[NNagain] Net neutrality and Bufferbloat?

[NNagain] Net neutrality and Bufferbloat?

[Ronan Pigott]

Hi,

I read the recent NOI response and it sparked my interest in the relationship
between Net Neutrality and bufferbloat. I also found [1] which makes it seem
Net Neutrality is an obstacle to solving bufferbloat in the US, at least. I'm
just curious about the legal obstacles to bufferbloat solutions in the US. I
tried reading the FCC rules which I understand changed in 2010, 2014, and 2017
but theye're kinda vague I think and I am no lawyer nor industry veteran and
don't think I really understand the implications.

In particular, [1] claims:

> Misapplied concepts of network neutrality is one of the things that killed
> fq codel for DOCSIS 3.1

Does anyone know more about this?

When looking around, I found more similar claims [2]:

> Finally, some jurisdictions impose regulations that limit the ability of
> networks to provide differentiation of services, in large part this seems to
> be based on the belief that doing so necessarily involves prioritization or
> privileged access to bandwidth, and thus a benefit to one class of traffic
> always comes at the expense of another.

Anyone know what regulations the authors mean here?

I personally run openwrt+sqm/cake in my home router and have found it to be
effective, so I am convinced of the value of sqm. Is Net Neutrality regulation
an obstacle to wider deployment?

[1] https://blog.cerowrt.org/post/net_neutrality_customers/
[2] https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/

Thanks,

Ronan

Re: [NNagain] Net neutrality and Bufferbloat?

[Dave Taht]

On Fri, Dec 15, 2023 at 3:12 PM Ronan Pigott via Nnagain
<nnagain@lists.bufferbloat.net> wrote:
>
> Hi,
>
> I read the recent NOI response and it sparked my interest in the relationship
> between Net Neutrality and bufferbloat. I also found [1] which makes it seem
> Net Neutrality is an obstacle to solving bufferbloat in the US, at least. I'm
> just curious about the legal obstacles to bufferbloat solutions in the US. I
> tried reading the FCC rules which I understand changed in 2010, 2014, and 2017
> but theye're kinda vague I think and I am no lawyer nor industry veteran and
> don't think I really understand the implications.
>
> In particular, [1] claims:
>
> > Misapplied concepts of network neutrality is one of the things that killed
> > fq codel for DOCSIS 3.1
>
> Does anyone know more about this?

I quoted from a cable industry insider on that (2013) and at the time,
I too thought that the technology was so new that any number of
objections could be raised to it. Queuing remains ill-industood in
general, the pain points and misunderstandings that fueled the
bitorrent vs voip debacle, still present.

We've since cracked a few billion instances of fq_codel, so... tI long
ago stopped worrying a regulator would take an interest (except
perhaps in helping further deployment!), and even the pro-NN side,
places like public knowledge, have acknowledged the benefit, but it
has taken a huge educational and deployment process to get to where we
are today.

At the time I could hardly imagine the technology to be as successful
as it has been either (apple and linux defaults), and yet I keep
hoping to see deployments where it is needed most, on our wireless
technologies. fq_codel on 5G or starlink would be nice to see next
year!

>
> When looking around, I found more similar claims [2]:
>
> > Finally, some jurisdictions impose regulations that limit the ability of
> > networks to provide differentiation of services, in large part this seems to
> > be based on the belief that doing so necessarily involves prioritization or
> > privileged access to bandwidth, and thus a benefit to one class of traffic
> > always comes at the expense of another.
>
> Anyone know what regulations the authors mean here?

We have done extensive surveys of US and some european law here, and
the consensus appears to be that so long as it is an application
class, not a specific service from a specific provider being boosted
or not, "reasonable network management" suffices.

> I personally run openwrt+sqm/cake in my home router and have found it to be
> effective, so I am convinced of the value of sqm. Is Net Neutrality regulation
> an obstacle to wider deployment?
>
> [1] https://blog.cerowrt.org/post/net_neutrality_customers/
> [2] https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/
>
> Thanks,
>
> Ronan
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain



