Re: Adding ECN to Transport and Recovery

[Ian Swett <[e-mail]>]

QUIC is complex enough, I think we should just call them ACK and ACK_ECN.
A few implementations sending at least one ACK_ECN frame per connection
will dispel any belief that ACK_ECN is optional.  A small amount of use
will be a lot more valuable than clever naming.

On Sat, Jun 9, 2018 at 7:25 AM Brian Trammell (IETF) <[e-mail]>
wrote:

> +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
>
>