UPDATE: After I made very big stink about this here, on g+, and slashdot and multiple mailing lists, I received a private email this morning from Virgin Media telling me my access to their community forums had been restored. I hope that one piece of fallout from creating this controversy about the terribly slow ISP industry progress towards recognising and fixing their bufferbloat, that now a constructive dialog can now ensue. As in the past, and in the future, I will attempt to do my best to help Virgin (and the rest of the cable and dsp and fiber ISPs, and the makers of their chipsets, and CPE) provide better information about how to fix their bufferbloat to their customers... and continue to help get the fixes more widely distributed - and into more firmware... after I wake up! - yesterday was a very stressful day for me. Thank you all for amplifying my concerns and to whoever found the right person at Virgin to address my issue - THANK YOU VERY MUCH!

Btw, this song, You gotta be loud from the wonderful musical, Matilda, ran through my head all day, yesterday. It simply drips with irony and sarcasm in the context of the play. It is very, very British, and I have a lot of empathy for the travails of the main character. If you haven't seen the play, you should. I went to see it each of the last 3 times I was in London.

But! to preserve all the information I put out here originally remains important! So the original post, remains below:

...

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 about bufferbloat... and my post, was deleted. For the record, that url was:

http://community.virginmedia.com/t5/Up-to-152Mb/Bufferbloat-High-Latency-amp-packet-loss-when-connection/td-p/2773495

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 cable industry's 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.

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 PIE AQM component in the 3.1 standard - in which I participated and am cited in, is here.

I happen to prefer the fq_codel based solution as that works better on most traffic, but am perfectly happy to see PIE get deployed.

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 23 minute talk at uknof, the premier conference for network operators in the UK  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 they all 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 I was wrong.

A rather human readable explanation of what has gone into the pending 3.1  standard is in the IETF DOCSIS-PIE internet draft here.

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 in tests done on comcast's cablemodems in the USA with typical results in the 240-800 millisecond range.


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... and no acknowlegment or visible understanding that you get it yet...

The best way to fix bufferbloat for your long-suffering customers for the past 3 years, is to help them - and your customer service departments - recognize the latency and bad performance bufferbloat causes when it occurs and propose sane ways to fix it with stuff available off the shelf which includes the free firmware upgrades for thousands of home routers distributed by openwrt, or nearly any Linux derived product  available downstream from those manufacturers that have bothered to keep up with the times.

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, several different ways, 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 embeddable 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 have provided free tools to diagnose and fix your epidemic bufferbloat accurately on every kind of device you and your customers have.

Here are two actual examples of fixing bufferbloat on cablemodems without needing to upgrade the modem or CMTS.

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 without publicity - and then fix them! is here:

https://github.com/tohojo/netperf-wrapper

So, now, a rant: