Encoding of blocksize in ACK frames.

[huitema]

The text that describe the encoding of block lengths in the ACK frames is a bit too smart for my test. It reads:

First ACK Block Length:

: An unsigned packet number delta that indicates the number of contiguous additional packets being
acknowledged starting at the Largest Acknowledged.

If I look at it with attention, I understand it to mean "the number of continuous packet being acknowledged, not counting the Largest Acknowledged."

Is this correct? Does highest=5, length=2 means "Acknowledging packets 5, 4 and 3", not just "5 and 4"? If yes, some more direct language would be nice.

[MikeBishop]

That's how I read it, yes -- as "additional" packets. Otherwise zero would be a nonsensical value.

[martinthomson]

I had the same reading of this as both of you. However, if we want to allow a larger gap, then having zero length on subsequent ACK blocks might have some utility and consistency with that is perhaps desirable.

[larseggert]

Understood it this way, too, but had to re-read the sentence a few times. Suggest to add @huitema's example to the draft?

[igorlord]

Does Gap = 0 ever make sense? I do not think so.
We could do one of two things:

1. Define the actual gap to be Gap+1 (and keep the semantics of "ACK Block Length" unchanged), or

2. If Gap=0, the following (("ACK Block Length" << 8) | "Following Gap") actually defines the length of the gap. In this case, the semantics of the regular "ACK Block Length" can be made to match "First ACK Block Length", and chances are excellent that multiple ACK frames will not be needed.

Option 2 has a few special cases in it: (a) If "ACK Block Length" is 64 bit, (("ACK Block Length" << 8) | "Following Gap") is too large; (b) the last Gap=0 still does not make sense (unless someone is willing to assign semantics to it).

[ianswett]

I think this is closed by #877