[Starlink] Re: [LibreQoS] Re: Re: Keynote: QoE/QoS - Bandwidth Is A Lie! at WISPAPALOOZA 2025 (October 16)

[J Pan <Pan@uvic.ca>]

they are layer 8 or 9 issues ;-) yes, networking is an infrastructure,
and people only realize its importance when it's broken, just like
roads, canadapost/usps, air traffic controller,...
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Sat, Nov 8, 2025 at 11:46 AM Sebastian Moeller via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
>
>
> > On 8. Nov 2025, at 20:30, David Fernández via Starlink <starlink@lists.bufferbloat.net> wrote:
> >
> > "Infrastructure (and at least access networks are at least
> > infrastructure-ish IMHO) is not something where the free market typically
> > excels at."
> >
> > Telecom operators want an oligopoly. If there is much competition they
> > complain about it.
>
> Oh, almost all companies want to find themselves in an under-regulated monopoly situation, nothing surprising. The question is, should we as society actually accept that?
>
> > Telecommunications are infrastructure like water and electricity
> > distribution. Every time I see I can call emergencies from mobile, but I
> > don't have service from my operator I find it ridiculous. There is a
> > network there I could use, but "the free market" does not allow it.
>
> Well, the ugly truth about markets is, no side actually wants a fair market, but would prefer a monopoly or monopsony, alas typically the supply side is better positioned to reach that, especially with things that lend themselves to natural monopolies like infrastructure.
>
> >
> > Then, there is roaming and the prohibition of ISPs in contracts to share
> > your connection, e.g. with neighbors, so you walk around any city and you
> > have zillions of Wi-Fi access points, all closed, in the name of
> > profit/economic sustainability. Great.
>
> Late stage capitalism... let's see what comes next... ;) Maybe we can fix things
>
> Regards
>         Sebastian
>
> >
> > Regards,
> >
> > David
> >
> >
> > Date: Sat, 8 Nov 2025 19:11:38 +0100
> >> From: Sebastian Moeller <moeller0@gmx.de>
> >> Subject: [Starlink] Re: [LibreQoS] Re: Re: Keynote: QoE/QoS -
> >>        Bandwidth Is A Lie!  at WISPAPALOOZA 2025 (October 16)
> >> To: J Pan <Pan@uvic.ca>
> >> Cc: dan <dandenson@gmail.com>, Jim Forster <jim@connectivitycap.com>,
> >>        Frantisek Borsik <frantisek.borsik@gmail.com>, Cake List
> >>        <cake@lists.bufferbloat.net>, bloat <bloat@lists.bufferbloat.net>,
> >>        codel@lists.bufferbloat.net, libreqos
> >>        <libreqos@lists.bufferbloat.net>, l4s-discuss@ietf.org,
> >>        starlink@lists.bufferbloat.net
> >> Message-ID: <93519830-549F-459A-A737-792F18F3241C@gmx.de>
> >> Content-Type: text/plain;       charset=utf-8
> >>
> >> Hi J,
> >>
> >>
> >>> On 8. Nov 2025, at 18:03, J Pan via Starlink <
> >> starlink@lists.bufferbloat.net> wrote:
> >>>
> >>> yes, availability (at least two competing network providers with
> >>> reliable services),
> >>
> >> As David already mentioned that gets us a duopoly, but going mildly higher
> >> still results in an oligopoly... As a market realist (that is someone who
> >> accepts efficient market when he sees them, but does not naive believe in
> >> the fairy tales of the invisible hand of the market) I think that we would
> >> be often much better off with a competently managed/regulated monopoly than
> >> with duo- to oligopolies that are treated as if they were efficient
> >> markets... Infrastructure (and at least access networks are at least
> >> infrastructure-ish IMHO) is not something where the free market typically
> >> excels at.
> >>
> >>> affordability (so the competition to bring the
> >>> price and cost down)
> >>
> >> I agree, but that is really at odds with your first point, to get that
> >> from a market we clearly need to grow the supply side to get out of
> >> oligopoly territory, and I am not sure that that is actually feasible.
> >>
> >>> and applicability to modern internet applications
> >>> (video streaming, conferencing and gaming in addition to email and web
> >>> browsing) shall be the user-centric metrics in addition to throughput,
> >>> latency/jitter, packet loss, etc
> >>
> >> I am 100% behind this. I will mention though that I believe that latency
> >> increase under load is a decent proxy for the utility of a given access
> >> link for the usability with interactive applications.
> >>
> >> Regards
> >>        Sebastian
> >>
> >>> --
> >>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA,
> >> Web.UVic.CA/~pan
> >>>
> >>> On Sat, Nov 8, 2025 at 8:00 AM dan <dandenson@gmail.com> wrote:
> >>>>
> >>>> I'm starting to see the signs that raw bandwidth is starting to lose
> >>>> it's dominance for marketing.  It's still the clear #1 ask but price
> >>>> is rapidly overtaking speed for our customer requests.
> >>>>
> >>>> I believe we've hit this era's threshold on throughput needs and
> >>>> people have started to notice that 'more' doesn't feel like a faster
> >>>> service.
> >>>>
> >>>> one common scenario that we are using to win customers, in combination
> >>>> with facebook testimonials, is that people have bad experiences with
> >>>> wifi and they order a faster service from cable/fiber company and the
> >>>> wifi just gets worse.  This scenario I think is incredibly common and
> >>>> seems to be a catalyst for 'speed isn't everything'.  We come in with
> >>>> 50-500Mbps of service and solid whole-home wifi and they are
> >>>> converted.
> >>>>
> >>>> I hope we're not to far off from having 'speed' be just a feature, not
> >>>> the entire story.
> >>>>
> >>>> and yes, we QoE or service with cake via libreqos which is the
> >>>> difference between great service and inadequate service IMO.
> >>>>
> >>>> On Fri, Nov 7, 2025 at 12:50 PM J Pan via LibreQoS
> >>>> <libreqos@lists.bufferbloat.net> wrote:
> >>>>>
> >>>>> marketing is even worse. some claim 200mbps because 150mbps down and
> >>>>> 50mbps up at peak data rate. of course, this is not the only problem
> >>>>> in telecom, but likely the worst
> >>>>>
> >>>>> nevertheless, there are stats such as 10% inflation for food and 20%
> >>>>> for gas, so in total 30% ;-) at this rate, any numbers can be floating
> >>>>> around but none are telling the truth ;-)
> >>>>> --
> >>>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA,
> >> Web.UVic.CA/~pan
> >>>>>
> >>>>> On Fri, Nov 7, 2025 at 10:55 AM Jim Forster <jim@connectivitycap.com>
> >> wrote:
> >>>>>>
> >>>>>> Exactly so.
> >>>>>>
> >>>>>> Consumer expectations and service provider marketing may be
> >> influenced by memories of experience when transmission delay did matter.
> >> At one time I was very happy with my home ISDN connection, and even shared
> >> it with my neighbor.  At about 128kbs, it was three orders of magnitude
> >> slower than my home fiber link.  I’ve not run the numbers but I’m pretty
> >> sure transimission speed mattered for video, even for crummy quality
> >> video,  So then when I learned a bit about digital video, and cable’s 64
> >> QAM 27mbps channels, I got excited and thought, “wow, they could deliver
> >> 1mbps service!  And wouldn’t it be cool to have 1M home online at 10x the
> >> speed of ISDN?”.  It was cool!  And two more orders of magnitude later,
> >> here we are.
> >>>>>>
> >>>>>> — Jim
> >>>>>>
> >>>>>> On Nov 7, 2025, at 12:52 PM, J Pan <Pan@uvic.ca> wrote:
> >>>>>>
> >>>>>> latency is based on round-trip time, and one-way delay includes
> >>>>>> transmission delay, propagation delay, queuing delay and processing
> >>>>>> delay. bandwidth does affect transmission delay (or serialization
> >>>>>> delay), propagation delay is determined by the link length and the
> >>>>>> "travel" speed of the signal, queuing delay is the hardest part and
> >>>>>> affected by the buffer bloat a lot, and processing delay is another
> >>>>>> variable. of course, transmission delay takes less and less portion of
> >>>>>> the end-to-end delay now due to higher and higher "speed" links
> >>>>>>
> >>>>>> consumers may mistaken the speed of the link (the "width" of their
> >>>>>> pipe) as how fast their internet is (the "length" of the pipe), due to
> >>>>>> the poor terminology we have been using ;-)
> >>>>>>
> >>>>>>
> >>>>> _______________________________________________
> >>>>> LibreQoS mailing list -- libreqos@lists.bufferbloat.net
> >>>>> To unsubscribe send an email to libreqos-leave@lists.bufferbloat.net
> >>> _______________________________________________
> >>> Starlink mailing list -- starlink@lists.bufferbloat.net
> >>> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
> >>
> >>
> >>
> > _______________________________________________
> > Starlink mailing list -- starlink@lists.bufferbloat.net
> > To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net