Hi I discovered when I re-worked the SCReAM CC algorithm that I needed to rely on packets marked when I computed the fraction marked and thus the L4S alpha. The reason is that the tail RTP packet of a video frame (with the marker bit set) is likely smaller than the MTU. In some cases that tail packet was more frequently marked than the other packets. If I based L4S alpha on marked bytes, then the alpha became lower than expected so I ended up with using marked packets for the update of L4S alpha. The increase of the CWND is however based on unmarked vs marked bytes. I have not tried out how it works with unmarked vs marked packets.
/Ingemar From: Vidhi Goel <[email protected]> Sent: Tuesday, 21 November 2023 09:37 To: Christian Huitema <[email protected]> Cc: Marten Seemann <[email protected]>; Kazuho Oku <[email protected]>; Martin Thomson <[email protected]>; QUIC WG <[email protected]> Subject: Re: more accurate ECN feedback in ACK frames 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]<mailto:[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]<mailto:[email protected]>> wrote: 2023年11月4日(土) 4:06 Kazuho Oku <[email protected]<mailto:[email protected]>>: 2023年11月2日(木) 3:07 Martin Thomson <[email protected]<mailto:[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
