Re: [Cerowrt-devel] [Bloat] Latency Measurements in Speed Test suites (was: DOCSIS 3+ recommendation?)

[Pedro Tumusok <pedro.tumusok@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 9214 bytes --]

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 <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 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
>
> 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 <support@speedtest.net> or open a ticket at:
> https://www.ookla.com/support
> - SpeedOfMe <contact@speedof.me>
> - TestMyNet <webmaster@testmy.net>
>
> 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 the
> Bufferbloat team.)
> http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat
>
> 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" <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"
> >> <Jason_Livingood@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,  <dpreed@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
> >>> 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
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> 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
>



-- 
Best regards / Mvh
Jan Pedro Tumusok

[-- Attachment #2: Type: text/html, Size: 12439 bytes --]