From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp121.iad3a.emailsrvr.com (smtp121.iad3a.emailsrvr.com [173.203.187.121]) (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 9C8AD3CB36 for ; Tue, 19 Jun 2018 15:45:33 -0400 (EDT) Received: from smtp8.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 327A15789; Tue, 19 Jun 2018 15:45:33 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp8.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 2CF985691; Tue, 19 Jun 2018 15:45:33 -0400 (EDT) Received: from app15.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 010B057A3; Tue, 19 Jun 2018 15:45:32 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app15.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Tue, 19 Jun 2018 15:45:33 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app15.wa-webapps.iad3a (Postfix) with ESMTP id E3488A0F21; Tue, 19 Jun 2018 15:45:32 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Tue, 19 Jun 2018 15:45:32 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Tue, 19 Jun 2018 15:45:32 -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="----=_20180619154532000000_19933" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <1529339194.276412941@apps.rackspace.com> <1529361825.80979395@apps.rackspace.com> Message-ID: <1529437532.92879322@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: Tue, 19 Jun 2018 19:45:33 -0000 ------=_20180619154532000000_19933 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0Agood rant!=0A =0A-----Original Message-----=0AFrom: "Dave Taht" =0ASent: Tuesday, June 19, 2018 3:33pm=0ATo: "dpreed@deepplum.= com" =0ACc: cerowrt-devel@lists.bufferbloat.net, "bloa= t" =0ASubject: Re: Invisibility of bufferbloat= and its remedies=0A=0A=0A=0AWell, I ranted: http://blog.cerowrt.org/post/n= et_neutrality_isps/=0A=0AI am thinking a string of shorter pieces aimed dir= ectly at customers,=0Areviewers, politicians, etc might do a bit more good = than the=0Agargantuan things jim tends to do.=0A=0AOn Mon, Jun 18, 2018 at = 6:46 PM, Dave Taht wrote:=0A> I will be in D.C., pres= enting https://www.cs.kau.se/tohojo/cake/ - next week.=0A>=0A> If there are= people to see, asses to kick or kiss, I'm up for it, let=0A> me know. Pres= ently I just plan to give my talk and get the heck out of=0A> dodge.=0A>=0A= > One of cake's "minor" features is the *perfect* defeat of the htb=0A> bas= ed shaper in cable modems. If you know the set-rate on the modem,=0A> you= =0A> just set it to the same thing and get vastly superior performance to= =0A> docsis 3.1, pie, or the sqm-scripts.=0A>=0A> On Mon, Jun 18, 2018 at 3= :43 PM, dpreed@deepplum.com=0A> wrote:=0A>> I have be= en one of the most prominent advocates of network neutrality. I'm=0A>> cons= tantly informing my friends and the press about "buffering" not being=0A>> = related to neutrality at all.=0A>>=0A>>=0A>>=0A>> I think that's the best w= e can do.=0A>>=0A>>=0A>>=0A>> Packet neutrality is actually a key part of t= he Internet's design, pushing=0A>> control mechanisms to the edge, with a m= inimum of "intelligence" in the=0A>> routers/switches/gateways. In particul= ar, "content-based" and=0A>> "endpoint-address-based" targeted throttling w= as never how the Internet=0A>> Protocol layer was supposed to work. That's = a fundamental result of the=0A>> "end-to-end argument" applied to congestio= n management. I've spent a lot of=0A>> time on that issue technically. The = original discussions going back before=0A>> Van Jacobson's early work, up t= o RED and ECN, all are based on providing=0A>> congestion signalling suffic= ient to cause endpoints competing for resources=0A>> to adapt their behavio= r cooperatively in real time, while maintaining=0A>> minimal latency under = load.=0A>>=0A>>=0A>>=0A>> Latency under load is the crucial metric across t= he entire IP layer,=0A>> endpoints and routers. It's clear that minimizing = latency under load has to=0A>> be achieved by avoiding buffering insite the= network, moving it to the=0A>> source (and destination).=0A>>=0A>>=0A>>=0A= >> I've given this lecture to policy people a lot. In fact, deliberate crea= tion=0A>> of "bloat" is a technical strategy that has been used in the past= to destroy=0A>> VoIP and other real-time communicaitons. Microsoft was cau= ght doing it=0A>> decades ago, as were some other conflicted communicaitons= providers. They=0A>> could selectively delay small packets using DPI, whil= e letting FTPs get full=0A>> speed. That's one of the reasons we coined the= idea of Network Neutrality.=0A>>=0A>>=0A>>=0A>> But radical right wingers = of the sort that blossom in the paranoid world of=0A>> the dark net started= arguing that the routers should have political freedom=0A>> to do whatever= they damn well pleased with packets, because routers are=0A>> people just = like corporations, and a "free market" is the solution to=0A>> everything.= =0A>>=0A>>=0A>>=0A>> Well, technically, the Internet doesn't work if their = is not some mechanism=0A>> for eliminiating lag under load by eliminating q= ueueing delay in bottleneck=0A>> nodes.=0A>>=0A>>=0A>>=0A>> That's ultimate= ly what Network Neutrality is about. There's a lot of other=0A>> crap being= pushed by folks who pile on to the Network Neutrality discussion.=0A>> Peo= ple want to "fix prices" for example, arguing that profits are bad. Those= =0A>> guys are not the problem.=0A>>=0A>>=0A>>=0A>> The problem is that the= vertically integrated monopolists want to claim that=0A>> the Internet sho= uld be subject to Deep Packet Inspection at every router,=0A>> designed to = charge rents based on content of the packets and who is the=0A>> original s= ender or destination of the packet - that is, charging Netflix or=0A>> NBC = Universal packets nothing, and charging IPFS packets 100x as much.=0A>>=0A>= >=0A>>=0A>> So, no, the Network Neutrality people are NOT the problem with = Bufferbloat.=0A>>=0A>>=0A>>=0A>> Comcast, on the other hand, has been slow-= rolling DOCSIS 3.0, because their=0A>> customers on DOCSIS 2.0 are just ord= ering faster service tiers to overcome=0A>> the Bufferbloat in their DOCSIS= 2 CMTS's.=0A>>=0A>> -----Original Message-----=0A>> From: "Dave Taht" =0A>> Sent: Monday, June 18, 2018 3:07pm=0A>> To: "dpreed@= deepplum.com" =0A>> Cc: cerowrt-devel@lists.bufferbloa= t.net, "bloat"=0A>> =0A>> Subject: Re: Invisib= ility of bufferbloat and its remedies=0A>>=0A>> On Mon, Jun 18, 2018 at 9:2= 6 AM, dpreed@deepplum.com=0A>> wrote:=0A>>> https://w= ww.cordcuttersnews.com/3-easy-tips-to-fix-constant-buffering/=0A>>>=0A>>> I= t's distressing how little the tech press understands the real problem.=0A>= >=0A>> Yea, that one is pretty sad.=0A>>=0A>> It still remains a field of a= ctive academic research:=0A>>=0A>> https://scholar.google.com/scholar?as_yl= o=3D2018&q=3Dbufferbloat&hl=3Den&as_sdt=3D0,5=0A>>=0A>>>=0A>>> Of course, c= able companies like Charter and ATT who have mostly DOCSIS 2=0A>>> gear dep= loyed can't admit to their plant being bloat-causing.=0A>>>=0A>>> In fact i= t protects their cable business against cord cutters.=0A>>=0A>> Lacking com= petition in general, doesn't help.=0A>>=0A>> What I am actually more frustr= ated about is the network neutrality=0A>> advocates A) conflating "bufferin= g" with malfeasance, rather than a=0A>> technical problem=0A>> and B) Using= politics rather than technology to attempt to achieve=0A>> their goals. If= *only* a few prominent members of that side of affairs=0A>> "got" that som= e better technology, deployed, might solve some of their=0A>> problems and = make the internet better for everyone, we'd make more=0A>> progress.=0A>>= =0A>> fq_codel is a uniquely "american" algorithm, in that it gives the=0A>= > "little guy" a little boost until it achieves parity with everyone=0A>> e= lse.=0A>>=0A>>>=0A>>> And the solution is needed in the CMTS once neighbors= all start becoming=0A>>> heavier users, because it is a shared buffering p= ool with no fairness or=0A>>> bloat protection.=0A>>=0A>> My principle obse= rvation is that with the changes in traffic patterns=0A>> in the last decad= e, and the predominance of application-rate limited=0A>> streaming, that mo= st=0A>> folk are merely forced into a bandwidth tier that is less rarely=0A= >> annoying. This does not of course solve the corporate gateway problems= =0A>> very well, nor does it truly kill it dead, but until that day when=0A= >> "the right stuff" is readily available, and more informed demand=0A>> ex= ists.=0A>>=0A>> I was sad to see recently a cisco white paper that even ign= ored their=0A>> own work on pie.=0A>>=0A>>> Still, routers with queue manag= ement that reduce bloat would help a lot,=0A>>> if "buffering" is seen freq= uently under load.=0A>>>=0A>>> So why isn't anyone talking about this probl= em after at least a decade of=0A>>> knowing it, and knowing how to fix it?= =0A>>>=0A>>> I blame IETF members, individually and collectively. If ietf e= xists for=0A>>> any reason other than as a boondoggle for world travel, it'= s for resolving=0A>>> issues like this one.=0A>>=0A>> Heh. I have essential= ly abandoned the IETF as the inmates are running=0A>> the asylum, and tryin= g to continue to make our points there was=0A>> seemingly fruitless=0A>> - = and out of my budget. I'd rather stay home and get better code out=0A>> the= door. Or come up with some other set of orgs to annoy into paying=0A>> att= ention.=0A>>=0A>> I would not mind going to another IETF meeting to give a = preso (on,=0A>> say, cake), but I'm unwilling to front the funds or time an= ymore.=0A>>=0A>>=0A>>>=0A>>=0A>>=0A>>=0A>> --=0A>>=0A>> Dave T=C3=A4ht=0A>>= CEO, TekLibre, LLC=0A>> http://www.teklibre.com=0A>> Tel: 1-669-226-2619= =0A>=0A>=0A>=0A> --=0A>=0A> Dave T=C3=A4ht=0A> CEO, TekLibre, LLC=0A> http:= //www.teklibre.com=0A> Tel: 1-669-226-2619=0A=0A=0A=0A-- =0A=0ADave T=C3=A4= ht=0ACEO, TekLibre, LLC=0Ahttp://www.teklibre.com=0ATel: 1-669-226-2619 ------=_20180619154532000000_19933 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

good rant!

=0A

 

=0A

-----Original Message-----
From= : "Dave Taht" <dave.taht@gmail.com>
Sent: Tuesday, June 19, 2018= 3:33pm
To: "dpreed@deepplum.com" <dpreed@deepplum.com>
Cc:= cerowrt-devel@lists.bufferbloat.net, "bloat" <bloat@lists.bufferbloat.n= et>
Subject: Re: Invisibility of bufferbloat and its remedies
=

=0A
=0A

Well, I r= anted: http://blog.cerowrt.org/post/net_neutrality_isps/

I am th= inking a string of shorter pieces aimed directly at customers,
reviewe= rs, politicians, etc might do a bit more good than the
gargantuan thin= gs jim tends to do.

On Mon, Jun 18, 2018 at 6:46 PM, Dave Taht &= lt;dave.taht@gmail.com> wrote:
> I will be in D.C., presenting h= ttps://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
&g= t; dodge.
>
> One of cake's "minor" features is the *perfec= t* defeat of the htb
> based shaper in cable modems. If you know th= e set-rate on the modem,
> you
> just set it to the same th= ing and get vastly superior performance to
> docsis 3.1, pie, or th= e sqm-scripts.
>
> On Mon, Jun 18, 2018 at 3:43 PM, dpreed@= deepplum.com
> <dpreed@deepplum.com> wrote:
>> I h= ave 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.
>>
&g= t;>
>>
>> I think that's the best we can do.
= >>
>>
>>
>> Packet neutrality is act= ually a key part of the Internet's design, pushing
>> control me= chanisms 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 resu= lt of the
>> "end-to-end argument" applied to congestion managem= ent. I've spent a lot of
>> time on that issue technically. The = original discussions going back before
>> Van Jacobson's early w= ork, 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<= br />>> minimal latency under load.
>>
>>
= >>
>> Latency under load is the crucial metric across the = entire IP layer,
>> endpoints and routers. It's clear that minim= izing latency under load has to
>> be achieved by avoiding buffe= ring insite the network, moving it to the
>> source (and destina= tion).
>>
>>
>>
>> I've given t= his lecture to policy people a lot. In fact, deliberate creation
>&= gt; of "bloat" is a technical strategy that has been used in the past to de= stroy
>> VoIP and other real-time communicaitons. Microsoft was = caught doing it
>> decades ago, as were some other conflicted co= mmunicaitons providers. They
>> could selectively delay small pa= ckets using DPI, while letting FTPs get full
>> speed. That's on= e of the reasons we coined the idea of Network Neutrality.
>>>>
>>
>> But radical right wingers of the so= rt 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.
>>
>>
>>
&= gt;> Well, technically, the Internet doesn't work if their is not some m= echanism
>> for eliminiating lag under load by eliminating queue= ing delay in bottleneck
>> nodes.
>>
>>>>
>> That's ultimately what Network Neutrality is abou= t. 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
>> guy= s are not the problem.
>>
>>
>>
>&= gt; The problem is that the vertically integrated monopolists want to claim= that
>> the Internet should be subject to Deep Packet Inspectio= n 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 pa= ckets nothing, and charging IPFS packets 100x as much.
>>
&= gt;>
>>
>> So, no, the Network Neutrality people a= re NOT the problem with Bufferbloat.
>>
>>
>&= gt;
>> 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 DOC= SIS 2 CMTS's.
>>
>> -----Original Message-----
&= gt;> From: "Dave Taht" <dave.taht@gmail.com>
>> Sent: M= onday, June 18, 2018 3:07pm
>> To: "dpreed@deepplum.com" <dpr= eed@deepplum.com>
>> Cc: cerowrt-devel@lists.bufferbloat.net,= "bloat"
>> <bloat@lists.bufferbloat.net>
>> Su= bject: Re: Invisibility of bufferbloat and its remedies
>>
= >> On Mon, Jun 18, 2018 at 9:26 AM, dpreed@deepplum.com
>>= <dpreed@deepplum.com> wrote:
>>> https://www.cordcutte= rsnews.com/3-easy-tips-to-fix-constant-buffering/
>>>
&g= t;>> 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=3D2018&= amp;q=3Dbufferbloat&hl=3Den&as_sdt=3D0,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 p= rotects their cable business against cord cutters.
>>
>&= gt; Lacking competition in general, doesn't help.
>>
>&g= t; 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 rathe= r 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
>> p= roblems 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 o= nce neighbors all start becoming
>>> heavier users, because i= t is a shared buffering pool with no fairness or
>>> bloat pr= otection.
>>
>> 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 ra= rely
>> annoying. This does not of course solve the corporate ga= teway 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 wi= th queue management that reduce bloat would help a lot,
>>> i= f "buffering" is seen frequently under load.
>>>
>>= ;> So why isn't anyone talking about this problem after at least a decad= e 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 on= e.
>>
>> Heh. I have essentially abandoned the IETF a= s 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 pa= ying
>> 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.
>>
= >>
>>>
>>
>>
>>
&= gt;> --
>>
>> Dave T=C3=A4ht
>> CEO, Te= kLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-669-= 226-2619
>
>
>
> --
>
> Dav= e T=C3=A4ht
> CEO, TekLibre, LLC
> http://www.teklibre.com<= br />> Tel: 1-669-226-2619



--

Dave T= =C3=A4ht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-6= 69-226-2619

=0A
 ------=_20180619154532000000_19933--