From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 CC3F83CB42 for ; Wed, 1 May 2024 18:10:50 -0400 (EDT) Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1ecc23e6c9dso4951995ad.2 for ; Wed, 01 May 2024 15:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; t=1714601450; x=1715206250; 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=rY0Bol0DQUQvzv3ddoutXJiNUBR1ellbCrBb0zfSzWg=; b=fk/s6E+JO9mrFjUIqES8QLeD24CLb/O5TW1WogHZ+7Ho67EzswbHftA36ElNmSHyH+ z99L0cr0AMqFui92v4269V31iUIUeQYwGm6HO17qnftXM72rth9LQHY+nKbHzvo4AOrh R8MCfmr3T4lSDcR45SoMkXrf2rSRQGTBxGzd8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714601450; x=1715206250; 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=rY0Bol0DQUQvzv3ddoutXJiNUBR1ellbCrBb0zfSzWg=; b=QD9L7wYsknWW6Z/8ICVCt0iQRaem8VNCxArHuBE4erDJW8Wajo8TZTHqTY/gtJm5yM 07XWaX34ZFoJRWu3+zeH+6H+SQiN0GzE+G1NcLikY2kImJMtJDeykV2vZqiwL9Yr7nSW JKkCGvA5BB29U93itFKuCh99L3STye+Pbu0THqln4qKkvfUk+XbsMnaRK+K3p3Iop6gu OmFjTRAMRaBEFUntg++gwKvlkAI3Fjui2wwWGl4FvWEXipQTG765iDT+zyPYlgHrGpDi uI3NNjaR4WlEig7OIBQAip9qGkG12RpFzPiQ1cpQjAjWYjrd6Tjre6ngsIcEIjfftcjK TIxA== X-Forwarded-Encrypted: i=1; AJvYcCWPodFWkoq3FOcnDWrVb7MRNr8jeoruHdcflpXcM+eM/2QDThbUwcG20AGnqybc0eO/IS63SkxRYK/E2zqlBqSPt3I7Pu1iCNzTOUU9DUk= X-Gm-Message-State: AOJu0YyRP34dBugHzALL4cZU1RclpuqqJ9h+YPkzNLERIHWjeCYBIJqs VXrmCsM3soOg7uPDYMK9/dNawpn0A6WE6/26mhGVpJ1uuHBn7iDtKkk3WDqujg== X-Google-Smtp-Source: AGHT+IG1K9s9sHaJqYOq0po8C5hIbjBtXRV+qnLBEEMw0O05EupP11faoTx370S5vruTOVPtqbSy4g== X-Received: by 2002:a17:902:ce8e:b0:1eb:5323:c320 with SMTP id f14-20020a170902ce8e00b001eb5323c320mr5237749plg.56.1714601449231; Wed, 01 May 2024 15:10:49 -0700 (PDT) Received: from smtpclient.apple (dhcp-72-253-194-45.hawaiiantel.net. [72.253.194.45]) by smtp.gmail.com with ESMTPSA id q9-20020a170902dac900b001eb07ee30e4sm10428363plx.2.2024.05.01.15.10.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 May 2024 15:10:48 -0700 (PDT) From: Eugene Y Chang Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7E355C67-4760-4149-A438-EA91583536BB"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Date: Wed, 1 May 2024 12:10:46 -1000 In-Reply-To: Cc: Eugene Y Chang , David Lang , Colin_Higbie , Dave Taht via Starlink To: Frantisek Borsik 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> <6qop2p3o-351p-788q-q1q2-86sosnq3rn21@ynat.uz> X-Mailer: Apple Mail (2.3696.120.41.1.8) 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 22:10:51 -0000 --Apple-Mail=_7E355C67-4760-4149-A438-EA91583536BB Content-Type: multipart/alternative; boundary="Apple-Mail=_EB4997F3-2B7C-41B6-8EB5-97688F8EE7C6" --Apple-Mail=_EB4997F3-2B7C-41B6-8EB5-97688F8EE7C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you all for the discussion. Given everything that has been said my plan A will be to engage the = eSports community and find some engineering students that will want to = give this a test. The business users will follow the ISPs and the state experts. Since = they all learned their craft from the incumbent ISP, nothing will happen = here (for now). 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 1, 2024, at 11:11 AM, Frantisek Borsik = wrote: >=20 > Eugene, this is one of the ISP examples of using OpenWrt, CAKE & = FQ-CoDel to fix not only his network, but also to refurbish an old = device - when the vendor didn't give a flying F: > = https://blog.nafiux.com/posts/cnpilot_r190w_openwrt_bufferbloat_fqcodel_ca= ke/ = >=20 > Here is also the list of OpenWrt supported HW: = https://openwrt.org/supported_devices = > If you/ISP want to go mainstream, MikroTik will be a good option. >=20 > This is a great place to start (not only for your ISP): = https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Buffer= bloat/ = >=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 Wed, May 1, 2024 at 9:18=E2=80=AFPM David Lang via Starlink = > = wrote: > On Wed, 1 May 2024, Eugene Y Chang wrote: >=20 > > Thanks David, > > > > > >> On Apr 30, 2024, at 6:12 PM, David Lang > wrote: > >> > >> On Tue, 30 Apr 2024, Eugene Y Chang wrote: > >> > >>> I=E2=80=99m not completely up to speed on the gory details. Please = humor 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. > > > > Would a user feel the improvement with a 10 minute session: > > shopping on Amazon? > > using Salesforce? > > working with a shared Google doc? >=20 > When it's only a single user, they are unlikely to notice any = difference. >=20 > But if you have one person on zoom, a second downloading something, = and a third > on Amazon, it doesn't take much to notice a difference. >=20 > >> 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 improvement for just about any connection. > > > > Are you saying some of the benefits can be realized with just = upgrading the > > subscriber=E2=80=99s router? This makes adoption harder because the = subscriber will > > lose the ISP=E2=80=99s support for any connectivity issues. If a = demo impresses the > > subscribers, the ISP still needs to embrace this change; otherwise = the ISP > > will wash their hands of any subscriber problems. >=20 > Yes, just upgrading the subscriber's device with cake and configuring = it > appropriately largely solves the problem (at the cost of sacraficing = bandwith > because cake isn't working directly on the data flowing from the ISP = to the > client, and so it has to work indirectly to get the Internet server to = slow down > instead and that's a laggy, imperect work-around. If the ISPs router = does active > queue management with fq_codel, then you don't have to do this. >=20 > This is how we know this works, many of use have been doing this for = years (see > the bufferbloat mailing list and it's archives_ >=20 > >> If you can put fq_codel on both ends of the link, you can usually = skip capping the bandwidth. > > > > This is good if this means the benefits can be achieved with just = the CPE. This also limits the changes to subscribers that care. >=20 > fq_codel on the ISPs router for downlink, and on the subscribers = router for > uplink. >=20 > putting cake on the router on the subscriber's end and tuning it = appropriately > can achieve most of the benefit, but is more work to configure. >=20 > >> > >> 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. > > > > Is this just an alternative to having the change at the CPE? > > Yes this is harder for routers in the network. >=20 > simple fq_codel on both ends of the bottleneck connection works quite = well > without any configuration. Cake adds some additional fairness = capabilities and > has a mode to work around the router on the other end of the = bottleneck not > doing active queue management >=20 > >> If you can point at the dramatic decrease in latency, with no = bandwidth losses, that Starlink has achieved on existing hardware, that = may help. > > > > This is good to know for the engineers. This adds confusion with the = subscribers. > > > >> > >> There are a number of ISPs around the world that have implemented = active queue management and report very good results from doing so. > > > > Can we get these ISPs to publically report how they have achieved = great latency reduction? > > We can help them get credit for caring about their subscribers. It = would/could be a (short term) competitive advantage. > > Of course their competitors will (might) adopt these changes and = eliminate the advantage, BUT the subscribers will retain glow of the = initial marketing for a much longer time. >=20 > several of them have done so, I think someone else posted a report = from one in > this thread. >=20 > >> But showing that their existing hardware can do it when their = upstream vendor doesn't support it is going to be hard. > > > > Is the upstream vendor a network provider or a computing center? > > Getting good latency from the subscriber, through the access network = to the edge computing center and CDNs would be great. The CDNs would = harvest the benefits. The other computing configurations would have make = the change to be competitive. >=20 > I'm talking about the manufacturer of the routers that the ISPs deploy = at the > last hop before getting to the subscriber, and the router on the = subscriber end > of the link (although most of those are running some variation of = openWRT, so > turning it on would not be significant work for the manufacturer) >=20 > > We wouild have done our part at pushing the next round of adoption. >=20 > Many of us have been pushing this for well over a decade. Getting = Starlink's > attention to address their bufferbloat issues is a major success. >=20 > David Lang >=20 > > Gene > > > >> > >> David Lang > >> > >>> > >>> We will want to show the human visible impact and not debate good = or not 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 = vendors 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 = if 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 campaign. > >>>>> > >>>>> Gene > >>>>> > >>>>> > >>>>>> On Apr 30, 2024, at 2:36 PM, David Lang > = >>> 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 scenarios. > >>>>>>> > >>>>>>> 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 email 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 = --Apple-Mail=_EB4997F3-2B7C-41B6-8EB5-97688F8EE7C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thank= you all for the discussion.

