Quick update: I just published the draft ( https://datatracker.ietf.org/doc/draft-seemann-quic-accurate-ack-ecn/). Thanks to Vidhi for a lot of clarifying text and an encoding example!
On Sat, 4 Nov 2023 at 10:08, Kazuho Oku <[email protected]> wrote: > > > 2023年11月4日(土) 4:06 Kazuho Oku <[email protected]>: > >> >> >> 2023年11月2日(木) 3:07 Martin Thomson <[email protected]>: >> >>> We knew that L4S was likely to come around and use markings more. What >>> we didn't know was exactly how that would end up looking, so I believe that >>> the idea was to do exactly what you are proposing: deal with it in an >>> extension, later. What we have works with what you call classic ECN, >>> OGECN, but just like fine-grained timing information, we decided to defer. >>> >> >> FYI we discussed alternative encoding schemes at the interim in Sep 2018: >> * slides: file:///Users/kazuho/Downloads/ack-ecn.pdf >> > > Agh. Only I can see this URL, the correct one is > https://github.com/quicwg/wg-materials/blob/master/interim-18-09/ack-ecn.pdf > > >> * notes: >> https://github.com/quicwg/wg-materials/blob/main/interim-18-09/minutes.md#ack-ecn---ian >> >> >>> (That's my memory only, I don't think that I was involved in the design >>> team directly.) >>> >>> On Wed, Nov 1, 2023, at 21:38, Marten Seemann wrote: >>> > While looking at Prague CC / L4S, I noticed that it might be useful if >>> > the sender could know which packet was CE-marked. This is currently >>> not >>> > possible with the ACK frame defined in RFC 9000, as it only contains >>> > cumulative ECN counts. >>> > >>> > Instead of including cumulative counters at the end of the ACK frame, >>> > we could have encoded the ECN markings alongside the ACK ranges. This >>> > would lead to ACK frames with more ACK ranges when a lot of packets >>> are >>> > received alternating ECN markings. However, in the steady state of >>> L4S, >>> > 2 packets per RTT are expected to be CE-marked, so the overhead would >>> > be negligible. >>> > >>> > I wrote up an alternative encoding scheme in >>> > https://github.com/marten-seemann/draft-seemann-quic-accurate-ack-ecn >>> > (I currently can't submit it as a draft, since the datatracker doesn’t >>> > allow new submissions past the deadline for 118). ECN counts were >>> > introduced in https://github.com/quicwg/base-drafts/pull/1372, based >>> on >>> > the output of a design team. Why did we decide to introduce these >>> > counters, instead of explicitly encoding the ECN marking for every >>> > packet? Is it because that's all we needed back then for classic ECN >>> > support? >>> >>> >> >> -- >> Kazuho Oku >> > > > -- > Kazuho Oku >
