> In fact, I am not sure that there is much of a performance gain if the node > is using L4S. L4S tracks the state of the path by computing a rolling ratio > "alpha" of packets marked with CE vs total number of packets acknowledged. > Without the "ECN fidelity" improvement, that ratio is computed with a weight > of 1 per packet. With the improvement, the weight of a packet is set to the > number of bytes sent in the packet. The theoretical foundations for that are > weak, because it is unclear whether the CE marking strategy of routers is > based on bytes or packets. It is also unclear whether the two ways of > computing that ratio provide significant differences in practice.
The problem wasn’t the ratio of packets vs bytes. It was really when an ACK arrives that acknowledges a mix of CE and non CE packets, then while the CE marked packets will contribute to rolling alpha but the non CE marked packets must be used to increase the cwnd. And to do that, you’d want to know how many bytes do the non CE marked packets represent. I don’t think we can make an approximation here. > Then there is the fact that many CC algorithms do not actually use L4S > strategy of making CWIN increases proportional to the number of CE marking. > BBR, for example, will tune the sending rate based on observed data rates, > and will just use the arrival of "more than usual" CE marks as a signal to > slow down. When you say many CC algorithms don’t use L4S strategy, it might be true today and that would mean those CCAs are not ready for L4S networks. In fact, there was a modification made to BBR in Linux to make it L4S compliant by adding DCTCP.alpha to it. Here is the code - https://github.com/L4STeam/linux/blob/testing/net/ipv4/tcp_bbr2.c#L1389. > And finally there is the issue that ECN is not an "honest signal", in the > sense that it is pretty easy for networks to "fake it", either in some > misguided effort at traffic engineering, or simply because of bugs. That much > easier than faking transmission delays or transmission rates, and less costly > for the network's reputation than just dropping packets. Is this your opinion or do you have evidence that any network is actually faking ECN (CE)? Nonetheless, this kind of faking shouldn’t be taken lightly and ECN MUST be an “honest signal”. We constantly work with vendors, network providers to fix any ECN issue. Thanks, Vidhi > On Nov 17, 2023, at 10:48 PM, Christian Huitema <[email protected]> wrote: > > Having a draft is good, but we are obviously facing a tradeoff: more precise > ECN feedback may improve the performance of the L4S congestion control, but > increasing the fidelity of ECN reporting increases the size of the ACKs and > thus affects performance overall. > > In fact, I am not sure that there is much of a performance gain if the node > is using L4S. L4S tracks the state of the path by computing a rolling ratio > "alpha" of packets marked with CE vs total number of packets acknowledged. > Without the "ECN fidelity" improvement, that ratio is computed with a weight > of 1 per packet. With the improvement, the weight of a packet is set to the > number of bytes sent in the packet. The theoretical foundations for that are > weak, because it is unclear whether the CE marking strategy of routers is > based on bytes or packets. It is also unclear whether the two ways of > computing that ratio provide significant differences in practice. > > Then there is the fact that many CC algorithms do not actually use L4S > strategy of making CWIN increases proportional to the number of CE marking. > BBR, for example, will tune the sending rate based on observed data rates, > and will just use the arrival of "more than usual" CE marks as a signal to > slow down. > > And finally there is the issue that ECN is not an "honest signal", in the > sense that it is pretty easy for networks to "fake it", either in some > misguided effort at traffic engineering, or simply because of bugs. That much > easier than faking transmission delays or transmission rates, and less costly > for the network's reputation than just dropping packets. > > But if you want to experiment with variations of ECN, then yes having a draft > and an extension code point is a very good idea. > > -- Christian Huitema > > On 11/17/2023 9:16 PM, Marten Seemann wrote: >> Quick update: I just published the draft ( >> https://datatracker.ietf.org/doc/draft-seemann-quic-accurate-ack-ecn/). >> Thanks to Vidhi for a lot of clarifying text and an encoding example! >> On Sat, 4 Nov 2023 at 10:08, Kazuho Oku <[email protected]> wrote: >>> >>> >>> 2023年11月4日(土) 4:06 Kazuho Oku <[email protected]>: >>> >>>> >>>> >>>> 2023年11月2日(木) 3:07 Martin Thomson <[email protected]>: >>>> >>>>> 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. >>>>> >>>> >>>> FYI we discussed alternative encoding schemes at the interim in Sep 2018: >>>> * slides: file:///Users/kazuho/Downloads/ack-ecn.pdf >>>> >>> >>> Agh. Only I can see this URL, the correct one is >>> https://github.com/quicwg/wg-materials/blob/master/interim-18-09/ack-ecn.pdf >>> >>> >>>> * notes: >>>> https://github.com/quicwg/wg-materials/blob/main/interim-18-09/minutes.md#ack-ecn---ian >>>> >>>> >>>>> (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? >>>>> >>>>> >>>> >>>> -- >>>> Kazuho Oku >>>> >>> >>> >>> -- >>> Kazuho Oku >>> >