Given everything that has been said my plan A will be to = engage the eSports community and find some engineering students that = will want to give this a test.

The business users will follow the ISPs = and the state experts. Since they all learned their craft from the = incumbent ISP, nothing will happen here (for now).

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 1, 2024, at 11:11 AM, Frantisek Borsik <frantisek.borsik@gmail.com> wrote:

Eugene, this is one of the ISP = examples of using OpenWrt, CAKE & FQ-CoDel to fix not only his = network, but also to refurbish an old device - when the vendor didn't = give a flying F:
https://blog.nafiux.com/posts/cnpilot_r190w_openwrt_bufferbloat= _fqcodel_cake/

Here is also the list of OpenWrt supported HW: https://openwrt.org/supported_devices 
If you/ISP want to go mainstream, MikroTik will be a good = option.

This = is a great place to start (not only for your ISP): https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_a= bout_Bufferbloat/

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 9:18=E2=80=AFPM David Lang via Starlink <starlink@lists.bufferbloat.net> wrote:
On Wed, 1 May 2024, Eugene Y Chang = wrote:

> Thanks David,
>
>
>> On Apr 30, 2024, at 6:12 PM, David Lang <david@lang.hm> wrote:
>>
>> On Tue, 30 Apr 2024, Eugene Y Chang wrote:
>>
>>> I=E2=80=99m not completely up to speed on the gory details. = Please humor 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.
>
> Would a user feel the improvement with a 10 minute session:
> shopping on Amazon?
> using Salesforce?
> working with a shared Google doc?

When it's only a single user, they are unlikely to notice any = difference.

But if you have one person on zoom, a second downloading something, and = a third
on Amazon, it doesn't take much to notice a difference.

>> 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 improvement for just about any connection.
>
> Are you saying some of the benefits can be realized with just = upgrading the
> subscriber=E2=80=99s router? This makes adoption harder because the = subscriber will
> lose the ISP=E2=80=99s support for any connectivity issues. If a = demo impresses the
> subscribers, the ISP still needs to embrace this change; otherwise = the ISP
> will wash their hands of any subscriber problems.

Yes, just upgrading the subscriber's device with cake and configuring it =
appropriately largely solves the problem (at the cost of sacraficing = bandwith
because cake isn't working directly on the data flowing from the ISP to = the
client, and so it has to work indirectly to get the Internet server to = slow down
instead and that's a laggy, imperect work-around. If the ISPs router = does active
queue management with fq_codel, then you don't have to do this.

This is how we know this works, many of use have been doing this for = years (see
the bufferbloat mailing list and it's archives_

>> If you can put fq_codel on both ends of the link, you can = usually skip capping the bandwidth.
>
> This is good if this means the benefits can be achieved with just = the CPE. This also limits the changes to subscribers that care.

fq_codel on the ISPs router for downlink, and on the subscribers router = for
uplink.

putting cake on the router on the subscriber's end and tuning it = appropriately
can achieve most of the benefit, but is more work to configure.

>>
>> 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.
>
> Is this just an alternative to having the change at the CPE?
> Yes this is harder for routers in the network.

simple fq_codel on both ends of the bottleneck connection works quite = well
without any configuration. Cake adds some additional fairness = capabilities and
has a mode to work around the router on the other end of the bottleneck = not
doing active queue management

>> If you can point at the dramatic decrease in latency, with no = bandwidth losses, that Starlink has achieved on existing hardware, that = may help.
>
> This is good to know for the engineers. This adds confusion with = the subscribers.
>
>>
>> There are a number of ISPs around the world that have = implemented active queue management and report very good results from = doing so.
>
> Can we get these ISPs to publically report how they have achieved = great latency reduction?
> We can help them get credit for caring about their subscribers. It = would/could be a (short term) competitive advantage.
> Of course their competitors will (might) adopt these changes and = eliminate the advantage, BUT the subscribers will retain glow of the = initial marketing for a much longer time.

several of them have done so, I think someone else posted a report from = one in
this thread.

>> But showing that their existing hardware can do it when their = upstream vendor doesn't support it is going to be hard.
>
> Is the upstream vendor a network provider or a computing center?
> Getting good latency from the subscriber, through the access = network to the edge computing center and CDNs would be great. The CDNs = would harvest the benefits. The other computing configurations would = have make the change to be competitive.

I'm talking about the manufacturer of the routers that the ISPs deploy = at the
last hop before getting to the subscriber, and the router on the = subscriber end
of the link (although most of those are running some variation of = openWRT, so
turning it on would not be significant work for the manufacturer)

> We wouild have done our part at pushing the next round of = adoption.

Many of us have been pushing this for well over a decade. Getting = Starlink's
attention to address their bufferbloat issues is a major success.

David Lang

> Gene
>
>>
>> David Lang
>>
>>>
>>> We will want to show the human visible impact and not = debate good or not 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 vendors 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> 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 if 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 campaign.
>>>>>
>>>>> Gene
>>>>>
>>>>>
>>>>>> On Apr 30, 2024, at 2:36 PM, David Lang <david@lang.hm <mailto:david@lang.hm> <mailto: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 = 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 scenarios.
>>>>>>>
>>>>>>> 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 email 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

= --Apple-Mail=_EB4997F3-2B7C-41B6-8EB5-97688F8EE7C6-- --Apple-Mail=_7E355C67-4760-4149-A438-EA91583536BB 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/8FiYdKmAFAmYyveYACgkQv0/8FiYd KmCV4A/+OVFuIaVgzX3/zHknzaJAp/YxpC4BH/aYwl30zDU4egZT8G7GtaBu2Wbz 4LMNDLnM7cdWP/ANwkEM3AWKXELtkmgYxuzIgIq2Zo7VGts4BEORo6dIE1RQj6kz 7ME8hnKIi8s4812gU/9UTdK8g/+zQNLrq3LnpQcG8UvtQCIF//xh+swl5sEOrJtc z3Ld70QHtbStfAuUw2CUkTTMDzjRg6F+vCxsigfPxh9XaEACZBxyGPiqf12RJVG/ F+GSZH2HEkIPP5xbGK/NTlNcxqb/el78GRr+Doga4XWguadOe19aoaWXhR+O7L9T oV2DQkb5Ezp99i+KFcseJQjfgg+a1HwmZgDGrLoHGMlApxC0FEPTp0g+1c0PC6h9 DAMmMda6Ia/FMu9GcWd5piesG/ul2rro9DnIEx8wBd326LcLieGO3TAoSI6pXJqM SmFsN/YsJkliK6XOlkddYs1/08rxXDuuRet5YlSR9GNKLpPP49B4pdBrR+EDtWyA +NsDFMymxg/YKIS9jMXs1Cg+U6X10NkuSqXGerHYDEUyVwnlROROb44wbO8ksNoc QUIXYmSFKjKq4r5w0aUNvzYDLFgd/R/ERGq5Sa0AAO3XH4Rwsm784CC4PygQr+xC fAkaCMXaHr7hUDxMSWFaY9Y5d3h4DGpXTFvhInIRMJ0ZXXPweDs= =T3y3 -----END PGP SIGNATURE----- --Apple-Mail=_7E355C67-4760-4149-A438-EA91583536BB--