General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Mark Allman <mallman@icir.org>
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Bufferbloat Paper
Date: Tue, 08 Jan 2013 08:55:10 -0500	[thread overview]
Message-ID: <20130108135510.EF4CA59F9BA@lawyers.icir.org> (raw)
In-Reply-To: <87vcb7hmip.fsf@toke.dk>

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


Let me make a few general comments here ...

(0) The goal is to bring *some* *data* to the conversation.  To
    understand the size and scope of bufferbloat problem it seems to me
    we need data.

(1) My goal is to make some observations of the queuing (/delay
    variation) in the non-FTTH portion of the network path.  As folks
    have pointed out, its unlikely bufferbloat is much of a problem in
    the 1Gbps portion of the network I monitor.

(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.  So, the fact that
    this is a 1Gbps environment for local users is really not material.
    The REHs are whatever the local users decide to talk to.  I have no
    idea what the edge bandwidth on the remote side is, but I presume it
    is general not a Gbps (especially for the residential set).

    So, if you wrote off the paper after the sentence that noted the
    data was collected within an FTTH project, I'd invite you to read
    further.

(3) This data is not ideal.  Ideally I'd like to directly measure queues
    in a bazillion places.  That'd be fabulous.  But, I am working with
    what I have.  I have traces that offer windows into the actual queue
    occupancy when the local users I monitor engage particular remote
    endpoints.  Is this representative of the delays I'd find when the
    local users are not engaging the remote end system?  I have no
    idea.  I'd certainly like to know.  But, the data doesn't tell me.
    I am reporting what I have.  It is something.  And, it is more than
    I have seen reported anywhere else.  Folks should go collect more
    data.

    (And, note, this is not a knock on the folks---some of them my
    colleagues---who have quite soundly assessed potential queue sizes
    by trying to jam as much into the queue as possible and measuring
    the worst case delays.  That is well and good.  It establishes a
    bound and that there is the potential for problems.  But, it does
    not speak to what queue occupancy actually looks like.  This latter
    is what I am after.)

allman




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

  reply	other threads:[~2013-01-08 13:55 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-07 23:37 Hagen Paul Pfeifer
2013-01-08  0:33 ` Dave Taht
2013-01-08  0:40   ` David Lang
2013-01-08  2:04   ` Mark Watson
2013-01-08  2:24     ` David Lang
2013-01-09 20:08       ` Michael Richardson
2013-01-08  4:52     ` Mark Watson
2013-01-08  1:54 ` Stephen Hemminger
2013-01-08  2:15   ` Oliver Hohlfeld
2013-01-08 12:44   ` Toke Høiland-Jørgensen
2013-01-08 13:55     ` Mark Allman [this message]
2013-01-09  0:03       ` David Lang
2013-01-10 13:01         ` Mark Allman
2013-01-09 20:14       ` Michael Richardson
2013-01-09 20:19         ` Mark Allman
2013-01-09 20:31           ` Michael Richardson
2013-01-10 18:05             ` Mark Allman
2013-01-08 14:04     ` Mark Allman
2013-01-08 17:22   ` Dave Taht
2013-01-09 20:05 ` Michael Richardson
2013-01-09 20:14   ` Mark Allman
2013-01-08  7:35 [Bloat] bufferbloat paper Ingemar Johansson S
2013-01-18 22:00 ` Haiqing Jiang
2013-01-08 19:03 Hal Murray
2013-01-08 20:28 ` Jonathan Morton
2013-01-09  0:12 ` David Lang
2013-01-09  1:59   ` Mark Allman
2013-01-09  4:53     ` David Lang
2013-01-09  5:13       ` Jonathan Morton
2013-01-09  5:32       ` Mark Allman
     [not found] <87r4lvgss4.fsf@toke.dk>
2013-01-09  3:39 ` [Bloat] Bufferbloat Paper Mark Allman
2013-01-09  5:02   ` David Lang
2013-01-18  1:23     ` grenville armitage

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130108135510.EF4CA59F9BA@lawyers.icir.org \
    --to=mallman@icir.org \
    --cc=bloat@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox