From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 D80533CC9C for ; Tue, 7 May 2024 16:25:38 -0400 (EDT) Received: by mail-pf1-x42a.google.com with SMTP id d2e1a72fcca58-6f44bcbaae7so2710230b3a.2 for ; Tue, 07 May 2024 13:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; t=1715113538; x=1715718338; 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=eEVsTI5TQDVgLSnRQc0/B61XOj/Rcaqn3dL2yq5iTqM=; b=MbAhJHBY4g0Wi4j9tVe57H4TkbMXBVxVSykBTyihimvToD7Yu1ljYCqAmzuShZg1jF dy1DbuDjYhF2W7ftw3yiobZSie/tskS7FMdPPMxUM/oy1np5BncS/M6qIMdXer3scoBN Z42Hu8YjkiLHnw8cAlC5QPwefnLDXU5obzXEc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715113538; x=1715718338; 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=eEVsTI5TQDVgLSnRQc0/B61XOj/Rcaqn3dL2yq5iTqM=; b=BsquL8A8asjk/vHwM/UYY47rpDk6LC9DsukADuDUIKa1Ad37V1QITvMOSOaiSaCgt5 g3fyfb3zjfSZrOGyzI04j+Pl/B2fh5LQ38LPC9/n3kKsbGhEgzcFfh/6chzi/76OSDLA GrNv3bY6Zb3qEMMCKgbrCEiS0d2tpKc1INm1Ww8tU+1T/m4WKPE2kDJ+pOMUIsZa6dbd KPNDSATnytCYUJEtv67EJ/hdpPzqTfA+34WkoXu54K23Ub71KMVY7gzYwyW7/gXLnoml Dwm+uf3FNKQh7h8hRmgqHweoX67rqHB2vBY+Sak7pUjrys0ShckrfF2jvtC5qttdSEfh 021w== X-Forwarded-Encrypted: i=1; AJvYcCXzBGEpoSKdP0rBVbMHeyIBFL5YedpagOHezZTLXKDkoX9tnmL4F1hJnNvf3P76DbeF7hvVx5bdfKc9uoznEUGAa3aiKt+Fe/7Vpu6eVfc= X-Gm-Message-State: AOJu0Yx0cJ61Fudodei9WRwsbxvAPgOE8rBwmDFhBB6WK4+tioKO19fw X/JF4+bKm3HfJlk+wiomQRVPUru3O+BNPaYDlxzunq/OqIQNRYsePy58MYkkrw== X-Google-Smtp-Source: AGHT+IEAqWShxfprIt+XXxWZAzoi5T45HyrXmKtsHaWlL/PWZ4GfHhrwBNW+r6T4ginDZANLJ3k4Gg== X-Received: by 2002:a05:6a00:4f0f:b0:6ea:950f:7d29 with SMTP id d2e1a72fcca58-6f49c23e0d9mr691292b3a.20.1715113537330; Tue, 07 May 2024 13:25:37 -0700 (PDT) Received: from smtpclient.apple (dhcp-72-253-194-45.hawaiiantel.net. [72.253.194.45]) by smtp.gmail.com with ESMTPSA id hy12-20020a056a006a0c00b006ed26aa0ae6sm9827432pfb.54.2024.05.07.13.25.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 May 2024 13:25:36 -0700 (PDT) From: Eugene Y Chang Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AF597DC1-4D61-475D-91C6-AB4FA8F758C7"; 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:25:34 -1000 In-Reply-To: Cc: Eugene Y Chang , Dave Taht , Jeremy Austin , Dave Taht via Starlink , Dave Collier-Brown To: Frantisek Borsik References: <3d6bdccf-e3d1-4f62-a029-25bfd1f458f5@indexexchange.com> <1779481A-0817-4F18-A0D7-A7A5AA0AF9D6@ieee.org> <9C282F48-BA0A-4DF4-B079-A0825453FE44@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:25:39 -0000 --Apple-Mail=_AF597DC1-4D61-475D-91C6-AB4FA8F758C7 Content-Type: multipart/alternative; boundary="Apple-Mail=_A90A87D3-E7B9-4F77-B2E6-552446F3183D" --Apple-Mail=_A90A87D3-E7B9-4F77-B2E6-552446F3183D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Frank, So it is not the universal cure. Not surprising. I don=E2=80=99t see a show-stopper for pushing adoption. Gene ---------------------------------------------- Eugene Chang IEEE Life Senior Member IEEE Communications Society & Signal Processing Society, Hawaii Chapter Chair IEEE Life Member Affinity Group Hawaii Chair IEEE Entrepreneurship, Mentor eugene.chang@ieee.org m 781-799-0233 (in Honolulu) > On May 7, 2024, at 10:05 AM, Frantisek Borsik = wrote: >=20 > Here is a current view of it, IIRC: >=20 > = https://forum.openwrt.org/t/rfc9330-rfc9331-rfc9332-for-lower-latency/1805= 19/12 = >=20 > All the best, >=20 > Frank >=20 > Frantisek (Frank) Borsik >=20 >=20 >=20 > https://www.linkedin.com/in/frantisekborsik = > Signal, Telegram, WhatsApp: +421919416714 >=20 > iMessage, mobile: +420775230885 >=20 > Skype: casioa5302ca >=20 > frantisek.borsik@gmail.com >=20 > On Tue, May 7, 2024 at 10:03=E2=80=AFPM Eugene Y Chang via Starlink = > = wrote: > I thought I saw a reference to an OpenWRT implementation with L4S. How = well does that work? >=20 >=20 >=20 > Gene > ---------------------------------------------- > Eugene Chang >=20 >=20 >=20 >> 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 >=20 > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink = --Apple-Mail=_A90A87D3-E7B9-4F77-B2E6-552446F3183D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Frank,
So it is not the universal cure. = Not surprising.
I don=E2=80=99t see a show-stopper = for pushing adoption.

