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

[Matteo Guarna S303434 <[e-mail]>]

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.

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


Grateful for your willingness

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