Re: [Bloat] Bufferbloat Paper

[Mark Allman <mallman@icir.org>]

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


> > (2) The network I am monitoring looks like this ...
> >
> >        LEH -> IHR -> SW -> Internet -> REH
> >
> >     where, "LEH" is the local end host and "IHR" is the in-home
> >     router provided by the FTTH project.  The connection between the
> >     LEH and the IHR can either be wired (at up to 1Gbps) or wireless
> >     (at much less than 1Gbps, but I forget the actual wireless
> >     technology used on the IHR).  The IHRs are all run into a switch
> >     (SW) at 1Gbps.  The switch connects to the Internet via a 1Gbps
> >     link (so, this is a theoretical bottleneck right here ...).  The
> >     "REH" is the remote end host.  We monitor via mirroring on SW.
> >
> >     The delay we measure is from SW to REH and back.  
> 
>  The issue is that if the home user has a 1G uplink to you, and then
>  you hae a 1G uplink to the Internet, there is not going to be very
>  much if any congestion in place. The only place where you are going
>  to have any buffering is in your 1G uplink to the Internet (and only
>  if there is enough traffic to cause congestion here)
> 
>  In the 'normal' residential situation, the LEH -> THR connection is
>  probably 1G if wired, but the THR -> SW connection is likely to be
>  <1M. Therefor the THR ends up buffering the outbound traffic.

(I assume 'THR' is what I called 'IHR'.)

You are too focused on the local side of the network that produced the
traffic and you are not understanding what was actually measured.  As I
say above, the delays are measured from SW to REH and back.  That *does
not* involve the LEH or the IHR in any way.  Look at the picture and
think about it for a minute.  Read my email.  Read email from others'
that has also tried to clarify the issue.

Let me try one more time to be as absolutely explicit as I can be.  Say,
...

  - LEH sends a data packet D that is destined for REH at time t0.

  - D is forwarded by IHR at time t1.

  - D is both forwarded by SW and recorded in my packet trace at time
    t2.

  - D traverses the wide area Internet and arrives at REH (which is
    whatever LEH happens to be talking to; not something I control or
    can monitor) at time t3.

  - At time t4 the REH will transmit an ACK A for data packet D.

  - A will go back across the wide-area Internet and eventually hit SW
    at time t5.  A will be both forwarded to IHR and recorded in my
    packet trace at this time.

  - A will be forwarded by IHR at time t6.

  - A will arrive at LEH at time t7.

The RTT sample I will take from this exchange is t5-t2.  Your discussion
of focuses on t7-t5 (the downlink) and t2-t0 (the uplink).  In other
words, you are talking about something different from what is presented
in the paper.  If you want to comment on the paper, that is fine.  But,
you should comment on what the paper says or what the paper is lacking
and not try to distort what the paper presents.

I fully understand that these FTTH links to the Internet are abnormal.
And, as such, if I were looking for buffers on the FTTH side of things
that'd be bogus.  But, I am not doing that.  Regardless of how many
times you say it.  The measurements are not of 90 homes, but of 118K
remote peers that the 90 homes happened to communicate with (and the
networks used to reach those 118K peers).  If it helps, you can think of
the 90 homes as just 90 homes connected to the Internet by whatever
technology (DSL, cable, fiber, wireless ...).  The measurements are not
concerned with the networks inside of connecting these 90 homes.

Look, I could complain about my own paper all day long and twice as much
on Sunday.  There are plenty of ways it is lacking.  Others could no
doubt do the same.  I have tried hard to use the right perspective and
to say what this data does and does not show.  I have done that on this
list and in the paper itself.  E.g., these are the first two bullets in
the Future Work section:

\item Bringing datasets from additional vantage points to bear on
  the questions surrounding bufferbloat is unquestionably useful.
  While we study bufferbloat related to 118K peers for some modest
  period of time (up to one week), following more peers and over the
  course of a longer period would be useful.

\item While we are able to assess 118K peers, we are only able to do
  so opportunistically when a host on the network we monitor
  communicates with those peers.  A vantage point that provides a
  more comprehensive view of residential peers' behavior would be
  useful.

So, complain away if you'd like.  I don't mind at all.  But, at least
complain about what is in the paper and what is actually measured.
Please. 

allman




[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]