-- 
:( My old R&D campus is up for sale: https://tinyurl.com/yurtlab
Dave Täht CSO, LibreQos

Re: [NNagain] Net neutrality and Bufferbloat?

[Ronan Pigott]

Hey Dave,

That's good to hear. Thanks for the reply and thanks for the cake!

Cheers,

Ronan

Re: [NNagain] Net neutrality and Bufferbloat?

[Livingood, Jason]

> Misapplied concepts of network neutrality is one of the things that killed
> fq codel for DOCSIS 3.1

I am not so sure this was the case - I think it was just that a different AQM was selected. DOCSIS 3.1 includes the DOCSIS-PIE AQM - see  https://www.rfc-editor.org/rfc/rfc8034.html and 
https://www.cablelabs.com/blog/how-docsis-3-1-reduces-latency-with-active-queue-management. I co-wrote a paper about our deployment during COVID at https://arxiv.org/pdf/2107.13968.pdf. See also https://www.ietf.org/archive/id/draft-livingood-low-latency-deployment-03.html.

> Finally, some jurisdictions impose regulations that limit the ability of
> networks to provide differentiation of services, in large part this seems to
> be based on the belief that doing so necessarily involves prioritization or
> privileged access to bandwidth, and thus a benefit to one class of traffic
> always comes at the expense of another.

Much regulatory/policy discussion still frames networks as making decisions with scarce bandwidth, rather than abundant bandwidth, and prioritization in that view is a zero-sum game. But IMO we're no longer in the bandwidth-scarcity era but in a bandwidth-abundance era - or at least in an era with declining marginal utility of bandwidth as compared to techniques to improve latency. But I digress.

To go back to the question of reasonable network management - the key is that any technique used must not be application or destination-specific. So for example, it cannot be focused on flows to the example.com destination or on any flows that are streaming video [1]. 

Anyway - I do not think new AQMs or dual queue low latency networking is in conflict with net neutrality. 

Jason

[1] Current rules differ between wireless/mobile and fixed last mile networks; currently the MNOs have a lot more latitude that fixed networks but that may be sorted out in the current NPRM. My personal view is there should be a unified set of rules of all networks.

Re: [NNagain] Net neutrality and Bufferbloat?

[Sebastian Moeller]

Hi Jason,


during the Covid19 era, the EU issued clarifications that even throttling a complete class like streaming video might be within reasonable network management. The only stipulations wer this needs to happen only to allow arguably more important traffic classes (like work-from home vide conferences or remote schooling) to proceed with less interferences and blind to source and sender. That is using this to play favorites amongst streaming services would still be problematic, but down-prioritizing all streaming would be acceptable. (Now the assumption is that reasonable network management will not last for ever and is no replacement for scaling the capacity to the load in the intermediate/longer terms).



> On Dec 18, 2023, at 16:10, Livingood, Jason via Nnagain <nnagain@lists.bufferbloat.net> wrote:
> 
>> Misapplied concepts of network neutrality is one of the things that killed
>> fq codel for DOCSIS 3.1
> 
> I am not so sure this was the case - I think it was just that a different AQM was selected. DOCSIS 3.1 includes the DOCSIS-PIE AQM - see  https://www.rfc-editor.org/rfc/rfc8034.html and 
> https://www.cablelabs.com/blog/how-docsis-3-1-reduces-latency-with-active-queue-management. I co-wrote a paper about our deployment during COVID at https://arxiv.org/pdf/2107.13968.pdf. See also https://www.ietf.org/archive/id/draft-livingood-low-latency-deployment-03.html.
> 
>> Finally, some jurisdictions impose regulations that limit the ability of
>> networks to provide differentiation of services, in large part this seems to
>> be based on the belief that doing so necessarily involves prioritization or
>> privileged access to bandwidth, and thus a benefit to one class of traffic
>> always comes at the expense of another.
> 
> Much regulatory/policy discussion still frames networks as making decisions with scarce bandwidth, rather than abundant bandwidth, and prioritization in that view is a zero-sum game. But IMO we're no longer in the bandwidth-scarcity era but in a bandwidth-abundance era - or at least in an era with declining marginal utility of bandwidth as compared to techniques to improve latency. But I digress.

	Speaking from my side of the pond, over here we still have a somewhat big divide between those sitting on heaps of capacity and those that are still in the painful range <= 16 Mbps (16 itself would not be so bad, but that class goes down below 1 Mbps links and that is IMHO painful).


> 
> To go back to the question of reasonable network management - the key is that any technique used must not be application or destination-specific. So for example, it cannot be focused on flows to the example.com destination or on any flows that are streaming video [1]. 

	See above, while as long as example.com is not violating the law this first is also not an option inside the EU regulatory framework, but the second already has been under specific limited circumstances.


> Anyway - I do not think new AQMs or dual queue low latency networking is in conflict with net neutrality. 

	I agree that AQMs are pretty safe, and I feel that packet schedulers are also fine, even conditional priority schedulers ;)

Regards
	Sebastian

> 
> Jason
> 
> [1] Current rules differ between wireless/mobile and fixed last mile networks; currently the MNOs have a lot more latitude that fixed networks but that may be sorted out in the current NPRM. My personal view is there should be a unified set of rules of all networks.
> 
> 
> 
> 
> 
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Net neutrality and Bufferbloat?

[Dick Roy]

Given that the capacity of a system is in essence a theoretical maximum (in
this case data rates of a communications sytem), I am not sure what "scaling
the capacity to the load" means. Throttling the load to the capacity I
understand.

Hmm ....

RR

-----Original Message-----
From: Nnagain [mailto:nnagain-bounces@lists.bufferbloat.net] On Behalf Of
Sebastian Moeller via Nnagain
Sent: Monday, December 18, 2023 7:24 AM
To: Network Neutrality is back! Let´s make the technical aspects heard this
time!
Cc: Sebastian Moeller; Ronan Pigott
Subject: Re: [NNagain] Net neutrality and Bufferbloat?

Hi Jason,


during the Covid19 era, the EU issued clarifications that even throttling a
complete class like streaming video might be within reasonable network
management. The only stipulations wer this needs to happen only to allow
arguably more important traffic classes (like work-from home vide
conferences or remote schooling) to proceed with less interferences and
blind to source and sender. That is using this to play favorites amongst
streaming services would still be problematic, but down-prioritizing all
streaming would be acceptable. (Now the assumption is that reasonable
network management will not last for ever and is no replacement for scaling
the capacity to the load in the intermediate/longer terms).



> On Dec 18, 2023, at 16:10, Livingood, Jason via Nnagain
<nnagain@lists.bufferbloat.net> wrote:
> 
>> Misapplied concepts of network neutrality is one of the things that
killed
>> fq codel for DOCSIS 3.1
> 
> I am not so sure this was the case - I think it was just that a different
AQM was selected. DOCSIS 3.1 includes the DOCSIS-PIE AQM - see
https://www.rfc-editor.org/rfc/rfc8034.html and 
>
https://www.cablelabs.com/blog/how-docsis-3-1-reduces-latency-with-active-qu
eue-management. I co-wrote a paper about our deployment during COVID at
https://arxiv.org/pdf/2107.13968.pdf. See also
https://www.ietf.org/archive/id/draft-livingood-low-latency-deployment-03.ht
ml.
> 
>> Finally, some jurisdictions impose regulations that limit the ability of
>> networks to provide differentiation of services, in large part this seems
to
>> be based on the belief that doing so necessarily involves prioritization
or
>> privileged access to bandwidth, and thus a benefit to one class of
traffic
>> always comes at the expense of another.
> 
> Much regulatory/policy discussion still frames networks as making
decisions with scarce bandwidth, rather than abundant bandwidth, and
prioritization in that view is a zero-sum game. But IMO we're no longer in
the bandwidth-scarcity era but in a bandwidth-abundance era - or at least in
an era with declining marginal utility of bandwidth as compared to
techniques to improve latency. But I digress.

	Speaking from my side of the pond, over here we still have a
somewhat big divide between those sitting on heaps of capacity and those
that are still in the painful range <= 16 Mbps (16 itself would not be so
bad, but that class goes down below 1 Mbps links and that is IMHO painful).


> 
> To go back to the question of reasonable network management - the key is
that any technique used must not be application or destination-specific. So
for example, it cannot be focused on flows to the example.com destination or
on any flows that are streaming video [1]. 

	See above, while as long as example.com is not violating the law
this first is also not an option inside the EU regulatory framework, but the
second already has been under specific limited circumstances.


> Anyway - I do not think new AQMs or dual queue low latency networking is
in conflict with net neutrality. 

	I agree that AQMs are pretty safe, and I feel that packet schedulers
are also fine, even conditional priority schedulers ;)

Regards
	Sebastian

> 
> Jason
> 
> [1] Current rules differ between wireless/mobile and fixed last mile
networks; currently the MNOs have a lot more latitude that fixed networks
but that may be sorted out in the current NPRM. My personal view is there
should be a unified set of rules of all networks.
> 
> 
> 
> 
> 
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

_______________________________________________
Nnagain mailing list
Nnagain@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Net neutrality and Bufferbloat?

[Sebastian Moeller]

Hi Dick,


