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.
(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?
