[Cerowrt-devel] Invisibility of bufferbloat and its remedies

Tue Jun 19 15:45:32 EDT 2018

good rant!

-----Original Message-----
From: "Dave Taht" <dave.taht at gmail.com>
Sent: Tuesday, June 19, 2018 3:33pm
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

Well, I ranted: http://blog.cerowrt.org/post/net_neutrality_isps/

I am thinking a string of shorter pieces aimed directly at customers,
reviewers, politicians, etc might do a bit more good than the
gargantuan things jim tends to do.

On Mon, Jun 18, 2018 at 6:46 PM, Dave Taht <dave.taht at gmail.com> wrote:
> I will be in D.C., presenting https://www.cs.kau.se/tohojo/cake/ - next week.
>
> If there are people to see, asses to kick or kiss, I'm up for it, let
> me know. Presently I just plan to give my talk and get the heck out of
> dodge.
>
> One of cake's "minor" features is the *perfect* defeat of the htb
> based shaper in cable modems. If you know the set-rate on the modem,
> you
> just set it to the same thing and get vastly superior performance to
> docsis 3.1, pie, or the sqm-scripts.
>
> On Mon, Jun 18, 2018 at 3:43 PM, dpreed at deepplum.com
> <dpreed at deepplum.com> wrote:
>> 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
>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619

-- 

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/20180619/441f62aa/attachment-0001.html>