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@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 > 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@ieee.org > > 781-799-0233 (in Honolulu) > > > > > > > > On Sep 26, 2022, at 10:48 AM, David Lang 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@ieee.org > > 781-799-0233 (in Honolulu) > > > > > > > > On Sep 26, 2022, at 10:04 AM, Bruce Perens 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: > > 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 > 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@alum.mit.edu > > +1-781-799-0233 (in Honolulu) > > > > > > > > > > > > On Sep 26, 2022, at 6:32 AM, Bruce Perens via Starlink < > starlink@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@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@gmail.com>> wrote: > > > > > > On Mon, Sep 26, 2022 at 8:20 AM Livingood, Jason > > > > 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@lists.bufferbloat.net starlink-bounces@lists.bufferbloat.net> on behalf of > starlink@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@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink < > https://lists.bufferbloat.net/listinfo/starlink> > > > > > > -- > > Bruce Perens K6BP > > _______________________________________________ > > Starlink mailing list > > Starlink@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink < > https://lists.bufferbloat.net/listinfo/starlink> > > > > > > > > > > -- > > Bruce Perens K6BP > > > > > > _______________________________________________ > > Starlink mailing list > > Starlink@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@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink >