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

Mon Sep 26 17:28:39 EDT 2022

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20220926/d78a8bae/attachment-0001.html>