Re: Adding ECN to Transport and Recovery

[Kazuho Oku <[e-mail]>]

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.

>
> On Fri, Jun 8, 2018 at 11:08 AM Dmitri Tikhonov
> <[e-mail]> wrote:
>>
>> 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.
>>
>



-- 
Kazuho Oku