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

Hi Matteo,

> On Sep 5, 2023, at 21:44, Matteo Guarna S303434 <matteo.guarna@studenti.polito.it> wrote:
> 
> 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.

See https://github.com/heistp/l4s-tests sections network bias and RTT unfairness. At its heart the DualQ is a (weighted/conditional) priority scheduler with a default 10/1 weight for the L- over the C-queue, there exist realistic scenarios in which the heuristics L4S employs to deliver more equitable sharing break down and capacity sharing regresses closer to the underlaying priority ratio. The crux here is that while L4S argues that it is possible to disentangle latency priority and throughput priority, that is simply incorrect (if a packet is sent it will both consume a transmit opportunity/latency and it will also consume some amount of throughput*). During the IETF ratification process the argument was more or less: L-queue traffic does not fully starve C-queue traffic and that is enough. Attempts at getting an actionable definition of what kind of balance would need to be struck or even a numerical definition of starvation failed.

*) So some coupling/linkage is unavoidable, and you need to be careful when using a priority scheduler here, unless the higher priority class capacity usage is restraint somehow there will be scenarios with that class getting a higher capacity share than predicted/expected. See https://ieeexplore.ieee.org/document/9954450 for an alternative design in which the lower latency class gains its lower average latency by essentially dropping within its own class/capacity share, but that design works by not employing a fixed conditional priority scheduler between the classes and it is currently not aimed for scalable transports so is in no way a drop-in replacement "L4S-AQM".

> 
> 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.

	As said by others L4S uses a different CE feedback mechanism than rfc3168 ECN, instead of asserting ECE until a CWR is send back, AccECN will keep a count of received CE marks and will echo the current lowest three bits of this count back to the sender... even if up to 7? ACK packets are lost the sender will still get the correct CE count. Alternatively there is an AccECN TCP option that contains more precise/detailed ECN information. Not sure any OS out in the wild supports AccECN though.

> 
> 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
> L4s-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/l4s-discuss