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

Hi Matteo,

> On Sep 6, 2023, at 17:13, Koen De Schepper (Nokia) <koen.de_schepper=40nokia-bell-labs.com@dmarc.ietf.org> 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).

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

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 <matteo.guarna@studenti.polito.it> 
> Sent: Tuesday, September 5, 2023 9:44 PM
> To: l4s-discuss@ietf.org
> 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
> L4s-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/l4s-discuss