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