Gene
----------------------------------------------
Eugene Chang
IEEE Life Senior Member
IEEE = Communications Society & Signal Processing Society,    
    Hawaii Chapter Chair
IEEE Life Member = Affinity Group Hawaii Chair
IEEE Entrepreneurship, Mentor
eugene.chang@ieee.org
m 781-799-0233 (in = Honolulu)



On May 7, 2024, at 10:05 AM, Frantisek Borsik <frantisek.borsik@gmail.com> wrote:

Here is a current view of it, IIRC:

https://forum.openwrt.org/t/rfc9330-rfc9331-rfc9332-for-lower-l= atency/180519/12

All the best,

Frank

Frantisek (Frank) Borsik

 

https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: = +421919416714 

iMessage, mobile: = +420775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com



On Tue, May 7, 2024 at 10:03=E2=80=AFPM = Eugene Y Chang via Starlink <starlink@lists.bufferbloat.net> wrote:
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-fi= ndings

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

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

= --Apple-Mail=_A90A87D3-E7B9-4F77-B2E6-552446F3183D-- --Apple-Mail=_AF597DC1-4D61-475D-91C6-AB4FA8F758C7 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/8FiYdKmAFAmY6jj4ACgkQv0/8FiYd KmCU4RAAhPxPd3W8ER9ywWth0kUFnMf9HSHa74/7ZK79tu8quLpVQoApeV9zi6rW C7y23hxktBWLlsFLbXNyhNXaQ3BkEaYQ1JdiWBbgnBfTEOHvvdTwwY9wEtjWYT3H nJP2PQ7OSgtDE6177KTTBggv8Xm1wDGrzx1H6YzhwpKH82KXXH2NDPxp5ETkA9wh e0GR1LPLoMM9eMjWM/1b8lzDXNrvjvIxPs5Zyr2JXM9Aw4zoOSBhS1F9ng1fAwza ksyTEnWe45simDhR9JJxGhya1k0m9brrc+s0Sv1VS0cojbvW54+eqYUf0PU98u8e X2go/85h+P7k53yqEfat0IhaVLM7lhYQLXCdd68qctCfXQKG/xbnP5lIzqiPYD9H uyD6aVDNNLQzsm6FmVgWefj1XcPznqPcAYH8qgMMwCQoNh5/gfC+7tyPt+++gOxj oKU13JLFpt3d2prfXm7nu0D7Zcp6cXI+t+Mpp4DU9N1mwhy1iSCJdv+S/6acco9C 59aC3RVLZBN90BhxmHVtZUx2j9U35CiHDIurL3ygK9IwLBVlu0kXzL9CWJmCkovr 1bizrTU9JiynpcA8lX+w66Av+bgD9dOaSzD+QVwTP2Z5U+cz5Rc/vlo5CUpO0elA HwuiVq6aLK+4xtbx6Xb8OuBE1tjpMU3FUoPWxc3gEHDhQkKdg/g= =BCCv -----END PGP SIGNATURE----- --Apple-Mail=_AF597DC1-4D61-475D-91C6-AB4FA8F758C7--