[Bloat] [aqm] ping loss "considered harmful"

Dave Taht dave.taht at gmail.com
Mon Mar 2 17:15:59 EST 2015

On Mon, Mar 2, 2015 at 12:48 PM, Bill Ver Steeg (versteb) <versteb at cisco.com
> wrote:

> While I do not formally speak for “a big vendor” in this (or any) context,
> I do happen to work for one.
> There are several efforts underway within this particular big vendor to
> address bloat. Are these efforts crash programs to get code out the door as
> fast as humanly possible? No. There are efforts underway, though. These
> things take time…… To be frank, the best way to drive feature
> development/deployment/adoption in most big companies is to have customers
> ask for them.

Creating understanding and demand has been my nearly f/t project for
several years now. I hope it is finally starting to work!

However, along the way - in trying to work with everybody in all parts of
the industry, and to "get along" - I found myself in a deep moral and
mental hole where I realized I was no longer being true to myself or being
effective in what I had really set out to do by attempting to create this
open, shared project, where I had hoped we all would be working together
for a common goal.

It was probably the gogo-in-flight test results with a *total lack of ping
loss* and *12 minutes of latency* that set me off in the beginning... here
are some pings from the middle of the test:

64 bytes from :elided: icmp_seq=5108 ttl=42 time=144333 ms
64 bytes from :elided: icmp_seq=5109 ttl=42 time=143335 ms
64 bytes from :elided: icmp_seq=5110 ttl=42 time=142327 ms
64 bytes from :elided: icmp_seq=5111 ttl=42 time=141319 ms
64 bytes from :elided: icmp_seq=5113 ttl=42 time=139311 ms

netperf-wrapper results and the ping log of the flight as it went towards
landing are here:


of the actual remaining throughput and latency on the aircraft, after a
test had completed (sort of), and another started:

(netperf-wrapper was not designed to deal with RTTs greater than from here
to mars, so
the plot doesn't make much sense! The pings don't fit right! But the
bandwidth is *gone*)

Gogo-in-flight, at least, could use a crash program to fix their
bufferbloat! I know that adding a 50 dollar openwrt box or upgrading their
software would probably cost a lot in regulatory approvals, but gawd!!! 12
minutes of latency! A total collapse of their network! From a simple test!
And despite trying through every channel I could, I have not found anyone
there with an IQ above 80 to talk to about how to dramatically fix their
own services. They make their money from selling the service, not,
actually, in providing it, in a totally captive market.

And at some point, you just have to laugh - as I did when I called them
out, and gave them the finger, at nznog.

And my inspiration, for what basically has caused me to rear back, and
start saying and doing exactly what I think, *all the time*, a few weeks
ago, here and on the internet, in words that that were utterly clear, short
and simple, was George Carlin's piece, here:


It is NSFW, but I do find clearing the air, has been useful, and I hope
everyone here, laughs their collective arses off at this!

I will write more tomorrow, I'm done today. I have *severe trust issues*
where your company is concerned, and I will detail why, tomorrow, publicly,
if I can filter out the cuss words and be at least reasonably polite about

> We are actually starting to see broader awareness of the problem at the SP
> network edge, and this is probably where we need solutions the fastest.
> There have been some gap-filler changes in the HFC space recently, and the
> next generation CMTS products will have a quite robust solution. As noted
> previously, the CPE and the DSLAMs will also need to be addressed.
> Unfortunately (perhaps fortunately to some folks on this list…. but I
> digress), the company I work for is no longer in these parts of the
> business, as we sold off the Linksys group off a few years ago and got out
> of the DSLAM business many years ago. I do still have some contacts in the
> chipset vendor community in the CPE space, and could help drive awareness
> if it would help. As most of us understand, the chipset vendors have a lot
> clout in this area - as they supply most of the heavy lifting code to the
> OEM/ODM CPE folks for their commercial offers. The open source community is
> currently ahead of the chipset folks and the OEM/ODM folks in this space.
> So, IMHO the best way to make progress in the CPE arena is to get the
> chipset vendors to provide a robust AQM scheme in their default drivers.
> There may have to be some tweaks to get a given algorithm to work in a
> given chipset/memory/CPU architecture. In fact, there may be room for
> algorithms that take advantage of features of a given chipset, or to design
> a new chipset that “does the right thing” in uCode.  If I were a consultant
> – this is where I would focus my efforts……….
> I am not sure how to crack the DSLAM egg, though. Different set of
> players, different set of initial conditions.
> Bill VerSteeg
> *From:* bloat-bounces at lists.bufferbloat.net [mailto:
> bloat-bounces at lists.bufferbloat.net] *On Behalf Of *Jonathan Morton
> *Sent:* Monday, March 02, 2015 2:42 PM
> *To:* Kathleen Nichols
> *Cc:* bloat
> *Subject:* Re: [Bloat] [aqm] ping loss "considered harmful"
> Probably the least cynical answer to that I can come up with is the hope
> that big vendors get a clue that this stuff is needed, and start hiring
> field experts as consultants to help them get it right.
> You can stop snickering now.
> Another possibility is that some of us have to club together and make our
> own hardware that Does The Right Thing, possibly still based on one of the
> generic reference hardware platforms, if we can find one that we like and
> is cheap enough to compete. Which, once again, would take care of the CPE
> problem but practically nothing else, unless we somehow managed to get a
> foot in the door of the DSLAM market. Which is about as likely as the
> Prince of Darkness taking a skiing holiday at home.
> - Jonathan Morton
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Dave Täht
Let's make wifi fast, less jittery and reliable again!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20150302/884e704f/attachment-0003.html>

More information about the Bloat mailing list