Re: Proposal to replace ACK block count with ACK length

[Kazuho Oku <[e-mail]>]

2018-06-16 16:10 GMT+09:00 Christian Huitema <[e-mail]>:
> On 6/15/2018 6:57 PM, Kazuho Oku wrote:
>
>> And I think that the proposed change would be fine because it does not
>> necessary increase the size of the ACK frame, if we remove ACK Block
>> Count field in exchange.
> Ack block count is generally one byte, the length would have to be two
> bytes most of the time, especially if one wants to avoid 2 passes. So
> that's one extra byte.

I am not sure if that is true.

I think that it would be safe to assume that most of the blocks or
gaps will be smaller than 65. On a high bandwidth scenario, some of
the blocks could become bigger than that, but IIUC having many big
blocks with gaps within is unlikely.

Therefore, we can assume that an ACK Length field of one-octet can
hold up to nearly 30 pairs of blocks and gaps (whereas one-octet ACK
Block Count can hold up to 63).

I think that that would be enough. Or, I would argue that if we think
that having nearly 30 pairs is not enough, I wonder that 63 could be
not enough as well.

Besides, I would like to note also that you can implement
space-efficient one-pass encoding of an ACK frame even if we replace
the Block Count field with a variable-length ACK Length field. For
one-pass encoding, I'd assume that you retain the size of each block
(or gap) and update that as new frames arrive. What you would do is as
you update the size of the block (or gap), you update the expected
size of the ACK frame as well. The size increments by one when the
size of the block becomes greater than 63, or decrements by one when
the size of the gap becomes smaller than 64.

>> Instead of relying on the field, a receiver of the ACK frame can read
>> blocks until it consumes the number of bytes specified by the length
>> of the frame.
> Modulo handling of ECN counters, of course. In the ECN proposal, we have
> three varints at the end of the ack frame, and that would make parsing a
> variable number of ack blocks more interesting. So if we take the length
> proposal, we have to make sure that the ECN counters  get moved before
> the ack blocks.

Agreed.

> -- Christian Huitema
>
>



-- 
Kazuho Oku