Re: [Starlink] [Rpm] [Bloat] [LibreQoS] net neutrality back in the news

Re: [Starlink] [Rpm] [Bloat] [LibreQoS] net neutrality back in the news

[Livingood, Jason]

On 9/29/23, 09:29, "Rich Brown" <richb.hanover@gmail.com <mailto:richb.hanover@gmail.com>> wrote:
> Thank you Jonathan for this clear description of the issues and their history. I wonder if there's a fourth one - privacy. 
> Rosenworcel's talk also points out that ISPs might want to monetize our traffic patterns and location data. (This is less of an issue in the EU, but the US remains a Wild West in this regard.) 

That reference is to mobile networks in the US - but the US-EU contrast you make is a good one! The EU IMO does privacy right - it is not sector-specific regulation but is general privacy protecting law that protects user data no matter the entity collecting/aggregating/sharing. In the US we seem to pursue sector-specific privacy law - like specific to credit cards. What we end up with is a real mess and I would love to see comprehensive national data privacy legislation - but our legislative body can’t even agree right now to keep our government funded past this coming Sunday. ;-)

IANAL but it seems like if the US wanted to provide comprehensive location data privacy then it would have a uniform law that applied not just to a MNO with towers that can locate a handset, but also what the apps loaded on that handset with access to GPS can do with the data as well - and any other party that might be able to collect data.

JL 

Re: [Starlink] [Rpm] [Bloat] [LibreQoS] net neutrality back in the news

[Mike Conlow]

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

First, a thank you to Dave, and lots of you all, for longtime shepherding
of this community and efforts to make the Internet better.

As I read this thread and think about the coming debate in the U.S., two
things come to mind:

1. Ofcom is considering
<https://www.ofcom.org.uk/consultations-and-statements/category-1/net-neutrality-review>
a net neutrality "clarification". The first topic in the consultation is
whether ISPs should be allowed to offer "premium quality retail plans". It
doesn't specify the technical implementation, but there would be different
plans for "users who mainly stream" vs "people who use high quality
virtual reality applications". Apparently ISPs feel the existing NN rules
are not clear on whether this is allowed.

The question I'm thinking about is do we want an Internet where end user
plans are divided up this way? And if not, is a NN regulation the right
place to put those rules?

2. To the point in the PS of the below email, I would agree things are
mostly working in the EU, and in the US. But things
<https://twitter.com/j0xaf/status/850081406277619712> are
<https://twitter.com/th3_s4int/status/1672153674724810752> broken
<https://twitter.com/FuzeMid/status/1369055984052809730> in Germany to the
point where consumers have a degraded Internet experience because their ISP
won't provision enough interconnection.

Are NN rules the right place to address this and make sure it doesn't
happen in the US? Or is one bad actor across the EU and US the cost of
doing business and the Internet ecosystem and "market" are *mostly* solving
the issue?



On Sat, Sep 30, 2023 at 8:19 AM Sebastian Moeller via Rpm <
rpm@lists.bufferbloat.net> wrote:

> Hi Frantisek,
>
> > On Sep 30, 2023, at 14:00, Frantisek Borsik via Rpm <
> rpm@lists.bufferbloat.net> wrote:
> >
> > Back then in 2015, when NN was enacted by Wheeler & CO, there was a
> great body of work (IMHO) done on this subject by Martin Geddes:
> > https://www.martingeddes.com/1261-2/
> >
> > But let's pick one report written by his colleagues and published by
> Ofcom (UK telecoms regulator):
> >
> >       • You cannot conflate ‘equality of [packet] treatment’ with
> delivering equality of [user application] outcomes. Only the latter
> matters, as ordinary users don’t care what happened to the packets in
> transit. Yet the relevant academic literature fixates on the local
> operation of the mechanisms (including Traffic Management), not their
> global aggregate effect.
>
>         [SM] The EU laid out pretty clear why they mandated the NN
> regulations in eu regulation 2015/2120:
>
> [...]
> (8)
> When providing internet access services, providers of those services
> should treat all traffic equally, without discrimination, restriction or
> interference, independently of its sender or receiver, content, application
> or service, or terminal equipment. According to general principles of Union
> law and settled case-law, comparable situations should not be treated
> differently and different situations should not be treated in the same way
> unless such treatment is objectively justified.
> (9)
> The objective of reasonable traffic management is to contribute to an
> efficient use of network resources and to an optimisation of overall
> transmission quality responding to the objectively different technical
> quality of service requirements of specific categories of traffic, and thus
> of the content, applications and services transmitted. Reasonable traffic
> management measures applied by providers of internet access services should
> be transparent, non-discriminatory and proportionate, and should not be
> based on commercial considerations. The requirement for traffic management
> measures to be non-discriminatory does not preclude providers of internet
> access services from implementing, in order to optimise the overall
> transmission quality, traffic management measures which differentiate
> between objectively different categories of traffic. Any such
> differentiation should, in order to optimise overall quality and user
> experience, be permitted only on the basis of objectively different
> technical quality of service requirements (for example, in terms of
> latency, jitter, packet loss, and bandwidth) of the specific categories of
> traffic, and not on the basis of commercial considerations. Such
> differentiating measures should be proportionate in relation to the purpose
> of overall quality optimisation and should treat equivalent traffic
> equally. Such measures should not be maintained for longer than necessary.
> (10)
> Reasonable traffic management does not require techniques which monitor
> the specific content of data traffic transmitted via the internet access
> service.
> (11)
> Any traffic management practices which go beyond such reasonable traffic
> management measures, by blocking, slowing down, altering, restricting,
> interfering with, degrading or discriminating between specific content,
> applications or services, or specific categories of content, applications
> or services, should be prohibited, subject to the justified and defined
> exceptions laid down in this Regulation. Those exceptions should be subject
> to strict interpretation and to proportionality requirements. Specific
> content, applications and services, as well as specific categories thereof,
> should be protected because of the negative impact on end-user choice and
> innovation of blocking, or of other restrictive measures not falling within
> the justified exceptions. Rules against altering content, applications or
> services refer to a modification of the content of the communication, but
> do not ban non-discriminatory data compression techniques which reduce the
> size of a data file without any modification of the content. Such
> compression enables a more efficient use of scarce resources and serves the
> end-users’ interests by reducing data volumes, increasing speed and
> enhancing the experience of using the content, applications or services
> concerned.
> (12)
> Traffic management measures that go beyond such reasonable traffic
> management measures may only be applied as necessary and for as long as
> necessary to comply with the three justified exceptions laid down in this
> Regulation.
> [...]
>
> There really is little IMHO that can be brought against these, all pretty
> fair and reasonable. What it does is accept that internet access is
> essential infrastructure and that hence access needs to be as well
> regulated as access to water, electricity, gas, streets, ... . Yes this has
> some consequences of what ISPs can and can not do. But this is normal "cost
> of business". I for one am quite happy about this regulation existing as
> locally it did away with some (not all) shenanigans of some ISPs that were
> clearly not operating in the interest of their paying eye-balls.
>
> There is a whole cottage industry of consultants that decry the EU's
> decision and try to lobby against it, but honestly reading these mostly
> makes me think harsher regulation might be required (on consultans about
> how much they are allowed to massage the facts ;) ).
>
> Regards
>         Sebastian
>
> P.S.: Of course if we look close enough we surely can find corner-cases
> where either the EU regulations or the translation into national law result
> in less desirable outcomes, but "nothing is perfect" and all in all the
> regulations seem to be "good enough". With the caveat that explicitly
> excluding ISP interconnect from the regulations BEREC essentially pointed
> the way for ISPs wanting to monetize their eye-balls twice to do so via
> interconnects, but that only works for the 800 pound gorillas and generally
> is not a game smaller ISPs can play. I do understand why BEREC wants to
> stay out of the interconnection issue, as this is rather complicated and
> the market seems to generally work okay-ish (that is not badly enough to
> make intervention a hot-button issue for voters and hence politicians).
>
>
>
> >
> > 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 Fri, Sep 29, 2023 at 6:15 PM dan via Rpm <rpm@lists.bufferbloat.net>
> wrote:
> > ok, lots and lots of great comments here for sure.
> >
> > bandwidth abundance:  Not for most people and ISPs.  The 'carriers'
> aren't carrying to many places at affordable rates.  I've pulled quotes
> from Lumen and Zayo at over $5k/month/gig.  We typically pay 900-1400 for a
> gig of service.  This isn't abundance and it's widespread and it leaves
> only major providers that can afford/amortize out 100G transits etc.
> > My answer to this is one that Dave and I have bounced back and forth is
> the idea of micro IXs in every municipality and having that somehow tied
> into access to the ROW in counties etc.  Not fully hashed out, but the
> fiber is in the ground, it could be sold, but the carriers are not well
> incentivised to sell it.  It takes the better part of a year to get a DIA
> within 100ft of a Lumen hut sometimes...  Heck, it could even be a
> government program to get an μIX with x feet of every school, city hall,
> and library.  I don't care how it's done but this would get abundance NEAR
> end users and open up essentially every town to competition.
> >
> > monopoly.  This is a historical thing for most cable and DSL
> incumbents.  They have enjoyed virtual monopolies with cable owning
> population centers and DSL owning the outskirts and there is no product
> darwinism here where customer satisfaction is a pressure.  That may not be
> the future but it definitely is the past.  These companies may have to
> shift into customer satisfaction as a major part instead of a minor part of
> their corporate culture to fend off fttx and ultra-modern wisps.
> >
> > Starlink is not offering significant competition to major carriers.
> Starlink's 1.5 million customers are at LEAST 90% pulled from other
> satellite services and small ISPs.  Spectrum and Comcast's losses to
> starlink are measured in decimal points.
> >
> > Only fttx and ultra-modern wireless tech really threatens these
> incumbents.  Typical wisps aren't putting a dent in these guys, just
> scraping the paint off their bumper.  We're pulling customers at the scale
> of 'dozens' for example.  Spectrum's management doesn't know we exist we're
> such a small threat to them.
> >
> > But to further the point here, these fttx and ultra-modern wisps can
> only exist in places where there is adequate carrier services to start
> with.  In areas where they spend the money and do the build but there
> aren't good carrier services, those fiber services suck and the wISPs start
> to claw back even with inferior technology.  We've pulled quite a few
> customers off fttx deployments because of this sort of situation.
> >
> >
> > On Fri, Sep 29, 2023 at 7:28 AM Rich Brown <richb.hanover@gmail.com>
> wrote:
> > Thank you Jonathan for this clear description of the issues and their
> history. I wonder if there's a fourth one - privacy.
> >
> > Rosenworcel's talk
> https://docs.fcc.gov/public/attachments/DOC-397257A1.pdf also points out
> that ISPs might want to monetize our traffic patterns and location data.
> (This is less of an issue in the EU, but the US remains a Wild West in this
> regard.)
> >
> > I am hopeful that the FCC will include this in their NPRM (which must be
> available by now but I haven't looked...)
> >
> > - Rich Brown
> >
> > > On Sep 29, 2023, at 12:54 AM, Jonathan Morton via Rpm <
> rpm@lists.bufferbloat.net> wrote:
> > >
> > >> On 29 Sep, 2023, at 1:19 am, David Lang via Bloat <
> bloat@lists.bufferbloat.net> wrote:
> > >>
> > >> Dave T called out earlier that the rise of bittorrent was a large
> part of the inital NN discussion here in the US. But a second large portion
> was a money grab from ISPs thinking that they could hold up large paid
> websites (netflix for example) for additional fees by threatening to make
> their service less useful to their users (viewing their users as an asset
> to be marketed to the websites rather than customers to be satisfied by
> providing them access to the websites)
> > >>
> > >> I don't know if a new round of "it's not fair that Netflix doesn't
> pay us for the bandwidth to service them" would fall flat at this point or
> not.
> > >
> > > I think there were three more-or-less separate concerns which have,
> over time, fallen under the same umbrella:
> > >
> > >
> > > 1:  Capacity-seeking flows tend to interfere with latency-sensitive
> flows, and the "induced demand" phenomenon means that increases in link
> rate do not in themselves solve this problem, even though they may be sold
> as doing so.
> > >
> > > This is directly addressed by properly-sized buffers and/or AQM, and
> even better by FQ and SQM.  It's a solved problem, so long as the solutions
> are deployed.  It's not usually necessary, for example, to specifically
> enhance service for latency-sensitive traffic, if FQ does a sufficiently
> good job.  An increased link rate *does* enhance service quality for both
> latency-sensitive and capacity-seeking traffic, provided FQ is in use.
> > >
> > >
> > > 2:  Swarm traffic tends to drown out conventional traffic, due to
> congestion control algorithms which try to be more-or-less fair on a
> per-flow basis, and the substantially larger number of parallel flows used
> by swarm traffic.  This also caused subscribers using swarm traffic to
> impair the service of subscribers who had nothing to do with it.
> > >
> > > FQ on a per-flow basis (see problem 1) actually amplifies this effect,
> and I think it was occasionally used as an argument for *not* deploying
> FQ.  ISPs' initial response was to outright block swarm traffic where they
> could identify it, which was then softened to merely throttling it heavily,
> before NN regulations intervened.  Usage quotas also showed up around this
> time, and were probably related to this problem.
> > >
> > > This has since been addressed by several means.  ISPs may use FQ on a
> per-subscriber basis to prevent one subscriber's heavy traffic from
> degrading service for another.  Swarm applications nowadays tend to employ
> altruistic congestion control which deliberately compensates for the large
> number of flows, and/or mark them with one or more of the Least Effort
> class DSCPs.  Hence, swarm applications are no longer as damaging to
> service quality as they used to be.  Usage quotas, however, still remain in
> use as a profit centre, to the point where an "unlimited" service is a rare
> and precious specimen in many jurisdictions.
> > >
> > >
> > > 3:  ISPs merged with media distribution companies, creating a conflict
> of interest in which the media side of the business wanted the internet
> side to actively favour "their own" media traffic at the expense of "the
> competition".  Some ISPs began to actively degrade Netflix traffic, in
> particular by refusing to provision adequate peering capacity at the nodes
> through which Netflix traffic predominated, or by zero-rating (for the
> purpose of usage quotas) traffic from their own media empire while refusing
> to do the same for Netflix traffic.
> > >
> > > **THIS** was the true core of Net Neutrality.  NN regulations forced
> ISPs to carry Netflix traffic with reasonable levels of service, even
> though they didn't want to for purely selfish and greedy commercial
> reasons.  NN succeeded in curbing an anti-competitive and consumer-hostile
> practice, which I am perfectly sure would resume just as soon as NN
> regulations were repealed.
> > >
> > > And this type of practice is just the sort of thing that technologies
> like L4S are designed to support.  The ISPs behind L4S actively do not want
> a technology that works end-to-end over the general Internet.  They want
> something that can provide a domination service within their own walled
> gardens.  That's why L4S is a NN hazard, and why they actively resisted all
> attempts to displace it with SCE.
> > >
> > >
> > > All of the above were made more difficult to solve by the monopolistic
> nature of the Internet service industry.  It is actively difficult for
> Internet users to move to a truly different service, especially one based
> on a different link technology.  When attempts are made to increase
> competition, for example by deploying a publicly-funded network, the
> incumbents actively sabotage those attempts by any means they can.
> Monopolies are inherently customer-hostile, and arguments based on market
> forces fail in their presence.
> > >
> > > - Jonathan Morton
> > >
> > > _______________________________________________
> > > Rpm mailing list
> > > Rpm@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/rpm
> >
> > _______________________________________________
> > Rpm mailing list
> > Rpm@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm
> > _______________________________________________
> > Rpm mailing list
> > Rpm@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm
>
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm
>

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

Re: [Starlink] [Rpm] [Bloat] [LibreQoS] net neutrality back in the news

[Sebastian Moeller]

So, let me start wit a big caveat:
I am just an internet end-user and have no insight into the ISP side of things.
Nor am I a lawyer and hence might moss some of the subtleties of the regulation and their translation into law in each member state.



> On Sep 30, 2023, at 14:42, Vint Cerf <vint@google.com> wrote:
> 
> the phrase "treat equally" can (maybe should?) be interpreted as offering the same options for traffic handling to all parties on the same terms and conditions.

	[SM] Let me start with noting that, clearly selling internet access links with different maximum capacity is established practice in the EU (as in most/all other markets), and has been before and after the regulation was published and converted to national law in the member states*. The EU regulation contains some rules about how ISPs are allowed to market these speed/capacity numbers and which remedies end customers have when the ISP under-delivers (as well as making the national regulator responsible to create methods to actually assess achievable capacity). So on the consumer side this is pretty clear (and the regulations encompasses all parties buying access service as end-customers, so a content provider buying internet access will covered just as a privat hoisehold.

*) There are however unicorn ISPs like Switzerland's Init7 that offered 1Gbps, 10 Gbps or 25 Gbps symmetric internet access links for the same monthly price (they recently seemed to have dropped the 1 Gbps tier, but 10 or 25 still cost the same relative low CHF 64.75/month); the main difference is the initial cost differs (probably to cover the cost of the more expensive optics at the optical switch in the CO). But again that is clearly NOT the norm ;) and as much as would wish otherwise Switzerland is not a member of the EU... 



Here is the first clause of the preamble (see https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32015R2120 ):
(1)
This Regulation aims to establish common rules to safeguard equal and non-discriminatory treatment of traffic in the provision of internet access services and related end-users’ rights. It aims to protect end-users and simultaneously to guarantee the continued functioning of the internet ecosystem as an engine of innovation. Reforms in the field of roaming should give end-users the confidence to stay connected when they travel within the Union, and should, over time, become a driver of convergent pricing and other conditions in the Union.

making it clear that this mainly focusses on internet access (and mobile roaming, but that seems less relevant for this thread).

> If there is only one class of service, then equally is the only option.

This would likely be other/non-internet accesss or specialized services in the parlance of the regulation:

(16)
There is demand on the part of providers of content, applications and services to be able to provide electronic communication services other than internet access services, for which specific levels of quality, that are not assured by internet access services, are necessary. Such specific levels of quality are, for instance, required by some services responding to a public interest or by some new machine-to-machine communications services. Providers of electronic communications to the public, including providers of internet access services, and providers of content, applications and services should therefore be free to offer services which are not internet access services and which are optimised for specific content, applications or services, or a combination thereof, where the optimisation is necessary in order to meet the requirements of the content, applications or services for a specific level of quality. National regulatory authorities should verify whether and to what extent such optimisation is objectively necessary to ensure one or more specific and key features of the content, applications or services and to enable a corresponding quality assurance to be given to end-users, rather than simply granting general priority over comparable content, applications or services available via the internet access service and thereby circumventing the provisions regarding traffic management measures applicable to the internet access services.
(17)
In order to avoid the provision of such other services having a negative impact on the availability or general quality of internet access services for end-users, sufficient capacity needs to be ensured. Providers of electronic communications to the public, including providers of internet access services, should, therefore, offer such other services, or conclude corresponding agreements with providers of content, applications or services facilitating such other services, only if the network capacity is sufficient for their provision in addition to any internet access services provided. The provisions of this Regulation on the safeguarding of open internet access should not be circumvented by means of other services usable or offered as a replacement for internet access services. However, the mere fact that corporate services such as virtual private networks might also give access to the internet should not result in them being considered to be a replacement of the internet access services, provided that the provision of such access to the internet by a provider of electronic communications to the public complies with Article 3(1) to (4) of this Regulation, and therefore cannot be considered to be a circumvention of those provisions. The provision of such services other than internet access services should not be to the detriment of the availability and general quality of internet access services for end-users. In mobile networks, traffic volumes in a given radio cell are more difficult to anticipate due to the varying number of active end-users, and for this reason an impact on the quality of internet access services for end-users might occur in unforeseeable circumstances. In mobile networks, the general quality of internet access services for end-users should not be deemed to incur a detriment where the aggregate negative impact of services other than internet access services is unavoidable, minimal and limited to a short duration. National regulatory authorities should ensure that providers of electronic communications to the public comply with that requirement. In this respect, national regulatory authorities should assess the impact on the availability and general quality of internet access services by analysing, inter alia, quality of service parameters (such as latency, jitter, packet loss), the levels and effects of congestion in the network, actual versus advertised speeds, the performance of internet access services as compared with services other than internet access services, and quality as perceived by end-users.


As an non-jurist I would gather that (17) above can be a bit tricky to police, but as long as an ISP is not actively using such services to monetize giving users a remedy for their own congested normal internet access offering something like this is not an issue. Also while the regulation does not mention interconnection at all, the interpretation of the EU's regulatory agencies (BEREC) explicitly treats it as something different:
https://www.berec.europa.eu/sites/default/files/files/document_register_store/2022/6/BoR_%2822%29_81_Update_to_the_BEREC_Guidelines_on_the_Implementation_of_the_Open_Internet_Regulation.pdf
"	• CAPs are protected as end-users under the Regulation in so far as CAPs use an IAS to reach other end-users. However, some CAPs may also operate their own networks and, as part of that, have interconnection agreements with ISPs; the provision of interconnection is a distinct service from the provision of IAS.

	• NRAs may take into account the interconnection policies and practices of ISPs in so far as they have the effect of limiting the exercise of end-user rights under Article 3(1). For example, this may be relevant in some cases, such as if the interconnection is implemented in a way which seeks to circumvent the Regulation.9"

As long as ISP do not use interconnects to blatently violate the articles of the EU directive they are out of scope for this regulation. I believe the assessment is that there is a healthy enough market to self-control. I lack real data to be able to assess the validity of that judgement, but I am willing to accept it as probably correct ;).


> If there are multiple classes of service, then these could (should?) be available to all customers indiscriminately. For example, there might be several distinct services with different maximum bit rates;

	[SM] As I mention above, different access rates are fine with the regulation, as are different prices, and ISPs are also free (at least from the perspective of the 2015/2120) to set any prices and rates for their plans as they see fit (resulting in clearly different prices for similar conditions between different european countries, this is also not a problem for the regulation*)


*) This and other regulations however expect more or less that any union citizen will be able to get the same price from the same ISP in the same country, so TelakomA might charge me X in Germany and Y in Austria, both need to charge the same whether a customer is from Germany or Austria as long as the customer books in the same country. The EU hopes that prices will converge inside the union, but it does not enforce this.


> the higher rates possibly available for a higher charge. If there is discrimination, it should be on the basis of customer choice and not dictated by the provider. 
> 
> Is that consistent with the European interpretation?

	[SM] For end-customers plans, yes this is fully aligned with the directive, the idea, to put it bluntly, seems not have been to completely disrupt the existing market, but merely prohibit attempts of ISPs to unduly exploit their often near-monopoly on customer eye-balls*. And I would say this all in all has worked pretty well (again, maybe not perfectly, but I am fine with "good enough").

If you have time the whole thing is worth a read as are the implementation guidelines, independent on whether you finally agree or disagree with the position the EU has taken on this matter. It will however cost some time and is written in the kind of language that quickly makes me drowsy.

Regards
	Sebastian

*) And there was precedence of unsavory behavior by some ISPs so this thing was not coming out of the blue. But on the other hand the regulation has not magically stopped al unsavory ISP behavior either. I happen to think that all in all this is a decent piece of regulation not perfect, but plenty "good enough" solving a real emerging problem in a way that seems just to all sides.


P.S.: The regulation also contains a section about transparency (essentially ISPs are free what rates to offer, but once they offer a rate they are responsible to actually deliver on their offer, doing away with a lot of the "up to X" shenanigans some ISPs had been up to before) that initially caused ISP backlash when it was introduced in German law, but since then things have been pretty quiet, ISP simply got better at making sure they deliver or alternatively allow under-served customers to cancel contracts without penalty. A lot of bruhaha about nothing....

P.P.S.: The last case where the 2015/2120 was used was to prohibit mobile operators from using zero-rating, that is not accounting some traffic against the mobile data caps. But I am sure I am not doing justice to the subtlety of that case with a single sentence ;)

P.P.P.S.: The same EU having made a rather reasonable piece of regulation can at the same time come up with hare-brained ideas about having content providers pay for the network build-out in the EU. While I have sympathy for taxing big technology companies more similar to other companies and individuals in the individual countries they generate revenue**, I do not think that forcing "big tech" to fill the coffers of "old telco" is an endeavor anybody but "big telco" shareholders should fathom acceptable.

**) Without strong evidence, I believe this is currently not the case


> 
> v
> 
> 
> On Sat, Sep 30, 2023 at 1:19 PM Sebastian Moeller via Starlink <starlink@lists.bufferbloat.net> wrote:
> Hi Frantisek,
> 
> > On Sep 30, 2023, at 14:00, Frantisek Borsik via Rpm <rpm@lists.bufferbloat.net> wrote:
> > 
> > Back then in 2015, when NN was enacted by Wheeler & CO, there was a great body of work (IMHO) done on this subject by Martin Geddes:
> > https://www.martingeddes.com/1261-2/
> > 
> > But let's pick one report written by his colleagues and published by Ofcom (UK telecoms regulator):
> > 
> >       • You cannot conflate ‘equality of [packet] treatment’ with delivering equality of [user application] outcomes. Only the latter matters, as ordinary users don’t care what happened to the packets in transit. Yet the relevant academic literature fixates on the local operation of the mechanisms (including Traffic Management), not their global aggregate effect.
> 
>         [SM] The EU laid out pretty clear why they mandated the NN regulations in eu regulation 2015/2120:
> 
> [...]
> (8)
> When providing internet access services, providers of those services should treat all traffic equally, without discrimination, restriction or interference, independently of its sender or receiver, content, application or service, or terminal equipment. According to general principles of Union law and settled case-law, comparable situations should not be treated differently and different situations should not be treated in the same way unless such treatment is objectively justified.
> (9)
> The objective of reasonable traffic management is to contribute to an efficient use of network resources and to an optimisation of overall transmission quality responding to the objectively different technical quality of service requirements of specific categories of traffic, and thus of the content, applications and services transmitted. Reasonable traffic management measures applied by providers of internet access services should be transparent, non-discriminatory and proportionate, and should not be based on commercial considerations. The requirement for traffic management measures to be non-discriminatory does not preclude providers of internet access services from implementing, in order to optimise the overall transmission quality, traffic management measures which differentiate between objectively different categories of traffic. Any such differentiation should, in order to optimise overall quality and user experience, be permitted only on the basis of objectively different technical quality of service requirements (for example, in terms of latency, jitter, packet loss, and bandwidth) of the specific categories of traffic, and not on the basis of commercial considerations. Such differentiating measures should be proportionate in relation to the purpose of overall quality optimisation and should treat equivalent traffic equally. Such measures should not be maintained for longer than necessary.
> (10)
> Reasonable traffic management does not require techniques which monitor the specific content of data traffic transmitted via the internet access service.
> (11)
> Any traffic management practices which go beyond such reasonable traffic management measures, by blocking, slowing down, altering, restricting, interfering with, degrading or discriminating between specific content, applications or services, or specific categories of content, applications or services, should be prohibited, subject to the justified and defined exceptions laid down in this Regulation. Those exceptions should be subject to strict interpretation and to proportionality requirements. Specific content, applications and services, as well as specific categories thereof, should be protected because of the negative impact on end-user choice and innovation of blocking, or of other restrictive measures not falling within the justified exceptions. Rules against altering content, applications or services refer to a modification of the content of the communication, but do not ban non-discriminatory data compression techniques which reduce the size of a data file without any modification of the content. Such compression enables a more efficient use of scarce resources and serves the end-users’ interests by reducing data volumes, increasing speed and enhancing the experience of using the content, applications or services concerned.
> (12)
> Traffic management measures that go beyond such reasonable traffic management measures may only be applied as necessary and for as long as necessary to comply with the three justified exceptions laid down in this Regulation.
> [...]
> 
> There really is little IMHO that can be brought against these, all pretty fair and reasonable. What it does is accept that internet access is essential infrastructure and that hence access needs to be as well regulated as access to water, electricity, gas, streets, ... . Yes this has some consequences of what ISPs can and can not do. But this is normal "cost of business". I for one am quite happy about this regulation existing as locally it did away with some (not all) shenanigans of some ISPs that were clearly not operating in the interest of their paying eye-balls.
> 
> There is a whole cottage industry of consultants that decry the EU's decision and try to lobby against it, but honestly reading these mostly makes me think harsher regulation might be required (on consultans about how much they are allowed to massage the facts ;) ). 
> 
> Regards
>         Sebastian
> 
> P.S.: Of course if we look close enough we surely can find corner-cases where either the EU regulations or the translation into national law result in less desirable outcomes, but "nothing is perfect" and all in all the regulations seem to be "good enough". With the caveat that explicitly excluding ISP interconnect from the regulations BEREC essentially pointed the way for ISPs wanting to monetize their eye-balls twice to do so via interconnects, but that only works for the 800 pound gorillas and generally is not a game smaller ISPs can play. I do understand why BEREC wants to stay out of the interconnection issue, as this is rather complicated and the market seems to generally work okay-ish (that is not badly enough to make intervention a hot-button issue for voters and hence politicians).
> 
> 
> 
> > 
> > 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 Fri, Sep 29, 2023 at 6:15 PM dan via Rpm <rpm@lists.bufferbloat.net> wrote:
> > ok, lots and lots of great comments here for sure.  
> > 
> > bandwidth abundance:  Not for most people and ISPs.  The 'carriers' aren't carrying to many places at affordable rates.  I've pulled quotes from Lumen and Zayo at over $5k/month/gig.  We typically pay 900-1400 for a gig of service.  This isn't abundance and it's widespread and it leaves only major providers that can afford/amortize out 100G transits etc.
> > My answer to this is one that Dave and I have bounced back and forth is the idea of micro IXs in every municipality and having that somehow tied into access to the ROW in counties etc.  Not fully hashed out, but the fiber is in the ground, it could be sold, but the carriers are not well incentivised to sell it.  It takes the better part of a year to get a DIA within 100ft of a Lumen hut sometimes...  Heck, it could even be a government program to get an μIX with x feet of every school, city hall, and library.  I don't care how it's done but this would get abundance NEAR end users and open up essentially every town to competition.
> > 
> > monopoly.  This is a historical thing for most cable and DSL incumbents.  They have enjoyed virtual monopolies with cable owning population centers and DSL owning the outskirts and there is no product darwinism here where customer satisfaction is a pressure.  That may not be the future but it definitely is the past.  These companies may have to shift into customer satisfaction as a major part instead of a minor part of their corporate culture to fend off fttx and ultra-modern wisps.
> > 
> > Starlink is not offering significant competition to major carriers.    Starlink's 1.5 million customers are at LEAST 90% pulled from other satellite services and small ISPs.  Spectrum and Comcast's losses to starlink are measured in decimal points.
> > 
> > Only fttx and ultra-modern wireless tech really threatens these incumbents.  Typical wisps aren't putting a dent in these guys, just scraping the paint off their bumper.  We're pulling customers at the scale of 'dozens' for example.  Spectrum's management doesn't know we exist we're such a small threat to them.   
> > 
> > But to further the point here, these fttx and ultra-modern wisps can only exist in places where there is adequate carrier services to start with.  In areas where they spend the money and do the build but there aren't good carrier services, those fiber services suck and the wISPs start to claw back even with inferior technology.  We've pulled quite a few customers off fttx deployments because of this sort of situation.
> > 
> > 
> > On Fri, Sep 29, 2023 at 7:28 AM Rich Brown <richb.hanover@gmail.com> wrote:
> > Thank you Jonathan for this clear description of the issues and their history. I wonder if there's a fourth one - privacy. 
> > 
> > Rosenworcel's talk https://docs.fcc.gov/public/attachments/DOC-397257A1.pdf also points out that ISPs might want to monetize our traffic patterns and location data. (This is less of an issue in the EU, but the US remains a Wild West in this regard.) 
> > 
> > I am hopeful that the FCC will include this in their NPRM (which must be available by now but I haven't looked...)
> > 
> > - Rich Brown
> > 
> > > On Sep 29, 2023, at 12:54 AM, Jonathan Morton via Rpm <rpm@lists.bufferbloat.net> wrote:
> > > 
> > >> On 29 Sep, 2023, at 1:19 am, David Lang via Bloat <bloat@lists.bufferbloat.net> wrote:
> > >> 
> > >> Dave T called out earlier that the rise of bittorrent was a large part of the inital NN discussion here in the US. But a second large portion was a money grab from ISPs thinking that they could hold up large paid websites (netflix for example) for additional fees by threatening to make their service less useful to their users (viewing their users as an asset to be marketed to the websites rather than customers to be satisfied by providing them access to the websites)
> > >> 
> > >> I don't know if a new round of "it's not fair that Netflix doesn't pay us for the bandwidth to service them" would fall flat at this point or not.
> > > 
> > > I think there were three more-or-less separate concerns which have, over time, fallen under the same umbrella:
> > > 
> > > 
> > > 1:  Capacity-seeking flows tend to interfere with latency-sensitive flows, and the "induced demand" phenomenon means that increases in link rate do not in themselves solve this problem, even though they may be sold as doing so.
> > > 
> > > This is directly addressed by properly-sized buffers and/or AQM, and even better by FQ and SQM.  It's a solved problem, so long as the solutions are deployed.  It's not usually necessary, for example, to specifically enhance service for latency-sensitive traffic, if FQ does a sufficiently good job.  An increased link rate *does* enhance service quality for both latency-sensitive and capacity-seeking traffic, provided FQ is in use.
> > > 
> > > 
> > > 2:  Swarm traffic tends to drown out conventional traffic, due to congestion control algorithms which try to be more-or-less fair on a per-flow basis, and the substantially larger number of parallel flows used by swarm traffic.  This also caused subscribers using swarm traffic to impair the service of subscribers who had nothing to do with it.
> > > 
> > > FQ on a per-flow basis (see problem 1) actually amplifies this effect, and I think it was occasionally used as an argument for *not* deploying FQ.  ISPs' initial response was to outright block swarm traffic where they could identify it, which was then softened to merely throttling it heavily, before NN regulations intervened.  Usage quotas also showed up around this time, and were probably related to this problem.
> > > 
> > > This has since been addressed by several means.  ISPs may use FQ on a per-subscriber basis to prevent one subscriber's heavy traffic from degrading service for another.  Swarm applications nowadays tend to employ altruistic congestion control which deliberately compensates for the large number of flows, and/or mark them with one or more of the Least Effort class DSCPs.  Hence, swarm applications are no longer as damaging to service quality as they used to be.  Usage quotas, however, still remain in use as a profit centre, to the point where an "unlimited" service is a rare and precious specimen in many jurisdictions.
> > > 
> > > 
> > > 3:  ISPs merged with media distribution companies, creating a conflict of interest in which the media side of the business wanted the internet side to actively favour "their own" media traffic at the expense of "the competition".  Some ISPs began to actively degrade Netflix traffic, in particular by refusing to provision adequate peering capacity at the nodes through which Netflix traffic predominated, or by zero-rating (for the purpose of usage quotas) traffic from their own media empire while refusing to do the same for Netflix traffic.
> > > 
> > > **THIS** was the true core of Net Neutrality.  NN regulations forced ISPs to carry Netflix traffic with reasonable levels of service, even though they didn't want to for purely selfish and greedy commercial reasons.  NN succeeded in curbing an anti-competitive and consumer-hostile practice, which I am perfectly sure would resume just as soon as NN regulations were repealed.
> > > 
> > > And this type of practice is just the sort of thing that technologies like L4S are designed to support.  The ISPs behind L4S actively do not want a technology that works end-to-end over the general Internet.  They want something that can provide a domination service within their own walled gardens.  That's why L4S is a NN hazard, and why they actively resisted all attempts to displace it with SCE.
> > > 
> > > 
> > > All of the above were made more difficult to solve by the monopolistic nature of the Internet service industry.  It is actively difficult for Internet users to move to a truly different service, especially one based on a different link technology.  When attempts are made to increase competition, for example by deploying a publicly-funded network, the incumbents actively sabotage those attempts by any means they can.  Monopolies are inherently customer-hostile, and arguments based on market forces fail in their presence.
> > > 
> > > - Jonathan Morton
> > > 
> > > _______________________________________________
> > > Rpm mailing list
> > > Rpm@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/rpm
> > 
> > _______________________________________________
> > Rpm mailing list
> > Rpm@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm
> > _______________________________________________
> > Rpm mailing list
> > Rpm@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
> 
> 
> -- 
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
> 
> 
> until further notice
> 
> 
> 

Re: [Starlink] [Rpm] [Bloat] [LibreQoS] net neutrality back in the news

[Vint Cerf]

[-- Attachment #1.1: Type: text/plain, Size: 17087 bytes --]

the phrase "treat equally" can (maybe should?) be interpreted as offering
the same options for traffic handling to all parties on the same terms and
conditions. If there is only one class of service, then equally is the only
option. If there are multiple classes of service, then these could
(should?) be available to all customers indiscriminately. For example,
there might be several distinct services with different maximum bit rates;
the higher rates possibly available for a higher charge. If there is
discrimination, it should be on the basis of customer choice and not
dictated by the provider.

Is that consistent with the European interpretation?

v


On Sat, Sep 30, 2023 at 1:19 PM Sebastian Moeller via Starlink <
starlink@lists.bufferbloat.net> wrote:

> Hi Frantisek,
>
> > On Sep 30, 2023, at 14:00, Frantisek Borsik via Rpm <
> rpm@lists.bufferbloat.net> wrote:
> >
> > Back then in 2015, when NN was enacted by Wheeler & CO, there was a
> great body of work (IMHO) done on this subject by Martin Geddes:
> > https://www.martingeddes.com/1261-2/
> >
> > But let's pick one report written by his colleagues and published by
> Ofcom (UK telecoms regulator):
> >
> >       • You cannot conflate ‘equality of [packet] treatment’ with
> delivering equality of [user application] outcomes. Only the latter
> matters, as ordinary users don’t care what happened to the packets in
> transit. Yet the relevant academic literature fixates on the local
> operation of the mechanisms (including Traffic Management), not their
> global aggregate effect.
>
>         [SM] The EU laid out pretty clear why they mandated the NN
> regulations in eu regulation 2015/2120:
>
> [...]
> (8)
> When providing internet access services, providers of those services
> should treat all traffic equally, without discrimination, restriction or
> interference, independently of its sender or receiver, content, application
> or service, or terminal equipment. According to general principles of Union
> law and settled case-law, comparable situations should not be treated
> differently and different situations should not be treated in the same way
> unless such treatment is objectively justified.
> (9)
> The objective of reasonable traffic management is to contribute to an
> efficient use of network resources and to an optimisation of overall
> transmission quality responding to the objectively different technical
> quality of service requirements of specific categories of traffic, and thus
> of the content, applications and services transmitted. Reasonable traffic
> management measures applied by providers of internet access services should
> be transparent, non-discriminatory and proportionate, and should not be
> based on commercial considerations. The requirement for traffic management
> measures to be non-discriminatory does not preclude providers of internet
> access services from implementing, in order to optimise the overall
> transmission quality, traffic management measures which differentiate
> between objectively different categories of traffic. Any such
> differentiation should, in order to optimise overall quality and user
> experience, be permitted only on the basis of objectively different
> technical quality of service requirements (for example, in terms of
> latency, jitter, packet loss, and bandwidth) of the specific categories of
> traffic, and not on the basis of commercial considerations. Such
> differentiating measures should be proportionate in relation to the purpose
> of overall quality optimisation and should treat equivalent traffic
> equally. Such measures should not be maintained for longer than necessary.
> (10)
> Reasonable traffic management does not require techniques which monitor
> the specific content of data traffic transmitted via the internet access
> service.
> (11)
> Any traffic management practices which go beyond such reasonable traffic
> management measures, by blocking, slowing down, altering, restricting,
> interfering with, degrading or discriminating between specific content,
> applications or services, or specific categories of content, applications
> or services, should be prohibited, subject to the justified and defined
> exceptions laid down in this Regulation. Those exceptions should be subject
> to strict interpretation and to proportionality requirements. Specific
> content, applications and services, as well as specific categories thereof,
> should be protected because of the negative impact on end-user choice and
> innovation of blocking, or of other restrictive measures not falling within
> the justified exceptions. Rules against altering content, applications or
> services refer to a modification of the content of the communication, but
> do not ban non-discriminatory data compression techniques which reduce the
> size of a data file without any modification of the content. Such
> compression enables a more efficient use of scarce resources and serves the
> end-users’ interests by reducing data volumes, increasing speed and
> enhancing the experience of using the content, applications or services
> concerned.
> (12)
> Traffic management measures that go beyond such reasonable traffic
> management measures may only be applied as necessary and for as long as
> necessary to comply with the three justified exceptions laid down in this
> Regulation.
> [...]
>
> There really is little IMHO that can be brought against these, all pretty
> fair and reasonable. What it does is accept that internet access is
> essential infrastructure and that hence access needs to be as well
> regulated as access to water, electricity, gas, streets, ... . Yes this has
> some consequences of what ISPs can and can not do. But this is normal "cost
> of business". I for one am quite happy about this regulation existing as
> locally it did away with some (not all) shenanigans of some ISPs that were
> clearly not operating in the interest of their paying eye-balls.
>
> There is a whole cottage industry of consultants that decry the EU's
> decision and try to lobby against it, but honestly reading these mostly
> makes me think harsher regulation might be required (on consultans about
> how much they are allowed to massage the facts ;) ).
>
> Regards
>         Sebastian
>
> P.S.: Of course if we look close enough we surely can find corner-cases
> where either the EU regulations or the translation into national law result
> in less desirable outcomes, but "nothing is perfect" and all in all the
> regulations seem to be "good enough". With the caveat that explicitly
> excluding ISP interconnect from the regulations BEREC essentially pointed
> the way for ISPs wanting to monetize their eye-balls twice to do so via
> interconnects, but that only works for the 800 pound gorillas and generally
> is not a game smaller ISPs can play. I do understand why BEREC wants to
> stay out of the interconnection issue, as this is rather complicated and
> the market seems to generally work okay-ish (that is not badly enough to
> make intervention a hot-button issue for voters and hence politicians).
>
>
>
> >
> > All the best,
> >
> > Frank
> >
> > Frantisek (Frank) Borsik
> >
> >
> >
> > https://www.linkedin.com/in/frantisekborsik
> >
> > Signal, Telegram, WhatsApp: +421919416714 <+421%20919%20416%20714>
> >
> > iMessage, mobile: +420775230885 <+420%20775%20230%20885>
> >
> > Skype: casioa5302ca
> >
> > frantisek.borsik@gmail.com
> >
> >
> >
> > On Fri, Sep 29, 2023 at 6:15 PM dan via Rpm <rpm@lists.bufferbloat.net>
> wrote:
> > ok, lots and lots of great comments here for sure.
> >
> > bandwidth abundance:  Not for most people and ISPs.  The 'carriers'
> aren't carrying to many places at affordable rates.  I've pulled quotes
> from Lumen and Zayo at over $5k/month/gig.  We typically pay 900-1400 for a
> gig of service.  This isn't abundance and it's widespread and it leaves
> only major providers that can afford/amortize out 100G transits etc.
> > My answer to this is one that Dave and I have bounced back and forth is
> the idea of micro IXs in every municipality and having that somehow tied
> into access to the ROW in counties etc.  Not fully hashed out, but the
> fiber is in the ground, it could be sold, but the carriers are not well
> incentivised to sell it.  It takes the better part of a year to get a DIA
> within 100ft of a Lumen hut sometimes...  Heck, it could even be a
> government program to get an μIX with x feet of every school, city hall,
> and library.  I don't care how it's done but this would get abundance NEAR
> end users and open up essentially every town to competition.
> >
> > monopoly.  This is a historical thing for most cable and DSL
> incumbents.  They have enjoyed virtual monopolies with cable owning
> population centers and DSL owning the outskirts and there is no product
> darwinism here where customer satisfaction is a pressure.  That may not be
> the future but it definitely is the past.  These companies may have to
> shift into customer satisfaction as a major part instead of a minor part of
> their corporate culture to fend off fttx and ultra-modern wisps.
> >
> > Starlink is not offering significant competition to major carriers.
> Starlink's 1.5 million customers are at LEAST 90% pulled from other
> satellite services and small ISPs.  Spectrum and Comcast's losses to
> starlink are measured in decimal points.
> >
> > Only fttx and ultra-modern wireless tech really threatens these
> incumbents.  Typical wisps aren't putting a dent in these guys, just
> scraping the paint off their bumper.  We're pulling customers at the scale
> of 'dozens' for example.  Spectrum's management doesn't know we exist we're
> such a small threat to them.
> >
> > But to further the point here, these fttx and ultra-modern wisps can
> only exist in places where there is adequate carrier services to start
> with.  In areas where they spend the money and do the build but there
> aren't good carrier services, those fiber services suck and the wISPs start
> to claw back even with inferior technology.  We've pulled quite a few
> customers off fttx deployments because of this sort of situation.
> >
> >
> > On Fri, Sep 29, 2023 at 7:28 AM Rich Brown <richb.hanover@gmail.com>
> wrote:
> > Thank you Jonathan for this clear description of the issues and their
> history. I wonder if there's a fourth one - privacy.
> >
> > Rosenworcel's talk
> https://docs.fcc.gov/public/attachments/DOC-397257A1.pdf also points out
> that ISPs might want to monetize our traffic patterns and location data.
> (This is less of an issue in the EU, but the US remains a Wild West in this
> regard.)
> >
> > I am hopeful that the FCC will include this in their NPRM (which must be
> available by now but I haven't looked...)
> >
> > - Rich Brown
> >
> > > On Sep 29, 2023, at 12:54 AM, Jonathan Morton via Rpm <
> rpm@lists.bufferbloat.net> wrote:
> > >
> > >> On 29 Sep, 2023, at 1:19 am, David Lang via Bloat <
> bloat@lists.bufferbloat.net> wrote:
> > >>
> > >> Dave T called out earlier that the rise of bittorrent was a large
> part of the inital NN discussion here in the US. But a second large portion
> was a money grab from ISPs thinking that they could hold up large paid
> websites (netflix for example) for additional fees by threatening to make
> their service less useful to their users (viewing their users as an asset
> to be marketed to the websites rather than customers to be satisfied by
> providing them access to the websites)
> > >>
> > >> I don't know if a new round of "it's not fair that Netflix doesn't
> pay us for the bandwidth to service them" would fall flat at this point or
> not.
> > >
> > > I think there were three more-or-less separate concerns which have,
> over time, fallen under the same umbrella:
> > >
> > >
> > > 1:  Capacity-seeking flows tend to interfere with latency-sensitive
> flows, and the "induced demand" phenomenon means that increases in link
> rate do not in themselves solve this problem, even though they may be sold
> as doing so.
> > >
> > > This is directly addressed by properly-sized buffers and/or AQM, and
> even better by FQ and SQM.  It's a solved problem, so long as the solutions
> are deployed.  It's not usually necessary, for example, to specifically
> enhance service for latency-sensitive traffic, if FQ does a sufficiently
> good job.  An increased link rate *does* enhance service quality for both
> latency-sensitive and capacity-seeking traffic, provided FQ is in use.
> > >
> > >
> > > 2:  Swarm traffic tends to drown out conventional traffic, due to
> congestion control algorithms which try to be more-or-less fair on a
> per-flow basis, and the substantially larger number of parallel flows used
> by swarm traffic.  This also caused subscribers using swarm traffic to
> impair the service of subscribers who had nothing to do with it.
> > >
> > > FQ on a per-flow basis (see problem 1) actually amplifies this effect,
> and I think it was occasionally used as an argument for *not* deploying
> FQ.  ISPs' initial response was to outright block swarm traffic where they
> could identify it, which was then softened to merely throttling it heavily,
> before NN regulations intervened.  Usage quotas also showed up around this
> time, and were probably related to this problem.
> > >
> > > This has since been addressed by several means.  ISPs may use FQ on a
> per-subscriber basis to prevent one subscriber's heavy traffic from
> degrading service for another.  Swarm applications nowadays tend to employ
> altruistic congestion control which deliberately compensates for the large
> number of flows, and/or mark them with one or more of the Least Effort
> class DSCPs.  Hence, swarm applications are no longer as damaging to
> service quality as they used to be.  Usage quotas, however, still remain in
> use as a profit centre, to the point where an "unlimited" service is a rare
> and precious specimen in many jurisdictions.
> > >
> > >
> > > 3:  ISPs merged with media distribution companies, creating a conflict
> of interest in which the media side of the business wanted the internet
> side to actively favour "their own" media traffic at the expense of "the
> competition".  Some ISPs began to actively degrade Netflix traffic, in
> particular by refusing to provision adequate peering capacity at the nodes
> through which Netflix traffic predominated, or by zero-rating (for the
> purpose of usage quotas) traffic from their own media empire while refusing
> to do the same for Netflix traffic.
> > >
> > > **THIS** was the true core of Net Neutrality.  NN regulations forced
> ISPs to carry Netflix traffic with reasonable levels of service, even
> though they didn't want to for purely selfish and greedy commercial
> reasons.  NN succeeded in curbing an anti-competitive and consumer-hostile
> practice, which I am perfectly sure would resume just as soon as NN
> regulations were repealed.
> > >
> > > And this type of practice is just the sort of thing that technologies
> like L4S are designed to support.  The ISPs behind L4S actively do not want
> a technology that works end-to-end over the general Internet.  They want
> something that can provide a domination service within their own walled
> gardens.  That's why L4S is a NN hazard, and why they actively resisted all
> attempts to displace it with SCE.
> > >
> > >
> > > All of the above were made more difficult to solve by the monopolistic
> nature of the Internet service industry.  It is actively difficult for
> Internet users to move to a truly different service, especially one based
> on a different link technology.  When attempts are made to increase
> competition, for example by deploying a publicly-funded network, the
> incumbents actively sabotage those attempts by any means they can.
> Monopolies are inherently customer-hostile, and arguments based on market
> forces fail in their presence.
> > >
> > > - Jonathan Morton
> > >
> > > _______________________________________________
> > > Rpm mailing list
> > > Rpm@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/rpm
> >
> > _______________________________________________
> > Rpm mailing list
> > Rpm@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm
> > _______________________________________________
> > Rpm mailing list
> > Rpm@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice

[-- Attachment #1.2: Type: text/html, Size: 19686 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3995 bytes --]

Re: [Starlink] [Rpm] [Bloat] [LibreQoS] net neutrality back in the news

[Sebastian Moeller]

Hi Frantisek,

> On Sep 30, 2023, at 14:00, Frantisek Borsik via Rpm <rpm@lists.bufferbloat.net> wrote:
> 
> Back then in 2015, when NN was enacted by Wheeler & CO, there was a great body of work (IMHO) done on this subject by Martin Geddes:
> https://www.martingeddes.com/1261-2/
> 
> But let's pick one report written by his colleagues and published by Ofcom (UK telecoms regulator):
> 
> 	• You cannot conflate ‘equality of [packet] treatment’ with delivering equality of [user application] outcomes. Only the latter matters, as ordinary users don’t care what happened to the packets in transit. Yet the relevant academic literature fixates on the local operation of the mechanisms (including Traffic Management), not their global aggregate effect.

	[SM] The EU laid out pretty clear why they mandated the NN regulations in eu regulation 2015/2120:

[...]
(8)
When providing internet access services, providers of those services should treat all traffic equally, without discrimination, restriction or interference, independently of its sender or receiver, content, application or service, or terminal equipment. According to general principles of Union law and settled case-law, comparable situations should not be treated differently and different situations should not be treated in the same way unless such treatment is objectively justified.
(9)
The objective of reasonable traffic management is to contribute to an efficient use of network resources and to an optimisation of overall transmission quality responding to the objectively different technical quality of service requirements of specific categories of traffic, and thus of the content, applications and services transmitted. Reasonable traffic management measures applied by providers of internet access services should be transparent, non-discriminatory and proportionate, and should not be based on commercial considerations. The requirement for traffic management measures to be non-discriminatory does not preclude providers of internet access services from implementing, in order to optimise the overall transmission quality, traffic management measures which differentiate between objectively different categories of traffic. Any such differentiation should, in order to optimise overall quality and user experience, be permitted only on the basis of objectively different technical quality of service requirements (for example, in terms of latency, jitter, packet loss, and bandwidth) of the specific categories of traffic, and not on the basis of commercial considerations. Such differentiating measures should be proportionate in relation to the purpose of overall quality optimisation and should treat equivalent traffic equally. Such measures should not be maintained for longer than necessary.
(10)
Reasonable traffic management does not require techniques which monitor the specific content of data traffic transmitted via the internet access service.
(11)
Any traffic management practices which go beyond such reasonable traffic management measures, by blocking, slowing down, altering, restricting, interfering with, degrading or discriminating between specific content, applications or services, or specific categories of content, applications or services, should be prohibited, subject to the justified and defined exceptions laid down in this Regulation. Those exceptions should be subject to strict interpretation and to proportionality requirements. Specific content, applications and services, as well as specific categories thereof, should be protected because of the negative impact on end-user choice and innovation of blocking, or of other restrictive measures not falling within the justified exceptions. Rules against altering content, applications or services refer to a modification of the content of the communication, but do not ban non-discriminatory data compression techniques which reduce the size of a data file without any modification of the content. Such compression enables a more efficient use of scarce resources and serves the end-users’ interests by reducing data volumes, increasing speed and enhancing the experience of using the content, applications or services concerned.
(12)
Traffic management measures that go beyond such reasonable traffic management measures may only be applied as necessary and for as long as necessary to comply with the three justified exceptions laid down in this Regulation.
[...]

There really is little IMHO that can be brought against these, all pretty fair and reasonable. What it does is accept that internet access is essential infrastructure and that hence access needs to be as well regulated as access to water, electricity, gas, streets, ... . Yes this has some consequences of what ISPs can and can not do. But this is normal "cost of business". I for one am quite happy about this regulation existing as locally it did away with some (not all) shenanigans of some ISPs that were clearly not operating in the interest of their paying eye-balls.

There is a whole cottage industry of consultants that decry the EU's decision and try to lobby against it, but honestly reading these mostly makes me think harsher regulation might be required (on consultans about how much they are allowed to massage the facts ;) ). 

Regards
	Sebastian

P.S.: Of course if we look close enough we surely can find corner-cases where either the EU regulations or the translation into national law result in less desirable outcomes, but "nothing is perfect" and all in all the regulations seem to be "good enough". With the caveat that explicitly excluding ISP interconnect from the regulations BEREC essentially pointed the way for ISPs wanting to monetize their eye-balls twice to do so via interconnects, but that only works for the 800 pound gorillas and generally is not a game smaller ISPs can play. I do understand why BEREC wants to stay out of the interconnection issue, as this is rather complicated and the market seems to generally work okay-ish (that is not badly enough to make intervention a hot-button issue for voters and hence politicians).



> 
> 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 Fri, Sep 29, 2023 at 6:15 PM dan via Rpm <rpm@lists.bufferbloat.net> wrote:
> ok, lots and lots of great comments here for sure.  
> 
> bandwidth abundance:  Not for most people and ISPs.  The 'carriers' aren't carrying to many places at affordable rates.  I've pulled quotes from Lumen and Zayo at over $5k/month/gig.  We typically pay 900-1400 for a gig of service.  This isn't abundance and it's widespread and it leaves only major providers that can afford/amortize out 100G transits etc.
> My answer to this is one that Dave and I have bounced back and forth is the idea of micro IXs in every municipality and having that somehow tied into access to the ROW in counties etc.  Not fully hashed out, but the fiber is in the ground, it could be sold, but the carriers are not well incentivised to sell it.  It takes the better part of a year to get a DIA within 100ft of a Lumen hut sometimes...  Heck, it could even be a government program to get an μIX with x feet of every school, city hall, and library.  I don't care how it's done but this would get abundance NEAR end users and open up essentially every town to competition.
> 
> monopoly.  This is a historical thing for most cable and DSL incumbents.  They have enjoyed virtual monopolies with cable owning population centers and DSL owning the outskirts and there is no product darwinism here where customer satisfaction is a pressure.  That may not be the future but it definitely is the past.  These companies may have to shift into customer satisfaction as a major part instead of a minor part of their corporate culture to fend off fttx and ultra-modern wisps.
> 
> Starlink is not offering significant competition to major carriers.    Starlink's 1.5 million customers are at LEAST 90% pulled from other satellite services and small ISPs.  Spectrum and Comcast's losses to starlink are measured in decimal points.
> 
> Only fttx and ultra-modern wireless tech really threatens these incumbents.  Typical wisps aren't putting a dent in these guys, just scraping the paint off their bumper.  We're pulling customers at the scale of 'dozens' for example.  Spectrum's management doesn't know we exist we're such a small threat to them.   
> 
> But to further the point here, these fttx and ultra-modern wisps can only exist in places where there is adequate carrier services to start with.  In areas where they spend the money and do the build but there aren't good carrier services, those fiber services suck and the wISPs start to claw back even with inferior technology.  We've pulled quite a few customers off fttx deployments because of this sort of situation.
> 
> 
> On Fri, Sep 29, 2023 at 7:28 AM Rich Brown <richb.hanover@gmail.com> wrote:
> Thank you Jonathan for this clear description of the issues and their history. I wonder if there's a fourth one - privacy. 
> 
> Rosenworcel's talk https://docs.fcc.gov/public/attachments/DOC-397257A1.pdf also points out that ISPs might want to monetize our traffic patterns and location data. (This is less of an issue in the EU, but the US remains a Wild West in this regard.) 
> 
> I am hopeful that the FCC will include this in their NPRM (which must be available by now but I haven't looked...)
> 
> - Rich Brown
> 
> > On Sep 29, 2023, at 12:54 AM, Jonathan Morton via Rpm <rpm@lists.bufferbloat.net> wrote:
> > 
> >> On 29 Sep, 2023, at 1:19 am, David Lang via Bloat <bloat@lists.bufferbloat.net> wrote:
> >> 
> >> Dave T called out earlier that the rise of bittorrent was a large part of the inital NN discussion here in the US. But a second large portion was a money grab from ISPs thinking that they could hold up large paid websites (netflix for example) for additional fees by threatening to make their service less useful to their users (viewing their users as an asset to be marketed to the websites rather than customers to be satisfied by providing them access to the websites)
> >> 
> >> I don't know if a new round of "it's not fair that Netflix doesn't pay us for the bandwidth to service them" would fall flat at this point or not.
> > 
> > I think there were three more-or-less separate concerns which have, over time, fallen under the same umbrella:
> > 
> > 
> > 1:  Capacity-seeking flows tend to interfere with latency-sensitive flows, and the "induced demand" phenomenon means that increases in link rate do not in themselves solve this problem, even though they may be sold as doing so.
> > 
> > This is directly addressed by properly-sized buffers and/or AQM, and even better by FQ and SQM.  It's a solved problem, so long as the solutions are deployed.  It's not usually necessary, for example, to specifically enhance service for latency-sensitive traffic, if FQ does a sufficiently good job.  An increased link rate *does* enhance service quality for both latency-sensitive and capacity-seeking traffic, provided FQ is in use.
> > 
> > 
> > 2:  Swarm traffic tends to drown out conventional traffic, due to congestion control algorithms which try to be more-or-less fair on a per-flow basis, and the substantially larger number of parallel flows used by swarm traffic.  This also caused subscribers using swarm traffic to impair the service of subscribers who had nothing to do with it.
> > 
> > FQ on a per-flow basis (see problem 1) actually amplifies this effect, and I think it was occasionally used as an argument for *not* deploying FQ.  ISPs' initial response was to outright block swarm traffic where they could identify it, which was then softened to merely throttling it heavily, before NN regulations intervened.  Usage quotas also showed up around this time, and were probably related to this problem.
> > 
> > This has since been addressed by several means.  ISPs may use FQ on a per-subscriber basis to prevent one subscriber's heavy traffic from degrading service for another.  Swarm applications nowadays tend to employ altruistic congestion control which deliberately compensates for the large number of flows, and/or mark them with one or more of the Least Effort class DSCPs.  Hence, swarm applications are no longer as damaging to service quality as they used to be.  Usage quotas, however, still remain in use as a profit centre, to the point where an "unlimited" service is a rare and precious specimen in many jurisdictions.
> > 
> > 
> > 3:  ISPs merged with media distribution companies, creating a conflict of interest in which the media side of the business wanted the internet side to actively favour "their own" media traffic at the expense of "the competition".  Some ISPs began to actively degrade Netflix traffic, in particular by refusing to provision adequate peering capacity at the nodes through which Netflix traffic predominated, or by zero-rating (for the purpose of usage quotas) traffic from their own media empire while refusing to do the same for Netflix traffic.
> > 
> > **THIS** was the true core of Net Neutrality.  NN regulations forced ISPs to carry Netflix traffic with reasonable levels of service, even though they didn't want to for purely selfish and greedy commercial reasons.  NN succeeded in curbing an anti-competitive and consumer-hostile practice, which I am perfectly sure would resume just as soon as NN regulations were repealed.
> > 
> > And this type of practice is just the sort of thing that technologies like L4S are designed to support.  The ISPs behind L4S actively do not want a technology that works end-to-end over the general Internet.  They want something that can provide a domination service within their own walled gardens.  That's why L4S is a NN hazard, and why they actively resisted all attempts to displace it with SCE.
> > 
> > 
> > All of the above were made more difficult to solve by the monopolistic nature of the Internet service industry.  It is actively difficult for Internet users to move to a truly different service, especially one based on a different link technology.  When attempts are made to increase competition, for example by deploying a publicly-funded network, the incumbents actively sabotage those attempts by any means they can.  Monopolies are inherently customer-hostile, and arguments based on market forces fail in their presence.
> > 
> > - Jonathan Morton
> > 
> > _______________________________________________
> > Rpm mailing list
> > Rpm@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm
> 
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm

Re: [Starlink] [Rpm] [Bloat] [LibreQoS] net neutrality back in the news

[Frantisek Borsik]

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

Back then in 2015, when NN was enacted by Wheeler & CO, there was a great
body of work (IMHO) done on this subject by Martin Geddes:
https://www.martingeddes.com/1261-2/

But let's pick *one
<https://www.martingeddes.com/ofcom-publishes-pnsol-scientific-report-on-net-neutrality/>
*report written
by his colleagues and published by Ofcom (UK telecoms regulator):


   - *You cannot conflate ‘equality of [packet] treatment’ with delivering
   equality of [user application] outcomes.* Only the latter matters, as
   ordinary users don’t care what happened to the packets in transit. Yet the
   relevant academic literature fixates on the local operation of the
   mechanisms (including Traffic Management), not their global aggregate
   effect.


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 Fri, Sep 29, 2023 at 6:15 PM dan via Rpm <rpm@lists.bufferbloat.net>
wrote:

> ok, lots and lots of great comments here for sure.
>
> bandwidth abundance:  Not for most people and ISPs.  The 'carriers' aren't
> carrying to many places at affordable rates.  I've pulled quotes from Lumen
> and Zayo at over $5k/month/gig.  We typically pay 900-1400 for a gig of
> service.  This isn't abundance and it's widespread and it leaves only
> major providers that can afford/amortize out 100G transits etc.
> My answer to this is one that Dave and I have bounced back and forth is
> the idea of micro IXs in every municipality and having that somehow tied
> into access to the ROW in counties etc.  Not fully hashed out, but the
> fiber is in the ground, it could be sold, but the carriers are not well
> incentivised to sell it.  It takes the better part of a year to get a DIA
> within 100ft of a Lumen hut sometimes...  Heck, it could even be a
> government program to get an μ*IX* with x feet of every school, city
> hall, and library.  I don't care how it's done but this would get abundance
> NEAR end users and open up essentially every town to competition.
>
> monopoly.  This is a historical thing for most cable and DSL incumbents.
> They have enjoyed virtual monopolies with cable owning population centers
> and DSL owning the outskirts and there is no product darwinism here where
> customer satisfaction is a pressure.  That may not be the future but it
> definitely is the past.  These companies may have to shift into customer
> satisfaction as a major part instead of a minor part of their corporate
> culture to fend off fttx and ultra-modern wisps.
>
> Starlink is not offering significant competition to major carriers.
> Starlink's 1.5 million customers are at LEAST 90% pulled from other
> satellite services and small ISPs.  Spectrum and Comcast's losses to
> starlink are measured in decimal points.
>
> Only fttx and ultra-modern wireless tech really threatens these
> incumbents.  Typical wisps aren't putting a dent in these guys, just
> scraping the paint off their bumper.  We're pulling customers at the scale
> of 'dozens' for example.  Spectrum's management doesn't know we exist we're
> such a small threat to them.
>
> But to further the point here, these fttx and ultra-modern wisps can only
> exist in places where there is adequate carrier services to start with.  In
> areas where they spend the money and do the build but there aren't good
> carrier services, those fiber services suck and the wISPs start to claw
> back even with inferior technology.  We've pulled quite a few customers off
> fttx deployments because of this sort of situation.
>
>
> On Fri, Sep 29, 2023 at 7:28 AM Rich Brown <richb.hanover@gmail.com>
> wrote:
>
>> Thank you Jonathan for this clear description of the issues and their
>> history. I wonder if there's a fourth one - privacy.
>>
>> Rosenworcel's talk
>> https://docs.fcc.gov/public/attachments/DOC-397257A1.pdf also points out
>> that ISPs might want to monetize our traffic patterns and location data.
>> (This is less of an issue in the EU, but the US remains a Wild West in this
>> regard.)
>>
>> I am hopeful that the FCC will include this in their NPRM (which must be
>> available by now but I haven't looked...)
>>
>> - Rich Brown
>>
>> > On Sep 29, 2023, at 12:54 AM, Jonathan Morton via Rpm <
>> rpm@lists.bufferbloat.net> wrote:
>> >
>> >> On 29 Sep, 2023, at 1:19 am, David Lang via Bloat <
>> bloat@lists.bufferbloat.net> wrote:
>> >>
>> >> Dave T called out earlier that the rise of bittorrent was a large part
>> of the inital NN discussion here in the US. But a second large portion was
>> a money grab from ISPs thinking that they could hold up large paid websites
>> (netflix for example) for additional fees by threatening to make their
>> service less useful to their users (viewing their users as an asset to be
>> marketed to the websites rather than customers to be satisfied by providing
>> them access to the websites)
>> >>
>> >> I don't know if a new round of "it's not fair that Netflix doesn't pay
>> us for the bandwidth to service them" would fall flat at this point or not.
>> >
>> > I think there were three more-or-less separate concerns which have,
>> over time, fallen under the same umbrella:
>> >
>> >
>> > 1:  Capacity-seeking flows tend to interfere with latency-sensitive
>> flows, and the "induced demand" phenomenon means that increases in link
>> rate do not in themselves solve this problem, even though they may be sold
>> as doing so.
>> >
>> > This is directly addressed by properly-sized buffers and/or AQM, and
>> even better by FQ and SQM.  It's a solved problem, so long as the solutions
>> are deployed.  It's not usually necessary, for example, to specifically
>> enhance service for latency-sensitive traffic, if FQ does a sufficiently
>> good job.  An increased link rate *does* enhance service quality for both
>> latency-sensitive and capacity-seeking traffic, provided FQ is in use.
>> >
>> >
>> > 2:  Swarm traffic tends to drown out conventional traffic, due to
>> congestion control algorithms which try to be more-or-less fair on a
>> per-flow basis, and the substantially larger number of parallel flows used
>> by swarm traffic.  This also caused subscribers using swarm traffic to
>> impair the service of subscribers who had nothing to do with it.
>> >
>> > FQ on a per-flow basis (see problem 1) actually amplifies this effect,
>> and I think it was occasionally used as an argument for *not* deploying
>> FQ.  ISPs' initial response was to outright block swarm traffic where they
>> could identify it, which was then softened to merely throttling it heavily,
>> before NN regulations intervened.  Usage quotas also showed up around this
>> time, and were probably related to this problem.
>> >
>> > This has since been addressed by several means.  ISPs may use FQ on a
>> per-subscriber basis to prevent one subscriber's heavy traffic from
>> degrading service for another.  Swarm applications nowadays tend to employ
>> altruistic congestion control which deliberately compensates for the large
>> number of flows, and/or mark them with one or more of the Least Effort
>> class DSCPs.  Hence, swarm applications are no longer as damaging to
>> service quality as they used to be.  Usage quotas, however, still remain in
>> use as a profit centre, to the point where an "unlimited" service is a rare
>> and precious specimen in many jurisdictions.
>> >
>> >
>> > 3:  ISPs merged with media distribution companies, creating a conflict
>> of interest in which the media side of the business wanted the internet
>> side to actively favour "their own" media traffic at the expense of "the
>> competition".  Some ISPs began to actively degrade Netflix traffic, in
>> particular by refusing to provision adequate peering capacity at the nodes
>> through which Netflix traffic predominated, or by zero-rating (for the
>> purpose of usage quotas) traffic from their own media empire while refusing
>> to do the same for Netflix traffic.
>> >
>> > **THIS** was the true core of Net Neutrality.  NN regulations forced
>> ISPs to carry Netflix traffic with reasonable levels of service, even
>> though they didn't want to for purely selfish and greedy commercial
>> reasons.  NN succeeded in curbing an anti-competitive and consumer-hostile
>> practice, which I am perfectly sure would resume just as soon as NN
>> regulations were repealed.
>> >
>> > And this type of practice is just the sort of thing that technologies
>> like L4S are designed to support.  The ISPs behind L4S actively do not want
>> a technology that works end-to-end over the general Internet.  They want
>> something that can provide a domination service within their own walled
>> gardens.  That's why L4S is a NN hazard, and why they actively resisted all
>> attempts to displace it with SCE.
>> >
>> >
>> > All of the above were made more difficult to solve by the monopolistic
>> nature of the Internet service industry.  It is actively difficult for
>> Internet users to move to a truly different service, especially one based
>> on a different link technology.  When attempts are made to increase
>> competition, for example by deploying a publicly-funded network, the
>> incumbents actively sabotage those attempts by any means they can.
>> Monopolies are inherently customer-hostile, and arguments based on market
>> forces fail in their presence.
>> >
>> > - Jonathan Morton
>> >
>> > _______________________________________________
>> > Rpm mailing list
>> > Rpm@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/rpm
>>
>> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm
>

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

Re: [Starlink] [Rpm] [Bloat] [LibreQoS] net neutrality back in the news

[David Fernández]

Mobile phone operators are monetizing metadata, as the issue with the
Apple Private Relay generating their complaints made evident.

The 5G has a network function for that: NWDAF


> Date: Fri, 29 Sep 2023 08:28:00 -0400
> From: Rich Brown <richb.hanover@gmail.com>
> To: Jonathan Morton <chromatix99@gmail.com>
> Cc: David Lang <david@lang.hm>, Rpm <rpm@lists.bufferbloat.net>, dan
> 	<dandenson@gmail.com>, Jamal Hadi Salim <jhs@mojatatu.com>, libreqos
> 	<libreqos@lists.bufferbloat.net>, Dave Taht via Starlink
> 	<starlink@lists.bufferbloat.net>, "Livingood, Jason"
> 	<Jason_Livingood@comcast.com>, bloat <bloat@lists.bufferbloat.net>
> Subject: Re: [Starlink] [Rpm] [Bloat] [LibreQoS] net neutrality back
> 	in the news
> Message-ID: <039490DA-48A7-4AE2-B00F-AA2A260FB747@gmail.com>
> Content-Type: text/plain;	charset=us-ascii
>
> Thank you Jonathan for this clear description of the issues and their
> history. I wonder if there's a fourth one - privacy.
>
> Rosenworcel's talk https://docs.fcc.gov/public/attachments/DOC-397257A1.pdf
> also points out that ISPs might want to monetize our traffic patterns and
> location data. (This is less of an issue in the EU, but the US remains a
> Wild West in this regard.)
>
> I am hopeful that the FCC will include this in their NPRM (which must be
> available by now but I haven't looked...)
>
> - Rich Brown

Re: [Starlink] [Rpm] [Bloat] [LibreQoS] net neutrality back in the news

[dan]

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

ok, lots and lots of great comments here for sure.

bandwidth abundance:  Not for most people and ISPs.  The 'carriers' aren't
carrying to many places at affordable rates.  I've pulled quotes from Lumen
and Zayo at over $5k/month/gig.  We typically pay 900-1400 for a gig of
service.  This isn't abundance and it's widespread and it leaves only
major providers that can afford/amortize out 100G transits etc.
My answer to this is one that Dave and I have bounced back and forth is the
idea of micro IXs in every municipality and having that somehow tied into
access to the ROW in counties etc.  Not fully hashed out, but the fiber is
in the ground, it could be sold, but the carriers are not well incentivised
to sell it.  It takes the better part of a year to get a DIA within 100ft
of a Lumen hut sometimes...  Heck, it could even be a government program to
get an μ*IX* with x feet of every school, city hall, and library.  I don't
care how it's done but this would get abundance NEAR end users and open up
essentially every town to competition.

monopoly.  This is a historical thing for most cable and DSL incumbents.
They have enjoyed virtual monopolies with cable owning population centers
and DSL owning the outskirts and there is no product darwinism here where
customer satisfaction is a pressure.  That may not be the future but it
definitely is the past.  These companies may have to shift into customer
satisfaction as a major part instead of a minor part of their corporate
culture to fend off fttx and ultra-modern wisps.

Starlink is not offering significant competition to major carriers.
Starlink's 1.5 million customers are at LEAST 90% pulled from other
satellite services and small ISPs.  Spectrum and Comcast's losses to
starlink are measured in decimal points.

Only fttx and ultra-modern wireless tech really threatens these
incumbents.  Typical wisps aren't putting a dent in these guys, just
scraping the paint off their bumper.  We're pulling customers at the scale
of 'dozens' for example.  Spectrum's management doesn't know we exist we're
such a small threat to them.

But to further the point here, these fttx and ultra-modern wisps can only
exist in places where there is adequate carrier services to start with.  In
areas where they spend the money and do the build but there aren't good
carrier services, those fiber services suck and the wISPs start to claw
back even with inferior technology.  We've pulled quite a few customers off
fttx deployments because of this sort of situation.


On Fri, Sep 29, 2023 at 7:28 AM Rich Brown <richb.hanover@gmail.com> wrote:

> Thank you Jonathan for this clear description of the issues and their
> history. I wonder if there's a fourth one - privacy.
>
> Rosenworcel's talk
> https://docs.fcc.gov/public/attachments/DOC-397257A1.pdf also points out
> that ISPs might want to monetize our traffic patterns and location data.
> (This is less of an issue in the EU, but the US remains a Wild West in this
> regard.)
>
> I am hopeful that the FCC will include this in their NPRM (which must be
> available by now but I haven't looked...)
>
> - Rich Brown
>
> > On Sep 29, 2023, at 12:54 AM, Jonathan Morton via Rpm <
> rpm@lists.bufferbloat.net> wrote:
> >
> >> On 29 Sep, 2023, at 1:19 am, David Lang via Bloat <
> bloat@lists.bufferbloat.net> wrote:
> >>
> >> Dave T called out earlier that the rise of bittorrent was a large part
> of the inital NN discussion here in the US. But a second large portion was
> a money grab from ISPs thinking that they could hold up large paid websites
> (netflix for example) for additional fees by threatening to make their
> service less useful to their users (viewing their users as an asset to be
> marketed to the websites rather than customers to be satisfied by providing
> them access to the websites)
> >>
> >> I don't know if a new round of "it's not fair that Netflix doesn't pay
> us for the bandwidth to service them" would fall flat at this point or not.
> >
> > I think there were three more-or-less separate concerns which have, over
> time, fallen under the same umbrella:
> >
> >
> > 1:  Capacity-seeking flows tend to interfere with latency-sensitive
> flows, and the "induced demand" phenomenon means that increases in link
> rate do not in themselves solve this problem, even though they may be sold
> as doing so.
> >
> > This is directly addressed by properly-sized buffers and/or AQM, and
> even better by FQ and SQM.  It's a solved problem, so long as the solutions
> are deployed.  It's not usually necessary, for example, to specifically
> enhance service for latency-sensitive traffic, if FQ does a sufficiently
> good job.  An increased link rate *does* enhance service quality for both
> latency-sensitive and capacity-seeking traffic, provided FQ is in use.
> >
> >
> > 2:  Swarm traffic tends to drown out conventional traffic, due to
> congestion control algorithms which try to be more-or-less fair on a
> per-flow basis, and the substantially larger number of parallel flows used
> by swarm traffic.  This also caused subscribers using swarm traffic to
> impair the service of subscribers who had nothing to do with it.
> >
> > FQ on a per-flow basis (see problem 1) actually amplifies this effect,
> and I think it was occasionally used as an argument for *not* deploying
> FQ.  ISPs' initial response was to outright block swarm traffic where they
> could identify it, which was then softened to merely throttling it heavily,
> before NN regulations intervened.  Usage quotas also showed up around this
> time, and were probably related to this problem.
> >
> > This has since been addressed by several means.  ISPs may use FQ on a
> per-subscriber basis to prevent one subscriber's heavy traffic from
> degrading service for another.  Swarm applications nowadays tend to employ
> altruistic congestion control which deliberately compensates for the large
> number of flows, and/or mark them with one or more of the Least Effort
> class DSCPs.  Hence, swarm applications are no longer as damaging to
> service quality as they used to be.  Usage quotas, however, still remain in
> use as a profit centre, to the point where an "unlimited" service is a rare
> and precious specimen in many jurisdictions.
> >
> >
> > 3:  ISPs merged with media distribution companies, creating a conflict
> of interest in which the media side of the business wanted the internet
> side to actively favour "their own" media traffic at the expense of "the
> competition".  Some ISPs began to actively degrade Netflix traffic, in
> particular by refusing to provision adequate peering capacity at the nodes
> through which Netflix traffic predominated, or by zero-rating (for the
> purpose of usage quotas) traffic from their own media empire while refusing
> to do the same for Netflix traffic.
> >
> > **THIS** was the true core of Net Neutrality.  NN regulations forced
> ISPs to carry Netflix traffic with reasonable levels of service, even
> though they didn't want to for purely selfish and greedy commercial
> reasons.  NN succeeded in curbing an anti-competitive and consumer-hostile
> practice, which I am perfectly sure would resume just as soon as NN
> regulations were repealed.
> >
> > And this type of practice is just the sort of thing that technologies
> like L4S are designed to support.  The ISPs behind L4S actively do not want
> a technology that works end-to-end over the general Internet.  They want
> something that can provide a domination service within their own walled
> gardens.  That's why L4S is a NN hazard, and why they actively resisted all
> attempts to displace it with SCE.
> >
> >
> > All of the above were made more difficult to solve by the monopolistic
> nature of the Internet service industry.  It is actively difficult for
> Internet users to move to a truly different service, especially one based
> on a different link technology.  When attempts are made to increase
> competition, for example by deploying a publicly-funded network, the
> incumbents actively sabotage those attempts by any means they can.
> Monopolies are inherently customer-hostile, and arguments based on market
> forces fail in their presence.
> >
> > - Jonathan Morton
> >
> > _______________________________________________
> > Rpm mailing list
> > Rpm@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm
>
>

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

Re: [Starlink] [Rpm] [Bloat] [LibreQoS] net neutrality back in the news

[Rich Brown]

Thank you Jonathan for this clear description of the issues and their history. I wonder if there's a fourth one - privacy. 

Rosenworcel's talk https://docs.fcc.gov/public/attachments/DOC-397257A1.pdf also points out that ISPs might want to monetize our traffic patterns and location data. (This is less of an issue in the EU, but the US remains a Wild West in this regard.) 

I am hopeful that the FCC will include this in their NPRM (which must be available by now but I haven't looked...)

- Rich Brown

> On Sep 29, 2023, at 12:54 AM, Jonathan Morton via Rpm <rpm@lists.bufferbloat.net> wrote:
> 
>> On 29 Sep, 2023, at 1:19 am, David Lang via Bloat <bloat@lists.bufferbloat.net> wrote:
>> 
>> Dave T called out earlier that the rise of bittorrent was a large part of the inital NN discussion here in the US. But a second large portion was a money grab from ISPs thinking that they could hold up large paid websites (netflix for example) for additional fees by threatening to make their service less useful to their users (viewing their users as an asset to be marketed to the websites rather than customers to be satisfied by providing them access to the websites)
>> 
>> I don't know if a new round of "it's not fair that Netflix doesn't pay us for the bandwidth to service them" would fall flat at this point or not.
> 
> I think there were three more-or-less separate concerns which have, over time, fallen under the same umbrella:
> 
> 
> 1:  Capacity-seeking flows tend to interfere with latency-sensitive flows, and the "induced demand" phenomenon means that increases in link rate do not in themselves solve this problem, even though they may be sold as doing so.
> 
> This is directly addressed by properly-sized buffers and/or AQM, and even better by FQ and SQM.  It's a solved problem, so long as the solutions are deployed.  It's not usually necessary, for example, to specifically enhance service for latency-sensitive traffic, if FQ does a sufficiently good job.  An increased link rate *does* enhance service quality for both latency-sensitive and capacity-seeking traffic, provided FQ is in use.
> 
> 
> 2:  Swarm traffic tends to drown out conventional traffic, due to congestion control algorithms which try to be more-or-less fair on a per-flow basis, and the substantially larger number of parallel flows used by swarm traffic.  This also caused subscribers using swarm traffic to impair the service of subscribers who had nothing to do with it.
> 
> FQ on a per-flow basis (see problem 1) actually amplifies this effect, and I think it was occasionally used as an argument for *not* deploying FQ.  ISPs' initial response was to outright block swarm traffic where they could identify it, which was then softened to merely throttling it heavily, before NN regulations intervened.  Usage quotas also showed up around this time, and were probably related to this problem.
> 
> This has since been addressed by several means.  ISPs may use FQ on a per-subscriber basis to prevent one subscriber's heavy traffic from degrading service for another.  Swarm applications nowadays tend to employ altruistic congestion control which deliberately compensates for the large number of flows, and/or mark them with one or more of the Least Effort class DSCPs.  Hence, swarm applications are no longer as damaging to service quality as they used to be.  Usage quotas, however, still remain in use as a profit centre, to the point where an "unlimited" service is a rare and precious specimen in many jurisdictions.
> 
> 
> 3:  ISPs merged with media distribution companies, creating a conflict of interest in which the media side of the business wanted the internet side to actively favour "their own" media traffic at the expense of "the competition".  Some ISPs began to actively degrade Netflix traffic, in particular by refusing to provision adequate peering capacity at the nodes through which Netflix traffic predominated, or by zero-rating (for the purpose of usage quotas) traffic from their own media empire while refusing to do the same for Netflix traffic.
> 
> **THIS** was the true core of Net Neutrality.  NN regulations forced ISPs to carry Netflix traffic with reasonable levels of service, even though they didn't want to for purely selfish and greedy commercial reasons.  NN succeeded in curbing an anti-competitive and consumer-hostile practice, which I am perfectly sure would resume just as soon as NN regulations were repealed.
> 
> And this type of practice is just the sort of thing that technologies like L4S are designed to support.  The ISPs behind L4S actively do not want a technology that works end-to-end over the general Internet.  They want something that can provide a domination service within their own walled gardens.  That's why L4S is a NN hazard, and why they actively resisted all attempts to displace it with SCE.
> 
> 
> All of the above were made more difficult to solve by the monopolistic nature of the Internet service industry.  It is actively difficult for Internet users to move to a truly different service, especially one based on a different link technology.  When attempts are made to increase competition, for example by deploying a publicly-funded network, the incumbents actively sabotage those attempts by any means they can.  Monopolies are inherently customer-hostile, and arguments based on market forces fail in their presence.
> 
> - Jonathan Morton
> 
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm

Re: [Starlink] [Rpm] [Bloat] [LibreQoS] net neutrality back in the news

[Sebastian Moeller]

Hi Gert,


> On Sep 29, 2023, at 08:31, Gert Doering <gert@space.net> wrote:
> 
> Hi,
> 
> On Fri, Sep 29, 2023 at 08:24:13AM +0200, Sebastian Moeller via Starlink wrote:
>> 	[SM] In the EU we have this as a continuous lobbying effort by big incumbent ISPs (a move to have the large content providers (CAPs) shoulder their "fair" share of the cost of modernizing the networks*), why this flys with at least some EU politicians is that the intended payees of this scheme are all located outside the EU and hence will have little support by the EU citizenry... (The latter is IMHO not fully undeserved either, the days of "do no evil" are long behind us and big tech often forgets that we are all in this together, but I digress). In the EU one of these days such an effort might actually succeed, as much as I dislike this.
> 
> And then the local incumbent uses that line of argument to arm-twist
> all the smaller ISPs to pay them for traffic into their network...
> (and calling up fees well above normal market rates for "transit").

	Indeed, but that only flies because the regulators so far only feel responsible for the end-customer to internet access provider links, and explicitly exempt AS interconnect from their regulatory efforts. Given how complicated this can become I have some sympathy for their position, the national incumbent however plays a somewhat dangerous game, if he makes things too obvious it will likely result in regulatory interventions. This is also why the product sold is not "access to our eye-balls" but access "to the whole internet, including our eye-balls" yet at a cost that nobody is likely to use to access anything but that ISPs eye-balls. As much as it pains me that is behavior not untypical for large corporations these days...

Regards
	Sebastian


> 
> Gert Doering
>        -- NetMaster
> -- 
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

Re: [Starlink] [Rpm] [Bloat] [LibreQoS] net neutrality back in the news

[Gert Doering]

Hi,

On Fri, Sep 29, 2023 at 08:24:13AM +0200, Sebastian Moeller via Starlink wrote:
> 	[SM] In the EU we have this as a continuous lobbying effort by big incumbent ISPs (a move to have the large content providers (CAPs) shoulder their "fair" share of the cost of modernizing the networks*), why this flys with at least some EU politicians is that the intended payees of this scheme are all located outside the EU and hence will have little support by the EU citizenry... (The latter is IMHO not fully undeserved either, the days of "do no evil" are long behind us and big tech often forgets that we are all in this together, but I digress). In the EU one of these days such an effort might actually succeed, as much as I dislike this.

And then the local incumbent uses that line of argument to arm-twist
all the smaller ISPs to pay them for traffic into their network...
(and calling up fees well above normal market rates for "transit").

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

Re: [Starlink] [Rpm] [Bloat] [LibreQoS] net neutrality back in the news

[Sebastian Moeller]

Hi David,


> On Sep 29, 2023, at 00:19, David Lang via Rpm <rpm@lists.bufferbloat.net> wrote:
> 
> On Thu, 28 Sep 2023, Livingood, Jason via Bloat wrote:
> 
>> Date: Thu, 28 Sep 2023 20:48:58 +0000
>> From: "Livingood, Jason via Bloat" <bloat@lists.bufferbloat.net>
>> Reply-To: "Livingood, Jason" <Jason_Livingood@comcast.com>
>> To: dan <dandenson@gmail.com>, Dave Taht <dave.taht@gmail.com>
>> Cc: Rpm <rpm@lists.bufferbloat.net>,
>>    Dave Taht via Starlink <starlink@lists.bufferbloat.net>,
>>    bloat <bloat@lists.bufferbloat.net>,
>>    libreqos <libreqos@lists.bufferbloat.net>,
>>    Jamal Hadi Salim <jhs@mojatatu.com>
>> Subject: Re: [Bloat] [Starlink] [LibreQoS] [Rpm] net neutrality back in the
>>    news
>>> dan <dandenson@gmail.com> wrote:
>> 
>>> "(I assume most ISPs want happy customers)."
> 
>>> made me laugh a little.  'Most' by quantity of businesses maybe, but 'most' in terms of customers being served by puts the Spectrums and Comcasts in the mix (in the US) and they don't care about happy customers they care about defacto monopolies in markets so that they don't have to care about happy customers. 
>> 
>> In that context, happy customers stay longer (less churn) and spend more (upgrades, multiple services). And unhappy customers generate costs via disconnects (loss of revenue, costs to replace them with a new customer to just stay at the same subscriber levels), and costs via customer contacts (call center staff).
> 
> Except when you have a monopoly in an area, at which point the ability of customers to leave is minimal, and years of bad customer service means that people don't bother complaining, so the call center staffing costs are lower than they should be.
> 
>>> For the last mile, I'm actually less concerned with pure NN and more concerned with no-blocking or 'brand' prioritization and required/label transparency...
>> 
>> The two thoughts your comments (thanks for the response BTW!) trigger are:
> 
>> 1 - Often regulation looks to the past - in this case maybe an era of bandwidth scarcity where prioritization may have mattered. I think we're in the midst of a shift into bandwidth abundance where priority does not matter. What will is latency/responsiveness, content/compute localization, reliability, consistency, security, etc.
> 
>> 2 - If an ISP blocked YouTube or Netflix, they'd incur huge customer care (contact) costs and would see people start to immediately shift to competitors (5G FWA, FTTP or DOCSIS, WISP, Starlink/LEO, etc.). It just does not seem like something that could realistically happen any longer in the US.
> 
> Dave T called out earlier that the rise of bittorrent was a large part of the inital NN discussion here in the US. But a second large portion was a money grab from ISPs thinking that they could hold up large paid websites (netflix for example) for additional fees by threatening to make their service less useful to their users (viewing their users as an asset to be marketed to the websites rather than customers to be satisfied by providing them access to the websites)
> 
> I don't know if a new round of "it's not fair that Netflix doesn't pay us for the bandwidth to service them" would fall flat at this point or not.

	[SM] In the EU we have this as a continuous lobbying effort by big incumbent ISPs (a move to have the large content providers (CAPs) shoulder their "fair" share of the cost of modernizing the networks*), why this flys with at least some EU politicians is that the intended payees of this scheme are all located outside the EU and hence will have little support by the EU citizenry... (The latter is IMHO not fully undeserved either, the days of "do no evil" are long behind us and big tech often forgets that we are all in this together, but I digress). In the EU one of these days such an effort might actually succeed, as much as I dislike this.




*) This argument about fairness is indeed made by the same ISPs that already charge their eye-ball customers for the same capacity they say they need to built with particpatoin of the CAPs


> 
> David Lang_______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm