I have put this on a blog post, and my g+ also, here, and submitted the story to slashdot and reddit. How I spend my sunday afternoons these days! The linky version: http://the-edge.blogspot.com/2015/03/virgin-media-fixing-epidemic-of.html or g+: https://plus.google.com/u/0/107942175615993706558/posts/E1yMgbWW81C --snip snip-- To whom it may concern at Virgin Media: My IP address is apparently now banned from accessing your site at all, for "advertising", on this thread: http://community.virginmedia.com/t5/Up-to-152Mb/Bufferbloat-High-Latency-amp... Believe me, I understand the degree to which advertising pollutes the internet. And certainly, given the brevity of my post, you could assume that I was just some random guy, selling snake oil. Nothing could be further from the truth. Admittedly, it was a short message, it was kind of late, and I was in a hurry, being that I have so many other networks to help fix. To clarify matters: I am the co-founder of the bufferbloat project, and I like to think, a world-wide acknowledged expert on the topic on this thread. In particular, I worked pretty hard on part of the DOCSIS 3.1 standard, which was ratified years ago, and has a specific section on it regarding technologies that can help fix *half* your bufferbloat problem. http://www.cablelabs.com/how-docsis-3-1-reduces-latency-with-active-queue-ma... I admit to some frustration as to how long it is taking DOCSIS 3.1 to roll out. The cablelabs study that led up to the AQM component in the 3.1 standard - in which I participated and am cited in, is here: http://www.cablelabs.com/wp-content/uploads/2013/11/Active_Queue_Management_... And while I continue to favor fq_codel as the best solution for low and medium bandwidths - I have no problem with you somehow, soon, getting DOCSIS-pie out the door. If you continue to exist in denial of what your own R&D department for your own industry is saying, ghu help you! After giving this talk at uknof, the premier conference for network operators in the UK: https://plus.google.com/u/0/107942175615993706558/posts/immF8Pkj19C *over two years ago*, I met with 6+ technical members of Virgin Media's staff, who all agreed they had a problem, understood what it was, and grokked the various means to fix it. Judging from the enthusiasm in the room, I figured you'd be rolling out fixes by now, but was wrong. A rather human readable explanation of what has gone into the pending 3.1 standard is in the IETF internet draft here: https://datatracker.ietf.org/doc/draft-white-aqm-docsis-pie/ Sadly, just DOCSIS-pie rolling out on the modems is not enough - you have to somehow, yourselves, fix the dramatic overbuffering on the CMTS side, as shown here: http://burntchrome.blogspot.com/2014/05/disabling-shaping-in-one-direction-w... These downlink problems have been discussed thoroughly on the bufferbloat.net bloat and the ietf aqm mailing lists, and rather than point at direct links I would encourage more people to join the discussions there, and browse the archives. As I have seen no visible progress on the CMTS front yet... The best way to fix bufferbloat for your suffering customers *now*, is to help them - and your customer service departments - recognise the problem when it occurs and propose sane ways to fix it with stuff available off the shelf which includes the free firmware upgrades distributed by openwrt, or nearly any linux derived product and by the products available downstream from those. I have no financial interest in *free firmware*. I'm just trying to fix bufferbloat on a billion+ devices and nearly every network in the world as fast as humanly possible. Furthermore, me and a whole bunch of Internet luminaries gave the theory and code away for *free* also, in the hope that by doing so that might more quickly get the megacorps of the world to adopt them and make the quality of experience of internet access for billions of users of the world vastly better. Fixing bufferbloat was a 50 year old network research problem, now solved, with great joy, thoroughly, by some of the best minds in the business, and the answers are now so simple as to fit into a few hundred lines of code, easy to configure for end-users and easily embeddible in your own devices and networks if only you would get on the stick about it. We have provided the code, are in the standardization process, and provided free tools to diagnose and fix your epidemic bufferbloat accurately on every kind of device you have. Two examples of fixing bufferbloat on cablemodems: http://burntchrome.blogspot.com/2014/05/fixing-bufferbloat-on-comcasts-blast... http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html And the *free* tool designed not only to accurately measure bufferbloat, but one that you can setup internally to test your networks and devices for it privately and quietly and then fix them with, is here: https://github.com/tohojo/netperf-wrapper So, now, a rant: Now, if me pointing a customer of yours that has correctly identified the root cause of his own problems, at the solutions both available now, and pending, is considered "advertising", then there really is an orwellian mixup between the definition of that word, and the truth, on your side of the water. Please, unblock my dtaht account and unblock my IP, and allow in better information about how customers of yours can solve the incredibly serious, and incredibly epidemic problem of bufferbloat. ... A problem that is now easy to solve with cheap gear now all over the market so that all your customers suffering can fix it for themselves if they so choose. And: I would like a public apology for blocking me, and a clear statement from Virgin, as to how, when, and where, they will begin to roll out their own fixes to bufferbloat across their subscriber base. And perhaps, you could publish some guidelines - like accurate up/download settings to use - to help your customers fix your problems for themselves. Sincerely, Dave Taht Co-founder, bufferbloat.net -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb