From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 398993B29D for ; Wed, 1 May 2024 06:16:32 -0400 (EDT) Received: by mail-oi1-x235.google.com with SMTP id 5614622812f47-3c70d8bb618so2996510b6e.2 for ; Wed, 01 May 2024 03:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714558591; x=1715163391; darn=lists.bufferbloat.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5uMWOzaukaOLR+F5TLrkjfM5lQNJxbKG7MwwfPcpgSI=; b=Mh6e1Q0hl8nfnj3dDtE8WsagKOuSWs14aqeDipWmcJAMVxcs4RVbTu9hEG8bhVFibI Pzs+NuMhzzR2UJKTGrwOl9OSwhbMdm+2gACSQtbU7H76aKZx64yc695SfhAHNyhwZaNC 3vsy/xDCnnxNPAlTQLZzZLle7eBs0MTsGhKndbACE+5PsLqbSFWQPoXTUok2nbCUrRhf WBbiN+qzLDIsxm7OfmbD6c3+x3xT/2OKxRdgZLWyD9CDOVv1lRGY+V5Zk6MBkBaaAMs3 QRbbC+O9O353Fyr9EKwBbgxjO5ZxO0zFuk4rcRyAex8kKEkc/cPrtqrCuWv9vbuTOZTR Qp1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714558591; x=1715163391; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5uMWOzaukaOLR+F5TLrkjfM5lQNJxbKG7MwwfPcpgSI=; b=U0cQIdwyrPgOhATy31HfrJ19rB4YCrElqrrzvLxWqI81+6EMFa5jYfWEmTfw8KSMoK sD35yF+IjnRqi/TAvD/2tPnnMsQKQ16dKHjWGUuLRPmmYVFSDLRIqXH+DFXkFBIph7rt NT7ywluOKoD1p206UrvzDOtFfI9Bj+RQVQZu9Xc2HL50Nv18j8W/aY36Hqishh+J6CsJ ChiC+JDmbC3Gg9fIUiojSqyDHdLF68wrLChltcWp0rEaZOkXt7nrFnfA+5EQt6Ku/aqR hHD5h+qZhp+1cwvCkIyS6G1wg/ILV1WuzMAwkKxN+umrHTKryEVIpwriiyQ5e9Qhg6v1 Lk+Q== X-Forwarded-Encrypted: i=1; AJvYcCV45nX8eNzJaLBDsCZcz6cN/r+4d6qwMvoyC5yJNlpJUn2fe5m5eZMGzuHYiC/I40EBJJroagt/bvmsUy1KWyuso8jGnvazATrveCwMlAs= X-Gm-Message-State: AOJu0YwX25bD2jS2PfA2rePZAXC2H4M2yO3XoOnuOZxLDr063mj+gKyM N5WFiSahWDtAVFBYY5Gn5posNDl/yVg50OdAj/c6ZpLBZK8KEMJoqkEecCSWRarrki1S6AI1LMy Q/BN7UxM9iCmZ+vat94jexvxdDEQ= X-Google-Smtp-Source: AGHT+IGeSB1E+9A2Plh4PpH8+T8oO19j4UUp89l94eCV1MG1a9KSF0vRWGCqIWnFkdqK8+4eybXf9Buqi0xKD2Yy7iw= X-Received: by 2002:a05:6808:1293:b0:3c8:61b2:353d with SMTP id a19-20020a056808129300b003c861b2353dmr3003087oiw.3.1714558591258; Wed, 01 May 2024 03:16:31 -0700 (PDT) MIME-Version: 1.0 References: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org> <79C02ABB-B2A6-4B4D-98F4-6540D3F96EBB@ieee.org> <7E918B58-382A-4793-A144-13A7075CA56C@connectivitycap.com> <13rq2389-9012-p95n-s494-q3pp070s497n@ynat.uz> In-Reply-To: <13rq2389-9012-p95n-s494-q3pp070s497n@ynat.uz> From: Frantisek Borsik Date: Wed, 1 May 2024 12:15:55 +0200 Message-ID: To: David Lang Cc: Eugene Y Chang , Colin_Higbie , Dave Taht via Starlink Content-Type: multipart/alternative; boundary="000000000000c75d4f061761c7e2" Subject: Re: [Starlink] =?utf-8?q?It=CA=BCs_the_Latency=2C_FCC?= 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: Wed, 01 May 2024 10:16:32 -0000 --000000000000c75d4f061761c7e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This was a nice story of overhauling good ole Cambium Networks HW with OpenWrt, FQ-CoDel & CAKE: https://blog.nafiux.com/posts/cnpilot_r190w_openwrt_bufferbloat_fqcodel_cak= e/ 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 Wed, May 1, 2024 at 6:12=E2=80=AFAM David Lang via Starlink < starlink@lists.bufferbloat.net> wrote: > On Tue, 30 Apr 2024, Eugene Y Chang wrote: > > > I=E2=80=99m not completely up to speed on the gory details. Please humo= r me. I > am pretty good on the technical marketing magic. > > > > What is the minimum configuration of an ISP infrastructure where we can > show an A/B (before and after) test? > > It can be a simplified scenario. The simpler, the better. We can talk > through the issues of how minimal is adequate. Of course and ISP engineer > will argue against simplicity. > > I did not see a very big improvement on a 4/.5 dsl link, but there was > improvement. > > if you put openwrt on the customer router and configure cake with the > targeted > bandwith at ~80% of line speed, you will usually see a drastic improvemen= t > for > just about any connection. > > If you can put fq_codel on both ends of the link, you can usually skip > capping > the bandwidth. > > unfortunantly, it's not possible to just add this to the ISPs existing > hardware > without having the source for the firmware there (and if they have their > queues > in ASICs it's impossible to change them. > > If you can point at the dramatic decrease in latency, with no bandwidth > losses, > that Starlink has achieved on existing hardware, that may help. > > There are a number of ISPs around the world that have implemented active > queue > management and report very good results from doing so. > > But showing that their existing hardware can do it when their upstream > vendor > doesn't support it is going to be hard. > > David Lang > > > > > We will want to show the human visible impact and not debate good or no= t > so good measurements. If we get the business and community subscribers on > our side, we win. > > > > Note: > > Stage 1 is to show we have a pure software fix (that can work on their > hardware). The fix is =E2=80=9Cso dramatic=E2=80=9D that subscribers can = experience it > without debating measurements. > > Stage 2 discusses why the ISP should demand that their equipment vendor= s > add this software. (The software could already be available, but the ISP > doesn=E2=80=99t think it is worth the trouble to enable it.) Nothing will= happen > unless we stay engaged. We need to keep the subscribers engaged, too. > > > > Should we have a conference call to discuss this? > > > > > > Gene > > ---------------------------------------------- > > Eugene Chang > > IEEE Life Senior Member > > > > > > > >> On Apr 30, 2024, at 3:52 PM, Jim Forster > wrote: > >> > >> Gene, David, > >> =E2=80=98m > >> Agreed that the technical problem is largely solved with cake & codel. > >> > >> Also that demos are good. How to do one for this problem> > >> > >> =E2=80=94 Jim > >> > >>> The bandwidth mantra has been used for so long that a technical > discussion cannot unseat the mantra. > >>> Some technical parties use the mantra to sell more, faster, > ineffective service. Gullible customers accept that they would be happy i= f > they could afford even more speed. > >>> > >>> Shouldn=E2=80=99t we create a demo to show the solution? > >>> To show is more effective than to debate. It is impossible to explain > to some people. > >>> Has anyone tried to create a demo (to unseat the bandwidth mantra)? > >>> Is an effective demo too complicated to create? > >>> I=E2=80=99d be glad to participate in defining a demo and publicity c= ampaign. > >>> > >>> Gene > >>> > >>> > >>>> On Apr 30, 2024, at 2:36 PM, David Lang david@lang.hm>> wrote: > >>>> > >>>> On Tue, 30 Apr 2024, Eugene Y Chang via Starlink wrote: > >>>> > >>>>> I am always surprised how complicated these discussions become. > (Surprised mostly because I forgot the kind of issues this community care > about.) The discussion doesn=E2=80=99t shed light on the following scenar= ios. > >>>>> > >>>>> While watching stream content, activating controls needed to switch > content sometimes (often?) have long pauses. I attribute that to buffer > bloat and high latency. > >>>>> > >>>>> With a happy household user watching streaming media, a second user > could have terrible shopping experience with Amazon. The interactive > response could be (is often) horrible. (Personally, I would be doing emai= l > and working on a shared doc. The Amazon analogy probably applies to more > people.) > >>>>> > >>>>> How can we deliver graceful performance to both persons in a > household? > >>>>> Is seeking graceful performance too complicated to improve? > >>>>> (I said =E2=80=9Cgraceful=E2=80=9D to allow technical flexibility.) > >>>> > >>>> it's largely a solved problem from a technical point of view. > fq_codel and cake solve this. > >>>> > >>>> The solution is just not deployed widely, instead people argue that > more bandwidth is needed instead. > >> > > > >_______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > --000000000000c75d4f061761c7e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This was a nice story of overhauling good ole Cambium Netw= orks HW with=C2=A0OpenWrt, FQ-CoDel & CAKE:


