From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1D58B3CB37 for ; Tue, 27 Sep 2022 02:36:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1664260599; bh=5l1E1R8GdjKJvCI5IwY4O0sRe8UXqgX87WwhPgy0ex8=; h=X-UI-Sender-Class:Date:From:To:CC:Subject:In-Reply-To:References; b=iM0z2wNqGCLkaj7D0jjX5mIBwghhUAGm1IMBEFm/cbnqWLvrwpPb1ZgT6W4xZl08x VnSFkES08o+YlDWtSSGZWByC2tNVnE//Hfn/ZEpBhJDkkyJXF4N82AkDj9HrNIy1Xw 1PlhmqR01NX8sIER1waGhrx/WyMnvUgZSLkmay3Y= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [127.0.0.1] ([80.187.110.211]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MAOJV-1oWDdt2lMh-00BqBe; Tue, 27 Sep 2022 08:36:38 +0200 Date: Tue, 27 Sep 2022 08:36:33 +0200 From: Sebastian Moeller To: Eugene Y Chang CC: Eugene Chang , David Lang , Dave Taht via Starlink User-Agent: K-9 Mail for Android In-Reply-To: <8E6A87E1-8424-44BE-B582-DF3C8424F584@ieee.org> References: <060F7695-D48E-413C-9501-54ECC651ABEB@cable.comcast.com> <07C46DD5-7359-410E-8820-82B319944618@alum.mit.edu> <39E525B8-D356-4F76-82FF-F1F0B3183908@ieee.org> <498p2p23-on1q-op89-p518-1874r3r6rpo@ynat.uz> <8DC6E5EE-2B46-4815-A909-E326507E95B1@ieee.org> <2086C010-B91E-450A-A77F-D0840BC5FCC1@gmx.de> <8E6A87E1-8424-44BE-B582-DF3C8424F584@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Jy52kCJu7vnYu/Kxf+8JH0VWU8YCERg7t619MZidaDndvJQ3tIy gltcdyW8Q+v4EYcy5EzGf87O1jcVEDLI6vwLWUFKTcsRqAN+hpuVoh8qcMbkRNr2wqMDX6z 7pOM1iper/yWq3fzUv/6JadAbWCpXKlgZ/gC7YSBuXwd0w3Fo0oBi+0YdqZJRcdDxj33MIc jDpU38MIlnY3ykxBWz6vQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:V3Vlk5OHXNQ=:sLh7ezfd6OUKmCyqUOWNv6 pLHBzFUzAyNsuFnlhXE2gAKMhDdmY925WGVaSeRU5203nkECClDzU9AucmhPDBa9qRoNOHrtR VKs4wPNkCCpagnXsWiv+HLIw7aWcr0hqMFlC0RPdUGW4jAMlqE6+5aHxVYp/PbCiS5p+JZqBj VpGuoL6BhoO2Bl58DZMhE3Zu3ltfRfiLmMAwsl53qtLvRlUmopHQRoRlUROhpsHdevI9fZIYl Lul6TuBE8DB7yzFj3tAbcEYGEroyWeMOydZau51eP3KoM/m59g0bd/dzFaUgfk9i9zBxDE1P3 sKxlpeH7eVVDNuNFRw7OdKNzhFBs01DEqvW2ARZVjsczx2N9rwQAuCXDDY2IFmfv57tc37sdy BlBACwJVpzhyg2csu49pf9DMIbuvf//o1MsYyzG8xmxEkUyPKQRyM5r/ZR3tP8b2TIweBZ0SN 3uqNx7AfuyeHut2GVpBWJXIngZThbrCbfN16q55t4+dT3xTO8SV0Z5ybOtu8Qvrz1bWoqn7Xy aK2zLlaoUDlfEj1ov3nhsWjEFdnSkuo8qmGJptz7KjOeOHhPrbJkyZYCl/8BKupdUzie6O+4A rOAJSlrKbNzm/3ZShk6gFNvCPqpNlYuhg9cnmO9WVceOsBcmQttvOYyXzH6xnGbGbgwxaSseB anFx5fc7dpAozd+NSQrilxXjuOpB61SoY+ESvVVc3VtdmBoyo01J7uhti9vTc8CMuNcPLH+jj SlTgbstjujqKh8KqnnvcL92ZFy+lOkdT/pqKjUzyDy7DNm4nLLzgvqsPpinWNmbofXu8CtlKW X31NW1dQ7nGN0i8ib7vyTmtJyXadSG2jHh4qeJ7GFnJBFEnAEWAEYw/yEOo5g6LtlXpmxySVA QpWSl6Oa/ym/3vvGlbprESvYa9286EVTyb3gqUqIGaHRCdeZyjGXcj9Kf9wMAL0CE0T2NXqH7 MRgPB1GywgKVMIWX/PVrej4loKteFqufzDJNiAxWtobchnME88nRYydLZy4STMtWaQ1E6oKXw dwfFdL9mMU/Qi27ZFvNxPhXRqgFSdbmP2X/33HitbCFqsJ1/JNCfuqfWtkQGUDNkJSlcqskeg hNSBsI9yLPg/JUQKJlLMFmnXod7nauWJMqDqZ06FnfCe1aYGyjr2bRdrd1vkEDoqzHJ9huWBu /I6iUcGAgP6NeI5r63eWu6ejl7 Subject: Re: [Starlink] It's still the starlink latency... 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, 27 Sep 2022 06:36:43 -0000 Hi Gene, On 27 September 2022 05:47:48 CEST, Eugene Y Chang wrote: >> [SM] I note that typically for ingress shaping a post-true-bottleneck s= haper will not work unless we create an artificial bottleneck by shaping th= e traffic to below true bottleneck (thereby creating a new true but artific= ial bottleneck so the queue develops at a point where we can control it)=2E >> Also if the difference between "true structural" and artificial bottle= neck is small in comparison to the traffic inrush we can see "traffic back-= spill" into the typically oversized and under-managed upstream buffers, but= for reasonably well behaved that happens relatively rarely=2E Rarely enoug= h that ingress traffic shaping noticeably improves latency-under-load in sp= ite of not beeing a guranteed solution=2E > >Perhaps I am overthinking this=2E In general, I don=E2=80=99t think this = really works=2E [SM] Yes this method's effectiveness depends on having control over the bo= ttleneck and that in turn requires seeing all traffic traversing the bottle= neck link=2E It turns out that for a competent ISP the relevant bottleneck = is often the actual internet access link itself, that is why sqm on a home = router in practice works often very well even though in theory it looks unl= ikely to do so=2E Consider a router with M ports from the network edge and N ports toward t= he network core=2E You are only trying to influence one of the M ports=2E E= ven if N=3D1, what actually happens with the buffering at N depends on all = the traffic, not just the traffic you are shaping=2E [SM] Not that an uncommon situation, thinking e=2Eg=2E of a DSLAM, OLT or = CMTS where the aggregate of access speeds exceeds the uplink capacity, and = the ISP misjudged the usage and under-provided the uplink*=2E The more remo= te the bottleneck is and the less of the traversing flows we can control th= e more problematic the debloating exercise gets=2E=2E=2E=2E *) I use this phrasing because these uplinks are effectively always smalle= r than the aggregate marketed rates on such a device, aka the ISP oversubsc= ribes the unit, but that is a theoretical problem as long as the actual agg= regated traffic does not exceed the units uplink capacity=2E Dimensioning s= uch uplinks to the worst case would likely either mean really high prices o= r really low contracted rates=2E So oversubscription per se is fine with me= , as long as the ISP manages to handle the real traffic for most of the tim= e, but I digress=2E > >> [SM] Well, sometimes such links are congested too for economic reasons= =E2=80=A6 > >It is always economic=2E The network is always undersized because of some= economic (or management) policy=2E [SM] I was thinking about a specific case of a T1-ISP that notoriously let= 's his links to other T1 run hot during peak usage times, to incentivise co= ntent providers to buy direct access (technically they sell 'transit' but a= t a above market price so content providers are unlikely to use this link f= or traffic not intended for that ISP's AS or its single-homed customers=2E > >These days it is more and more true with the preference of taking fiber t= o the subscriber=2E It is physically possible to send more traffic to the n= etwork than the router can handle=2E=20 [SM] That depends on the router ;), but yes with access speeds reaching cl= ose to 10 Gbps for some european ISPs home neyworking gear tends to be out = of its league, with accelerators helping at least speed tests to limp along= well enough=2E My ISP happily markets 1Gbps service but the fine print of their contract = says they don=E2=80=99t promise more than 700Mbps=2E [SM] The question is what is the consequence/remedy if the ISP does not fu= lfill that promise? Over here ISPs need to publish a set of rates in a stan= dardized format and in case of not delivering these rates customers can eit= her opt for canceling the contract or adjusting the price they pay to the r= elative fulfillment of the contracted rates=2E The details however are bein= g worked out ATM=2E Worst, I waited 9 months for them to resolve why I was only getting 300Mb= ps on my 1Gbps service (oops, sorry my 700Mbps service)=2E [SM] I guess mass market internet access is a low margin business, where e= xpert debugging time is precious=2E I hope they at least gave you a rebate = for that time=2E Regards Sebastian > > >Gene >---------------------------------------------- >Eugene Chang >IEEE Senior Life Member >eugene=2Echang@ieee=2Eorg >781-799-0233 (in Honolulu) > > > >> On Sep 26, 2022, at 11:29 AM, Sebastian Moeller wro= te: >>=20 >> Hi David, >>=20 >>> On Sep 26, 2022, at 23:22, David Lang wrote: >>>=20 >>> On Mon, 26 Sep 2022, Eugene Y Chang wrote: >>>=20 >>>>> On Sep 26, 2022, at 11:01 AM, Sebastian Moeller = wrote: >>>>>=20 >>>>> Hi Eugene, >>>>>=20 >>>>>=20 >>>>>> On Sep 26, 2022, at 22:54, Eugene Y Chang via Starlink > wrote: >>>>>>=20 >>>>>> Ok, we are getting into the details=2E I agree=2E >>>>>>=20 >>>>>> Every node in the path has to implement this to be effective=2E >>>>>=20 >>>>> Amazingly the biggest bang for the buck is gotten by fixing those n= odes that actually contain a network path's bottleneck=2E Often these are p= retty stable=2E So yes for fully guaranteed service quality all nodes would= need to participate, but for improving things noticeably it is sufficient = to improve the usual bottlenecks, e=2Eg=2E for many internet access links t= he home gateway is a decent point to implement better buffer management=2E = (In short the problem are over-sized and under-managed buffers, and one of = the best solution is better/smarter buffer management)=2E >>>>>=20 >>>>=20 >>>> This is not completely true=2E Say the bottleneck is at node N=2E Dur= ing the period of congestion, the upstream node N-1 will have to buffer=2E = When node N recovers, the bufferbloat at N-1 will be blocking until the buf= ferbloat drains=2E Etc=2E etc=2E Making node N better will reduce the exte= nt of the backup at N-1, but N-1 should implement the better code=2E >>>=20 >>> only if node N and node N-1 handle the same traffic with the same link= speeds=2E In practice this is almost never the case=2E >>=20 >> [SM] I note that typically for ingress shaping a post-true-bottleneck = shaper will not work unless we create an artificial bottleneck by shaping t= he traffic to below true bottleneck (thereby creating a new true but artifi= cial bottleneck so the queue develops at a point where we can control it)= =2E >> Also if the difference between "true structural" and artificial bottle= neck is small in comparison to the traffic inrush we can see "traffic back-= spill" into the typically oversized and under-managed upstream buffers, but= for reasonably well behaved that happens relatively rarely=2E Rarely enoug= h that ingress traffic shaping noticeably improves latency-under-load in sp= ite of not beeing a guranteed solution=2E >>=20 >>=20 >>> Until you get to gigabit last-mile links, the last mile is almost alwa= ys the bottleneck from both sides, so implementing cake on the home router = makes a huge improvement (and if you can get it on the last-mile ISP router= , even better)=2E Once you get into the Internet fabric, bottlenecks are fa= irly rare, they do happen, but ISPs carefully watch for those and add addit= ional paths and/or increase bandwith to avoid them=2E >>=20 >> [SM] Well, sometimes such links are congested too for economic reasons= =2E=2E=2E >>=20 >> Regards >> Sebastian >>=20 >>=20 >>>=20 >>> David Lang >>>=20 >>>>>=20 >>>>>> In fact, every node in the path has to have the same prioritization= or the scheme becomes ineffective=2E >>>>>=20 >>>>> Yes and no, one of the clearest winners has been flow queueing, IMH= O not because it is the most optimal capacity sharing scheme, but because i= t is the least pessimal scheme, allowing all (or none) flows forward progre= ss=2E You can interpret that as a scheme in which flows below their capacit= y share are prioritized, but I am not sure that is the best way to look at = these things=2E >>>>=20 >>>> The hardest part is getting competing ISPs to implement and coordinat= e=2E Bufferbloat and handoff between ISPs will be hard=2E The only way to f= ix this is to get the unwashed public to care=2E Then they can say =E2=80= =9Cwe don=E2=80=99t care about the technical issues, just fix it=2E=E2=80= =9D Until then =E2=80=A6=2E=2E >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Regards >>>>> Sebastian >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Gene >>>>>> ---------------------------------------------- >>>>>> Eugene Chang >>>>>> IEEE Senior Life Member >>>>>> eugene=2Echang@ieee=2Eorg >>>>>> 781-799-0233 (in Honolulu) >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On Sep 26, 2022, at 10:48 AM, David Lang wrote: >>>>>>>=20 >>>>>>> software updates can do far more than just improve recovery=2E >>>>>>>=20 >>>>>>> In practice, large data transfers are less sensitive to latency th= an smaller data transfers (i=2Ee=2E downloading a CD image vs a video confe= rence), software can ensure better fairness in preventing a bulk transfer f= rom hurting the more latency sensitive transfers=2E >>>>>>>=20 >>>>>>> (the example below is not completely accurate, but I think it gets= the point across) >>>>>>>=20 >>>>>>> When buffers become excessivly large, you have the situation where= a video call is going to generate a small amount of data at a regular inte= rval, but a bulk data transfer is able to dump a huge amount of data into t= he buffer instantly=2E >>>>>>>=20 >>>>>>> If you just do FIFO, then you get a small chunk of video call, the= n several seconds worth of CD transfer, followed by the next small chunk of= the video call=2E >>>>>>>=20 >>>>>>> But the software can prevent the one app from hogging so much of t= he connection and let the chunk of video call in sooner, avoiding the impac= t to the real time traffic=2E Historically this has required the admin clas= sify all traffic and configure equipment to implement different treatment b= ased on the classification (and this requires trust in the classification p= rocess), the bufferbloat team has developed options (fq_codel and cake) tha= t can ensure fairness between applications/servers with little or no config= uration, and no trust in other systems to properly classify their traffic= =2E >>>>>>>=20 >>>>>>> The one thing that Cake needs to work really well is to be able to= know what the data rate available is=2E With Starlink, this changes freque= ntly and cake integrated into the starlink dish/router software would be fa= r better than anything that can be done externally as the rate changes can = be fed directly into the settings (currently they are only indirectly detec= ted) >>>>>>>=20 >>>>>>> David Lang >>>>>>>=20 >>>>>>>=20 >>>>>>> On Mon, 26 Sep 2022, Eugene Y Chang via Starlink wrote: >>>>>>>=20 >>>>>>>> You already know this=2E Bufferbloat is a symptom and not the cau= se=2E Bufferbloat grows when there are (1) periods of low or no bandwidth o= r (2) periods of insufficient bandwidth (aka network congestion)=2E >>>>>>>>=20 >>>>>>>> If I understand this correctly, just a software update cannot mak= e bufferbloat go away=2E It might improve the speed of recovery (e=2Eg=2E t= hrow away all time sensitive UDP messages)=2E >>>>>>>>=20 >>>>>>>> Gene >>>>>>>> ---------------------------------------------- >>>>>>>> Eugene Chang >>>>>>>> IEEE Senior Life Member >>>>>>>> eugene=2Echang@ieee=2Eorg >>>>>>>> 781-799-0233 (in Honolulu) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 26, 2022, at 10:04 AM, Bruce Perens = wrote: >>>>>>>>>=20 >>>>>>>>> Please help to explain=2E Here's a draft to start with: >>>>>>>>>=20 >>>>>>>>> Starlink Performance Not Sufficient for Military Applications, S= ay Scientists >>>>>>>>>=20 >>>>>>>>> The problem is not availability: Starlink works where nothing bu= t another satellite network would=2E It's not bandwidth, although others ha= ve questions about sustaining bandwidth as the customer base grows=2E It's = latency and jitter=2E As load increases, latency, the time it takes for a p= acket to get through, increases more than it should=2E The scientists who h= ave fought bufferbloat, a major cause of latency on the internet, know why= =2E SpaceX needs to upgrade their system to use the scientist's Open Source= modifications to Linux to fight bufferbloat, and thus reduce latency=2E Th= is is mostly just using a newer version, but there are some tunable paramet= ers=2E Jitter is a change in the speed of getting a packet through the netw= ork during a connection, which is inevitable in satellite networks, but wil= l be improved by making use of the bufferbloat-fighting software, and proba= bly with the addition of more satellites=2E >>>>>>>>>=20 >>>>>>>>> We've done all of the work, SpaceX just needs to adopt it by upg= rading their software, said scientist Dave Taht=2E Jim Gettys, Taht's colla= borator and creator of the X Window System, chimed in: >>>>>>>>> Open Source luminary Bruce Perens said: sometimes Starlink's lat= ency and jitter make it inadequate to remote-control my ham radio station= =2E But the military is experimenting with remote-control of vehicles on th= e battlefield and other applications that can be demonstrated, but won't ha= ppen at scale without adoption of bufferbloat-fighting strategies=2E >>>>>>>>>=20 >>>>>>>>> On Mon, Sep 26, 2022 at 12:59 PM Eugene Chang > wrote: >>>>>>>>> The key issue is most people don=E2=80=99t understand why latenc= y matters=2E They don=E2=80=99t see it or feel it=E2=80=99s impact=2E >>>>>>>>>=20 >>>>>>>>> First, we have to help people see the symptoms of latency and ho= w it impacts something they care about=2E >>>>>>>>> - gamers care but most people may think it is frivolous=2E >>>>>>>>> - musicians care but that is mostly for a hobby=2E >>>>>>>>> - business should care because of productivity but they don=E2= =80=99t know how to =E2=80=9Csee=E2=80=9D the impact=2E >>>>>>>>>=20 >>>>>>>>> Second, there needs to be a =E2=80=9COMG, I have been seeing the= action of latency all this time and never knew it! I was being shafted=2E= =E2=80=9D Once you have this awakening, you can get all the press you want = for free=2E >>>>>>>>>=20 >>>>>>>>> Most of the time when business apps are developed, =E2=80=9Cwe= =E2=80=9D hide the impact of poor performance (aka latency) or they hide fr= om the discussion because the developers don=E2=80=99t have a way to fix th= e latency=2E Maybe businesses don=E2=80=99t care because any employees affe= cted are just considered poor performers=2E (In bad economic times, the poo= r performers are just laid off=2E) For employees, if they happen to be at a= location with bad latency, they don=E2=80=99t know that latency is hurting= them=2E Unfair but most people don=E2=80=99t know the issue is latency=2E >>>>>>>>>=20 >>>>>>>>> Talking and explaining why latency is bad is not as effective as= showing why latency is bad=2E Showing has to be with something that has a = person impact=2E >>>>>>>>>=20 >>>>>>>>> Gene >>>>>>>>> ----------------------------------- >>>>>>>>> Eugene Chang >>>>>>>>> eugene=2Echang@alum=2Emit=2Eedu >>>>>>>>> +1-781-799-0233 (in Honolulu) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On Sep 26, 2022, at 6:32 AM, Bruce Perens via Starlink > wro= te: >>>>>>>>>>=20 >>>>>>>>>> If you want to get attention, you can get it for free=2E I can = place articles with various press if there is something interesting to say= =2E Did this all through the evangelism of Open Source=2E All we need to do= is write, sign, and publish a statement=2E What they actually write is les= s relevant if they publish a link to our statement=2E >>>>>>>>>>=20 >>>>>>>>>> Right now I am concerned that the Starlink latency and jitter i= s going to be a problem even for remote controlling my ham station=2E The U= S Military is interested in doing much more, which they have demonstrated, = but I don't see happening at scale without some technical work on the netwo= rk=2E Being able to say this isn't ready for the government's application w= ould be an attention-getter=2E >>>>>>>>>>=20 >>>>>>>>>> Thanks >>>>>>>>>>=20 >>>>>>>>>> Bruce >>>>>>>>>>=20 >>>>>>>>>> On Mon, Sep 26, 2022 at 9:21 AM Dave Taht via Starlink > wro= te: >>>>>>>>>> These days, if you want attention, you gotta buy it=2E A 50k ha= lf page >>>>>>>>>> ad in the wapo or NYT riffing off of It's the latency, Stupid!"= , >>>>>>>>>> signed by the kinds of luminaries we got for the fcc wifi fight= , would >>>>>>>>>> go a long way towards shifting the tide=2E >>>>>>>>>>=20 >>>>>>>>>> On Mon, Sep 26, 2022 at 8:29 AM Dave Taht > wrote: >>>>>>>>>>>=20 >>>>>>>>>>> On Mon, Sep 26, 2022 at 8:20 AM Livingood, Jason >>>>>>>>>>> > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> The awareness & understanding of latency & impact on QoE is n= early unknown among reporters=2E IMO maybe there should be some kind of bac= kground briefings for reporters - maybe like a simple YouTube video explain= er that is short & high level & visual? Otherwise reporters will just conti= nue to focus on what they know=2E=2E=2E >>>>>>>>>>>=20 >>>>>>>>>>> That's a great idea=2E I have visions of crashing the washingt= on >>>>>>>>>>> correspondents dinner, but perhaps >>>>>>>>>>> there is some set of gatherings journalists regularly attend? >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> =EF=BB=BFOn 9/21/22, 14:35, "Starlink on behalf of Dave Taht = via Starlink" on behalf of starlink@lists=2Ebufferbloa= t=2Enet > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> I still find it remarkable that reporters are still missing t= he >>>>>>>>>>>> meaning of the huge latencies for starlink, under load=2E >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> FQ World Domination pending: https://blog=2Ecerowrt=2Eorg/post= /state_of_fq_codel/ >>>>>>>>>>> Dave T=C3=A4ht CEO, TekLibre, LLC >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> FQ World Domination pending: https://blog=2Ecerowrt=2Eorg/post/= state_of_fq_codel/ >>>>>>>>>> Dave T=C3=A4ht CEO, TekLibre, LLC >>>>>>>>>> _______________________________________________ >>>>>>>>>> Starlink mailing list >>>>>>>>>> Starlink@lists=2Ebufferbloat=2Enet >>>>>>>>>> https://lists=2Ebufferbloat=2Enet/listinfo/starlink >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Bruce Perens K6BP >>>>>>>>>> _______________________________________________ >>>>>>>>>> Starlink mailing list >>>>>>>>>> Starlink@lists=2Ebufferbloat=2Enet >>>>>>>>>> https://lists=2Ebufferbloat=2Enet/listinfo/starlink >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Bruce Perens K6BP >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Starlink mailing list >>>>>> Starlink@lists=2Ebufferbloat=2Enet >>>>>> https://lists=2Ebufferbloat=2Enet/listinfo/starlink > --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E