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.t...@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, dpr...@deepplum.com > <dpr...@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.t...@gmail.com> >> Sent: Monday, June 18, 2018 3:07pm >> To: "dpr...@deepplum.com" <dpr...@deepplum.com> >> Cc: cerowrt-devel@lists.bufferbloat.net, "bloat" >> <bl...@lists.bufferbloat.net> >> Subject: Re: Invisibility of bufferbloat and its remedies >> >> On Mon, Jun 18, 2018 at 9:26 AM, dpr...@deepplum.com >> <dpr...@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 _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel