From: "David Fernández" <davidfdzp@gmail.com>
To: starlink <starlink@lists.bufferbloat.net>
Subject: [Starlink] Re: [LibreQoS] Re: Re: Keynote: QoE/QoS - Bandwidth Is A Lie! at WISPAPALOOZA 2025 (October 16)
Date: Mon, 10 Nov 2025 16:41:53 +0500 [thread overview]
Message-ID: <CAC=tZ0pihJBGi8A0eK8uPWnedh=d3E0kwW1dh9cR=d0WgT7VkA@mail.gmail.com> (raw)
In Spain ISDN was replaced by DSL and now both, HFC and DSL and the POTS
have been replaced by FTTH.
Minimum you can get is 100 Mbit/s and max 10 Gbit/s (symmetrical), but for
households max 1 Gbit/s.
Prices start from ~20 euros/month.
The quality of the service that ISPs with revenues higher than 20 millions
are obliged to report follows ETSI standards (mainly speed tests), but will
include latency in 2026 ( as measured by IETF RFC 2681), jitter and packet
losses:
https://www.cnmc.es/sites/default/files/5753856.pdf
Regards
David
Date: Mon, 10 Nov 2025 07:27:37 +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: Jim Forster <jim@connectivitycap.com>
> Cc: J Pan <Pan@uvic.ca>, dan <dandenson@gmail.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: <CDF65ACE-06AD-4C4A-8F74-14B704B89637@gmx.de>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 10 November 2025 05:48:38 CET, Jim Forster <jim@connectivitycap.com>
> wrote:
> >> On Nov 8, 2025, at 1:11 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> >>
> >> 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.
> >
> >
> >Yeah, I also don’t think there’s an efficient, fair, market here that
> gets us what we w. In some ways, the Digital Divide is an expected outcome
> of capital allocation decisions by deregulated companies in a sector that
> has economies of scale and network effects.
>
> Indeed... I just note that the POTS network was much more comprehensive in
> its reach due to stricter regulation...
>
> >
> >At the same time, a "competently managed/regulated monopoly” may be as
> uncommon as Homo Economicus sitings are.
>
> Na, only if we put our aim for competence too high ;) . Over here
> electricity, water and street "networks" are dece
> ntly regulated infrastructure.
>
> >Which example can you cite? NZ? UK? SE? And have they transitioned
> smoothly to new technology that would diminish the value of their existing
> infrastructure?
>
> Tricky... for infrastructure in general I believe there are loads of
> examples in Europe, for internet access networks it gets a bit trickier,
> but there are some examples of combining a single network with operator
> competition. (And that is my preferred model, monopoly network with
> regulated and fair access for operators, and then have as many operators as
> possibke offer their services over that network). But partial examples
> exist, e.g. the fiber network built in Amsterdam, or the point to point
> fiber network in switzerland where the incumbent built most of the ftth
> network and is regulated to physically unbundle individual lines to end
> customers, resultung in surprising competition of ISPs operating different
> technology over the same fibers (swisscom uses xgspon, salt.ch uses their
> own xgspin OLTs, init7 uses AON up to 25 Gbps). Sweden also seems to have a
> decent (albeit not regulated) separation between network operators and ISPs
> that offer services over these networks.
>
>
> >
> >I recall that in the US prior to the .com boom, the telco’s idea of
> broadband was ISDN or maybe DSL or SMDS. They wrote many papers, had lots
> of trials, but did not aggressively do broadband,
>
> Yes, I agree that the old model of a vertically integrated full service
> telco breed complacency and was not ideal either (even though the POTS
> network had better reach than the HFC networks).
>
> : 'Everyone knew’ that the cablecos’ HFC would never work, and that they
> could not do digital and certainly not voice, HFC worked, and DOCSIS was a
> big success. That pressured the telcos to start actually deploying DSL, but
> it was too late, and the cablecos have dominated US broadband for a couple
> of decades.
>
> The outcome in Germany was different... hfc networks only ever reached
> around 75% of households and never exceeded 10 of estimated 45 million
> access sites for broadband services, while DSL still serves almost 23
> million (and reaches almost all 45 million).But yes on the technology side
> it likely was hfc's pressure that sped up dsl development.
> Now, the german market is a bit odd, as customers are neither terribly
> hungry for high capacity nor terribly price sensitive (the old ex-monopoly
> telco still serves most dsl customers in spite of being more expensive due
> to valid regulatory interventions).
>
> Regards
> Sebastian
>
> P.S.: I understand that in this question there are of course multiple
> equally valid and justifyable positions one could take, this just happens
> to be mine. A couple of friendly ISPs for example reject this idea as they
> consider access networks to be a field where ISPs can differentiate and
> compete (some of them however proposed a regulated middle mile to be able
> to economically reach IXs and peering points to even the playing field).
>
> >
> >Jim
> >
> >
> >>
> >
next reply other threads:[~2025-11-10 11:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-10 11:41 David Fernández [this message]
2025-11-10 16:01 ` Sebastian Moeller
[not found] <176262673045.1347.14550047629682790885@gauss>
2025-11-08 19:30 ` David Fernández
2025-11-08 19:45 ` Sebastian Moeller
2025-11-08 20:08 ` J Pan
[not found] <9390D9DA-3C77-429F-A41D-E0FECD52FF06@connectivitycap.com>
[not found] ` <CAJUtOOjt+DajPifDNLNBOT_xwNWL_Wec5Gf_O91HMDdwpxtmeg@mail.gmail.com>
[not found] ` <CAA_JP8XOeSOqbZJPH=1_oWMD055vOUxHipxJMs8sbsHLu5MHCA@mail.gmail.com>
[not found] ` <CAJUtOOhiu8CVLARsiMKUkN4s87_VUr17su1Nr_4aManrwkCQAg@mail.gmail.com>
2025-11-07 10:53 ` [Starlink] Re: [LibreQoS] " Frantisek Borsik
2025-11-07 16:19 ` Jim Forster
2025-11-07 17:52 ` J Pan
2025-11-07 18:55 ` Jim Forster
2025-11-07 19:50 ` J Pan
2025-11-08 16:00 ` [Starlink] Re: [LibreQoS] " dan
2025-11-08 17:03 ` J Pan
2025-11-08 18:04 ` David Collier-Brown
2025-11-08 18:12 ` Sebastian Moeller
2025-11-08 18:31 ` J Pan
2025-11-08 18:11 ` Sebastian Moeller
2025-11-10 4:48 ` Jim Forster
2025-11-10 6:27 ` Sebastian Moeller
2025-11-10 15:39 ` Jim Forster
2025-11-10 20:06 ` Frantisek Borsik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAC=tZ0pihJBGi8A0eK8uPWnedh=d3E0kwW1dh9cR=d0WgT7VkA@mail.gmail.com' \
--to=davidfdzp@gmail.com \
--cc=starlink@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox