Okay, yes that is addressed in AccECN with the Option that provided in addition the number of marked bytes and not only marked packets.
I don’t remember exactly why we decided for a packet count instead of a byte count but I guess it was seen as sufficient to assume equal or max sized packets. From: Marten Seemann <[email protected]> Date: Thursday, 2. November 2023 at 16:21 To: Mirja Kuehlewind <[email protected]> Cc: Gorry Fairhurst <[email protected]>, Martin Thomson <[email protected]>, QUIC WG <[email protected]> Subject: Re: more accurate ECN feedback in ACK frames 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]<mailto:[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]> <mailto:[email protected]<mailto:[email protected]>> on behalf of [email protected]<mailto:[email protected]> <mailto:[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
