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

[Sebastian Moeller <moeller0@gmx.de>]

> 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