> On Dec 18, 2023, at 21:51, Dick Roy <dickroy@alum.mit.edu> wrote:
> 
> Given that the capacity of a system is in essence a theoretical maximum (in
> this case data rates of a communications sytem), I am not sure what "scaling
> the capacity to the load" means.

	Oh this was supposed to mean that the EU regulators expect ISPs to increase their internal capacity if the sustained load of their customers exceed the given capacity reliably for too long. If an ISP throttles all streaming due to a transient overload and to allow e.g. video conference traffic to flow smoother this is acceptable, if the same ISPs decided to do so ad infinitum to save the cost of removing bottlenecks from its networks that will be a problem (in theory, how all of this is handled in practice I can not tell).... But hey I am extrapolation from EU regulation 2015/2120 :

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.



> Throttling the load to the capacity I
> understand.

	Yes, I thought it was clever to flip this nomenclature around, but as you demonstrate "far too clever"  ;)

Regards
	Sebastian

> 
> Hmm ....
> 
> RR
> 
> -----Original Message-----
> From: Nnagain [mailto:nnagain-bounces@lists.bufferbloat.net] On Behalf Of
> Sebastian Moeller via Nnagain
> Sent: Monday, December 18, 2023 7:24 AM
> To: Network Neutrality is back! Let´s make the technical aspects heard this
> time!
> Cc: Sebastian Moeller; Ronan Pigott
> Subject: Re: [NNagain] Net neutrality and Bufferbloat?
> 
> Hi Jason,
> 
> 
> during the Covid19 era, the EU issued clarifications that even throttling a
> complete class like streaming video might be within reasonable network
> management. The only stipulations wer this needs to happen only to allow
> arguably more important traffic classes (like work-from home vide
> conferences or remote schooling) to proceed with less interferences and
> blind to source and sender. That is using this to play favorites amongst
> streaming services would still be problematic, but down-prioritizing all
> streaming would be acceptable. (Now the assumption is that reasonable
> network management will not last for ever and is no replacement for scaling
> the capacity to the load in the intermediate/longer terms).
> 
> 
> 
>> On Dec 18, 2023, at 16:10, Livingood, Jason via Nnagain
> <nnagain@lists.bufferbloat.net> wrote:
>> 
>>> Misapplied concepts of network neutrality is one of the things that
> killed
>>> fq codel for DOCSIS 3.1
>> 
>> I am not so sure this was the case - I think it was just that a different
> AQM was selected. DOCSIS 3.1 includes the DOCSIS-PIE AQM - see
> https://www.rfc-editor.org/rfc/rfc8034.html and 
>> 
> https://www.cablelabs.com/blog/how-docsis-3-1-reduces-latency-with-active-qu
> eue-management. I co-wrote a paper about our deployment during COVID at
> https://arxiv.org/pdf/2107.13968.pdf. See also
> https://www.ietf.org/archive/id/draft-livingood-low-latency-deployment-03.ht
> ml.
>> 
>>> Finally, some jurisdictions impose regulations that limit the ability of
>>> networks to provide differentiation of services, in large part this seems
> to
>>> be based on the belief that doing so necessarily involves prioritization
> or
>>> privileged access to bandwidth, and thus a benefit to one class of
> traffic
>>> always comes at the expense of another.
>> 
>> Much regulatory/policy discussion still frames networks as making
> decisions with scarce bandwidth, rather than abundant bandwidth, and
> prioritization in that view is a zero-sum game. But IMO we're no longer in
> the bandwidth-scarcity era but in a bandwidth-abundance era - or at least in
> an era with declining marginal utility of bandwidth as compared to
> techniques to improve latency. But I digress.
> 
> 	Speaking from my side of the pond, over here we still have a
> somewhat big divide between those sitting on heaps of capacity and those
> that are still in the painful range <= 16 Mbps (16 itself would not be so
> bad, but that class goes down below 1 Mbps links and that is IMHO painful).
> 
> 
>> 
>> To go back to the question of reasonable network management - the key is
> that any technique used must not be application or destination-specific. So
> for example, it cannot be focused on flows to the example.com destination or
> on any flows that are streaming video [1]. 
> 
> 	See above, while as long as example.com is not violating the law
> this first is also not an option inside the EU regulatory framework, but the
> second already has been under specific limited circumstances.
> 
> 
>> Anyway - I do not think new AQMs or dual queue low latency networking is
> in conflict with net neutrality. 
> 
> 	I agree that AQMs are pretty safe, and I feel that packet schedulers
> are also fine, even conditional priority schedulers ;)
> 
> Regards
> 	Sebastian
> 
>> 
>> Jason
>> 
>> [1] Current rules differ between wireless/mobile and fixed last mile
> networks; currently the MNOs have a lot more latitude that fixed networks
> but that may be sorted out in the current NPRM. My personal view is there
> should be a unified set of rules of all networks.
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
> 
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>