From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vsmx001.dclux.xion.oxcs.net (vsmx001.dclux.xion.oxcs.net [185.74.65.81]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5E6263B29E for ; Fri, 16 Jul 2021 13:31:50 -0400 (EDT) Received: from proxy-2.proxy.oxio.ns.xion.oxcs.net (proxy-2.proxy.oxio.ns.xion.oxcs.net [83.61.18.4]) by mx-out.dclux.xion.oxcs.net (Postfix) with SMTP id 8F0218C09E0; Fri, 16 Jul 2021 17:31:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dclux.xion.oxcs.net; s=mail1; t=1626456709; bh=DABDI4ol3aqs/plDZhfXkDursFMQVZ5HEtLIAwg60O4=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=oMzIETkHkW4XwdXEFC0mJo7Ey61T6kXLpm5+SF2OZZKsKCVdn2DBOrc9KW1Dfuzhu /4OAI4nYU7yV03430fVEwxCvJbt5NV6FREr3E8EoNBlPlWILiwowChprVqL1VXMSlK I1dpej8ONE8tlVX2ziH3xZvuBSrmylIxSYRFx3FezOHF13EkNNEjsRkjaaBsk9uBN8 Y+32mZgXdNNRGg4XQLjG+htwTeh7XEdEz1y7J08FaG+WbrOqHMtxy36sfjpeinGhWu h3RN92gNNdRb2dNXYku528FJVc11wF1lIp2dM1o5SRwDWkSzWXUEy+T0sB8qgrWgSe ejxRCBtF9QhwA== Date: Fri, 16 Jul 2021 19:31:37 +0200 From: Mike Puchol To: David Lang , Nathan Owens Cc: "=?utf-8?Q?starlink=40lists.bufferbloat.net?=" , "David P. Reed" Message-ID: In-Reply-To: References: <1625856001.74681750@apps.rackspace.com> X-Readdle-Message-ID: a86674b4-0d52-4f16-92e3-deecb2badfb3@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="60f1c27e_542289ec_bde9" X-VadeSecure-Status: LEGIT X-VADE-STATUS: LEGIT Subject: Re: [Starlink] Starlink and bufferbloat status? 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: Fri, 16 Jul 2021 17:31:50 -0000 --60f1c27e_542289ec_bde9 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Satellite optical links are useful to extend coverage to areas where you = don=E2=80=99t have gateways - thus, they will introduce additional latenc= y compared to two space segment hops (terminal to satellite -> satellite = to gateway). If you have terminal to satellite, two optical hops, then fi= nal satellite to gateway, you will have more latency, not less. We are being =E2=80=9Csold=E2=80=9D optical links for what they are not I= MHO. Best, Mike On Jul 16, 2021, 19:29 +0200, Nathan Owens , wrote: > > As there are more satellites, the up down time will get closer to 4-5= ms rather then the =7E7ms you list > > Possibly, if you do steering to always jump to the lowest latency satel= lite. > > > with laser relays in orbit, and terminal to terminal routing in orbit= , there is the potential for the theoretical minimum to tend lower > Maybe for certain users really in the middle of nowhere, but I did the = best-case math for =22bent pipe=22 in Seattle area, which is as good as i= t gets. > > > On =46ri, Jul 16, 2021 at 10:24 AM David Lang wrote= : > > > hey, it's a good attitude to have :-) > > > > > > Elon tends to set 'impossible' goals, miss the timeline a bit, and = come very > > > close to the goal, if not exceed it. > > > > > > As there are more staellites, the up down time will get closer to 4= -5ms rather > > > then the =7E7ms you list, and with laser relays in orbit, and termi= nal to terminal > > > routing in orbit, there is the potential for the theoretical minimu= m to tend > > > lower, giving some headroom for other overhead but still being in t= he 20ms > > > range. > > > > > > David Lang > > > > > > =C2=A0 On =46ri, 16 Jul 2021, Nathan Owens wrote: > > > > > > > Elon said =22foolish packet routing=22 for things over 20ms=21 Wh= ich seems crazy > > > > if you do some basic math: > > > > > > > >=C2=A0 =C2=A0- Sat to User Terminal distance: 550-950km air/vacuum= : 1.9 - 3.3ms > > > >=C2=A0 =C2=A0- Sat to GW distance: 550-950km air/vacuum: 1.9 - 3.3= ms > > > >=C2=A0 =C2=A0- GW to PoP Distance: 50-800km fiber: 0.25 - 4ms > > > >=C2=A0 =C2=A0- PoP to Internet Distance: 50km fiber: 0.25 - 0.5ms > > > >=C2=A0 =C2=A0- Total one-way delay: 4.3 - 11.1ms > > > >=C2=A0 =C2=A0- Theoretical minimum RTT: 8.6ms - 22.2ms, call it 15= .4ms > > > > > > > > This includes no transmission delay, queuing delay, > > > > processing/fragmentation/reassembly/etc, and no time-division mul= tiplexing. > > > > > > > > On =46ri, Jul 16, 2021 at 10:09 AM David Lang w= rote: > > > > > > > >> I think it depends on if you are looking at datacenter-to-datace= nter > > > >> latency of > > > >> home to remote datacenter latency :-) > > > >> > > > >> my rule of thumb for cross US ping time has been 80-100ms latenc= y (but > > > >> it's been > > > >> a few years since I tested it). > > > >> > > > >> I note that an article I saw today said that Elon is saying that= latency > > > >> will > > > >> improve significantly in the near future, that up/down latency i= s =7E20ms > > > >> and the > > > >> additional delays pushing it to the 80ms range are 'stupid packe= t routing' > > > >> problems that they are working on. > > > >> > > > >> If they are still in that level of optimization, it doesn't surp= rise me > > > >> that > > > >> they haven't really focused on the bufferbloat issue, they have = more > > > >> obvious > > > >> stuff to fix first. > > > >> > > > >> David Lang > > > >> > > > >> > > > >>=C2=A0 =C2=A0On =46ri, 16 Jul 2021, Wheelock, Ian wrote: > > > >> > > > >>> Date: =46ri, 16 Jul 2021 10:21:52 +0000 > > > >>> =46rom: =22Wheelock, Ian=22 > > > >>> To: David Lang , David P. Reed > > > >>> Cc: =22starlink=40lists.bufferbloat.net=22 > > > >>> Subject: Re: =5BStarlink=5D Starlink and bufferbloat status=3F > > > >>> > > > >>> Hi David > > > >>> In terms of the Latency that David (Reed) mentioned for Califor= nia to > > > >> Massachusetts of about 17ms over the public internet, it seems a= bit faster > > > >> than what I would expect. My own traceroute via my VDSL link sho= ws 14ms > > > >> just to get out of the operator network. > > > >>> > > > >>> https://www.wondernetwork.com=C2=A0 is a handy tool for checkin= g geographic > > > >> ping perf between cities, and it shows a min of about 66ms for p= ings > > > >> between Boston and San Diego > > > >> https://wondernetwork.com/pings/boston/San%20Diego (so about 33m= s for > > > >> 1-way transfer). > > > >>> > > > >>> Distance wise this is about 4,100 KM (2,500 M), and =402/3 spee= d of light > > > >> (through a pure fibre link of that distance) the propagation tim= e is just > > > >> over 20ms. If the network equipment between the Boston and San D= iego is > > > >> factored in, with some buffering along the way, 33ms does seem q= uite > > > >> reasonable over the 20ms for speed of light in fibre for that 1-= way transfer > > > >>> > > > >>> -Ian Wheelock > > > >>> > > > >>> =46rom: Starlink on = behalf of > > > >> David Lang > > > >>> Date: =46riday 9 July 2021 at 23:59 > > > >>> To: =22David P. Reed=22 > > > >>> Cc: =22starlink=40lists.bufferbloat.net=22 > > > >>> Subject: Re: =5BStarlink=5D Starlink and bufferbloat status=3F > > > >>> > > > >>> IIRC, the definition of 'low latency' for the =46CC was somethi= ng like > > > >> 100ms, and Musk was predicting <40ms. roughly competitive with l= andlines, > > > >> and worlds better than geostationary satellite (and many > > > >>> External (mailto:david=40lang.hm) > > > >>> > > > >> https://shared.outlook.inky.com/report=3Fid=3DY29tbXNjb3BlL2lhbi= 53aGVlbG9ja0Bjb21tc2NvcGUuY29tL2I1Mz=46jZDA4OTZmMWI0Yzc5NzdiOTIzNmY3MTAzM= 2MxLzE2MjU4NzE1NDkuNjU=3D=23key=3D19e8545676e28e577c813de83a4cf1dc > > > >>=C2=A0 https://www.inky.com/banner-faq/=C2=A0 https://www.inky.co= m > > > >>> > > > >>> IIRC, the definition of 'low latency' for the =46CC was somethi= ng like > > > >> 100ms, and > > > >>> Musk was predicting <40ms. > > > >>> > > > >>> roughly competitive with landlines, and worlds better than geos= tationary > > > >>> satellite (and many wireless ISPs) > > > >>> > > > >>> but when doing any serious testing of latency, you need to be w= ired to > > > >> the > > > >>> router, wifi introduces so much variability that it swamps the = signal. > > > >>> > > > >>> David Lang > > > >>> > > > >>> On =46ri, 9 Jul 2021, David P. Reed wrote: > > > >>> > > > >>>> Date: =46ri, 9 Jul 2021 14:40:01 -0400 (EDT) > > > >>>> =46rom: David P. Reed > > > >>>> To: starlink=40lists.bufferbloat.net > > > >>>> Subject: =5BStarlink=5D Starlink and bufferbloat status=3F > > > >>>> > > > >>>> > > > >>>> Early measurements of performance of Starlink have shown signi= ficant > > > >> bufferbloat, as Dave Taht has shown. > > > >>>> > > > >>>> But...=C2=A0 Starlink is a moving target. The bufferbloat isn'= t a hardware > > > >> issue, it should be completely manageable, starting by simple fi= rmware > > > >> changes inside the Starlink system itself. =46or example, implem= enting > > > >> fq=5Fcodel so that bottleneck links just drop packets according = to the Best > > > >> Practices R=46C, > > > >>>> > > > >>>> So I'm hoping this has improved since Dave's measurements. How= much has > > > >> it improved=3F What's the current maximum packet latency under f= ull > > > >> load,=C2=A0 Ive heard anecdotally that a friend of a friend gets= 84 msec. *ping > > > >> times under full load*, but he wasn't using flent or some other = measurement > > > >> tool of good quality that gives a true number. > > > >>>> > > > >>>> 84 msec is not great - it's marginal for Zoom quality experien= ce (you > > > >> want latencies significantly less than 100 msec. as a rule of th= umb for > > > >> teleconferencing quality). But it is better than Dave's measurem= ents showed. > > > >>>> > > > >>>> Now Musk bragged that his network was =22low latency=22 unlike= other high > > > >> speed services, which means low end-to-end latency.=C2=A0 That g= ot him > > > >> permission from the =46CC to operate Starlink at all. His number= was, I > > > >> think, < 5 msec. 84 is a lot more than 5. (I didn't believe 5, b= ecause he > > > >> probably meant just the time from the ground station to the term= inal > > > >> through the satellite. But I regularly get 17 msec. between Cali= fornia and > > > >> Massachusetts over the public Internet) > > > >>>> > > > >>>> So 84 might be the current status. That would mean that someon= e at > > > >> Srarlink might be paying some attention, but it is a long way fr= om what > > > >> Musk implied. > > > >>>> > > > >>>> > > > >>>> PS: I forget the number of the R=46C, but the number of packet= s queued on > > > >> an egress link should be chosen by taking the hardware bottlenec= k > > > >> throughput of any path, combined with an end-to-end Internet und= erlying > > > >> delay of about 10 msec. to account for hops between source and d= estination. > > > >> Lets say Starlink allocates 50 Mb/sec to each customer, packets = are limited > > > >> to 10,000 bits (1500 * 8), so the outbound queues should be limi= ted to > > > >> about 0.01 * 50,000,000 / 10,000, which comes out to about 250 p= ackets from > > > >> each terminal of buffering, total, in the path from terminal to = public > > > >> Internet, assuming the connection to the public Internet is not = a problem. > > > >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > > >>> Starlink mailing list > > > >>> Starlink=40lists.bufferbloat.net > > > >>> > > > >> https://secure-web.cisco.com/1sNc=5F-1HhGCW7xdirt=5FlAoAy5Nn5T6U= A85Scjn5BR7QHXtumhrf6RKn78SuRJG7DUKI3duggU9g6hJKW-Ze07HTczYqB9mBpIeALqk5d= rQ7nMvM8K7JbWfUbPR7JSNrI75UjiNXQk0wslBfoOTvkMlRj5eMOZhps7DMGBRQTVAeTd5vwX= oQtDgS6zLCcJkrcO2S9MRSCC4f1I17SzgQJIwqo3LEwuN6lD-pkX0M=46LqGr2zzsHw5eapd-= VBlHu5reC4-OEn2zHkb7HNzS1pcue=466tsUE1v=46RsWs2SIOwU5MvbKe3J3Q6NRQ40cHI1A= Gd-i/https://lists.bufferbloat.net/listinfo/starlink > > > >>> > > > >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > > >> Starlink mailing list > > > >> Starlink=40lists.bufferbloat.net > > > >> https://lists.bufferbloat.net/listinfo/starlink > > > >> > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Starlink mailing list > Starlink=40lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink --60f1c27e_542289ec_bde9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Satellite optical links are useful to extend covera= ge to areas where you don=E2=80=99t have gateways - thus, they will intro= duce additional latency compared to two space segment hops (terminal to s= atellite -> satellite to gateway). If you have terminal to satellite, = two optical hops, then final satellite to gateway, you will have more lat= ency, not less.

