<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Am 13.02.2013 21:39, schrieb Joe Touch:<br>
    </div>
    <blockquote cite="mid:511BFA0E.9090303@isi.edu" type="cite">
      <br>
      FWIW, bufferbloat examples I've seen tend to focus on *upload* out
      of the home. As you note, download isn't the issue as much.
      <br>
      <br>
      Try this:
      <br>
      Â Â Â Â - upload a video to youtube (or anywhere)
      <br>
      Â Â Â Â - ping somewhere else
      <br>
    </blockquote>
    <br>
    Now, what will happen? The TCP socket will fully utilize the
    outgoing interface's buffer. And the ICMP packet has to enqueue
    itself at the end of the queue.<br>
    <br>
    However, this is not a problem of too much buffering. This is a
    scheduling problem. Actually, VJCC extends TCP's self<i>_clocking_ </i>into
    a self<i>_scheduling_</i>.<br>
    <br>
    As far as this works at all, it will achieve some kind of
    "statistically similar throughput" for greedy sources and long term
    flows.<br>
    <br>
    However, from the perspective of the ICMP echo request, the whole
    issue appears as some kind of head of line blocking. (With numerous
    heads...)<br>
    <blockquote cite="mid:511BFA0E.9090303@isi.edu" type="cite">
      <br>
      That can happen within a single machine (that was the first case I
      heard about, and as anticipated the issue was in-kernel buffering)
      or between two machines (if the home router has too much buffering
      and too little brains to do proportional sharing).
      <br>
      <br>
    </blockquote>
    <br>
    Absolutely. However, this is no issue. What you describe is an IP
    stack that "works as designed".<br>
    <br>
    <blockquote cite="mid:511BFA0E.9090303@isi.edu" type="cite">Less
      buffering - either in the OS or the router - sometimes helps
      reduce delay because the greedy application backs off (due to
      losses), is scheduled to transmit less often (when on the same
      machine), or simply loses more packets.
      <br>
    </blockquote>
    <br>
    I don't think that the described effect is a buffering issue. The
    problem is that we intertwined<br>
    - congestion control<br>
    - ressource sharing<br>
    - scheduling <br>
    <br>
    into one complex algorithm - and now, we wonder why the whole thing
    works as designed.<br>
    <br>
    And BTW, the congavoid paper only talks about TCP.  I don't remember
    that Van Jacobson or Michael Karels talked about "ping fairness" in
    this paper.... ;-)<br>
    <br>
    <br>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30   
70565 Stuttgart                            Tel.:   +49 711 5208031
                                           mobile: +49 172 6819937
                                           skype:     detlef.bosau
                                           ICQ:          566129673
<a class="moz-txt-link-abbreviated" href="mailto:detlef.bosau@web.de">detlef.bosau@web.de</a>                     <a class="moz-txt-link-freetext" href="http://www.detlef-bosau.de">http://www.detlef-bosau.de</a>
------------------------------------------------------------------
The nonsense that passes for knowledge around wireless networking,
even taught by "professors of networking" is appalling.  It's the 
blind leading the blind. (D.P. Reed, 2012/12/25)
------------------------------------------------------------------

</pre>
  </body>
</html>