[Starlink] It's still the starlink latency...

Mon Sep 26 17:34:53 EDT 2022

I'm giving Dave a wireguard link and root on my off-grid host (which is
recoverable with PiKVM unless the hardware fails). It's in the container in
the photo.[image: Macdoel.jpg]

On Mon, Sep 26, 2022 at 2:28 PM warren ponder via Starlink <
starlink at lists.bufferbloat.net> wrote:

> Dave what do you need in order to add sites to the data collection. Feel
> free to reply separate or link to a previous thread
>
> Thx
>
> WP
>
> On Mon, Sep 26, 2022, 2:10 PM Dave Taht via Starlink <
> starlink at lists.bufferbloat.net> wrote:
>
>> I tend to cite rfc7567 (published 2015) a lot, which replaces rfc2309
>> (published 1992!).
>>
>> Thing is, long before that, I'd come to the conclusion that fair
>> queuing was a requirement for
>> sustaining the right throughput for low rate flows in wildly variable
>> bandwidth. At certain places in
>> LTE/5g/starlink networks the payload is encrypted and the header info
>> required unavailable, and my advocacy of fq is certainly not shared by
>> everyone.
>>
>> We don't know enough about the actual points of congestion in starlink
>> to know if fq could be applied,
>> and although aqm is a very good idea everywhere, is also largely
>> undeployed where it would matter most.
>>
>> I focused my initial analysis of starlink on just uplink congestion,
>> which I believe can be easily improved given about 20 minutes with a
>> cross compiler for the dishy. We have a very good proof of concept as
>> to how to improve starlinks behavior over here:
>> https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/135379/87 and
>> ironically the same script could be run on their router as it is based
>> on a 6 year old version of openwrt in the first place.
>>
>> I have plenty of data later than this (
>>
>> https://docs.google.com/document/d/1puRjUVxJ6cCv-rgQ_zn-jWZU9ae0jZbFATLf4PQKblM/edit
>> ) but I would like to be collecting it from at least six sites around
>> the world.
>>
>> On Mon, Sep 26, 2022 at 1:54 PM Eugene Y Chang via Starlink
>> <starlink at lists.bufferbloat.net> wrote:
>> >
>> > Ok, we are getting into the details. I agree.
>> >
>> > Every node in the path has to implement this to be effective.
>> > In fact, every node in the path has to have the same prioritization or
>> the scheme becomes ineffective.
>> >
>> > Gene
>> > ----------------------------------------------
>> > Eugene Chang
>> > IEEE Senior Life Member
>> > eugene.chang at ieee.org
>> > 781-799-0233 (in Honolulu)
>> >
>> >
>> >
>> > On Sep 26, 2022, at 10:48 AM, David Lang <david at lang.hm> wrote:
>> >
>> > software updates can do far more than just improve recovery.
>> >
>> > In practice, large data transfers are less sensitive to latency than
>> smaller data transfers (i.e. downloading a CD image vs a video conference),
>> software can ensure better fairness in preventing a bulk transfer from
>> hurting the more latency sensitive transfers.
>> >
>> > (the example below is not completely accurate, but I think it gets the
>> point across)
>> >
>> > 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
>> interval, but a bulk data transfer is able to dump a huge amount of data
>> into the buffer instantly.
>> >
>> > If you just do FIFO, then you get a small chunk of video call, then
>> several seconds worth of CD transfer, followed by the next small chunk of
>> the video call.
>> >
>> > But the software can prevent the one app from hogging so much of the
>> connection and let the chunk of video call in sooner, avoiding the impact
>> to the real time traffic. Historically this has required the admin classify
>> all traffic and configure equipment to implement different treatment based
>> on the classification (and this requires trust in the classification
>> process), the bufferbloat team has developed options (fq_codel and cake)
>> that can ensure fairness between applications/servers with little or no
>> configuration, and no trust in other systems to properly classify their
>> traffic.
>> >
>> > The one thing that Cake needs to work really well is to be able to know
>> what the data rate available is. With Starlink, this changes frequently and
>> cake integrated into the starlink dish/router software would be far better
>> than anything that can be done externally as the rate changes can be fed
>> directly into the settings (currently they are only indirectly detected)
>> >
>> > David Lang
>> >
>> >
>> > On Mon, 26 Sep 2022, Eugene Y Chang via Starlink wrote:
>> >
>> > You already know this. Bufferbloat is a symptom and not the cause.
>> Bufferbloat grows when there are (1) periods of low or no bandwidth or (2)
>> periods of insufficient bandwidth (aka network congestion).
>> >
>> > If I understand this correctly, just a software update cannot make
>> bufferbloat go away. It might improve the speed of recovery (e.g. throw
>> away all time sensitive UDP messages).
>> >
>> > Gene
>> > ----------------------------------------------
>> > Eugene Chang
>> > IEEE Senior Life Member
>> > eugene.chang at ieee.org
>> > 781-799-0233 (in Honolulu)
>> >
>> >
>> >
>> > On Sep 26, 2022, at 10:04 AM, Bruce Perens <bruce at perens.com> wrote:
>> >
>> > Please help to explain. Here's a draft to start with:
>> >
>> > Starlink Performance Not Sufficient for Military Applications, Say
>> Scientists
>> >
>> > The problem is not availability: Starlink works where nothing but
>> another satellite network would. It's not bandwidth, although others have
>> questions about sustaining bandwidth as the customer base grows. It's
>> latency and jitter. As load increases, latency, the time it takes for a
>> packet to get through, increases more than it should. The scientists who
>> have fought bufferbloat, a major cause of latency on the internet, know
>> why. SpaceX needs to upgrade their system to use the scientist's Open
>> Source modifications to Linux to fight bufferbloat, and thus reduce
>> latency. This is mostly just using a newer version, but there are some
>> tunable parameters. Jitter is a change in the speed of getting a packet
>> through the network during a connection, which is inevitable in satellite
>> networks, but will be improved by making use of the bufferbloat-fighting
>> software, and probably with the addition of more satellites.
>> >
>> > We've done all of the work, SpaceX just needs to adopt it by upgrading
>> their software, said scientist Dave Taht. Jim Gettys, Taht's collaborator
>> and creator of the X Window System, chimed in: <fill in here please>
>> > Open Source luminary Bruce Perens said: sometimes Starlink's latency
>> and jitter make it inadequate to remote-control my ham radio station. But
>> the military is experimenting with remote-control of vehicles on the
>> battlefield and other applications that can be demonstrated, but won't
>> happen at scale without adoption of bufferbloat-fighting strategies.
>> >
>> > On Mon, Sep 26, 2022 at 12:59 PM Eugene Chang <
>> eugene.chang at alum.mit.edu<mailto:eugene.chang at alum.mit.edu>> wrote:
>> > The key issue is most people don’t understand why latency matters. They
>> don’t see it or feel it’s impact.
>> >
>> > First, we have to help people see the symptoms of latency and how it
>> impacts something they care about.
>> > - gamers care but most people may think it is frivolous.
>> > - musicians care but that is mostly for a hobby.
>> > - business should care because of productivity but they don’t know how
>> to “see” the impact.
>> >
>> > Second, there needs to be a “OMG, I have been seeing the action of
>> latency all this time and never knew it! I was being shafted.” Once you
>> have this awakening, you can get all the press you want for free.
>> >
>> > Most of the time when business apps are developed, “we” hide the impact
>> of poor performance (aka latency) or they hide from the discussion because
>> the developers don’t have a way to fix the latency. Maybe businesses don’t
>> care because any employees affected are just considered poor performers.
>> (In bad economic times, the poor performers are just laid off.) For
>> employees, if they happen to be at a location with bad latency, they don’t
>> know that latency is hurting them. Unfair but most people don’t know the
>> issue is latency.
>> >
>> > Talking and explaining why latency is bad is not as effective as
>> showing why latency is bad. Showing has to be with something that has a
>> person impact.
>> >
>> > Gene
>> > -----------------------------------
>> > Eugene Chang
>> > eugene.chang at alum.mit.edu <mailto:eugene.chang at alum.mit.edu>
>> > +1-781-799-0233 (in Honolulu)
>> >
>> >
>> >
>> >
>> >
>> > On Sep 26, 2022, at 6:32 AM, Bruce Perens via Starlink <
>> starlink at lists.bufferbloat.net<mailto:starlink at lists.bufferbloat.net>>
>> wrote:
>> >
>> > If you want to get attention, you can get it for free. I can place
>> articles with various press if there is something interesting to say. Did
>> this all through the evangelism of Open Source. All we need to do is write,
>> sign, and publish a statement. What they actually write is less relevant if
>> they publish a link to our statement.
>> >
>> > Right now I am concerned that the Starlink latency and jitter is going
>> to be a problem even for remote controlling my ham station. The US 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 network. Being
>> able to say this isn't ready for the government's application would be an
>> attention-getter.
>> >
>> >    Thanks
>> >
>> >    Bruce
>> >
>> > On Mon, Sep 26, 2022 at 9:21 AM Dave Taht via Starlink <
>> starlink at lists.bufferbloat.net<mailto:starlink at lists.bufferbloat.net>>
>> wrote:
>> > These days, if you want attention, you gotta buy it. A 50k half 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.
>> >
>> > On Mon, Sep 26, 2022 at 8:29 AM Dave Taht <dave.taht at gmail.com <mailto:
>> dave.taht at gmail.com>> wrote:
>> >
>> >
>> > On Mon, Sep 26, 2022 at 8:20 AM Livingood, Jason
>> > <Jason_Livingood at comcast.com <mailto:Jason_Livingood at comcast.com>>
>> wrote:
>> >
>> >
>> > The awareness & understanding of latency & impact on QoE is nearly
>> unknown among reporters. IMO maybe there should be some kind of background
>> briefings for reporters - maybe like a simple YouTube video explainer that
>> is short & high level & visual? Otherwise reporters will just continue to
>> focus on what they know...
>> >
>> >
>> > That's a great idea. I have visions of crashing the washington
>> > correspondents dinner, but perhaps
>> > there is some set of gatherings journalists regularly attend?
>> >
>> >
>> > On 9/21/22, 14:35, "Starlink on behalf of Dave Taht via Starlink" <
>> starlink-bounces at lists.bufferbloat.net <mailto:
>> starlink-bounces at lists.bufferbloat.net> on behalf of
>> starlink at lists.bufferbloat.net <mailto:starlink at lists.bufferbloat.net>>
>> wrote:
>> >
>> >    I still find it remarkable that reporters are still missing the
>> >    meaning of the huge latencies for starlink, under load.
>> >
>> >
>> >
>> >
>> > --
>> > FQ World Domination pending:
>> https://blog.cerowrt.org/post/state_of_fq_codel/<
>> https://blog.cerowrt.org/post/state_of_fq_codel/>
>> > Dave Täht CEO, TekLibre, LLC
>> >
>> >
>> >
>> >
>> > --
>> > FQ World Domination pending:
>> https://blog.cerowrt.org/post/state_of_fq_codel/<
>> https://blog.cerowrt.org/post/state_of_fq_codel/>
>> > Dave Täht CEO, TekLibre, LLC
>> > _______________________________________________
>> > Starlink mailing list
>> > Starlink at lists.bufferbloat.net <mailto:Starlink at lists.bufferbloat.net>
>> > https://lists.bufferbloat.net/listinfo/starlink <
>> https://lists.bufferbloat.net/listinfo/starlink>
>> >
>> >
>> > --
>> > Bruce Perens K6BP
>> > _______________________________________________
>> > Starlink mailing list
>> > Starlink at lists.bufferbloat.net <mailto:Starlink at lists.bufferbloat.net>
>> > https://lists.bufferbloat.net/listinfo/starlink <
>> https://lists.bufferbloat.net/listinfo/starlink>
>> >
>> >
>> >
>> >
>> > --
>> > Bruce Perens K6BP
>> >
>> >
>> > _______________________________________________
>> > Starlink mailing list
>> > Starlink at lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/starlink
>>
>>
>>
>> --
>> FQ World Domination pending:
>> https://blog.cerowrt.org/post/state_of_fq_codel/
>> Dave Täht CEO, TekLibre, LLC
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

-- 
Bruce Perens K6BP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20220926/508ad4b9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Macdoel.jpg
Type: image/jpeg
Size: 2351751 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20220926/508ad4b9/attachment-0001.jpg>