Re: Adding ECN to Transport and Recovery

["Brian Trammell (IETF)" <[e-mail]>]

+1 to two frame types; IIRC the suggestion was to add ECN data to the "normal" ACK frame, then have a diminished ACK frame for situations where there is no ECN information to report. The concern here is that having an ACK and an ACK-ECN frame reinforces the incorrect idea that ECN is somehow optional to implement for QUIC, which it should not be.

Half-serious suggestions for the smaller ACK frame included SMACK (small ACK), SHACK (short ACK), or ACK-ICN (Implicit Congestion Notification).

Cheers,

Brian

> On 9 Jun 2018, at 02:36, Christian Huitema <[e-mail]> wrote:
> 
> On 6/8/2018 3:17 PM, Kazuho Oku wrote:
>> 2018-06-08 19:40 GMT+03:00 Ian Swett <ianswett=[e-mail]>
>> :
>> 
>>> As Dmitri said, the num blocks is currently a varint, it's not a single byte
>>> like it was in GQUIC, so stealing a bit from it is a bit awkward and would
>>> not change the limit on the number of ack blocks from 256 to 128, and
>>> instead it would decrease it from 2
>>> 62 to 261
>>> .
>>> 
>>> Can you make the least significant bit of the ACK frame type indicate
>>> whether the ECN section is present, such as by using the 0x0d and 0x0e code
>>> points?  This is basically equivalent to defining two types, admittedly, but
>>> by making the least significant bit the indicator, one could write up the
>>> text as a single frame if people prefer that.
>>> 
>> +1 to using different frame types. We do not want to introduce
>> complexity for conserving the frame types. That was the conclusion of
>> the extension discussion, wasn't it?
>> 
>> I would prefer having different frame types, unless we find a very
>> clean way of encoding ACK and ACK_ECN using a single frame type.
>> Stealing bits from a varint encoding is a haphazard approach that
>> comes with a complexity.
>> 
>> Personally, I doubt if we will ever run out of frames types,
>> considering how we have done so far with TLS ContentType and HTTP/2
>> frame type. And if we do run out, we have the luxury of renumbering
>> unlike TCP or TLS, because QUIC encrypts the frame types.
>> 
> 
> +1. It is much simpler to have two frame types. And in fact is would be better to not try to be too smart, Ian's suggestion of allocating two consecutive types differing by one bit is cute, but it will create incompatibility with the previous versions for which 0xE means "path challenge". Not a very big deal but still annoying, especially if one attempts to support multiple versions while testing the new one.
> 
> -- Christian Huitema