From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6C1E63CB37 for ; Wed, 22 May 2024 08:55:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1716382496; x=1716987296; i=moeller0@gmx.de; bh=wuIA0FSVnRVmXenl0wXvpU31o+DKsdWWGJuY9IIflZ8=; h=X-UI-Sender-Class:Content-Type:Mime-Version:Subject:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id: References:To:cc:content-transfer-encoding:content-type:date:from: message-id:mime-version:reply-to:subject:to; b=StIOmHcH6kTzOYKBAc86ak5W8i1nb++6irRasaK6ztriDR0qhIDjsxBzhmv2C8J+ QLMbA+dBASt18iLPRFjxdENkBva38017OeN+XEKKALSD63RRwSTAoQh6/TGH7AX5L wrKsHYio2XVkc1VUJw9tWWFn8u5cWMzJNF25dt+BepH0UD2p2Bzyfce3utfs2Zs44 9Y6k6ovFtROOK3qUirJcytN7n/vbrcLcopyfrkKB8ffG6wMrGMgosyiwzfnFl/9zs yieu5dbol/MG09Sus8/2i3+M/awTcBaZ0dnosCTeWfClsZtuhmj0u7LT6ppLYWXaf JRI5P4kOXnCrKBTJhg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N8XPn-1se4371kHZ-014WcR; Wed, 22 May 2024 14:54:56 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) From: Sebastian Moeller In-Reply-To: <1B7AD485-9CEA-4F79-B6F0-F2C1B0A9355D@comcast.com> Date: Wed, 22 May 2024 14:54:44 +0200 Cc: Jonathan Morton , Frantisek Borsik , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <94F193F2-1ECA-440D-9673-576E42C47ADE@gmx.de> References: <28C0EFA5-8681-41DB-AF49-E551D1AA2A0A@gmail.com> <02D6BB37-B944-478D-947F-E08EF77A7764@comcast.com> <1B7AD485-9CEA-4F79-B6F0-F2C1B0A9355D@comcast.com> To: "Livingood, Jason" X-Mailer: Apple Mail (2.3774.600.62) X-Provags-ID: V03:K1:KvPplSGiBgW7S3BOCvqTmxjGNpM28Uj+Eio3SLKd8gQvhOBwuTQ AfgcJcco4Md7B3f0P5m8/SjoTwLQakAI3XWww16THPr3H1DSzSqqsBpbD2VSfPtq8bmI7sz WOHvbSyYvnQ2P3ipg45lKdUbpRpxN2YLtX3mlpO+XJDxO/hugBkkMfiMD8LR/AMsJ3BBpPS wTskSPUHHgaO+5gyfofIQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:rtciywVU4Tw=;vZTzovZ/D+fa0cY+3rsf2MIxqrB Z+usU8zGjZ5zpDKk0Xv8p8s7dTqchb64hUyHkc3d77oXPm7drzjhivTYz/VS0WRwC2xYZRIPI 071odr7TqTHZdWZeCdb9M58vuOdixP/vlqUKN1x7eJtJgdj8Saj0jQM7yYp4s3hZQcrkIaPpk gZcom5RJ2sSG3k+eaYPepaDGq+Qi3y4hPN2aMqPfoID0YQl2JSNAlhCBqD1H4sNW96raxyFAh 2hbkACYzPQ8LO8m24ldsW5M6gIlThpyUPW3s+sqwvT3vGGv27zpU0g/BY3v+Kl+cO2tWSlgUL 3izWhEqQcq8t1bOsTPakfTJjBh1MpbzqwIXE20hVcLKDgNmp/3GYDptsxW6R5oSskA7whU1i5 9njhKEE+tasmVvCFNV1AE+qSXJx4JOEgOBtuT7AdurAECojkdkbfLj9h6huRSBreTCpbpMEu5 W187kOafCevBSNQt/zI1na1ppAcusIzGEtpqo6hH/Z2u3m4v4l9IFeUeiXfNnbFwm56EcAot1 Z5sO3aVlupDvMTyJLYjxaplkbZC+fGFYq2gwwH6lbZukDFzAvyX6cNYCm6fekI3GvXoDfBL6E cGEK/Rh0Vkwy2SNHN7sQLkmQQJ/gjErld8V4h0Ou8AVfrmgHGunDXHsm8KlwosWPLDri8z2LF o/16uV8HT1zQS1QZ+w/dArLk9guKWos26XnBLYUk/jwB7BKWW3hPZznKHy5igyALDKWpZM1B3 gN1vj5ZE/IZrC9fyfafiFQYAYhv1ih6wjFRLu1X04ITJZbGcGf3dgGbIuSkFQYkRxTsC32w7/ C4BcdVKQlf0uNN/anJYeBp0XuYkhvnlr/OqGRUd5HEDHY= Subject: Re: [Bloat] [EXTERNAL] "Very interesting L4S presentation from Nokia Bell Labs on tap for RIPE 88 in Krakow this week! " X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2024 12:55:01 -0000 Hi Jason > On 22. May 2024, at 14:27, Livingood, Jason = wrote: >=20 > [SM] Here is Pete's data showing that, the middle two bars show what = happens when the bottleneck is not treating TCP Prague to the expected = signalling... That is not really fit for use over the open internet... >=20 > [JL] That graph is not anything like what we=E2=80=99ve seen in lab or = field testing. I suspect you may have made some bad assumptions in the = simulation. So have you actually tested 1 TCP CUBIC versus 1 TCP Prague flow over a = FIFO bottleneck with 80ms minRTT? Then, I would appreciate if you could share that data. My best guess is, that you did not explicitly test that (*). I expect = almost all testing used short RTTs and likely the low latency docsis = scheduler/AQM combination (essentially an implementation close to = DualQ). But I am happy to be wrong. One of my complaints of the data presented in favor of L4S during the = ratification process was (and still is) that we got a multitude of very = similar tests all around locations n parameter space that were known to = work, while the amount od even mildly adversarial testing was miniscule. *) As Jonathan implied the issue might be TCP Prague"s pedigree from TCP = Reno mostly, as Reno and Cubic compete similarly unequal at 80ms RTT. To = which I asked, who came up with the idea of basing TCP Prague on Reno in = the first place? Changing that now, essentially will invalidate most = previous L4S testing. See above why I do not believe this to be a = terrible loss, but just procedurally I consider than not very impressive = engineering. That aside. if this explanation is correct, the only way = for you not having encountered that dutring your tests is by not = actually testing that condition. But that in turn makes waters down the = weight of the claim "not anything like what we=E2=80=99ve seen in lab or = field testing" considerably, no?