[Bloat] [Cerowrt-devel] DOCSIS 3+ recommendation?

Greg White g.white at CableLabs.com
Thu Mar 19 19:18:10 EDT 2015

Netalyzr is great for network geeks, hardly consumer-friendly, and even so
the "network buffer measurements" part is buried in 150 other statistics.
Why couldn't Ookla* add a simultaneous "ping" test to their throughput
test?  When was the last time someone leaned on them?

*I realize not everyone likes the Ookla tool, but it is popular and about
as "sexy" as you are going to get with a network performance tool.


On 3/19/15, 2:29 PM, "dpreed at reed.com" <dpreed at reed.com> wrote:

>I do think engineers operating networks get it, and that Comcast's
>engineers really get it, as I clarified in my followup note.
>The issue is indeed prioritization of investment, engineering resources
>and management attention. The teams at Comcast in the engineering side
>have been the leaders in "bufferbloat minimizing" work, and I think they
>should get more recognition for that.
>I disagree a little bit about not having a test that shows the issue, and
>the value the test would have in demonstrating the issue to users.
>Netalyzer has been doing an amazing job on this since before the
>bufferbloat term was invented. Every time I've talked about this issue
>I've suggested running Netalyzer, so I have a personal set of comments
>from people all over the world who run Netalyzer on their home networks,
>on hotel networks, etc.
>When I have brought up these measurements from Netalyzr (which are not
>aimed at showing the problem as users experience) I observe an
>interesting reaction from many industry insiders:  the results are not
>"sexy enough for stupid users" and also "no one will care".
>I think the reaction characterizes the problem correctly - but the second
>part is the most serious objection.  People don't need a measurement
>tool, they need to know that this is why their home network sucks
>On Thursday, March 19, 2015 3:58pm, "Livingood, Jason"
><Jason_Livingood at cable.comcast.com> said:
>> On 3/19/15, 1:11 PM, "Dave Taht" <dave.taht at gmail.com> wrote:
>>>On Thu, Mar 19, 2015 at 6:53 AM,  <dpreed at reed.com> wrote:
>>>> How many years has it been since Comcast said they were going to fix
>>>>bufferbloat in their network within a year?
>> I¹m not sure anyone ever said it¹d take a year. If someone did (even if
>> it
>> was me) then it was in the days when the problem appeared less
>> than it is and I apologize for that. Let¹s face it - the problem is
>> complex and the software that has to be fixed is everywhere. As I said
>> about IPv6: if it were easy, it¹d be done by now. ;-)
>>>>It's almost as if the cable companies don't want OTT video or
>>>>simultaneous FTP and interactive gaming to work. Of course not. They'd
>>>>never do that.
>> Sorry, but that seems a bit unfair. It flies in the face of what we have
>> done and are doing. We¹ve underwritten some of Dave¹s work, we got
>> CableLabs to underwrite AQM work, and I personally pushed like heck to
>> AQM built into the default D3.1 spec (had CTO-level awareness & support,
>> and was due to Greg White¹s work at CableLabs). We are starting to field
>> test D3.1 gear now, by the way. We made some bad bets too, such as
>> to underwrite an OpenWRT-related program with ISC, but not every tactic
>> will always be a winner.
>> As for existing D3.0 gear, it¹s not for lack of trying. Has any DOCSIS
>> network of any scale in the world solved it? If so, I have something to
>> use to learn from and apply here at Comcast - and I¹d **love** an
>> introduction to someone who has so I can get this info.
>> But usually there are rational explanations for why something is still
>> done. One of them is that the at-scale operational issues are more
>> complicated that some people realize. And there is always a case of
>> prioritization - meaning things like running out of IPv4 addresses and
>> having service trump more subtle things like buffer bloat (and the
>> to get vendors to support v6 has been tremendous).
>>>I do understand there are strong forces against us, especially in the
>> I¹m not sure there are any forces against this issue. It¹s more a
>> question
>> of awareness - it is not apparent it is more urgent than other work in
>> everyone¹s backlog. For example, the number of ISP customers even aware
>> buffer bloat is probably 0.001%; if customers aren¹t asking for it, the
>> product managers have a tough time arguing to prioritize buffer bloat
>> over new feature X or Y.
>> One suggestion I have made to increase awareness is that there be a
>> web-based, consumer-friendly latency under load / bloat test that you
>> could get people to run as they do speed tests today. (If someone thinks
>> they can actually deliver this, I will try to fund it - ping me
>> I also think a better job can be done explaining buffer bloat - it¹s
>> to make an Œelevator pitch¹ about it.
>> It reminds me a bit of IPv6 several years ago. Rather than saying in
>> essence Œyou operators are dummies¹ for not already fixing this, maybe
>> assume the engineers all Œget it¹ and what to do it. Because we really
>> do
>> get it and want to do something about it. Then ask those operators what
>> they need to convince their leadership and their suppliers and product
>> managers and whomever else that it needs to be resourced more
>> (see above for example).
>> We¹re at least part of the way there in DOCSIS networks. It is in D3.1
>> default, and we¹re starting trials now. And probably within 18-24 months
>> we won¹t buy any DOCSIS CPE that is not 3.1.
>> The question for me is how and when to address it in DOCSIS 3.0.
>> - Jason
>Bloat mailing list
>Bloat at lists.bufferbloat.net

More information about the Bloat mailing list