When I started working on L4S a few years ago, I had raised this question about why packet count instead of bytes. But I realized that packet count is more appropriate given that network marks packets and not bytes.
But at the host, we can keep track of per packet state (including packet length) and if ACK provided the fine-grained info about which packets it was ACKing with a certain ECN code point, then we have everything to do fine-grained calculations at hosts (whether they do packet based or byte based cwnd). So, Marten’s draft is in the right direction and hopefully we can work on that speedily. Vidhi > On Nov 2, 2023, at 10:08 AM, Mirja Kuehlewind > <[email protected]> wrote: > > 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] > <mailto:[email protected]>> > Date: Thursday, 2. November 2023 at 16:21 > To: Mirja Kuehlewind <[email protected] > <mailto:[email protected]>> > Cc: Gorry Fairhurst <[email protected] <mailto:[email protected]>>, > Martin Thomson <[email protected] <mailto:[email protected]>>, QUIC WG > <[email protected] <mailto:[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 >>
