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 5AC023B2A4 for ; Wed, 22 May 2024 01:40:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1716356442; x=1716961242; i=moeller0@gmx.de; bh=UGJyp4QLT9QG9RalimuHD4aWHZix6K7klKEVvrBMgyI=; h=X-UI-Sender-Class:From:Content-Type:Mime-Version:Subject: Message-Id:References:To:Date:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=ONgWrnO9t7NeTT18DmXnB3Ss1TKQouVnsSOvUcnlioF0BUDL4yoa7Zhchh1jh8+7 xMCQxtYgjyztN8FP4eeHsNo/uTNehmHrxXmu1VEF2pjOji5/RzQWqZAv5gT9jLYet BDcjCVlt+1Ou2S1fyoil9yPsrQ/Wo87zKqU5wp1VBcxqIp9/gVId2EHqdfRf30QsT qeDTP+SLhTKyTX+M/taluM6OIrAa/fF+Tmtw9+Ze+pYmD5A07Po+j3uvpP1mRDhIw 24JDX2cA3iDM0M9UIJu512GPChoRF6lRrKSOvNzDQ6yiydNLBdrWHpOzUjhSF5o9V u0GVkt3vE6khWLW+pQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([95.119.211.13]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MRTRH-1rvA683ke5-00OTOa for ; Wed, 22 May 2024 07:40:42 +0200 From: Sebastian Moeller Content-Type: multipart/alternative; boundary="Apple-Mail=_02376193-03B6-4A1C-BA70-66D9D46B05D5" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Message-Id: <0F222476-EB44-45E9-93C5-2E595AE08C09@gmx.de> References: To: bloat Date: Wed, 22 May 2024 07:40:31 +0200 X-Mailer: Apple Mail (2.3774.600.62) X-Provags-ID: V03:K1:9G5e2F/q7rJdqRx3PcTBV332vIQbHcTPh76hj+D55tIENxBYLYb JlYjg/iC+8PFPl27ayWjBYKeL37jBNr+xqkgBHvMgFWP3GsYiMXzY5Gjj1TIpPYRueOp+mR YwiXei0BxPrgiCBWLqnUXblb9TKjzx+ElenXyLVxFalaERhmNuIGHlNPyVhtQlZYXdb4ndT MHAuGaIeuzEHN3VuAFIKA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:lzBjjOyJA2Y=;3pklR5HkSmTg7fn+ba25mgNPjzn uZtTT8mGcxM+nt19JGedJF/FPotFj9lD8zO6OhBG0JpHrdJ1BFcfsC9nlj6l56bz9kb3Tt789 mAAsY2AcIcruHwKQEF6w8Hi6atfElf+Nf4GlnmBMJ2Mejwnh+tUL+knMIT4h0/hiPrd04s0og LGZfyo+VpaX20LDhKn1wSlDuE5/E85DmEBgZdoJB55j4DSRN8/5kXhuFa8iiUhzeoGIvm1uUe six2cFfRilcDuOAVU7PFtFJ5WDmTQVHNdLtT9nHSOnjCH2hhn9zH4jMSAj6+ebM+m9/+i7O17 4jFGCEGGeWuLxBAKPiyevN3P4aJCfs6kJg0lRwFgUfW+CslnEwM7oWOCYEx0tpC9JJDQZzM/k w+eAGBvtuLOs64FSwC5pclMJwXZ9X9y9i50sX588uoDa5D4WTcJ1msn2t/Ka4lyAy1KbE0DsI R4KO96E/O4xziXtOhrDRT6FZ5pi8O2bIZPI9B8QAjtZBftWjmUxPN6F2TtxS5rZOIhuLhtfFz gvNSKd7jIVb8vSRD60NoWABvi6akYIG94+duKzHF4uLAavpv6D/cqdH2gO4O4CMDXwXx9CI5m pM8a7LKTft/YfnM1rdXWDxFJehHD9OQIckWrdPbZ/PeA7MAiY/7k4YIVtGaxcpjtFA7GDcToK c6mtjNHJNZg455+vMuz5Gn3rS5a2z8CkT2WOcsq9KtEq3x1Qhoy3E7uUWQzfdMkHNx5n7hEsd s9ULUVJNNt4H0Inf5ZAkwjYwBuF7Cq1gsw7l+9uBmHokMlF9yTEObyJOWNxoL5beBgNyRPCNG S4b06uF/TT1zfYdETI8gb6FsYnSLkTRlEsVSU4fI6gsOM= Subject: [Bloat] Fwd: "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 05:40:44 -0000 --Apple-Mail=_02376193-03B6-4A1C-BA70-66D9D46B05D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear All, since my attached image did not seem to make it to the list (thanks = Frantisek for letting me know) here a link to the image: h++ps = ://camo.githubusercontent.com/bbbcbf00baa8455073b8a9676d0a6d46a7aee25c7e= 456a44ad51b64abb30db5a/687474703a2f2f7363652e646e736d67722e6e65742f7265737= 56c74732f6c34732d323032302d31312d3131543132303030302d66696e616c2f73312d636= 8617274732f727474666169725f63635f71646973635f38306d735f38306d732e737667 Due my mail agents outgoing SPAM marking I need to replace the 't' in = the URL with + signs.... The point remains, TCP Prague does not gracefully compete with Cubic in = a FIFO bottleneck, and given that many bottlenecks are still FIFOs that = does not bode well for TCP Prague. It is unclear whether that is simply = a bug/misfeature in Prague or whether that is a consequence of L4S = signalling. IMHO the IETF has done the internet a disservice to ratify = the L4S RFC before making sure that everything works as expected. The whole L4S ratification process disillusioned me about the IETF in = general and TSVWG specifically. I understand and accept that = horse-trading is unavoidable when groups of humans cooperate, but in the = IETF the gap between the 'no politics' motto and the amount of = horse-trading that actually happens is breathtaking... Exemplified by the fact that nobody seems to bother that chairs and ADs = are not even trying to be impartial, but pretend they can separate = themselves out into a 'chair' and a 'non-chair' persona... And the fact = that WG members see no harm in having private only strategy discussions = with chairs and ADs. I am not saying that these things are necessarily = below the board, but there clearly is plenty of opportunity. But enough of that. My=20 > Begin forwarded message: >=20 > From: Sebastian Moeller via Bloat > Subject: Re: [Bloat] "Very interesting L4S presentation from Nokia = Bell Labs on tap for RIPE 88 in Krakow this week! " > Date: 21. May 2024 at 19:32:47 CEST > To: "Livingood, Jason" > Cc: Jonathan Morton , bloat = > Reply-To: Sebastian Moeller >=20 > Hi Jason, >=20 >=20 >> On 21. May 2024, at 19:13, Livingood, Jason via Bloat = wrote: >>=20 >> On 5/21/24, 12:19, "Bloat on behalf of Jonathan Morton via Bloat = wrote: >>=20 >>> Notice in particular that the only *performance* comparisons they = make are between L4S and no AQM at all, not between L4S and conventional = AQM - even though they now mention that the latter *exists*. >>=20 >> I cannot speak to the Nokia deck. But in our field trials we have = certainly compared single queue AQM to L4S, and L4S flows perform = better.=20 >>=20 >>> There's also no mention whatsoever of what happens when L4S traffic = meets a conventional AQM. >>=20 >> We also tested this and all is well; the performance of classic queue = with AQM is fine. >=20 > [SM] I think you are thinking of a different case than Jonathan, not = classic traffic in the C-queue, but L4S traffic (ECT(1)) that by chance = is not hiting abottleneck employing DualQ but the traditional FIFO... > This is the case where at least TCP Prague just folds it, gives up and = goes home... >=20 > 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... =EF=BF=BC >=20 > That is not really fit for use over the open internet... >=20 > Regards > Sebastian >=20 >=20 >=20 >>=20 >> Jason >>=20 >>=20 >>=20 >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --Apple-Mail=_02376193-03B6-4A1C-BA70-66D9D46B05D5 Content-Type: multipart/mixed; boundary="Apple-Mail=_24E62821-58DE-4B1C-8993-77271EC67391" --Apple-Mail=_24E62821-58DE-4B1C-8993-77271EC67391 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = All,

since my attached image did not seem to make it = to the list (thanks Frantisek for letting me know) here a link to the = image:
h++ps://camo.githubusercontent.com/bbbcbf00baa8455073b8a9676d0a6d46a7aee25= c7e456a44ad51b64abb30db5a/687474703a2f2f7363652e646e736d67722e6e65742f7265= 73756c74732f6c34732d323032302d31312d3131543132303030302d66696e616c2f73312d= 6368617274732f727474666169725f63635f71646973635f38306d735f38306d732e737667=
Due my mail agents outgoing SPAM marking I need to replace the = 't' in the URL with + signs....

The point = remains, TCP Prague does not gracefully compete with Cubic in a FIFO = bottleneck, and given that many bottlenecks are still FIFOs that does = not bode well for TCP Prague. It is unclear whether that is simply a = bug/misfeature in Prague or whether that is a consequence of L4S = signalling. IMHO the IETF has done the internet a disservice to ratify = the L4S RFC before making sure that everything works as = expected.

The whole L4S ratification process = disillusioned me about the IETF in general and TSVWG specifically. I = understand and accept that horse-trading is unavoidable when groups of = humans cooperate, but in the IETF the gap between the 'no politics' = motto and the amount of horse-trading that actually happens is = breathtaking...
Exemplified by the fact that nobody seems to = bother that chairs and ADs are not even trying to be impartial, but = pretend they can separate themselves out into a 'chair' and a = 'non-chair' persona... And the fact that WG members see no harm in = having private only strategy discussions with chairs and ADs. I am not = saying that these things are necessarily below the board, but there = clearly is plenty of opportunity.
But enough of = that.


My 



Begin forwarded = message:

From: Sebastian = Moeller via Bloat = <bloat@lists.bufferbloat.net>
Subject: Re: = [Bloat] "Very interesting L4S presentation from Nokia Bell Labs on tap = for RIPE 88 in Krakow this week! "
Date: 21. May = 2024 at 19:32:47 CEST
To: "Livingood, Jason" = <jason_livingood@comcast.com>
Cc: = Jonathan Morton = <chromatix99@gmail.com>, bloat = <bloat@lists.bufferbloat.net>
Reply-To: Sebastian = Moeller <moeller0@gmx.de>

Hi Jason,


On 21. May 2024, at 19:13, Livingood, Jason via Bloat = <bloat@lists.bufferbloat.net> wrote:

On 5/21/24, 12:19, = "Bloat on behalf of Jonathan Morton via Bloat wrote:

Notice in particular that the only *performance* = comparisons they make are between L4S and no AQM at all, not between L4S = and conventional AQM - even though they now mention that the latter = *exists*.

I cannot speak to the Nokia deck. But in = our field trials we have certainly compared single queue AQM to L4S, and = L4S flows perform better. 

There's also no mention whatsoever of what happens when = L4S traffic meets a conventional AQM.

We also tested = this and all is well; the performance of classic queue with AQM is = fine.

[SM] I = think you are thinking of a different case than Jonathan, not classic = traffic in the C-queue, but L4S traffic (ECT(1)) that by chance is not = hiting abottleneck employing DualQ but the traditional FIFO...
This is the case where at least TCP Prague = just folds it, gives up and goes home...

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...
= --Apple-Mail=_24E62821-58DE-4B1C-8993-77271EC67391 Content-Disposition: inline; filename*0=687474703a2f2f7363652e646e736d67722e6e65742f726573756c74732f6c34; filename*1=732d323032302d31312d3131543132303030302d66696e616c2f73312d636861; filename*2=7274732f727474666169725f63635f71646973635f38306d735f38306d732e73; filename*3=7667.svg Content-Type: image/svg+xml; x-unix-mode=0644; name="687474703a2f2f7363652e646e736d67722e6e65742f726573756c74732f6c34732d323032302d31312d3131543132303030302d66696e616c2f73312d6368617274732f727474666169725f63635f71646973635f38306d735f38306d732e737667.svg" Content-Transfer-Encoding: quoted-printable = --Apple-Mail=_24E62821-58DE-4B1C-8993-77271EC67391 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


That is not really fit for use over the = open internet...

Regards
= Sebastian




Jason



__________________________________________= _____
Bloat mailing = list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listi= nfo/bloat

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
<= /div>
= --Apple-Mail=_24E62821-58DE-4B1C-8993-77271EC67391-- --Apple-Mail=_02376193-03B6-4A1C-BA70-66D9D46B05D5--