From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by huchra.bufferbloat.net (Postfix) with ESMTP id A462321F38A; Fri, 20 Mar 2015 01:18:38 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 72382DE4004; Fri, 20 Mar 2015 09:18:35 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 65CB7DE4003; Fri, 20 Mar 2015 09:18:35 +0100 (CET) Received: from [10.193.161.225] (10.193.161.225) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.224.2; Fri, 20 Mar 2015 09:18:34 +0100 Message-ID: <550BD7DB.3040408@orange.com> Date: Fri, 20 Mar 2015 09:18:35 +0100 From: MUSCARIELLO Luca IMT/OLN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Greg White , "dpreed@reed.com" , "Livingood, Jason" References: <20150316203532.05BD21E2@taggart.lackof.org> <123130.1426635142@turing-police.cc.vt.edu> <15A0911A-E3B7-440A-A26B-C5E1489EA98B@viagenie.ca> <1426773234.362612992@apps.rackspace.com> <1426796961.194223197@apps.rackspace.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 20 Mar 2015 01:24:43 -0700 Cc: "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: MUSCARIELLO Luca IMT/OLN List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 08:19:07 -0000 I agree. Having that ping included in Ookla would help a lot more Luca On 03/20/2015 12:18 AM, Greg White wrote: > 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. > > -Greg > > > > On 3/19/15, 2:29 PM, "dpreed@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 >> sometimes. >> >> >> >> >> >> On Thursday, March 19, 2015 3:58pm, "Livingood, Jason" >> said: >> >>> On 3/19/15, 1:11 PM, "Dave Taht" wrote: >>> >>>> On Thu, Mar 19, 2015 at 6:53 AM, 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 >>> complicated >>> 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 >>> get >>> 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 >>> trying >>> 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 >>> not >>> 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 >>> not >>> having service trump more subtle things like buffer bloat (and the >>> effort >>> to get vendors to support v6 has been tremendous). >>> >>>> I do understand there are strong forces against us, especially in the >>>> USA. >>> 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 >>> of >>> 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 >>> work >>> over new feature X or Y. >>> >>> One suggestion I have made to increase awareness is that there be a >>> nice, >>> 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 >>> off-list.) >>> I also think a better job can be done explaining buffer bloat - it¹s >>> hard >>> 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 >>> effectively >>> (see above for example). >>> >>> We¹re at least part of the way there in DOCSIS networks. It is in D3.1 >>> by >>> 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 >>> >>> >>> >>> >>