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

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

[Livingood, Jason]

On 9/29/23, 00:54, "Jonathan Morton" <chromatix99@gmail.com <mailto:chromatix99@gmail.com>> wrote:
> 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

That is not true and really not worth re-litigating here. 

> 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 regulations played no role whatsoever in the resolution of that conflict - a business arrangement was reached, just as it was in the SK Telecom example recently: https://about.netflix.com/en/news/sk-telecom-sk-broadband-and-netflix-establish-strategic-partnership-to 

> ISPs behind L4S actively do not want a technology that works end-to-end over the general Internet. 

That's simply not true. As someone running an L4S field trial right now - we want the technology to get the widest possible deployment and be fully end-to-end. Why else would there be so much effort to ensure that ECN and DSCP marks can traverse network domain boundaries for example? Why else would there be strong app developer interest? What evidence do you have to show that anyone working on L4S want to create a walled garden? If anything, it seems the opposite of 5G network slicing, which seems to me personally to be another 3GPP run at walled garden stuff (like IMS). Ultimately it is like a lot of other IETF work -- it is an interesting technology and we'll have to see whether it gets good adoption - the 'market' will decide. 

> They want something that can provide a domination service within their own walled gardens. 

Also not correct. And last time I checked the balance sheets of companies in these sectors - video streaming services were losing money while provision of internet services were financially healthy. 

JL

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

[dan]

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

On Fri, Sep 29, 2023 at 7:17 AM Livingood, Jason via LibreQoS <
libreqos@lists.bufferbloat.net> wrote:

> On 9/29/23, 00:54, "Jonathan Morton" <chromatix99@gmail.com <mailto:
> chromatix99@gmail.com>> wrote:
> > 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
>
> That is not true and really not worth re-litigating here.
>
> > 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 regulations played no role whatsoever in the resolution of that
> conflict - a business arrangement was reached, just as it was in the SK
> Telecom example recently:
> https://about.netflix.com/en/news/sk-telecom-sk-broadband-and-netflix-establish-strategic-partnership-to
>
> > ISPs behind L4S actively do not want a technology that works end-to-end
> over the general Internet.
>
> That's simply not true. As someone running an L4S field trial right now -
> we want the technology to get the widest possible deployment and be fully
> end-to-end. Why else would there be so much effort to ensure that ECN and
> DSCP marks can traverse network domain boundaries for example? Why else
> would there be strong app developer interest? What evidence do you have to
> show that anyone working on L4S want to create a walled garden? If
> anything, it seems the opposite of 5G network slicing, which seems to me
> personally to be another 3GPP run at walled garden stuff (like IMS).
> Ultimately it is like a lot of other IETF work -- it is an interesting
> technology and we'll have to see whether it gets good adoption - the
> 'market' will decide.
>
> > They want something that can provide a domination service within their
> own walled gardens.
>
> Also not correct. And last time I checked the balance sheets of companies
> in these sectors - video streaming services were losing money while
> provision of internet services were financially healthy.
>
> JL
>
>
>
I think this stuff degrades into conspiracy theory often enough.  While I
don't discount the possibility of collusion, I don't give these
people/groups credit enough to pull of a mass scale conspiracy either....
If netflix is jammed down to small of a pipe at an ISP, that's more likely
(IMO...) disorganization or incompetence or disinterest over conspiracy.
 I feel the same about government in general...

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

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

[Frantisek Borsik]

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

>
> > They want something that can provide a domination service within their
> own walled gardens.
> Also not correct. And last time I checked the balance sheets of companies
> in these sectors - *video streaming services were losing money while
> provision of internet services were financially healthy. *


Indeed, Jason:
https://www.vulture.com/2023/06/streaming-industry-netflix-max-disney-hulu-apple-tv-prime-video-peacock-paramount.html


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 5:53 PM dan via Rpm <rpm@lists.bufferbloat.net>
wrote:

>
>
> On Fri, Sep 29, 2023 at 7:17 AM Livingood, Jason via LibreQoS <
> libreqos@lists.bufferbloat.net> wrote:
>
>> On 9/29/23, 00:54, "Jonathan Morton" <chromatix99@gmail.com <mailto:
>> chromatix99@gmail.com>> wrote:
>> > 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
>>
>> That is not true and really not worth re-litigating here.
>>
>> > 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 regulations played no role whatsoever in the resolution of that
>> conflict - a business arrangement was reached, just as it was in the SK
>> Telecom example recently:
>> https://about.netflix.com/en/news/sk-telecom-sk-broadband-and-netflix-establish-strategic-partnership-to
>>
>> > ISPs behind L4S actively do not want a technology that works end-to-end
>> over the general Internet.
>>
>> That's simply not true. As someone running an L4S field trial right now -
>> we want the technology to get the widest possible deployment and be fully
>> end-to-end. Why else would there be so much effort to ensure that ECN and
>> DSCP marks can traverse network domain boundaries for example? Why else
>> would there be strong app developer interest? What evidence do you have to
>> show that anyone working on L4S want to create a walled garden? If
>> anything, it seems the opposite of 5G network slicing, which seems to me
>> personally to be another 3GPP run at walled garden stuff (like IMS).
>> Ultimately it is like a lot of other IETF work -- it is an interesting
>> technology and we'll have to see whether it gets good adoption - the
>> 'market' will decide.
>>
>> > They want something that can provide a domination service within their
>> own walled gardens.
>>
>> Also not correct. And last time I checked the balance sheets of companies
>> in these sectors - video streaming services were losing money while
>> provision of internet services were financially healthy.
>>
>> JL
>>
>>
>>
> I think this stuff degrades into conspiracy theory often enough.  While I
> don't discount the possibility of collusion, I don't give these
> people/groups credit enough to pull of a mass scale conspiracy either....
> If netflix is jammed down to small of a pipe at an ISP, that's more likely
> (IMO...) disorganization or incompetence or disinterest over conspiracy.
>  I feel the same about government in general...
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm
>

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

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

[Jonathan Morton]

> 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

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

[David Lang]

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

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.

David Lang