From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 629303B2A4; Mon, 18 Jun 2018 21:46:20 -0400 (EDT) Received: by mail-qt0-x242.google.com with SMTP id y89-v6so17015268qtd.10; Mon, 18 Jun 2018 18:46:20 -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=3h19SZk90/AVACGSc4DHAodZDNjRQl3EvpxXkFVq+KA=; b=vUNCsvOatKzvmb4azETBEYbMI7nP1ZLN47pVuU7EgQ0rTa00qSoK6I6gXLowmL51/I tJYEnXiqgVB86LJEnB7XsYaesXRBapyDC4wAQCfS5iiYbIatzIDuNnWUh6kjfk9HqPK2 uEYK7hC1sYtwZriZl/xU5TPva7vGbbpkUjzIbdxxNKDyfbXnk1lMnPKZ4u6tillpcLop oqNmvarLzkbX2oo+gW0pf88PhCVT3a28W5JSY5bozgXpXwEga+La56CZlroGwYLRIUt9 af9IaYjFrvgBvmj4ndgpGsonCi2TaRKqImxANcINfauSCCt+3hhOX64N8kAWkgLDRI/q VI3Q== 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=3h19SZk90/AVACGSc4DHAodZDNjRQl3EvpxXkFVq+KA=; b=IHCoJjz0n4BaTX6NFqKH+IZ5+gk8wz8b0S7JZi7RAiAiGoVsLYDrcYS0yazi1hM1pJ 3rZRMTkMWMa7kBHe3VrNQXiOem8cQRQ47L9W7cerQvHUfGhFMekmQ0UTV39PE1GZJnSx VG51MRqxKtlwkna5jCbmjxqoFKXRl6JAXpAmhZwPbcNcwTDoBRU8LjewwOxcLKuGFlTv 54tigehLf36bnGb0nu7CNGjn5GTfv3Nu7mgP7Cj7zYlJD4eIHg6AH5SDkr7BCF5PJBhT J+1MErpIwxXn37j6v0aZQqYWJOZBEmJE0CjWFLvGNp8uat5J6xEpxWsfmLkqs/7ohfxH VHBQ== X-Gm-Message-State: APt69E31S+IeJu2/WJHHRSEDcGB9iabwVIk1ToXLv2orhiADkC3S+7gZ R/b81vuH++LIdSv/9g+pnyxICNitWWHKSVdH8rVm6A== X-Google-Smtp-Source: ADUXVKJwUPcRhLLYhOphv5B6WjEEI1o2pglU1cTRNgQlL1frbcfbdnFPXT1E9u0lP6nXUJ6ypkqfkNHw5mICaho+TVM= X-Received: by 2002:ac8:33cf:: with SMTP id d15-v6mr13640969qtb.261.1529372779800; Mon, 18 Jun 2018 18:46:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:24f0:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 18:46:18 -0700 (PDT) In-Reply-To: <1529361825.80979395@apps.rackspace.com> References: <1529339194.276412941@apps.rackspace.com> <1529361825.80979395@apps.rackspace.com> From: Dave Taht Date: Mon, 18 Jun 2018 18:46:18 -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 01:46:20 -0000 I will be in D.C., presenting https://www.cs.kau.se/tohojo/cake/ - next wee= k. 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 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, pushin= g > 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 befor= e > Van Jacobson's early work, up to RED and ECN, all are based on providing > congestion signalling sufficient to cause endpoints competing for resourc= es > 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 creat= ion > of "bloat" is a technical strategy that has been used in the past to dest= roy > 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 f= ull > 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 freed= om > 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 mechani= sm > for eliminiating lag under load by eliminating queueing delay in bottlene= ck > nodes. > > > > That's ultimately what Network Neutrality is about. There's a lot of oth= er > 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. Th= ose > guys are not the problem. > > > > The problem is that the vertically integrated monopolists want to claim t= hat > 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 Bufferbloa= t. > > > > Comcast, on the other hand, has been slow-rolling DOCSIS 3.0, because the= ir > customers on DOCSIS 2.0 are just ordering faster service tiers to overcom= e > 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 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 o= f >> 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 resolvi= ng >> 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 --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619