From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp65.iad3a.emailsrvr.com (smtp65.iad3a.emailsrvr.com [173.203.187.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3C7E73CB35 for ; Mon, 18 Jun 2018 18:43:46 -0400 (EDT) Received: from smtp17.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0AB8925FFD; Mon, 18 Jun 2018 18:43:46 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp17.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0664025FFF; Mon, 18 Jun 2018 18:43:46 -0400 (EDT) Received: from app37.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D5DE725FFD; Mon, 18 Jun 2018 18:43:45 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app37.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Mon, 18 Jun 2018 18:43:45 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app37.wa-webapps.iad3a (Postfix) with ESMTP id C6129E12EC; Mon, 18 Jun 2018 18:43:45 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Mon, 18 Jun 2018 18:43:45 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Mon, 18 Jun 2018 18:43:45 -0400 (EDT) From: "dpreed@deepplum.com" To: "Dave Taht" Cc: cerowrt-devel@lists.bufferbloat.net, "bloat" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20180618184345000000_52855" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <1529339194.276412941@apps.rackspace.com> Message-ID: <1529361825.80979395@apps.rackspace.com> X-Mailer: webmail/15.2.1-RC Subject: Re: [Cerowrt-devel] Invisibility of bufferbloat and its remedies X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 22:43:46 -0000 ------=_20180618184345000000_52855 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI have been one of the most prominent advocates of network neutrality. I= 'm constantly informing my friends and the press about "buffering" not bein= g related to neutrality at all.=0A =0AI think that's the best we can do.=0A= =0APacket neutrality is actually a key part of the Internet's design, push= ing control mechanisms to the edge, with a minimum of "intelligence" in the= routers/switches/gateways. In particular, "content-based" and "endpoint-ad= dress-based" targeted throttling was never how the Internet Protocol layer = was supposed to work. That's a fundamental result of the "end-to-end argume= nt" applied to congestion management. I've spent a lot of time on that issu= e technically. The original discussions going back before Van Jacobson's ea= rly work, up to RED and ECN, all are based on providing congestion signalli= ng sufficient to cause endpoints competing for resources to adapt their beh= avior cooperatively in real time, while maintaining minimal latency under l= oad.=0A =0ALatency under load is the crucial metric across the entire IP la= yer, endpoints and routers. It's clear that minimizing latency under load h= as to be achieved by avoiding buffering insite the network, moving it to th= e source (and destination).=0A =0AI'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 communicaito= ns. Microsoft was caught doing it decades ago, as were some other conflicte= d communicaitons providers. They could selectively delay small packets usin= g DPI, while letting FTPs get full speed. That's one of the reasons we coin= ed the idea of Network Neutrality.=0A =0ABut radical right wingers of the s= ort 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 pl= eased with packets, because routers are people just like corporations, and = a "free market" is the solution to everything.=0A =0AWell, technically, the= Internet doesn't work if their is not some mechanism for eliminiating lag = under load by eliminating queueing delay in bottleneck nodes.=0A =0AThat's = ultimately what Network Neutrality is about. There's a lot of other crap b= eing pushed by folks who pile on to the Network Neutrality discussion. Peop= le want to "fix prices" for example, arguing that profits are bad. Those gu= ys are not the problem.=0A =0AThe problem is that the vertically integrated= monopolists want to claim that the Internet should be subject to Deep Pack= et 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 IP= FS packets 100x as much.=0A =0ASo, no, the Network Neutrality people are NO= T the problem with Bufferbloat.=0A =0AComcast, on the other hand, has been = slow-rolling DOCSIS 3.0, because their customers on DOCSIS 2.0 are just ord= ering faster service tiers to overcome the Bufferbloat in their DOCSIS 2 CM= TS's.=0A-----Original Message-----=0AFrom: "Dave Taht" =0ASent: Monday, June 18, 2018 3:07pm=0ATo: "dpreed@deepplum.com" =0ACc: cerowrt-devel@lists.bufferbloat.net, "bloat" =0ASubject: Re: Invisibility of bufferbloat and its reme= dies=0A=0A=0A=0AOn Mon, Jun 18, 2018 at 9:26 AM, dpreed@deepplum.com=0A wrote:=0A> https://www.cordcuttersnews.com/3-easy-tips-to= -fix-constant-buffering/=0A>=0A> It's distressing how little the tech press= understands the real problem.=0A=0AYea, that one is pretty sad.=0A=0AIt st= ill remains a field of active academic research:=0A=0Ahttps://scholar.googl= e.com/scholar?as_ylo=3D2018&q=3Dbufferbloat&hl=3Den&as_sdt=3D0,5=0A=0A>=0A>= Of course, cable companies like Charter and ATT who have mostly DOCSIS 2 g= ear deployed can't admit to their plant being bloat-causing.=0A>=0A> In fac= t it protects their cable business against cord cutters.=0A=0ALacking compe= tition in general, doesn't help.=0A=0AWhat I am actually more frustrated ab= out is the network neutrality=0Aadvocates A) conflating "buffering" with ma= lfeasance, rather than a=0Atechnical problem=0Aand B) Using politics rather= than technology to attempt to achieve=0Atheir goals. If *only* a few promi= nent members of that side of affairs=0A"got" that some better technology, d= eployed, might solve some of their=0Aproblems and make the internet better = for everyone, we'd make more=0Aprogress.=0A=0Afq_codel is a uniquely "ameri= can" algorithm, in that it gives the=0A"little guy" a little boost until it= achieves parity with everyone=0Aelse.=0A=0A>=0A> And the solution is neede= d in the CMTS once neighbors all start becoming heavier users, because it i= s a shared buffering pool with no fairness or bloat protection.=0A=0AMy pri= nciple observation is that with the changes in traffic patterns=0Ain the la= st decade, and the predominance of application-rate limited=0Astreaming, th= at most=0Afolk are merely forced into a bandwidth tier that is less rarely= =0Aannoying. This does not of course solve the corporate gateway problems= =0Avery well, nor does it truly kill it dead, but until that day when=0A"th= e right stuff" is readily available, and more informed demand=0Aexists.=0A= =0AI was sad to see recently a cisco white paper that even ignored their=0A= own work on pie.=0A=0A> Still, routers with queue management that reduce bl= oat would help a lot, if "buffering" is seen frequently under load.=0A>=0A>= So why isn't anyone talking about this problem after at least a decade of = knowing it, and knowing how to fix it?=0A>=0A> I blame IETF members, indivi= dually and collectively. If ietf exists for any reason other than as a boon= doggle for world travel, it's for resolving issues like this one.=0A=0AHeh.= I have essentially abandoned the IETF as the inmates are running=0Athe asy= lum, and trying to continue to make our points there was=0Aseemingly fruitl= ess=0A- and out of my budget. I'd rather stay home and get better code out= =0Athe door. Or come up with some other set of orgs to annoy into paying=0A= attention.=0A=0AI would not mind going to another IETF meeting to give a pr= eso (on,=0Asay, cake), but I'm unwilling to front the funds or time anymore= .=0A=0A=0A>=0A=0A=0A=0A-- =0A=0ADave T=C3=A4ht=0ACEO, TekLibre, LLC=0Ahttp:= //www.teklibre.com=0ATel: 1-669-226-2619 ------=_20180618184345000000_52855 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I have been one of the mos= t prominent advocates of network neutrality. I'm constantly informing my fr= iends and the press about "buffering" not being related to neutrality at al= l.

=0A

 

=0A

I think that's the = best we can do.

=0A

 

=0A

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

= =0A

 

=0A

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

=0A 

=0A

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

=0A

 =

=0A

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

=0A

 

=0A

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.

=0A

 

=0A

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

=0A

 

=0A

The problem is that the vertically integrated monopolists want to= claim that the Internet should be subject to Deep Packet Inspection at eve= ry 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 Ne= tflix or NBC Universal packets nothing, and charging IPFS packets 100x as m= uch.

=0A

 

=0A

So, no, the Netwo= rk Neutrality people are NOT the problem with Bufferbloat.

=0A

 

=0A

Comcast, on the other hand, has been= slow-rolling DOCSIS 3.0, because their customers on DOCSIS 2.0 are just or= dering faster service tiers to overcome the Bufferbloat in their DOCSIS 2 C= MTS's.

=0A

-----Original Message-----
From: "Dave T= aht" <dave.taht@gmail.com>
Sent: Monday, June 18, 2018 3:07pmTo: "dpreed@deepplum.com" <dpreed@deepplum.com>
Cc: cerowrt-d= evel@lists.bufferbloat.net, "bloat" <bloat@lists.bufferbloat.net>
Subject: Re: Invisibility of bufferbloat and its remedies

= =0A
=0A

On Mon, Jun 18, 201= 8 at 9:26 AM, dpreed@deepplum.com
<dpreed@deepplum.com> wrote:> https://www.cordcuttersnews.com/3-easy-tips-to-fix-constant-buffer= ing/
>
> It's distressing how little the tech press underst= ands the real problem.

Yea, that one is pretty sad.

I= t still remains a field of active academic research:

https://sch= olar.google.com/scholar?as_ylo=3D2018&q=3Dbufferbloat&hl=3Den&a= s_sdt=3D0,5

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

Lacking competition in general, d= oesn't help.

What I am actually more frustrated about is the net= work 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 promine= nt members of that side of affairs
"got" that some better technology, = deployed, might solve some of their
problems and make the internet bet= ter for everyone, we'd make more
progress.

fq_codel is a un= iquely "american" algorithm, in that it gives the
"little guy" a littl= e boost until it achieves parity with everyone
else.

>> And the solution is needed in the CMTS once neighbors all start be= coming heavier users, because it is a shared buffering pool with no fairnes= s 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 n= ot 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 re= adily 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 bl= oat would help a lot, if "buffering" is seen frequently under load.
&g= t;
> So why isn't anyone talking about this problem after at least = a decade of knowing it, and knowing how to fix it?
>
> I bl= ame IETF members, individually and collectively. If ietf exists for any rea= son 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 po= ints there was
seemingly fruitless
- and out of my budget. I'd ra= ther 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 n= ot 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=C3=A4ht
CEO, TekLibre, = LLC
http://www.teklibre.com
Tel: 1-669-226-2619

=0A
------=_20180618184345000000_52855--