Re: [L4s-discuss] Irregularities in results from L4S testing

[Sebastian Moeller <[e-mail]>]

Hi Matteo,


> On Sep 13, 2023, at 15:21, Matteo Guarna S303434 <[e-mail]> wrote:
> 
> Hi Sebastian,
> thanks again for the previous answer, and thank you the same in advance for your assistance
> 
>> Hi Matteo,
>>> On Sep 6, 2023, at 17:13, Koen De Schepper (Nokia) <koen.de_schepper=[e-mail]> wrote:
>>> Hi Matteo,
>>>>> 1 - The TCP-Prague and TCP-Cubic flows do not seem to equitably share available bandwidth. In some cases, TCP-Prague appears to consume up to two/thirds of the channel's capacity.
>>> We do not expect exact equal throughput, which is also not possible with current Classic congestion controls, at least assuming the NW does not identify the different application flows. There are known and explainable/accepted
>> 	[SM] I will note, that "acceptable" needs to be qualified. ATM only
>> the designers of L4S and the majority of (self-selected) members of
>> the IETF's TSV working group consciously accepted that trade-off, that
>> is by all means not an unbiased sample (and also not a representative
>> sample of any meaningful internet-wide group)... "explainable" I
>> agree, but "accepted" I object to, these should be fixed in the L4S
>> design given that we know where the failures come from (partly as part
>> of the AQM specification, partly as part of the protocol
>> specification).
> 
>          [MG] I would like to know if you're aware of any official document raising this problem, as I couldn't find anything myself.

	[SM] During the rather long ratification process of the L4S RFCs Pete Heist ran a number of relative simple tests against the reference implementation revealing a number of "open issues":
https://github.com/heistp/l4s-tests
as well as a few comparisons between L4S and an alternative proposal SCE:
https://github.com/heistp/sce-l4s-ect1
https://github.com/heistp/sce-l4s-bakeoff

Not sure whether this is official enough for your purposes or not.