All the best,

Frank<= u>

Frantisek= (Frank) Borsik

=C2=A0

https://www.linkedin.com/in/fra= ntisekborsik

Signal, Telegram, WhatsApp: +421919416714=C2=A0

iMessage, mobile: +4= 20775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com<= /p>

=

On Wed, May 1, 2024 at 6:12=E2=80=AFAM David Lang via Starl= ink <starlink@lists.bu= fferbloat.net> wrote:
On Tue, 30 Apr 2024,= Eugene Y Chang wrote:

> I=E2=80=99m not completely up to speed on the gory details. Please hum= or me. I am pretty good on the technical marketing magic.
>
> What is the minimum configuration of an ISP infrastructure where we ca= n show an A/B (before and after) test?
> It can be a simplified scenario. The simpler, the better. We can talk = through the issues of how minimal is adequate. Of course and ISP engineer w= ill argue against simplicity.

I did not see a very big improvement on a 4/.5 dsl link, but there was
improvement.

if you put openwrt on the customer router and configure cake with the targe= ted
bandwith at ~80% of line speed, you will usually see a drastic improvement = for
just about any connection.

If you can put fq_codel on both ends of the link, you can usually skip capp= ing
the bandwidth.

unfortunantly, it's not possible to just add this to the ISPs existing = hardware
without having the source for the firmware there (and if they have their qu= eues
in ASICs it's impossible to change them.

If you can point at the dramatic decrease in latency, with no bandwidth los= ses,
that Starlink has achieved on existing hardware, that may help.

There are a number of ISPs around the world that have implemented active qu= eue
management and report very good results from doing so.

But showing that their existing hardware can do it when their upstream vend= or
doesn't support it is going to be hard.

David Lang

>
> We will want to show the human visible impact and not debate good or n= ot so good measurements. If we get the business and community subscribers o= n our side, we win.
>
> Note:
> Stage 1 is to show we have a pure software fix (that can work on their= hardware). The fix is =E2=80=9Cso dramatic=E2=80=9D that subscribers can e= xperience it without debating measurements.
> Stage 2 discusses why the ISP should demand that their equipment vendo= rs add this software. (The software could already be available, but the ISP= doesn=E2=80=99t think it is worth the trouble to enable it.) Nothing will = happen unless we stay engaged. We need to keep the subscribers engaged, too= .
>
> Should we have a conference call to discuss this?
>
>
> Gene
> ----------------------------------------------
> Eugene Chang
> IEEE Life Senior Member
>
>
>
>> On Apr 30, 2024, at 3:52 PM, Jim Forster <jim@connectivitycap.com> wro= te:
>>
>> Gene, David,
>> =E2=80=98m
>> Agreed that the technical problem is largely solved with cake &= ; codel.
>>
>> Also that demos are good. How to do one for this problem>
>>
>>=C2=A0 =C2=A0=E2=80=94 Jim
>>
>>> The bandwidth mantra has been used for so long that a technica= l discussion cannot unseat the mantra.
>>> Some technical parties use the mantra to sell more, faster, in= effective service. Gullible customers accept that they would be happy if th= ey could afford even more speed.
>>>
>>> Shouldn=E2=80=99t we create a demo to show the solution?
>>> To show is more effective than to debate. It is impossible to = explain to some people.
>>> Has anyone tried to create a demo (to unseat the bandwidth man= tra)?
>>> Is an effective demo too complicated to create?
>>> I=E2=80=99d be glad to participate in defining a demo and publ= icity campaign.
>>>
>>> Gene
>>>
>>>
>>>> On Apr 30, 2024, at 2:36 PM, David Lang <david@lang.hm <mailto:david@lang.hm>> wrote= :
>>>>
>>>> On Tue, 30 Apr 2024, Eugene Y Chang via Starlink wrote: >>>>
>>>>> I am always surprised how complicated these discussion= s become. (Surprised mostly because I forgot the kind of issues this commun= ity care about.) The discussion doesn=E2=80=99t shed light on the following= scenarios.
>>>>>
>>>>> While watching stream content, activating controls nee= ded to switch content sometimes (often?) have long pauses. I attribute that= to buffer bloat and high latency.
>>>>>
>>>>> With a happy household user watching streaming media, = a second user could have terrible shopping experience with Amazon. The inte= ractive response could be (is often) horrible. (Personally, I would be doin= g email and working on a shared doc. The Amazon analogy probably applies to= more people.)
>>>>>
>>>>> How can we deliver graceful performance to both person= s in a household?
>>>>> Is seeking graceful performance too complicated to imp= rove?
>>>>> (I said =E2=80=9Cgraceful=E2=80=9D to allow technical = flexibility.)
>>>>
>>>> it's largely a solved problem from a technical point o= f view. fq_codel and cake solve this.
>>>>
>>>> The solution is just not deployed widely, instead people a= rgue that more bandwidth is needed instead.
>>
>
>_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
--000000000000c75d4f061761c7e2--