<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 19, 2015 at 3:58 PM, Livingood, Jason <span dir="ltr"><<a href="mailto:Jason_Livingood@cable.comcast.com" target="_blank">Jason_Livingood@cable.comcast.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 3/19/15, 1:11 PM, "Dave Taht" <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
<br>
>On Thu, Mar 19, 2015 at 6:53 AM,  <<a href="mailto:dpreed@reed.com">dpreed@reed.com</a>> wrote:<br>
>> How many years has it been since Comcast said they were going to fix<br>
>>bufferbloat in their network within a year?<br>
<br>
</span>I¹m not sure anyone ever said it¹d take a year. If someone did (even if it<br>
was me) then it was in the days when the problem appeared less complicated<br>
than it is and I apologize for that. Let¹s face it - the problem is<br>
complex and the software that has to be fixed is everywhere. As I said<br>
about IPv6: if it were easy, it¹d be done by now. ;-)<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small;display:inline">​I think this was the hope that the buffer size control feature in Docsis could at least be used to cut bufferbloat down to the "traditional" 100ms level, as I remember the sequence of events.  But reality intervened: buggy implementations by too many vendors, is what I remember hearing from Rich Woundy.</div></div><div><div class="gmail_default" style="font-size:small;display:inline">​</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
>>It's almost as if the cable companies don't want OTT video or<br>
>>simultaneous FTP and interactive gaming to work. Of course not. They'd<br>
>>never do that.<br>
<br>
</span>Sorry, but that seems a bit unfair. It flies in the face of what we have<br>
done and are doing. We¹ve underwritten some of Dave¹s work, we got<br>
CableLabs to underwrite AQM work, and I personally pushed like heck to get<br>
AQM built into the default D3.1 spec (had CTO-level awareness & support,<br>
and was due to Greg White¹s work at CableLabs). We are starting to field<br>
test D3.1 gear now, by the way. We made some bad bets too, such as trying<br>
to underwrite an OpenWRT-related program with ISC, but not every tactic<br>
will always be a winner.<br>
<br>
As for existing D3.0 gear, it¹s not for lack of trying. Has any DOCSIS<br>
network of any scale in the world solved it? If so, I have something to<br>
use to learn from and apply here at Comcast - and I¹d **love** an<br>
introduction to someone who has so I can get this info.<br>
<br>
But usually there are rational explanations for why something is still not<br>
done. One of them is that the at-scale operational issues are more<br>
complicated that some people realize. And there is always a case of<br>
prioritization - meaning things like running out of IPv4 addresses and not<br>
having service trump more subtle things like buffer bloat (and the effort<br>
to get vendors to support v6 has been tremendous).<br>
<span class=""><br>
>I do understand there are strong forces against us, especially in the USA.<br>
<br>
</span>I¹m not sure there are any forces against this issue. It¹s more a question<br>
of awareness - it is not apparent it is more urgent than other work in<br>
everyone¹s backlog. For example, the number of ISP customers even aware of<br>
buffer bloat is probably 0.001%; if customers aren¹t asking for it, the<br>
product managers have a tough time arguing to prioritize buffer bloat work<br>
over new feature X or Y.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small;display:inline">​I agree with Jason on this one.  We have to take bufferbloat mainstream to generate "market pull". I've been reluctant in the past before we had solutions in hand: very early in this quest, Dave Clark noted:</div></div><div><div class="gmail_default" style="font-size:small">​"Yelling fire without having the exits marked" could be counter productive.  I think we have the exits marked now.  Time to yell "Fire".</div></div><div><div class="gmail_default" style="font-size:small;display:inline"><br></div></div><div><div class="gmail_default" style="font-size:small;display:inline">Even when you get to engineers in the organizations who build the equipment, it's hard.  First you have to explain that "more is not better", and "some packet loss is good for you".</div></div><div><div class="gmail_default" style="font-size:small;display:inline"><br></div></div><div><div class="gmail_default" style="font-size:small;display:inline">Day to day market pressures for other features mean that:</div></div><div><div class="gmail_default" style="font-size:small;display:inline">  1) many/most of the engineers</div> <div class="gmail_default" style="font-size:small;display:inline">​don't see that ​as what they need to do in the next quarter/year.</div></div><div><div class="gmail_default" style="font-size:small;display:inline">  2) their management don't see that working on it should take any of their time.  It won't help them sell the next set of gear.</div></div><div><div class="gmail_default" style="font-size:small;display:inline"><br></div></div><div><div class="gmail_default" style="font-size:small;display:inline">***So we have to generate demand from the market.***</div></div><div><div class="gmail_default" style="font-size:small;display:inline"><br></div></div><div><div class="gmail_default" style="font-size:small;display:inline">Now, I can see a couple ways to do this:</div></div><div><div class="gmail_default" style="font-size:small;display:inline"><br></div></div><div><div class="gmail_default" style="font-size:small;display:inline">1) help expose the problem, preferably in a dead simple way that everyone sees.  If we can get Ookla to add a simple test to their test system, this would be a good start.  If not, other test sites are needed.  Nice as Netalyzer is, it a) tops out around 20Mbps, and b) buries the buffering results among 50 other numbers.</div></div><div><div class="gmail_default" style="font-size:small;display:inline">2) Markets such as gaming are large, and very latency sensitive.  Even better, lots of geeks hang out there.  So investing in educating that submarket may help pull things through the system overall.</div></div><div><div class="gmail_default" style="font-size:small;display:inline">3) Competitive pressures can be very helpful: but this requires at least one significant player in each product category to "get it".  So these are currently slow falling dominoes.</div></div><div><div class="gmail_default" style="font-size:small;display:inline"><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
One suggestion I have made to increase awareness is that there be a nice,<br>
web-based, consumer-friendly latency under load / bloat test that you<br>
could get people to run as they do speed tests today. (If someone thinks<br>
they can actually deliver this, I will try to fund it - ping me off-list.)<br>
I also think a better job can be done explaining buffer bloat - it¹s hard<br>
to make an Œelevator pitch¹ about it.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small;display:inline">​Yeah, the elevator pitch is hard, since a number of things around bufferbloat are counter intuitive. I know, I've tried, and not really succeeded.  The best kinds of metaphors have been traffic related ("building parking lots at all the bottlenecks"),  and explanations like "packet loss is how the Internet enforces speed limits" <a href="http://www.circleid.com/posts/20150228_packet_loss_how_the_internet_enforces_speed_limits/">http://www.circleid.com/posts/20150228_packet_loss_how_the_internet_enforces_speed_limits/</a>.</div></div><div><div class="gmail_default" style="font-size:small;display:inline">​</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
It reminds me a bit of IPv6 several years ago. Rather than saying in<br>
essence Œyou operators are dummies¹ for not already fixing this, maybe<br>
assume the engineers all Œget it¹ and what to do it.</blockquote><div><br></div><div><div class="gmail_default" style="font-size:small;display:inline">​Many/most practicing engineers are still unaware of it, or if they have heard the word bufferbloat, still don't "get it" that they see bufferbloat's effects all the time.</div></div><div><div class="gmail_default" style="font-size:small;display:inline">​</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Because we really do<br>
get it and want to do something about it. Then ask those operators what<br>
they need to convince their leadership and their suppliers and product<br>
managers and whomever else that it needs to be resourced more effectively<br>
(see above for example).<br>
<br>
We¹re at least part of the way there in DOCSIS networks. It is in D3.1 by<br>
default, and we¹re starting trials now. And probably within 18-24 months<br>
we won¹t buy any DOCSIS CPE that is not 3.1.<br>
<br>
The question for me is how and when to address it in DOCSIS 3.0.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small;display:inline">​We should talk at IETF.</div></div><div><div class="gmail_default" style="font-size:small;display:inline">​</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
- Jason<br>
</font></span><div class=""><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</div></div></blockquote></div><br></div></div>