Re: Adding ECN to Transport and Recovery

[Dmitri Tikhonov <[e-mail]>]

On Fri, Jun 08, 2018 at 04:51:36PM +0200, Magnus Westerlund wrote:
> My understanding of the views at the interim was that eliminating the
> additional ACK_ECN frame was desired.

That is my understanding as well.

> I will next update the pull request to use an updated ACK frame with a
> signaling bit for the present or absence of the ECN counters. The plan
> is to steal a bit in the ACK Block count and make that into a fixed
> 7-bit field rather than a variable length encoding.  Limiting an ACK
> Frame to 128 ACK blocks.

Even though I don't have strong feelings about this, I wonder if there
is another way.  The ACK frame (Section 7.15 of
[draft-ietf-quic-transport-12]) is all varints.  Changing a field to a
fixed encoding would go against the "flavor of the frame," if one may
say so.  Perhaps we could keep the varint encoding and interpret the
decoded value as an ORed block count with the ECN bit (the low bit)?

Introducing an artifial limit to where there was none is a separate
discussion.  Perhaps 128 blocks is really enough for all practical
purposes.  And yet: at some point the block limit was removed as we
went from gQUIC to IETF QUIC...

  - Dmitri.