From nobody Thu Sep 7 01:03:31 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 8D28DC14CE2C; Thu, 7 Sep 2023 01:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 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_MSPIKE_H3=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 m0XRzuMwl--B; Thu, 7 Sep 2023 01:03:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 2CAF6C151080; Thu, 7 Sep 2023 01:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1694073779; x=1694678579; i=moeller0@gmx.de; bh=4zAd5D+mx5q0yVRaE9KUcY2v8tcr1xj3ieMrxi/qEyQ=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=P9Ffy86mYAtQPzswdp+29Nz5YtkMnKMpnS3BUqNR+zztzw2xdQ7XJiaxGxm1TpEQtfgwC+V do1LybjgHvJfzAj3kD3okYMPc4GS5yrzj4wXS017YfdE/A1pe0AwoyVKBH14X7Q0psxkOiFqH ZirMP2m+CNeQy4azZ5nyLCAVMBFhVURCoWbktogcEZSv5yrSe2eArIZuHOkkfM3I4/+N90B0q MlKC8RiRR0kTjNcw7js+p+p6r8KQf61Kusa4Op9Zs3X2unhjXIy1SWJEQcMm53R85N5wIYspv /HdydN5C7iBEz/FelpmFI48asK241A0ysWkAQj3MjAMGI7BQrQYw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MacSY-1q3BGb0LDG-00cDhl; Thu, 07 Sep 2023 10:02:59 +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: Date: Thu, 7 Sep 2023 10:02:58 +0200 Cc: Matteo Guarna S303434 , "l4s-discuss@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6E33F523-CDED-4145-A938-73F770A6B866@gmx.de> References: <181d20c79294d87ca7e3c4a398457cb2@studenti.polito.it> <6460de788e810fc720d196304e9cd228@studenti.polito.it> <8eea45b1cd4862fa731babeab073fc74@studenti.polito.it> To: "Koen De Schepper (Nokia)" X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Provags-ID: V03:K1:AbNrGUzhhfsAI+6fZ8iyE2esIawAS1EgRCeTS5OWeUy7DM6I0PN KUwX3tRwOB+eGkSSM81fehC7Y1FSvI/LByGRnMdyWeZ4SIJTckWxCYzI3D47iOS8spiAyrA ZINTe02OVi003UjhK3dkebd3+JExFjhSMuqBQ8uMVsr68QBMbJu1qZeMBIF4ZSjMZZ1vbtt avsokksDIiVr7GIh8Pe4w== UI-OutboundReport: notjunk:1;M01:P0:TwKeEzoQIDI=;y+LJODP/xUTTbjItPtPWZScaNO8 TcG1Hq5wDhLR+YCxbF+NZ8ggy69w4pcywym7anE0Oo34JXid3IseqD0yl3a0gvhZXP4a5jBHw PT9Bsd55OBzACNveHoJdopbiqf72FpXsSVLRrtGbab6ZxiACyvut+eMcNpvj4vgOGfEj1uVZY Oj5gaM0sIVumTgN+YFrcWKrN18SIGADuyER6gB1HlB34tDfN1bSQr3pc2IUvFquawW7nMaEgb L0CJv/9nSIg7RHSWXcY3sPPKv+ua4zUNhkmtixB9HkGP1ZeuAluX6/LIGHb2SFsieop/O8HsH 1XRVRax7J+PZ8Wvz78SBmWkEZvJsxKiMaC5tWp7xV8JTP6FvsL9MK9oKjwVi4x/vf/DL6b/Mo KV3ZIeU5/ENdqdKi4nTEf+SJXRBuuVSBC4tIZ2p0U7pqITdYsB4BtvisZe+Jbzb9AQ8x5wXSE PI59IW5S7GncbVM/pfkDBlIkghR/SoOv9cxCB5aK9wWgW0vXEml+SXd9xyQiFmCTBCjCHbTpm c5zllgL1iWCZjk/SosWjPW7xW12hwWtjm/dgjIqFeRlxKjeulkd+kYD80tpwAavEcM6WO4Z6j BIJSar1v4hgbzEohpi66HWW/5M7uHhaBotZ2Fysm0hyKBO9PHdNeoMWPnxGuUATv15oIejjKv H0xYAtYICF92QXtPaPlZQbedRE/eWPghSXF9fFvoaP2Iho3TMnCJvO109gIsp1Z3SYviAZ5oc 4zQuND1Okum8LALJoCaREsyIuh/vAxVDV8+LOBtiA+kveva/qrObqbG5/yUqD3A/HBMLK2J43 ypgmQO8mUePcvSfM5uYtwXFnD69SEMtb41/2K6z5txWYbRh9/bAelO1dkenTglZgLqinxvH2W Q9zDFoHvh8NEl7AHlf36YSfqwW0CTkh5PKOeanfUmvzODvyeueqVLvMQQDwdau6yL+DO6jU2h /sKxPQ2StzAoHEyWo9jOMxeGXOs= 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: Thu, 07 Sep 2023 08:03:30 -0000 Hi Matteo, > On Sep 6, 2023, at 17:13, Koen De Schepper (Nokia) = wrote: >=20 > Hi Matteo, >=20 >>> 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. >=20 > 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. >=20 >>> 2 - Upon inspecting the packets to assess the correctness of the = protocol's behavior >=20 > 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. >=20 > Regards, > Koen. >=20 >=20 > -----Original Message----- > From: Matteo Guarna S303434 =20 > Sent: Tuesday, September 5, 2023 9:44 PM > To: l4s-discuss@ietf.org > Subject: [L4s-discuss] Irregularities in results from L4S testing >=20 > Greetings, >=20 > 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. >=20 > For the network configuration and host setup, I have utilized the = source code available at the following GitHub repository: >=20 > https://github.com/L4STeam/linux/tree/testing . >=20 > While my initial tests have been generally successful, I have = encountered two specific issues: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > I extend my sincere gratitude in advance to anyone who can provide = insights or assistance with these matters. >=20 > Best regards, >=20 > Matteo Guarna >=20 >=20 > P.s. >=20 > 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: >=20 > https://github.com/L4STeam/linux/issues/21 >=20 >=20 > --=20 > L4s-discuss mailing list > L4s-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/l4s-discuss