> 
>>> deviations from the exact equal rates as well in L4S-only combinations, as in Classic-only combinations and by consequence also in a combination of both. The goal is to make flows share the capacity good enough, so that a user's applications don't get denied service when sharing a common bottleneck.
>> 	[SM] Again I note that "denied service" was never defined
>> numerically, making it rather hard to assess what constitutes "good
>> enough". That said, I principally agree that there needs to be some
>> level of slack, and I would argue that something like "random ratios
>> in the range of 1:4 to 4:1" are good enough, that is allow some
>> deviation UNLESS that deviation is systemically biased to one of the
>> classes under analysis.
> 
>          [MG] Here I also wonder if this is only an educated guess or if it may have something to do with the "k" coupling parameter set by default to "k=2" in the Dual-Queue algorithm in order to preserve the fairness between classic and L4S traffic. As in the RFC 9332 ( https://datatracker.ietf.org/doc/html/rfc9332 ), in the appendix A it's in fact stated:
> 
> In line 11 of the initialization function (Figure 2), the maximum Classic drop probability p_Cmax
> = min(1/k^2, 1) or 1/4 for the default coupling factor k = 2. In practice, 25% has been found to be a
> good threshold to preserve fairness between ECN-capable and non-ECN-capable trafc. This
> protects the queues against both temporary overload from responsive fows and more persistent
> overload from any unresponsive trafc that falsely claims to be responsive to ECN.

	[SM] My take on this is, the whole coupling issues really is just a heuristic that operates on top of a weighted priority scheduler weighted heavily in favor of the L-queue (C/L ~1/10). Whenever the heuristics fail to trigger we regress back to the known behaviour of a priority scheduler with the given set of weights. The problem is illustrated by thinking through what happens if you put an adversarial under-responsive flow into the L-queue. If that flow stays below the 1/10 C/L capacity share (so below 90% of capacity) and is sufficiently well paced and carries ECT(1) it will end up hogging all the capacity it desires... at the expense of traffic in the C-queue. Given today's access rates (in the 1 Gbps+ range) such a scenario is not unlikely, think a flow from a 1 Gbps ethernet host over a 1.5 Gbps PON/DOCSIS link with an L4S AQM, due to the ethernet limit such a flow will never exceed the 90% of 1.5 Gbps, it will however leave precious little capacity for the rest of the L-queue and C-queue traffic. L4S only remedy here is the purely optional queue protection, that alas has not been properly tested, also it scores flows based on how much queueing they cause and the better paced a flow is the less it contributes to queueing (but it will also scale with throughput a bit). 
	Now, it might be possible that playing with the coupling factor can change this to some degree, but I am not convinced that this actually tackles the root cause.

> Grateful for your willingness

	[SM] Always happy to help; just to be clear though, I was (and still am) of the opinion that the IETF should not have ratified the L4S drafts before the c=documented issues had been fixed sufficiently well. I generally agree that higher temporal-fidelity congestion feed-back is a good thing, but I am convinced L4S is "too little, too late".

Regards
	Sebastian


> 
> Matteo
> 
> 
>> Regards
>> 	Sebastian
>>> The main goal of L4S on top of this is to make sure that applications get as low as possible latency and as smooth as possible throughput while competing for that share.
>>> These latter objectives are much more important than throughput for interactive applications.
>>> Due to this lower latency the effective Prague RTTs are much smaller, potentially giving large benefits to Prague flows in NWs that have a small base (unloaded) RTT. The RTT-independent Prague requirement l
>>> argely fixes this for most low base RTT cases.
>>>>> 2 - Upon inspecting the packets to assess the correctness of the protocol's behavior
>>> As Vidhi already commented, this is due to the changed TCP-ECN echo protocol called accurate ECN. As this is a 3 bit running number, any of those 3 bits are expected to be 50% on and off, which your 5/9th ratio is as expected very close to.
>>> Regards,
>>> Koen.
>>> -----Original Message-----
>>> From: Matteo Guarna S303434 <[e-mail]>
>>> Sent: Tuesday, September 5, 2023 9:44 PM
>>> To: [e-mail]
>>> Subject: [L4s-discuss] Irregularities in results from L4S testing
>>> Greetings,
>>> I am currently conducting research for my thesis on the L4S suite. As part of my research, I have deployed a simple testbed to examine the behavior of a TCP-Prague data flow when deployed in conjunction with a TCP-Cubic flow on a congested, L4S-capable network link.
>>> For the network configuration and host setup, I have utilized the source code available at the following GitHub repository:
>>> https://github.com/L4STeam/linux/tree/testing .
>>> While my initial tests have been generally successful, I have encountered two specific issues:
>>> 1 - The TCP-Prague and TCP-Cubic flows do not seem to equitably share available bandwidth. In some cases, TCP-Prague appears to consume up to two/thirds of the channel's capacity.
>>> 2 - Upon inspecting the packets to assess the correctness of the protocol's behavior, I observed that the proportion of TCP-Prague ACK packets with the TCP ECE (Explicit Congestion Notification Echo) flag is approximately 5/9 of the total ACK packets, while the percentage of transmitted packets marked by the queue remains consistently at around 8%. While I did not anticipate a strict 1:1 ratio, this result still strikes me as peculiar.
>>> Additionally, I noted that all TCP-Prague packets inherently carry the CWR (Congestion Window Reduced) flag by default. It appears to me (if I'm not mistaken) to be an intentional implementation choice by the developers, as detailed in the source code found at https://github.com/L4STeam/linux/blob/testing/net/ipv4/tcp_prague.c , specifically beginning at line 53. I would appreciate confirmation regarding this implementation choice and assurance that it does not adversely impact its compliance with the standard.
>>> I extend my sincere gratitude in advance to anyone who can provide insights or assistance with these matters.
>>> Best regards,
>>> Matteo Guarna
>>> P.s.
>>> I someone wants a more detailed insight regarding my testplant and my results, I had tried to ask for help by opening an issue on the repository's github, where I provided a more in-depth description of my experiment. The conversation is available here:
>>> https://github.com/L4STeam/linux/issues/21
>>> --
>>> L4s-discuss mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/l4s-discuss
> 
> -- 
> L4s-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/l4s-discuss