From nobody Wed Sep 13 07:30:02 2023 Return-Path: X-Original-To: l4s-discuss@ietfa.amsl.com Delivered-To: l4s-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01BFC151542 for ; Wed, 13 Sep 2023 07:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmx.de Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3-7tr36kyPE for ; Wed, 13 Sep 2023 07:29:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFAABC14CF1C for ; Wed, 13 Sep 2023 07:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1694615395; x=1695220195; i=moeller0@gmx.de; bh=Q4Gj2LHQbmXnqHRLQTfPCg4Ok1LhvsceQy3SPdpk9vQ=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=PqC1pycTJ6LHKmzuTiT5MxCE+PPnkYhyUSjYURkdgFlNScbC7BzkJMhybzLv23US03XRfjigQxc 6nq8isJSRcrv4i9I/02AlRjeYnHc6ZhMfqspsQY4nPeuCGrWSzuf8Itp73Uq2O2xdxQT1t+rEcteF 4jkhXFMcs1J3m2PgHWI4xfCoymT1LQWhlkqudEUJxDYW5bqeLej+Lg6Kly1F1ecpt6aJK2/HZJMkm X3dgVUIxgjckrK5tuEvxND+vshPtL+NMhKHQH/xgn4SddLUqCltWsGO5pEzR/9FGTHn3lyCrrSiS5 edl7Xnu6yrZjNfWTFcuLyLdQFCILQmJxTL4w== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([77.0.223.134]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mf0BG-1rMfO50MHa-00gb0w; Wed, 13 Sep 2023 16:29:55 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) From: Sebastian Moeller In-Reply-To: <9a1f1e733e29f36149e64d20f1014e54@studenti.polito.it> Date: Wed, 13 Sep 2023 16:29:54 +0200 Cc: l4s-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4CBDA20F-4A7A-4AE8-A3C9-4CAEDC8BD19C@gmx.de> References: <181d20c79294d87ca7e3c4a398457cb2@studenti.polito.it> <6460de788e810fc720d196304e9cd228@studenti.polito.it> <8eea45b1cd4862fa731babeab073fc74@studenti.polito.it> <6E33F523-CDED-4145-A938-73F770A6B866@gmx.de> <9a1f1e733e29f36149e64d20f1014e54@studenti.polito.it> To: Matteo Guarna S303434 X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Provags-ID: V03:K1:JMzv93LuSoXrlu9Xvsmz+1ADHB9gnFmgBDOVpw6E+kRKqqr+LNC DtpZA1Rv3qMuYnOuc4YcqkFZz/HKWk/sb5ldL7B/FsNC612ljy1dVA4Gdq7tlO53s0+D9Il U4RmEUnKyGtt+ypEHwvLThKeHgtEQ0Pg4Um28xuwy+RcKDQCjvCH1ac3ZJGCFb+WQNzGXa+ 1sU7q1QWCMdkeyw+J4/rQ== UI-OutboundReport: notjunk:1;M01:P0:k8gOqh50zZQ=;g/zgUp8owiOk5S/KnQvoYBm+62D k4iQObw4uzI7jMQ/0Gmj5b3mjx7JM1CUl72tEBxnVEGv24XTrKSmTExnlUNzmI9ExCoXKkDlW /mpniKHyXXKpVitMQ8am3Q+ils4KKSdvKmelaktgS5ADgDYncB3xoA7Oklrt8DENNA8JPGsHn UrPzBfsE98k4LFCDF8NgPP/EKILxj7b0xAOb69naCbnjPi6W5SCN6Rt5UgUVBlXJePdXvpfaF vRF27ZayN2XDA8DEt/Fb0UsieFI3GJvBsssB2ZrLRTi+2uabdjiLVhiQNXlhWYlA0wbJb6TXW tX3HvMQUQnd1qfXN3AKd1PXt8SlvB1gGRqt0nyJTHu1vBAy2QDO01baIxFsQ7pN6WtoO+kyTG QiMPBVixegLNlSwyHo8k0lyfnutJFhfGVrvCYVdSPSxHrl2aPhADoSU6Vt9oBGyIZeCCLQzkb xARPu7Rqa0YAm03lvu7Izotaw5pDWbaw7M8SFahiG9lPZe3me0gI3z7FAZja+B4esZ0cp28T/ V2fA1ha5cG93N4z6XEAshwkq81fOX0NPssI7hGAMgsrZ2QsDkjFfAPn23tfKvpD4PrbT/bINO 4oqOWKZ/sHy/YdV5xANyYfVw6C4NcpFem6jQ/ewdyE8DkUPSE2hpfQimP8A8gkYHCa+5zah3g JMdRSvMYhKV1YG3WwaHVo/EQlXFrzLswQCdZaAejcLjcJrngqqLxU3FuojmBBLddfEEu/VxWv b0I8/2xJhNB/LS+aGIAPSYwgzFpoWJdqlNV//ZBNN7cGqWoNW18ZyWk7w7NaozkzwLjEU5sih rhoQ1lP5aCOqogTMiqTqemftqPqV3DYQQfKyEMNytyKMJtogpxwUZVbVYKHFaeWNsIXl83fDL 80nW0hePZFzpJtKi4L7f6QDx8ipKrJneME5NFXQQn0oIuRcQP5AWSoIKaSHw7pu/9t4/N0Gro K2sAMFloUYZMn6CIo4KiKSv9G8k= Archived-At: Subject: Re: [L4s-discuss] Irregularities in results from L4S testing X-BeenThere: l4s-discuss@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Low Latency, Low Loss, Scalable Throughput \(L4S\) " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2023 14:30:02 -0000 Hi Matteo, > On Sep 13, 2023, at 15:21, Matteo Guarna S303434 = wrote: >=20 > Hi Sebastian, > thanks again for the previous answer, and thank you the same in = advance for your assistance >=20 >> Hi Matteo, >>> On Sep 6, 2023, at 17:13, Koen De Schepper (Nokia) = 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). >=20 > [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. >=20 >>> 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. >=20 > [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=3D2" 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: >=20 > In line 11 of the initialization function (Figure 2), the maximum = Classic drop probability p_Cmax > =3D min(1/k^2, 1) or 1/4 for the default coupling factor k =3D 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).=20 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=3Ddocumented 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 >=20 > Matteo >=20 >=20 >> 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 >>> 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 >=20 > --=20 > L4s-discuss mailing list > L4s-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/l4s-discuss