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