From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 885C221F26A; Sun, 29 Mar 2015 10:36:13 -0700 (PDT) Received: by lboc7 with SMTP id c7so36174983lbo.1; Sun, 29 Mar 2015 10:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tj1TOIPWOxoE1fuiX+6sOB6wTmzm9MhLJmNfriRLICI=; b=BnmRb9lmanflAMIFOZ8vFI9qt9eNqOyCYEwDZ2OsF1KSIJH1onar8aS+Uqd045vU8i VU/iIfgpz8Sjyi86BEpv1ujVW/dmpsBS8/+pxDJjKJKVEAC9BCSjbxqmxldhakl3opY2 RJ46VYV7ZdHGwujNpGA2xR8xhbWvUZUkOX0XhLjMNlJfpexHamLK+dxX92sLX7qtUm4o 5UUt8GhvxwzAB6U9VLzUGaAuWeS8eNH64MWOMGG0rhD9+jAuuFH0pOFoToWLXNIfRJzI vhlYCE9nxmXYo02/u/8BAnn1+xv1D2kHPjLL08jCbTSB/P2bV/37Jm8OHfagwB6x6RKA T6VQ== MIME-Version: 1.0 X-Received: by 10.112.92.66 with SMTP id ck2mr25404165lbb.105.1427650571183; Sun, 29 Mar 2015 10:36:11 -0700 (PDT) Received: by 10.114.200.73 with HTTP; Sun, 29 Mar 2015 10:36:11 -0700 (PDT) In-Reply-To: <5FD20B4A-A7E8-48C0-89F9-E2EB86DED8A6@gmail.com> 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> <5FD20B4A-A7E8-48C0-89F9-E2EB86DED8A6@gmail.com> Date: Sun, 29 Mar 2015 19:36:11 +0200 Message-ID: From: Pedro Tumusok To: Rich Brown Content-Type: multipart/alternative; boundary=001a113372b428aac7051270cd9e Cc: "dpreed@reed.com" , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Bloat] Latency Measurements in Speed Test suites (was: DOCSIS 3+ recommendation?) X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 17:36:42 -0000 --001a113372b428aac7051270cd9e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dslreports got a new speedtester up, anybody know Justin or some of the other people over there? http://www.dslreports.com/speedtest Maybe somebody on here could even lend a hand in getting them to implement features like ping under load etc. Pedro On Fri, Mar 20, 2015 at 2:50 PM, Rich Brown wrote= : > On Mar 19, 2015, at 7:18 PM, 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 statistic= s. > > 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 abo= ut > > as "sexy" as you are going to get with a network performance tool. > > > > -Greg > > Back in July, I contacted the support groups at Ookla, speedof.me, and > testmy.net, and all three responded, "Hmmm... We'll refer that to our > techies for review." and I never heard back. > > It seems to be hard to attract attention when there's only one voice > crying in the wilderness. It might be worth sending a note to: > > - Speedtest.net or open a ticket at: > https://www.ookla.com/support > - SpeedOfMe > - TestMyNet > > I append my (somewhat edited) note from July for your email drafting > pleasure. > > Rich > > --- Sample Letter --- > > Subject: Add latency measurements (min/max) > > I have been using NAME-OF-SERVICE for quite a while to measure my > network's performance. I had a couple thoughts that could make it more > useful to me and others who want to test their network. > > Your page currently displays a single "latency" value of the ping time > before the data transfers begin. It would be really helpful to report > real-time min/max latency measurements made *during the up and downloads*= . > > Why is latency interesting? Because when it's not well controlled, it > completely destroys people's internet for voice, gaming, other > time-sensitive traffic, and even everyday web browsing. As you may know, > many routers (home and otherwise) buffer more data than can be sent, and > this can dramatically affect latency for everyone using that router. > > I'm asking you to consider implementing the web-equivalent of the "Quick > Test for Bufferbloat" that's on the Bufferbloat site. (I'm a member of th= e > Bufferbloat team.) > http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferblo= at > > Please get back to me if you have questions. > > Many thanks! > > YOUR NAME > YOUR SIG > > --- end of sample --- > > > 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 resource= s > >> and management attention. The teams at Comcast in the engineering side > >> have been the leaders in "bufferbloat minimizing" work, and I think th= ey > >> 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 network= s, > >> 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 fi= x > >>>>> bufferbloat in their network within a year? > >>> > >>> I=C2=B9m not sure anyone ever said it=C2=B9d 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=C2=B9s face it - the problem= is > >>> complex and the software that has to be fixed is everywhere. As I sai= d > >>> about IPv6: if it were easy, it=C2=B9d 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=C2=B9ve underwritten some of Dave=C2=B9s work,= we got > >>> CableLabs to underwrite AQM work, and I personally pushed like heck t= o > >>> get > >>> AQM built into the default D3.1 spec (had CTO-level awareness & > support, > >>> and was due to Greg White=C2=B9s 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 tact= ic > >>> will always be a winner. > >>> > >>> As for existing D3.0 gear, it=C2=B9s 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=C2=B9d **love** a= n > >>> introduction to someone who has so I can get this info. > >>> > >>> But usually there are rational explanations for why something is stil= l > >>> 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 an= d > >>> 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 th= e > >>>> USA. > >>> > >>> I=C2=B9m not sure there are any forces against this issue. It=C2=B9s = more a > >>> question > >>> of awareness - it is not apparent it is more urgent than other work i= n > >>> everyone=C2=B9s backlog. For example, the number of ISP customers eve= n aware > >>> of > >>> buffer bloat is probably 0.001%; if customers aren=C2=B9t 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=C2= =B9s > >>> hard > >>> to make an =C5=92elevator pitch=C2=B9 about it. > >>> > >>> It reminds me a bit of IPv6 several years ago. Rather than saying in > >>> essence =C5=92you operators are dummies=C2=B9 for not already fixing = this, maybe > >>> assume the engineers all =C5=92get it=C2=B9 and what to do it. Becaus= e we really > >>> do > >>> get it and want to do something about it. Then ask those operators wh= at > >>> they need to convince their leadership and their suppliers and produc= t > >>> managers and whomever else that it needs to be resourced more > >>> effectively > >>> (see above for example). > >>> > >>> We=C2=B9re at least part of the way there in DOCSIS networks. It is i= n D3.1 > >>> by > >>> default, and we=C2=B9re starting trials now. And probably within 18-2= 4 > months > >>> we won=C2=B9t 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@lists.bufferbloat.net > >> https://lists.bufferbloat.net/listinfo/bloat > > > > _______________________________________________ > > Bloat mailing list > > Bloat@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/bloat > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --=20 Best regards / Mvh Jan Pedro Tumusok --001a113372b428aac7051270cd9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dslreports got a new speedtester up, anybody know Justin o= r some of the other people over there?

http://www.dslreports.com/speedtest

Maybe somebody on here could even lend a hand in getti= ng them to implement features like ping under load etc.


Pedro

=C2=A0

On Fri, Mar 20, 2015 at 2:50 P= M, Rich Brown <richb.hanover@gmail.com> wrote:
On Mar 19, 2015, at 7:18 PM, Greg White <g.white@CableLabs.= com> wrote:

> Netalyzr is great for network geeks, hardly consumer-friendly, and eve= n so
> the "network buffer measurements" part is buried in 150 othe= r statistics.
> Why couldn't Ookla* add a simultaneous "ping" test to th= eir throughput
> test?=C2=A0 When was the last time someone leaned on them?
>
>
> *I realize not everyone likes the Ookla tool, but it is popular and ab= out
> as "sexy" as you are going to get with a network performance= tool.
>
> -Greg

Back in July, I contacted the support groups at Ookla, speedof.me, and testmy.net, and all three responded, "Hmmm...= We'll refer that to our techies for review." and I never heard ba= ck.

It seems to be hard to attract attention when there's only one voice cr= ying in the wilderness. It might be worth sending a note to:

- Speedtest.net <support@speedt= est.net> or open a ticket at: https://www.ookla.com/support
- SpeedOfMe <contact@speedof.me>
- TestMyNet <webmaster@testmy.ne= t>

I append my (somewhat edited) note from July for your email drafting pleasu= re.

Rich

--- Sample Letter ---

Subject: Add latency measurements (min/max)

I have been using NAME-OF-SERVICE for quite a while to measure my network&#= 39;s performance. I had a couple thoughts that could make it more useful to= me and others who want to test their network.

Your page currently displays a single "latency" value of the ping= time before the data transfers begin. It would be really helpful to report= real-time min/max latency measurements made *during the up and downloads*.=

Why is latency interesting? Because when it's not well controlled, it c= ompletely destroys people's internet for voice, gaming, other time-sens= itive traffic, and even everyday web browsing. As you may know, many router= s (home and otherwise) buffer more data than can be sent, and this can dram= atically affect latency for everyone using that router.

I'm asking you to consider implementing the web-equivalent of the "= ;Quick Test for Bufferbloat" that's on the Bufferbloat site. (I= 9;m a member of the Bufferbloat team.) http:= //www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat<= br>
Please get back to me if you have questions.

Many thanks!

YOUR NAME
YOUR SIG

--- end of sample ---

> On 3/19/15, 2:29 PM, "dpreed@r= eed.com" <dpreed@reed.com> wrote:
>
>> I do think engineers operating networks get it, and that Comcast&#= 39;s
>> engineers really get it, as I clarified in my followup note.
>>
>> The issue is indeed prioritization of investment, engineering reso= urces
>> 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 iss= ue, 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 th= is 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 net= works,
>> 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:=C2=A0 the result= s are not
>> "sexy enough for stupid users" and also "no one wil= l care".
>>
>> I think the reaction characterizes the problem correctly - but the= second
>> part is the most serious objection.=C2=A0 People don't need a = measurement
>> tool, they need to know that this is why their home network sucks<= br> >> sometimes.
>>
>>
>>
>>
>>
>> On Thursday, March 19, 2015 3:58pm, "Livingood, Jason" >> <Jason_Liv= ingood@cable.comcast.com> said:
>>
>>> On 3/19/15, 1:11 PM, "Dave Taht" <dave.taht@gmail.com> wrote:
>>>
>>>> On Thu, Mar 19, 2015 at 6:53 AM,=C2=A0 <dpreed@reed.com> wrote:
>>>>> How many years has it been since Comcast said they wer= e going to fix
>>>>> bufferbloat in their network within a year?
>>>
>>> I=C2=B9m not sure anyone ever said it=C2=B9d take a year. If s= omeone 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=C2=B9s face it - the = problem is
>>> complex and the software that has to be fixed is everywhere. A= s I said
>>> about IPv6: if it were easy, it=C2=B9d be done by now. ;-)
>>>
>>>>> It's almost as if the cable companies don't wa= nt OTT video or
>>>>> simultaneous FTP and interactive gaming to work. Of co= urse not. They'd
>>>>> never do that.
>>>
>>> Sorry, but that seems a bit unfair. It flies in the face of wh= at we have
>>> done and are doing. We=C2=B9ve underwritten some of Dave=C2=B9= 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=C2=B9s work at CableLabs). We are st= arting to field
>>> test D3.1 gear now, by the way. We made some bad bets too, suc= h as
>>> trying
>>> to underwrite an OpenWRT-related program with ISC, but not eve= ry tactic
>>> will always be a winner.
>>>
>>> As for existing D3.0 gear, it=C2=B9s not for lack of trying. H= as any DOCSIS
>>> network of any scale in the world solved it? If so, I have som= ething to
>>> use to learn from and apply here at Comcast - and I=C2=B9d **l= ove** 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 ca= se of
>>> prioritization - meaning things like running out of IPv4 addre= sses 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, especi= ally in the
>>>> USA.
>>>
>>> I=C2=B9m not sure there are any forces against this issue. It= =C2=B9s more a
>>> question
>>> of awareness - it is not apparent it is more urgent than other= work in
>>> everyone=C2=B9s backlog. For example, the number of ISP custom= ers even aware
>>> of
>>> buffer bloat is probably 0.001%; if customers aren=C2=B9t aski= ng for it, the
>>> product managers have a tough time arguing to prioritize buffe= r 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 t= hat you
>>> could get people to run as they do speed tests today. (If some= one thinks
>>> they can actually deliver this, I will try to fund it - ping m= e
>>> off-list.)
>>> I also think a better job can be done explaining buffer bloat = - it=C2=B9s
>>> hard
>>> to make an =C5=92elevator pitch=C2=B9 about it.
>>>
>>> It reminds me a bit of IPv6 several years ago. Rather than say= ing in
>>> essence =C5=92you operators are dummies=C2=B9 for not already = fixing this, maybe
>>> assume the engineers all =C5=92get it=C2=B9 and what to do it.= Because we really
>>> do
>>> get it and want to do something about it. Then ask those opera= tors what
>>> they need to convince their leadership and their suppliers and= product
>>> managers and whomever else that it needs to be resourced more<= br> >>> effectively
>>> (see above for example).
>>>
>>> We=C2=B9re at least part of the way there in DOCSIS networks. = It is in D3.1
>>> by
>>> default, and we=C2=B9re starting trials now. And probably with= in 18-24 months
>>> we won=C2=B9t 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@lists.bufferb= loat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat= .net
> https://lists.bufferbloat.net/listinfo/bloat

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/bloat



--
Best regards / Mvh
Jan Pedro Tumusok

--001a113372b428aac7051270cd9e--