[Cerowrt-devel] Invisibility of bufferbloat and its remedies

Mon Jun 18 18:43:45 EDT 2018

I have been one of the most prominent advocates of network neutrality. I'm constantly informing my friends and the press about "buffering" not being related to neutrality at all.

I think that's the best we can do.

Packet neutrality is actually a key part of the Internet's design, pushing control mechanisms to the edge, with a minimum of "intelligence" in the routers/switches/gateways. In particular, "content-based" and "endpoint-address-based" targeted throttling was never how the Internet Protocol layer was supposed to work. That's a fundamental result of the "end-to-end argument" applied to congestion management. I've spent a lot of time on that issue technically. The original discussions going back before Van Jacobson's early work, up to RED and ECN, all are based on providing congestion signalling sufficient to cause endpoints competing for resources to adapt their behavior cooperatively in real time, while maintaining minimal latency under load.

Latency under load is the crucial metric across the entire IP layer, endpoints and routers. It's clear that minimizing latency under load has to be achieved by avoiding buffering insite the network, moving it to the source (and destination).

I've given this lecture to policy people a lot. In fact, deliberate creation of "bloat" is a technical strategy that has been used in the past to destroy VoIP and other real-time communicaitons. Microsoft was caught doing it decades ago, as were some other conflicted communicaitons providers. They could selectively delay small packets using DPI, while letting FTPs get full speed. That's one of the reasons we coined the idea of Network Neutrality.

But radical right wingers of the sort that blossom in the paranoid world of the dark net started arguing that the routers should have political freedom to do whatever they damn well pleased with packets, because routers are people just like corporations, and a "free market" is the solution to everything.

Well, technically, the Internet doesn't work if their is not some mechanism for eliminiating lag under load by eliminating queueing delay in bottleneck nodes.

That's ultimately what Network Neutrality is about.  There's a lot of other crap being pushed by folks who pile on to the Network Neutrality discussion. People want to "fix prices" for example, arguing that profits are bad. Those guys are not the problem.

The problem is that the vertically integrated monopolists want to claim that the Internet should be subject to Deep Packet Inspection at every router, designed to charge rents based on content of the packets and who is the original sender or destination of the packet - that is, charging Netflix or NBC Universal packets nothing, and charging IPFS packets 100x as much.

So, no, the Network Neutrality people are NOT the problem with Bufferbloat.

Comcast, on the other hand, has been slow-rolling DOCSIS 3.0, because their customers on DOCSIS 2.0 are just ordering faster service tiers to overcome the Bufferbloat in their DOCSIS 2 CMTS's.
-----Original Message-----
From: "Dave Taht" <dave.taht at gmail.com>
Sent: Monday, June 18, 2018 3:07pm
To: "dpreed at deepplum.com" <dpreed at deepplum.com>
Cc: cerowrt-devel at lists.bufferbloat.net, "bloat" <bloat at lists.bufferbloat.net>
Subject: Re: Invisibility of bufferbloat and its remedies

On Mon, Jun 18, 2018 at 9:26 AM, dpreed at deepplum.com
<dpreed at deepplum.com> wrote:
> https://www.cordcuttersnews.com/3-easy-tips-to-fix-constant-buffering/
>
> It's distressing how little the tech press understands the real problem.

Yea, that one is pretty sad.

It still remains a field of active academic research:

https://scholar.google.com/scholar?as_ylo=2018&q=bufferbloat&hl=en&as_sdt=0,5

>
> Of course, cable companies like Charter and ATT who have mostly DOCSIS 2 gear deployed can't admit to their plant being bloat-causing.
>
> In fact it protects their cable business against cord cutters.

Lacking competition in general, doesn't help.

What I am actually more frustrated about is the network neutrality
advocates A) conflating "buffering" with malfeasance, rather than a
technical problem
and B) Using politics rather than technology to attempt to achieve
their goals. If *only* a few prominent members of that side of affairs
"got" that some better technology, deployed, might solve some of their
problems and make the internet better for everyone, we'd make more
progress.

fq_codel is a uniquely "american" algorithm, in that it gives the
"little guy" a little boost until it achieves parity with everyone
else.

>
> And the solution is needed in the CMTS once neighbors all start becoming heavier users, because it is a shared buffering pool with no fairness or bloat protection.

My principle observation is that with the changes in traffic patterns
in the last decade, and the predominance of application-rate limited
streaming, that most
folk are merely forced into a bandwidth tier that is less rarely
annoying. This does not of course solve the corporate gateway problems
very well, nor does it truly kill it dead, but until that day when
"the right stuff" is readily available, and more informed demand
exists.

I was sad to see recently a cisco white paper that even ignored their
own work on pie.

> Still, routers with queue management that reduce bloat would help a lot, if "buffering" is seen frequently under load.
>
> So why isn't anyone talking about this problem after at least a decade of knowing it, and knowing how to fix it?
>
> I blame IETF members, individually and collectively. If ietf exists for any reason other than as a boondoggle for world travel, it's for resolving issues like this one.

Heh. I have essentially abandoned the IETF as the inmates are running
the asylum, and trying to continue to make our points there was
seemingly fruitless
- and out of my budget. I'd rather stay home and get better code out
the door. Or come up with some other set of orgs to annoy into paying
attention.

I would not mind going to another IETF meeting to give a preso (on,
say, cake), but I'm unwilling to front the funds or time anymore.

>

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20180618/970e1b44/attachment-0001.html>