General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Stuart Cheshire <cheshire@apple.com>
To: "Livingood, Jason" <Jason_Livingood@comcast.com>
Cc: "bloat@lists.bufferbloat.net" <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] AQM & Net Neutrality
Date: Mon, 24 May 2021 12:18:28 -0700	[thread overview]
Message-ID: <3DC2F247-63C2-4753-9E44-2F494E545FEA@apple.com> (raw)
In-Reply-To: <8CA408F6-C8FA-4AAF-908A-B52BDC5030FF@cable.comcast.com>

On 24 May 2021, at 06:09, Livingood, Jason via Bloat <bloat@lists.bufferbloat.net> wrote:

> I’m looking for opinions here re bloat-busting techniques like AQM in the context of network neutrality (NN). The worry I have is whether some non-technical people will misunderstand how AQM works & conclude that implementing it may violate NN because it would make interactive traffic perform better than it does today. That is true of course – it’s a design goal of AQM, but non-interactive traffic performs as well as it always has – it is not disadvantaged.

There’s a faulty assumption buried in this, a common misunderstanding that we need to correct.

Consistently lower delay benefits *all* applications. The lower the round-trip time, the better TCP fast-retransmit works. TCP connection setup is faster. The TLS handshake is faster. The less buffering in the network, the less application-layer buffering is required for streaming video, giving quicker startup times, and quicker random access. If you try to make a list of applications that *don’t* benefit from lower delays, you’ll probably end up with an empty list.

This is why I’ve been advocating for making low delay available for *any* traffic that chooses to opt-in to this smarter queue management, not selectively for just some privileged traffic. I’m not making any subjective value judgement that video conferencing traffic is more important or more deserving that streaming video traffic, or weather forecasts, or driving directions, or software downloads. I do not support traffic prioritization schemes that privilege some traffic types over others. I support making low delay available to *all* traffic that agrees to behave properly and cooperate to keep the queues short -- meaning packet pacing, responding appropriately to congestion signals, etc.

Delay reduction is not an either/or choice. In order for some traffic to benefit other traffic doesn’t have to suffer. It’s not a zero-sum game. Eliminating standing queues in network buffers benefits all traffic. This can be hard to communicate because it seems counter to human intuition. It sounds too good to be true. In normal human life this is uncommon. When first class passengers board the plane first, all economy passengers wait a little bit longer as a result. Computer network queueing doesn’t operate like that, which makes it hard to explain by analogy to everyday experiences that most people understand.

I talked about this six years ago in my presentation at the Apple developer conference:
<https://developer.apple.com/videos/play/wwdc2015/719/?time=2702>

There’s also a neat demo a little earlier in that same video:
<https://developer.apple.com/videos/play/wwdc2015/719/?time=2520>

Stuart Cheshire


  parent reply	other threads:[~2021-05-24 19:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-24 13:09 Livingood, Jason
2021-05-24 14:30 ` Jonathan Morton
2021-05-24 14:51   ` Jonathan Morton
2021-05-24 21:13   ` Michael Richardson
2021-05-24 19:18 ` Stuart Cheshire [this message]
2021-05-24 21:23   ` Michael Richardson
2021-05-25 16:03   ` Jonathan Morton
2021-05-26 18:32     ` Dave Taht
2021-05-26 18:36       ` Dave Taht
2021-05-28 22:28         ` Aaron Wood
2021-05-28 23:18           ` Sebastian Moeller
2021-06-03  9:23   ` Holland, Jake

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/bloat.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=3DC2F247-63C2-4753-9E44-2F494E545FEA@apple.com \
    --to=cheshire@apple.com \
    --cc=Jason_Livingood@comcast.com \
    --cc=bloat@lists.bufferbloat.net \
    /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