Does a timestamp for a packet implicity ACK it

[siyengar]

In the ACK blocks we have a ACK block section and a Timestamp section. However there is not requirement that the TS be consistent with the ACK blocks. Should we consider the encoding of a packet (with its distance from largest acked), an implict ack for it. The nice thing about it is that the timestamp block is a much more efficient representation of single packets which are at a large gap away from other packets.

[ianswett]

I believe only the ack blocks ack packets. Otherwise we'll need special case behavior.

And I think the timestamp block is actually much less efficient, even for single packets, since it's a minimum of 3 bytes vs the smallest ack block size of 2 bytes.

[siyengar]

It's more efficient if you have a packet with a very large gap which you would need multiple ack blocks to represent

[ianswett]

Timestamps have to be within 255 packets of the largest acked, because there's only a byte to specify the delta from largest acked, so ack blocks can be used to represent much larger gaps than timestamps.

To come back to the first question, I don't think timestamps should be used to ack packets and I'd like to say that one MUST not specify timestamps that don't have corresponding ack blocks in the same ack frame. I'm not sure how many people would enforce that, but it is enforceable.

[mikkelfj]

to say that one MUST not specify timestamps that don't have corresponding ack blocks

This one is new to me - I was wondering and didn't find anything in spec a while back.
You might offload new timestamps in ack frame when running multiple ack frames because a single frame is insufficient.

Not arguing either way.

[ianswett]

Agreed, I think multiple ack frames should be acceptable and potentially could be critical for cases like connection migration.

[martinduke]

to say that one MUST not specify timestamps that don't have corresponding ack blocks

I actually would go the other way on this. If we are expected to send timestamps in most cases anyway, there is zero information added to also have a sack block for that data. If the ACK frame is lost, it's perfectly fine to later represent the receipt of that packet as an ack block.

But IMO receivers MUST interpret timestamps as an acknowledgement. Senders:

• MUST represent receipt of a packet as either a timestamp OR an ack block in a single ACK frame.
• SHOULD represent it as a timestamp when first attempting to ack the packet;

[martinduke]

@mnot Can we mark this for "needs discussion?" There are a lot of issues (which I need to write up) with norms and formatting for the ACK frame, but this fundamental issue is key to resolving those issues.

[janaiyengar]

@martinduke: I agree with you in theory that a timestamp semantically is an ack. That said, I can't see why a receiver would send a timestamp but not an ack for it -- that seems backwards. Timestamps are advisory in that they may or may not be received, and they tend to be sent just once.

Acks are the "primary" information here. It is much simpler to write out all the ack blocks and then fit all the timestamps you can within a frame, than to have rules that mix and match both. Making the receiver never send timestamps for packets that are not being acked in the frame makes it clear what the expected behavior is, and simplifies parsing the ack frame.

[martinduke]

I'm not suggesting that we get rid of ack blocks. But if recommend that people send timestamps once, making them also send an ack block in that frame is perverse. It is very easy for a receiver to cross off a packet if it sees either one. Making it check for both also makes things harder.

When the timestamp is lost, I am all for the retransmission including just ack blocks.

[ekr]

I agree with @martinduke that we should discuss this. I would prefer one of two choices:

• Merge them (so you only have to say it once)
• Make it impossible to say inconsistent things (e.g., by having an optional Timestamp attached to each ACK block that refers to the highest numbered ACK in each block or something)