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