Hi Frantisek,

> On Sep 30, 2023, at 14:00, Frantisek Borsik via Rpm 
> <r...@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.bor...@gmail.com
> 
> 
> 
> On Fri, Sep 29, 2023 at 6:15 PM dan via Rpm <r...@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.hano...@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 
> > <r...@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
> > r...@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm
> 
> _______________________________________________
> Rpm mailing list
> r...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm
> _______________________________________________
> Rpm mailing list
> r...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Reply via email to