We are being =E2=80=9Csold=E2=80=9D optical links for what they are not I= MHO.

Best,

Mike
On Jul 16, 2021, 19:29 +0200, Natha= n Owens <nathan=40nathan.io>, wrote:
> As there are more satellites, the up down time = will get closer to 4-5ms rather then the =7E7ms you list

Possibly, if you do steering to always jump to the lowest latency sa= tellite.&=23160;

> with laser relays in orbit, and terminal to terminal routing in= orbit, there is the potential for the theoretical minimum to tend lower<= br />
Maybe for certain users really in the middle of nowhere, but I did t= he best-case math for =22bent pipe=22 in Seattle area, which is as good a= s it gets.

On =46ri, Jul 16, 2021 at= 10:24 AM David Lang <david=40l= ang.hm> wrote:
hey, it's a= good attitude to have :-)

Elon tends to set 'impossible' goals, miss the timeline a bit, and come v= ery
close to the goal, if not exceed it.

As there are more staellites, the up down time will get closer to 4-5ms r= ather
then the =7E7ms you list, and with laser relays in orbit, and terminal to= terminal
routing in orbit, there is the potential for the theoretical minimum to t= end
lower, giving some headroom for other overhead but still being in the 20m= s
range.

David Lang

&=23160; On =46ri, 16 Jul 2021, Nathan Owens wrote:

