Network Neutrality is back! Let´s make the technical aspects heard this time!
 help / color / mirror / Atom feed
From: "Livingood, Jason" <jason_livingood@comcast.com>
To: "Network Neutrality is back! Let´s make the technical aspects
	heard this time!" <nnagain@lists.bufferbloat.net>
Cc: Ronan Pigott <ronan@rjp.ie>
Subject: Re: [NNagain] Net neutrality and Bufferbloat?
Date: Mon, 18 Dec 2023 15:10:18 +0000	[thread overview]
Message-ID: <0256BC1C-06CF-4E12-9C88-E42590CBBFB9@comcast.com> (raw)
In-Reply-To: <b25de682b71af4b429324a19ce4ae2ead10c8e06@rjp.ie>

> 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.






  parent reply	other threads:[~2023-12-18 15:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-11 23:55 Ronan Pigott
2023-12-15 23:31 ` Dave Taht
2023-12-17  1:00 ` Ronan Pigott
2023-12-18 15:10 ` Livingood, Jason [this message]
2023-12-18 15:23   ` Sebastian Moeller
2023-12-18 20:51     ` Dick Roy
2023-12-18 21:55       ` Sebastian Moeller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/nnagain.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0256BC1C-06CF-4E12-9C88-E42590CBBFB9@comcast.com \
    --to=jason_livingood@comcast.com \
    --cc=nnagain@lists.bufferbloat.net \
    --cc=ronan@rjp.ie \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox