<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There is rarely a one sized fits all answer when it comes to these things.   <br></blockquote><div><br></div><div>Absolutely true: every application has characteristic QoS parameters.</div><div><br></div><div>Unfortunately, it seems that 5-minute averages of data rates through links are the one-size-fits-all answer ... which doesn't fit all.</div><div><br></div><div>Etienne</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 13, 2020 at 5:37 PM Tom Beecher <beecher@beecher.cc> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p>Wouldn't it be better to measure the basic performance like packet drop rates and queue sizes ?</p></blockquote><div><br></div><div>Those values should be a standard part of monitoring and data collection, but if they happen to MATTER or not in a given situation very much depends. </div><div><br></div><div>The traffic profile traversing the link may be such that the observed drop % and buffer depths is acceptable for that traffic, and there is no need for further tuning or changes. In other scenarios it may not be, in which case either network or application adjustments are warranted. </div><div><br></div><div>There is rarely a one sized fits all answer when it comes to these things. </div><div> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 13, 2020 at 6:25 AM Olav Kvittem via NANOG <<a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

  
  <div>
    <p><br>
    </p>
    <div>On 12.08.2020 09:31, Hank Nussbacher
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      
      <p>At what point do commercial ISPs upgrade links in their
        backbone as well as peering and transit links that are
        congested?  At 80% capacity?  90%?  95%?  </p>
    </blockquote>
    <p><br>
    </p>
    <p>Hi,</p>
    <p><br>
    </p>
    <p>Wouldn't it be better to measure the basic performance like
      packet drop rates and queue sizes ?</p>
    <p>These days live video is needed and these parameters are
      essential to the quality.</p>
    <p>Queues are building up in milliseconds and people are averaging
      over minutes to estimate quality.<br>
    </p>
    <p><br>
    </p>
    <p>If you are measuring queue delay with high frequent one-way-delay
      measurements <br>
    </p>
    <p>you would then be able to advice better on what the consequences
      of a highly loaded link are.</p>
    <p><br>
    </p>
    <p>We are running a research project on end-to-end quality and the
      enclosed image is yesterdays report on</p>
    <p>queuesize(h_ddelay) in ms. It shows stats on delays between some
      peers.</p>
    <p>I would have looked at the trends on the involved links to see if
      upgrade is necessary -  <br>
    </p>
    <p>421 ms  might be too much ig it happens often.<br>
    </p>
    <p><br>
    </p>
    <p>Best regards<br>
    </p>
    <p><br>
    </p>
    <p>  Olav Kvittem<br>
    </p>
    <p><img alt=""></p>
    <p><br>
    </p>
    <blockquote type="cite">
      <p><br>
      </p>
      <p>Thanks,<br>
        Hank</p>
      <p><br>
      </p>
      <p>Caveat: The views expressed above are solely my own and do not
        express the views or opinions of my employer <br>
      </p>
    </blockquote>
  </div>

</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">Ing. Etienne-Victor Depasquale</span><br style="color:rgb(136,136,136);font-family:tahoma,sans-serif"><span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">Assistant Lecturer</span><br style="color:rgb(136,136,136);font-family:tahoma,sans-serif"><span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">Department of Communications & Computer Engineering</span><br style="color:rgb(136,136,136);font-family:tahoma,sans-serif"><span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">Faculty of Information & Communication Technology</span><br style="color:rgb(136,136,136);font-family:tahoma,sans-serif"><span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">University of Malta</span><div>Web. <a href="https://www.um.edu.mt/profile/etiennedepasquale" target="_blank">https://www.um.edu.mt/profile/etiennedepasquale</a><br></div></div></div>