In the current definition of Prague CC: 1. AI is currently based on the number of acknowledged minus the number of ECN-marked bytes. Unless all packets had the same size, you don't know the correct number of bytes. 2. When you receive an ACK frame that acknowledges a number of packets and also contains an ECN marking, it's unclear if you should do the AI or the MD first.
See also the discussion I started on the ICCRG mailing list. At this point, I'm not sure how much these two issues matter in practice, but it might be interesting to experiment with a more precise feedback mechanism. On Thu, 2 Nov 2023 at 17:07, Mirja Kuehlewind <[email protected]> wrote: > 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 > > > >
