[Starlink] Itʼs the Latency, FCC

Wed May 1 18:10:46 EDT 2024

Thank you all for the discussion.

Given everything that has been said my plan A will be to engage the eSports community and find some engineering students that will want to give this a test.

The business users will follow the ISPs and the state experts. Since they all learned their craft from the incumbent ISP, nothing will happen here (for now).

Gene
----------------------------------------------
Eugene Chang
IEEE Life Senior Member
IEEE Communications Society & Signal Processing Society,
    Hawaii Chapter Chair
IEEE Life Member Affinity Group Hawaii Chair
IEEE Entrepreneurship, Mentor
eugene.chang at ieee.org
m 781-799-0233 (in Honolulu)

> On May 1, 2024, at 11:11 AM, Frantisek Borsik <frantisek.borsik at gmail.com> wrote:
> 
> Eugene, this is one of the ISP examples of using OpenWrt, CAKE & FQ-CoDel to fix not only his network, but also to refurbish an old device - when the vendor didn't give a flying F:
> https://blog.nafiux.com/posts/cnpilot_r190w_openwrt_bufferbloat_fqcodel_cake/ <https://blog.nafiux.com/posts/cnpilot_r190w_openwrt_bufferbloat_fqcodel_cake/>
> 
> Here is also the list of OpenWrt supported HW: https://openwrt.org/supported_devices <https://openwrt.org/supported_devices>
> If you/ISP want to go mainstream, MikroTik will be a good option.
> 
> This is a great place to start (not only for your ISP): https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/ <https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/>
> 
> All the best,
> 
> Frank
> 
> Frantisek (Frank) Borsik
> 
> 
> 
> https://www.linkedin.com/in/frantisekborsik <https://www.linkedin.com/in/frantisekborsik>
> Signal, Telegram, WhatsApp: +421919416714
> 
> iMessage, mobile: +420775230885
> 
> Skype: casioa5302ca
> 
> frantisek.borsik at gmail.com <mailto:frantisek.borsik at gmail.com>
> 
> On Wed, May 1, 2024 at 9:18 PM David Lang via Starlink <starlink at lists.bufferbloat.net <mailto:starlink at lists.bufferbloat.net>> wrote:
> On Wed, 1 May 2024, Eugene Y Chang wrote:
> 
> > Thanks David,
> >
> >
> >> On Apr 30, 2024, at 6:12 PM, David Lang <david at lang.hm <mailto:david at lang.hm>> wrote:
> >>
> >> On Tue, 30 Apr 2024, Eugene Y Chang wrote:
> >>
> >>> I’m not completely up to speed on the gory details. Please humor me. I am pretty good on the technical marketing magic.
> >>>
> >>> What is the minimum configuration of an ISP infrastructure where we can show an A/B (before and after) test?
> >>> It can be a simplified scenario. The simpler, the better. We can talk through the issues of how minimal is adequate. Of course and ISP engineer will argue against simplicity.
> >>
> >> I did not see a very big improvement on a 4/.5 dsl link, but there was improvement.
> >
> > Would a user feel the improvement with a 10 minute session:
> > shopping on Amazon?
> > using Salesforce?
> > working with a shared Google doc?
> 
> When it's only a single user, they are unlikely to notice any difference.
> 
> But if you have one person on zoom, a second downloading something, and a third
> on Amazon, it doesn't take much to notice a difference.
> 
> >> if you put openwrt on the customer router and configure cake with the targeted bandwith at ~80% of line speed, you will usually see a drastic improvement for just about any connection.
> >
> > Are you saying some of the benefits can be realized with just upgrading the
> > subscriber’s router? This makes adoption harder because the subscriber will
> > lose the ISP’s support for any connectivity issues. If a demo impresses the
> > subscribers, the ISP still needs to embrace this change; otherwise the ISP
> > will wash their hands of any subscriber problems.
> 
> Yes, just upgrading the subscriber's device with cake and configuring it
> appropriately largely solves the problem (at the cost of sacraficing bandwith
> because cake isn't working directly on the data flowing from the ISP to the
> client, and so it has to work indirectly to get the Internet server to slow down
> instead and that's a laggy, imperect work-around. If the ISPs router does active
> queue management with fq_codel, then you don't have to do this.
> 
> This is how we know this works, many of use have been doing this for years (see
> the bufferbloat mailing list and it's archives_
> 
> >> If you can put fq_codel on both ends of the link, you can usually skip capping the bandwidth.
> >
> > This is good if this means the benefits can be achieved with just the CPE. This also limits the changes to subscribers that care.
> 
> fq_codel on the ISPs router for downlink, and on the subscribers router for
> uplink.
> 
> putting cake on the router on the subscriber's end and tuning it appropriately
> can achieve most of the benefit, but is more work to configure.
> 
> >>
> >> unfortunantly, it's not possible to just add this to the ISPs existing hardware without having the source for the firmware there (and if they have their queues in ASICs it's impossible to change them.
> >
> > Is this just an alternative to having the change at the CPE?
> > Yes this is harder for routers in the network.
> 
> simple fq_codel on both ends of the bottleneck connection works quite well
> without any configuration. Cake adds some additional fairness capabilities and
> has a mode to work around the router on the other end of the bottleneck not
> doing active queue management
> 
> >> If you can point at the dramatic decrease in latency, with no bandwidth losses, that Starlink has achieved on existing hardware, that may help.
> >
> > This is good to know for the engineers. This adds confusion with the subscribers.
> >
> >>
> >> There are a number of ISPs around the world that have implemented active queue management and report very good results from doing so.
> >
> > Can we get these ISPs to publically report how they have achieved great latency reduction?
> > We can help them get credit for caring about their subscribers. It would/could be a (short term) competitive advantage.
> > Of course their competitors will (might) adopt these changes and eliminate the advantage, BUT the subscribers will retain glow of the initial marketing for a much longer time.
> 
> several of them have done so, I think someone else posted a report from one in
> this thread.
> 
> >> But showing that their existing hardware can do it when their upstream vendor doesn't support it is going to be hard.
> >
> > Is the upstream vendor a network provider or a computing center?
> > Getting good latency from the subscriber, through the access network to the edge computing center and CDNs would be great. The CDNs would harvest the benefits. The other computing configurations would have make the change to be competitive.
> 
> I'm talking about the manufacturer of the routers that the ISPs deploy at the
> last hop before getting to the subscriber, and the router on the subscriber end
> of the link (although most of those are running some variation of openWRT, so
> turning it on would not be significant work for the manufacturer)
> 
> > We wouild have done our part at pushing the next round of adoption.
> 
> Many of us have been pushing this for well over a decade. Getting Starlink's
> attention to address their bufferbloat issues is a major success.
> 
> David Lang
> 
> > Gene
> >
> >>
> >> David Lang
> >>
> >>>
> >>> We will want to show the human visible impact and not debate good or not so good measurements. If we get the business and community subscribers on our side, we win.
> >>>
> >>> Note:
> >>> Stage 1 is to show we have a pure software fix (that can work on their hardware). The fix is “so dramatic” that subscribers can experience it without debating measurements.
> >>> Stage 2 discusses why the ISP should demand that their equipment vendors add this software. (The software could already be available, but the ISP doesn’t think it is worth the trouble to enable it.) Nothing will happen unless we stay engaged. We need to keep the subscribers engaged, too.
> >>>
> >>> Should we have a conference call to discuss this?
> >>>
> >>>
> >>> Gene
> >>> ----------------------------------------------
> >>> Eugene Chang
> >>> IEEE Life Senior Member
> >>>
> >>>
> >>>
> >>>> On Apr 30, 2024, at 3:52 PM, Jim Forster <jim at connectivitycap.com <mailto:jim at connectivitycap.com>> wrote:
> >>>>
> >>>> Gene, David,
> >>>> ‘m
> >>>> Agreed that the technical problem is largely solved with cake & codel.
> >>>>
> >>>> Also that demos are good. How to do one for this problem>
> >>>>
> >>>>  — Jim
> >>>>
> >>>>> The bandwidth mantra has been used for so long that a technical discussion cannot unseat the mantra.
> >>>>> Some technical parties use the mantra to sell more, faster, ineffective service. Gullible customers accept that they would be happy if they could afford even more speed.
> >>>>>
> >>>>> Shouldn’t we create a demo to show the solution?
> >>>>> To show is more effective than to debate. It is impossible to explain to some people.
> >>>>> Has anyone tried to create a demo (to unseat the bandwidth mantra)?
> >>>>> Is an effective demo too complicated to create?
> >>>>> I’d be glad to participate in defining a demo and publicity campaign.
> >>>>>
> >>>>> Gene
> >>>>>
> >>>>>
> >>>>>> On Apr 30, 2024, at 2:36 PM, David Lang <david at lang.hm <mailto:david at lang.hm> <mailto:david at lang.hm <mailto:david at lang.hm>> <mailto:david at lang.hm <mailto:david at lang.hm> <mailto:david at lang.hm <mailto:david at lang.hm>>>> wrote:
> >>>>>>
> >>>>>> On Tue, 30 Apr 2024, Eugene Y Chang via Starlink wrote:
> >>>>>>
> >>>>>>> I am always surprised how complicated these discussions become. (Surprised mostly because I forgot the kind of issues this community care about.) The discussion doesn’t shed light on the following scenarios.
> >>>>>>>
> >>>>>>> While watching stream content, activating controls needed to switch content sometimes (often?) have long pauses. I attribute that to buffer bloat and high latency.
> >>>>>>>
> >>>>>>> With a happy household user watching streaming media, a second user could have terrible shopping experience with Amazon. The interactive response could be (is often) horrible. (Personally, I would be doing email and working on a shared doc. The Amazon analogy probably applies to more people.)
> >>>>>>>
> >>>>>>> How can we deliver graceful performance to both persons in a household?
> >>>>>>> Is seeking graceful performance too complicated to improve?
> >>>>>>> (I said “graceful” to allow technical flexibility.)
> >>>>>>
> >>>>>> it's largely a solved problem from a technical point of view. fq_codel and cake solve this.
> >>>>>>
> >>>>>> The solution is just not deployed widely, instead people argue that more bandwidth is needed instead.
> >
> >_______________________________________________
> 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240501/9c6d978d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240501/9c6d978d/attachment-0001.sig>