From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F37C73CC92 for ; Tue, 7 May 2024 16:03:11 -0400 (EDT) Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-1e3c3aa8938so22855495ad.1 for ; Tue, 07 May 2024 13:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; t=1715112190; x=1715716990; darn=lists.bufferbloat.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=zoAOz1DfLJnpiE/uWOhh69F1cBurbcptiOVWO4N0LKw=; b=dHRF5whAQxAJDflFt2RyRUojrTpwYn7sdr1U/vJgjZzzdPLIGObpBmASUEiHRegwJA v7QhXc+t/8i5bLlDRJWjK/nsOSrBfQlr323jdNEVTW/oVDizN/HfpHhtmIDN+lODX3HF ildehinkiee2/AGwOKcUsjs6v3kRfGTP9uYjQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715112190; x=1715716990; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zoAOz1DfLJnpiE/uWOhh69F1cBurbcptiOVWO4N0LKw=; b=k4LXAkqfixSR2h27XVAj8nHYtNPJlkqeAFLXwY5CKWIGJQdZGeXiZLtTRsYQN+JbG7 /7SKKiklBYYmj1KvjElh0Q72eZ9KxevK6yl8ReyG6369ZD9Sp6DYOoErDp9lGSVGhUDt CS5Yp/iZ0tW5cWw8DT9tMnNMVnNJfh36Wo17gd3yDThpHwHxMuo7XAfFW9TSLRS1HSFV mjJk1g9M+na68dIG5jUsC+kx1QBCaXSEzA6LslwEryqHDmXjjmWyo94yW6lhmf7JziFk /TOBpdB/AnDMX10gql+5WvjEYhD2FcZbM5dVQhukMoyyyUgKPQMWZfpE8zlduG+pF6HO 4oOw== X-Forwarded-Encrypted: i=1; AJvYcCUHomQDMcQMon0dtq2IVWWHzTJ0aINSrNhQgOVrwPqEhxzxI2aBh1blbPdCzBunPLYCKYmJZehBg0rppZzM4TwQDwFPdUXhZwzbZ4LGgp8= X-Gm-Message-State: AOJu0YzeocoMGe9w+k6bgv/gmZl5gRF7n/YxeyB2zuxNwVUj9GkR+Kvq 7WS+68GYIKRSjhoxW33sLR7TY0cMjma/To9Unv6LyCybCiGHvWW3gGsl+NdvPA== X-Google-Smtp-Source: AGHT+IGsVC27o/58619Nj4f7JQJV1epIGWNUIGTX3P9/P52whqGlHwQAzEJ944uffc/QEo7Wubmifw== X-Received: by 2002:a17:902:e5c5:b0:1e4:b1a2:b40c with SMTP id d9443c01a7336-1eeb09a002emr8961205ad.42.1715112190431; Tue, 07 May 2024 13:03:10 -0700 (PDT) Received: from smtpclient.apple (dhcp-72-253-194-45.hawaiiantel.net. [72.253.194.45]) by smtp.gmail.com with ESMTPSA id q5-20020a170902a3c500b001e99ffdbe56sm10659003plb.215.2024.05.07.13.03.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 May 2024 13:03:10 -0700 (PDT) From: Eugene Y Chang Message-Id: <9C282F48-BA0A-4DF4-B079-A0825453FE44@ieee.org> Content-Type: multipart/signed; boundary="Apple-Mail=_987DEA5B-C289-4E7E-82B8-FBAE39F74407"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Date: Tue, 7 May 2024 10:03:08 -1000 In-Reply-To: To: Dave Taht , Jeremy Austin , Dave Taht via Starlink , Dave Collier-Brown References: <3d6bdccf-e3d1-4f62-a029-25bfd1f458f5@indexexchange.com> <1779481A-0817-4F18-A0D7-A7A5AA0AF9D6@ieee.org> X-Mailer: Apple Mail (2.3696.120.41.1.8) Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2024 20:03:12 -0000 --Apple-Mail=_987DEA5B-C289-4E7E-82B8-FBAE39F74407 Content-Type: multipart/alternative; boundary="Apple-Mail=_553BA259-FBE7-47B7-9072-F7ED14556D2C" --Apple-Mail=_553BA259-FBE7-47B7-9072-F7ED14556D2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I thought I saw a reference to an OpenWRT implementation with L4S. How = well does that work? Gene ---------------------------------------------- Eugene Chang > On May 7, 2024, at 9:46 AM, Dave Taht wrote: >=20 > Pete heist, jon morton, and rod grimes published a TON of research as > to where l4s went wrong in these github repos: >=20 > https://github.com/heistp >=20 > The last was: = https://github.com/heistp/l4s-tests?tab=3Dreadme-ov-file#key-findings >=20 > They were ignored. Me, I had taken one look at it 7+ years ago and > said this cannot possibly work with the installed base of wifi > properly and since 97E% of all home connections terminate in that it > was a dead horse which they kept flogging. >=20 > After the L4S RFCs were published they FINALLY took their brands of > wishful thinking to actually exploring what happeed on real wifi > networks, and... I have no idea where that stands today. Yes a custom > wifi7 AP and presumably wifi8 will be able to deal with it, but > everything from the backoff mechanisms in the e2e TCP Prague code and > the proposed implementations on routers just plain does not work > except in a testbed. Fq_codel outperforms it across the board with > perhaps, some increased sensivity to RFC3168 seems needed only. L4S > (all transports actually) benefits a lot from packet pacing, and... > wait for it... fq) >=20 > Slow start and convergence issues are problematic also with l4s. >=20 > Being backward incompatible with fq_codel's deployed treatment of = RFC3168 ECN. > is a huge barrier too. >=20 > The best use case I can think of for l4s is on a tightly controlled > docsis network, pure wires and short RTTs only. The one implementation > for 5G I have heard of was laughable in that they were only aiming for > 200ms of induced latency on that. >=20 > If on the other hand you look at fq (and also how well starlink is > performing nowadays) and ccs like bbr, well... >=20 > I do honestly think there is room for this sort of signalling > somewhere on the internet, and do plan to add what I think will work > to cake at some point in the future. I do wish SCE had won, as it was > backwards compatible. >=20 >=20 > On Tue, May 7, 2024 at 12:15=E2=80=AFPM Jeremy Austin = wrote: >>=20 >>=20 >>=20 >> On Tue, May 7, 2024 at 11:11=E2=80=AFAM Dave Taht via Starlink = wrote: >>>=20 >>> The RFC is very plausible but the methods break down in multiple = ways, >>> particularly with wifi. >>=20 >>=20 >> Dave, can you elaborate more on the failures? Are these being = researched or addressed in the current trials, in your opinion? >>=20 >> Jeremy >=20 >=20 >=20 > -- > https://www.youtube.com/watch?v=3DBVFWSyMp3xg&t=3D1098s Waves Podcast > Dave T=C3=A4ht CSO, LibreQos --Apple-Mail=_553BA259-FBE7-47B7-9072-F7ED14556D2C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = thought I saw a reference to an OpenWRT implementation with L4S. How = well does that work?



Gene
----------------------------------------------
Eugene Chang



On May 7, 2024, at 9:46 AM, Dave Taht <dave.taht@gmail.com>= wrote:

Pete heist, jon morton, and rod grimes published a TON of = research as
to where l4s went wrong in these github = repos:

https://github.com/heistp

The = last was: = https://github.com/heistp/l4s-tests?tab=3Dreadme-ov-file#key-findings

They were ignored. Me, I had taken one look at = it 7+ years ago and
said this cannot possibly work with = the installed base of wifi
properly and since 97E% of all = home connections terminate in that it
was a dead horse = which they kept flogging.

After the L4S = RFCs were published they FINALLY took their brands of
wishful thinking to actually exploring what happeed on real = wifi
networks, and... I have no idea where that stands = today. Yes a custom
wifi7 AP and presumably wifi8 will be = able to deal with it, but
everything from the backoff = mechanisms in the e2e TCP Prague code and
the proposed = implementations on routers just plain does not work
except = in a testbed. Fq_codel outperforms it across the board with
perhaps, some increased sensivity to RFC3168 seems needed = only. L4S
(all transports actually) benefits a lot from = packet pacing, and...
wait for it... fq)

Slow start and convergence issues are problematic also with = l4s.

Being backward incompatible with = fq_codel's deployed treatment of RFC3168 ECN.
is a huge = barrier too.

