Re: Adding ECN to Transport and Recovery

[Christian Huitema <[e-mail]>]

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 2^61.
>>
>> 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