<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">I don't know.<br>
      From my personal experience, I feel like the "expert" wearing ties
      <br>
      watch the speed meter and the needle moving across the red bar.<br>
      <br>
      We just need to be sure about the colors: when the latency goes
      into the crazy region<br>
      the needle has to cross a RED bar! GREEN is good, RED is bad
      (exceptions apply in case of daltonism).<br>
      <br>
      Maybe I'm oversimplifying... but not that much...<br>
      <br>
      If your solution is to educate people with ties on Internet
      congestion control I feel bad...<br>
      <br>
      Luca<br>
      <br>
      <br>
      On 03/20/2015 02:31 PM, David P. Reed wrote:<br>
    </div>
    <blockquote cite="mid:e8b29dbd-287e-46bf-b9bd-66ae04e21a41@reed.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      The mystery in most users' minds is that ping at a time when there
      is no load does tell them anything at all about why the network
      connection will such when their kid is uploading to youtube.<br
        clear="none">
      <br clear="none">
      So giving them ping time is meaningless. <br clear="none">
      I think most network engineers think ping time is a useful measure
      of a badly bufferbloated system. It is not.<br clear="none">
      <br clear="none">
      The only measure is ping time under maximum load of raw packets.<br
        clear="none">
      <br clear="none">
      And that requires a way to test maximum load rtt.<br clear="none">
      <br clear="none">
      There is no problem with that ... other than that to understand
      why and how that is relevant you have to understand Internet
      congestion control.  <br clear="none">
      <br clear="none">
      Having had to testify before CRTC about this, I learned that most
      access providers (the Canadian ones) claim that such measurements
      are never made as a measure of quality, and that you can calculate
      expected latency by using Little's lemma from average throughput.
      And that dropped packets are the right measure of quality of
      service.<br clear="none">
      <br clear="none">
      Ookla ping time  is useless in a context where even the "experts"
      wearing ties from the top grossing Internet firms are so confused.
      And maybe deliberately misleading on purpose... they had to be
      forced to provide any data they had about  congestion in their
      networks by a ruling during the proceeding and then responded that
      they had no data - they never measured queueing delay and disputed
      that it mattered. The proper measure of congestion was throughput.<br
        clear="none">
      <br clear="none">
      I kid you not.<br clear="none">
      <br clear="none">
      So Ookla ping time is useless against such public ignorance. <br
        clear="none">
      <br clear="none">
      <br clear="none">
      <br clear="none">
      That's completely wrong for  <br clear="none">
      <br clear="none">
      <div class="gmail_quote">On Mar 20, 2015, MUSCARIELLO Luca IMT/OLN
        <a class="moz-txt-link-rfc2396E" href="mailto:luca.muscariello@orange.com"><luca.muscariello@orange.com></a> wrote:
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <pre class="k10mail">I agree. Having that ping included in Ookla would help a lot more

Luca


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