From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B9E3C3B29E; Tue, 19 Jun 2018 15:33:12 -0400 (EDT) Received: by mail-qt0-x243.google.com with SMTP id d3-v6so878797qto.1; Tue, 19 Jun 2018 12:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HldFPCmlCsU7gMUzPpQD6ojG/12R9GSFeVaCNEw8/8U=; b=UplWydbzR/FkZT3KfVIwTye2F4Kl04hEBYxPjv+AitPN3IUnsemSb8IHjSc42dUfjT UizpCXXEfu4wPlTi6B9cLqTnqbcbXe6qWTBbJCBbDe0nJivP8/twQxhsw8ll1MJRFu5J HexWxwR/hgttJU8ff02amWxxwmetWTtUY2YBccIvO4g/U/7kqq9hqecOqEuVWFqjllTG 1mXEuc28eicG+061Y7NLT5+Jk4x4uuIhOIFvoTq16YeFYC6FWnM0wFo+RnHwZ5JOALAU NFGUPDVkUkb4v05addz7ou6cs2DGSwG6WtkEL5fPVEqhz11EAi3Wl9cW+rX76jj4Ry7n OJGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HldFPCmlCsU7gMUzPpQD6ojG/12R9GSFeVaCNEw8/8U=; b=orAhEEwZKe9gleX1Omq+ER74ItEi1qKohzePeWLMmUCmWNoo6V0u/hFjSV4DXrjV38 XXx3DRHGUTXxSeNuV6VGLVYbU2lTUXO+TCfnZhcRXrogFhMYHVwQkkDprGQzIb8+xRnf Ec4ISVB1e1b4JRL0RQG1vAvHKYkoVhDJuM6c5ZY2/Gd1eJha415J/VXVSmOpC522cEJF QPdg+g3GpuiVYpw2q6xt3t55ac3m4p/TXXTmIMTMaOQCtLjZQFsU4t0U9MfHi09+jYDK L5UVgY/Wx210yu75jPpQgUzNzLboy+32E03vp8Bp17/q9DGgZIJmcieRHkafQIq+Hykj d3Fw== X-Gm-Message-State: APt69E2+l39SvacG4px3tGg4cL6nFmN1iqIzG0fZhloy9tbl0Ue0Vusa vS8rBi5HxHnDaz3iJGFjrg8TAI1fSYy+ec7QYBU= X-Google-Smtp-Source: ADUXVKKw/E4EKvmVUqgjcLrEfUnqrF7kQ2lBzuhtS0ogWo39TWYZISKzFAzDdL+Z7sE1/hYWsM14RoDqYkKWmFoykdw= X-Received: by 2002:ac8:683:: with SMTP id f3-v6mr16791509qth.104.1529436792174; Tue, 19 Jun 2018 12:33:12 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:24f0:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 12:33:11 -0700 (PDT) In-Reply-To: References: <1529339194.276412941@apps.rackspace.com> <1529361825.80979395@apps.rackspace.com> From: Dave Taht Date: Tue, 19 Jun 2018 12:33:11 -0700 Message-ID: To: "dpreed@deepplum.com" Cc: cerowrt-devel@lists.bufferbloat.net, bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:33:12 -0000 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 wrote: > I will be in D.C., presenting https://www.cs.kau.se/tohojo/cake/ - next w= eek. > > 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@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 bein= g >> 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, pushi= ng >> 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 befo= re >> Van Jacobson's early work, up to RED and ECN, all are based on providing >> congestion signalling sufficient to cause endpoints competing for resour= ces >> 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 crea= tion >> of "bloat" is a technical strategy that has been used in the past to des= troy >> VoIP and other real-time communicaitons. Microsoft was caught doing it >> decades ago, as were some other conflicted communicaitons providers. The= y >> 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 Neutralit= y. >> >> >> >> 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 free= dom >> 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 mechan= ism >> for eliminiating lag under load by eliminating queueing delay in bottlen= eck >> nodes. >> >> >> >> That's ultimately what Network Neutrality is about. There's a lot of ot= her >> crap being pushed by folks who pile on to the Network Neutrality discuss= ion. >> People want to "fix prices" for example, arguing that profits are bad. T= hose >> 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 Bufferblo= at. >> >> >> >> Comcast, on the other hand, has been slow-rolling DOCSIS 3.0, because th= eir >> customers on DOCSIS 2.0 are just ordering faster service tiers to overco= me >> the Bufferbloat in their DOCSIS 2 CMTS's. >> >> -----Original Message----- >> From: "Dave Taht" >> Sent: Monday, June 18, 2018 3:07pm >> To: "dpreed@deepplum.com" >> Cc: cerowrt-devel@lists.bufferbloat.net, "bloat" >> >> Subject: Re: Invisibility of bufferbloat and its remedies >> >> On Mon, Jun 18, 2018 at 9:26 AM, dpreed@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=3D2018&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 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 becomin= g >>> heavier users, because it is a shared buffering pool with no fairness o= r >>> 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 resolv= ing >>> 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=C3=A4ht >> CEO, TekLibre, LLC >> http://www.teklibre.com >> Tel: 1-669-226-2619 > > > > -- > > Dave T=C3=A4ht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619