Yes, as Gorry notes below, the current CE counts are aligned with AccECN in TCP which should be sufficient for L4S. We didn't really have a use case that needed to know which packet was exactly marked. What are you using this information for?
Mirja On 02.11.23, 10:30, "QUIC on behalf of Gorry Fairhurst" <[email protected] <mailto:[email protected]> on behalf of [email protected] <mailto:[email protected]>> wrote: On 02/11/2023 02:06, Martin Thomson wrote: > 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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-20a83dbb1fa114dd&q=1&e=8edaae5a-d9a7-496c-b788-302eb79797c2&u=https%3A%2F%2Fgithub.com%2Fmarten-seemann%2Fdraft-seemann-quic-accurate-ack-ecn >> >> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-20a83dbb1fa114dd&q=1&e=8edaae5a-d9a7-496c-b788-302eb79797c2&u=https%3A%2F%2Fgithub.com%2Fmarten-seemann%2Fdraft-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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-bc6825591961722e&q=1&e=8edaae5a-d9a7-496c-b788-302eb79797c2&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F1372 >> >> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-bc6825591961722e&q=1&e=8edaae5a-d9a7-496c-b788-302eb79797c2&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F1372>, >> 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? On the history: The group of people who went away and thought about this, used AccECN (draft-ietf-tcpm-accurate-ecn-26) as the starting point, for what was then introduced into QUIC, it might be helpful to compare with that. Gorry
