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

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

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

This was a nice story of overhauling good ole Cambium Networks HW
with OpenWrt, FQ-CoDel & CAKE:

https://blog.nafiux.com/posts/cnpilot_r190w_openwrt_bufferbloat_fqcodel_cake/

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 6:12 AM David Lang via Starlink <
starlink@lists.bufferbloat.net> 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.
>
> 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.
>
> If you can put fq_codel on both ends of the link, you can usually skip
> capping
> the bandwidth.
>
> 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.
>
> If you can point at the dramatic decrease in latency, with no bandwidth
> losses,
> that Starlink has achieved on existing hardware, that may help.
>
> There are a number of ISPs around the world that have implemented active
> queue
> management and report very good results from doing so.
>
> But showing that their existing hardware can do it when their upstream
> vendor
> doesn't support it is going to be hard.
>
> 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>> 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: 7989 bytes --]