Re: [Starlink] Itʼs the Latency, FCC

[Frantisek Borsik <frantisek.borsik@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 9977 bytes --]

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/

Here is also the list of OpenWrt supported HW:
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/

All the best,

Frank

Frantisek (Frank) Borsik



https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com


On Wed, May 1, 2024 at 9:18 PM David Lang via Starlink <
starlink@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@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@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@lang.hm <mailto:
> david@lang.hm> <mailto:david@lang.hm <mailto:david@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/html, Size: 13495 bytes --]