> Elon said =22foolish packet routing=22 for things over 20ms=21 Which= seems crazy
> if you do some basic math:
>
>&=23160; &=23160;- Sat to User Terminal distance: 550-950km air/vacuu= m: 1.9 - 3.3ms
>&=23160; &=23160;- Sat to GW distance: 550-950km air/vacuum: 1.9 - 3.= 3ms
>&=23160; &=23160;- GW to PoP Distance: 50-800km fiber: 0.25 - 4ms
>&=23160; &=23160;- PoP to Internet Distance: 50km fiber: 0.25 - 0.5ms=
>&=23160; &=23160;- Total one-way delay: 4.3 - 11.1ms
>&=23160; &=23160;- Theoretical minimum RTT: 8.6ms - 22.2ms, call it 1= 5.4ms
>
> This includes no transmission delay, queuing delay,
> processing/fragmentation/reassembly/etc, and no time-division multip= lexing.
>
> On =46ri, Jul 16, 2021 at 10:09 AM David Lang <david=40lang.hm> wrot= e:
>
>> I think it depends on if you are looking at datacenter-to-datace= nter
>> latency of
>> home to remote datacenter latency :-)
>>
>> my rule of thumb for cross US ping time has been 80-100ms latenc= y (but
>> it's been
>> a few years since I tested it).
>>
>> I note that an article I saw today said that Elon is saying that= latency
>> will
>> improve significantly in the near future, that up/down latency i= s =7E20ms
>> and the
>> additional delays pushing it to the 80ms range are 'stupid packe= t routing'
>> problems that they are working on.
>>
>> If they are still in that level of optimization, it doesn't surp= rise me
>> that
>> they haven't really focused on the bufferbloat issue, they have = more
>> obvious
>> stuff to fix first.
>>
>> David Lang
>>
>>
>>&=23160; &=23160;On =46ri, 16 Jul 2021, Wheelock, Ian wrote:
>>
>>> Date: =46ri, 16 Jul 2021 10:21:52 +0000
>>> =46rom: =22Wheelock, Ian=22 <ian.wheelock=40commscope.= com>
>>> To: David Lang <david=40lang.hm>, David P. Reed <dpreed=40deepp= lum.com>
>>> Cc: =22starlink=40lists.bufferbloat.net=22 <starlink=40lists.bufferbloat.net>
>>> Subject: Re: =5BStarlink=5D Starlink and bufferbloat status=3F=
>>>
>>> Hi David
>>> In terms of the Latency that David (Reed) mentioned for Cali= fornia to
>> Massachusetts of about 17ms over the public internet, it seems a= bit faster
>> than what I would expect. My own traceroute via my VDSL link sho= ws 14ms
>> just to get out of the operator network.
>>>
>>> https://www.wondernetwork.com&=23160= ; is a handy tool for checking geographic
>> ping perf between cities, and it shows a min of about 66ms for p= ings
>> between Boston and San Diego
>> https://wondernetwork.com= /pings/boston/San%20Diego (so about 33ms for
>> 1-way transfer).
>>>
>>> Distance wise this is about 4,100 KM (2,500 M), and =402/3 s= peed of light
>> (through a pure fibre link of that distance) the propagation tim= e is just
>> over 20ms. If the network equipment between the Boston and San D= iego is
>> factored in, with some buffering along the way, 33ms does seem q= uite
>> reasonable over the 20ms for speed of light in fibre for that 1-= way transfer
>>>
>>> -Ian Wheelock
>>>
>>> =46rom: Starlink <starlink-bounces=40lists= .bufferbloat.net> on behalf of
>> David Lang <david=40lang.hm>
>>> Date: =46riday 9 July 2021 at 23:59
>>> To: =22David P. Reed=22 <dpreed=40deepplum.com>
>>> Cc: =22starlink=40lists.bufferbloat.net=22 <starlink=40lists.bufferbloat.net>
>>> Subject: Re: =5BStarlink=5D Starlink and bufferbloat status=3F=
>>>
>>> IIRC, the definition of 'low latency' for the =46CC was some= thing like
>> 100ms, and Musk was predicting <40ms. roughly competitive wit= h landlines,
>> and worlds better than geostationary satellite (and many
>>> External (mailto:david=40lang.hm)
>>>
>> https://shared.o= utlook.inky.com/report=3Fid=3DY29tbXNjb3BlL2lhbi53aGVlbG9ja0Bjb21tc2NvcGU= uY29tL2I1Mz=46jZDA4OTZmMWI0Yzc5NzdiOTIzNmY3MTAzM2MxLzE2MjU4NzE1NDkuNjU=3D= =23key=3D19e8545676e28e577c813de83a4cf1dc
>>&=23160; https://www.inky.com/banner-faq/&=23160; https://www.inky.com
>>>
>>> IIRC, the definition of 'low latency' for the =46CC was some= thing like
>> 100ms, and
>>> Musk was predicting <40ms.
>>>
>>> roughly competitive with landlines, and worlds better than g= eostationary
>>> satellite (and many wireless ISPs)
>>>
>>> but when doing any serious testing of latency, you need to b= e wired to
>> the
>>> router, wifi introduces so much variability that it swamps t= he signal.
>>>
>>> David Lang
>>>
>>> On =46ri, 9 Jul 2021, David P. Reed wrote:
>>>
>>>> Date: =46ri, 9 Jul 2021 14:40:01 -0400 (EDT)
>>>> =46rom: David P. Reed <dpreed=40deepplum.com>
>>>> To: starlink=40lists.bufferbloat.net
>>>> Subject: =5BStarlink=5D Starlink and bufferbloat status=3F=
>>>>
>>>>
>>>> Early measurements of performance of Starlink have shown= significant
>> bufferbloat, as Dave Taht has shown.
>>>>
>>>> But...&=23160; Starlink is a moving target. The bufferbl= oat isn't a hardware
>> issue, it should be completely manageable, starting by simple fi= rmware
>> changes inside the Starlink system itself. =46or example, implem= enting
>> fq=5Fcodel so that bottleneck links just drop packets according = to the Best
>> Practices R=46C,
>>>>
>>>> So I'm hoping this has improved since Dave's measurement= s. How much has
>> it improved=3F What's the current maximum packet latency under f= ull
>> load,&=23160; Ive heard anecdotally that a friend of a friend ge= ts 84 msec. *ping
>> times under full load*, but he wasn't using flent or some other = measurement
>> tool of good quality that gives a true number.
>>>>
>>>> 84 msec is not great - it's marginal for Zoom quality ex= perience (you
>> want latencies significantly less than 100 msec. as a rule of th= umb for
>> teleconferencing quality). But it is better than Dave's measurem= ents showed.
>>>>
>>>> Now Musk bragged that his network was =22low latency=22 = unlike other high
>> speed services, which means low end-to-end latency.&=23160; That= got him
>> permission from the =46CC to operate Starlink at all. His number= was, I
>> think, < 5 msec. 84 is a lot more than 5. (I didn't believe 5= , because he
>> probably meant just the time from the ground station to the term= inal
>> through the satellite. But I regularly get 17 msec. between Cali= fornia and
>> Massachusetts over the public Internet)
>>>>
>>>> So 84 might be the current status. That would mean that = someone at
>> Srarlink might be paying some attention, but it is a long way fr= om what
>> Musk implied.
>>>>
>>>>
>>>> PS: I forget the number of the R=46C, but the number of = packets queued on
>> an egress link should be chosen by taking the hardware bottlenec= k
>> throughput of any path, combined with an end-to-end Internet und= erlying
>> delay of about 10 msec. to account for hops between source and d= estination.
>> Lets say Starlink allocates 50 Mb/sec to each customer, packets = are limited
>> to 10,000 bits (1500 * 8), so the outbound queues should be limi= ted to
>> about 0.01 * 50,000,000 / 10,000, which comes out to about 250 p= ackets from
>> each terminal of buffering, total, in the path from terminal to = public
>> Internet, assuming the connection to the public Internet is not = a problem.
>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
>>> Starlink mailing list
>>> Starlink=40lists.bufferbloat.net
>>>
>> https://secure-web.cisco.com/1sN= c=5F-1HhGCW7xdirt=5FlAoAy5Nn5T6UA85Scjn5BR7QHXtumhrf6RKn78SuRJG7DUKI3dugg= U9g6hJKW-Ze07HTczYqB9mBpIeALqk5drQ7nMvM8K7JbWfUbPR7JSNrI75UjiNXQk0wslBfoO= TvkMlRj5eMOZhps7DMGBRQTVAeTd5vwXoQtDgS6zLCcJkrcO2S9MRSCC4f1I17SzgQJIwqo3L= EwuN6lD-pkX0M=46LqGr2zzsHw5eapd-VBlHu5reC4-OEn2zHkb7HNzS1pcue=466tsUE1v=46= RsWs2SIOwU5MvbKe3J3Q6NRQ40cHI1AGd-i/https://lists.bufferbloat.net/listinf= o/starlink
>>>
>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
>> Starlink mailing list
>> Starlink=40lists.bufferbloat.net
>> https://lists.bufferbloat.= net/listinfo/starlink
>>
>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Starlink mailing list
Starlink=40lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
--60f1c27e_542289ec_bde9--