The best use case I can think = of for l4s is on a tightly controlled
docsis network, pure = wires and short RTTs only. The one implementation
for 5G I = have heard of was laughable in that they were only aiming for
200ms of induced latency on that.

If on the other hand you look at fq (and also how well = starlink is
performing nowadays) and ccs like bbr, = well...

I do honestly think there is room = for this sort of signalling
somewhere on the internet, and = do plan to add what I think will work
to cake at some = point in the future. I do wish SCE had won, as it was
backwards compatible.


On Tue, May 7, 2024 at 12:15=E2=80=AFPM Jeremy Austin = <jeremy@aterlo.com> wrote:



On Tue, May 7, = 2024 at 11:11=E2=80=AFAM Dave Taht via Starlink = <starlink@lists.bufferbloat.net> wrote:

The RFC is very plausible but = the methods break down in multiple ways,
particularly with = wifi.


Dave, can = you elaborate more on the failures? Are these being researched or = addressed in the current trials, in your opinion?

Jeremy



--
https://www.youtube.com/watch?v=3DBVFWSyMp3xg&t=3D1098s = Waves Podcast
Dave T=C3=A4ht CSO, LibreQos

= --Apple-Mail=_553BA259-FBE7-47B7-9072-F7ED14556D2C-- --Apple-Mail=_987DEA5B-C289-4E7E-82B8-FBAE39F74407 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEERPTGiBqcibajhTSsv0/8FiYdKmAFAmY6iPwACgkQv0/8FiYd KmBisg//flZTJDFW8mesNa9PHl+wpbYyvcd8dx0VGOCJmLP+sASizhb50cENXAEv 3O0wnq/AzIumYNgLzukuNTQlhY6lFPdy7feEemQVivlTdnSMO9b0uiLQdHaKNzdW /J/2BuFuSIfJXEaUTLM500z+wIu3l12/N2uBCRju37q2xDf29Cjx9381XGpZ99/f 96EEk4JWzlLs08sRqrq3rr06peOnEn3WfErxwuCygVTCjsV0fF1yI3f1UWEKaipT 7IRIgR1zAdanKx/HDL42USIvC0MmufAhRGVwAyzTjYdPIf2MHRZpPRhVmB27v68U BMCgjm5zlm/uxL7zK5vT78rOzWU1Bna/LyY7TAYT4/pAVAme+AQ9a/AUsTsQ6TJe 9GDB1k+Y+bcYlidrieYP9szp6l4Mw0ASWjhAgEENKiEBdsx9mSBbkOkQ2HAE4oxM kqWP51YdqRpgyZh2JvpxNnmfPmTEdknLb0FmpShFcj7LEF7ME7cxA/f1WC4CXnuE vjrXFs3F6lagk+Kkd+U528gXFalopoi3AKGkXl7pLcA7q5rI6SWcwRR5qCGJYdui jhLitl+62egv9noblWsdIY00oQR5DC0ochqnDsEPhqZEj+iTN/mJ2TB/z7EfJeUZ z4xBA9je//aIPbBXSUk+0HRmSfnaQRu140x4mm6Rasa01X4Jk8Q= =XG42 -----END PGP SIGNATURE----- --Apple-Mail=_987DEA5B-C289-4E7E-82B8-FBAE39F74407--