General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Mark Allman <mallman@icir.org>
To: dpreed@reed.com
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>,
	Keith Winstein <keithw@mit.edu>,
	"end2end-interest@postel.org" <end2end-interest@postel.org>,
	"bloat@lists.bufferbloat.net" <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [e2e] bufferbloat paper
Date: Tue, 08 Jan 2013 11:40:26 -0500	[thread overview]
Message-ID: <20130108164026.367FC5AAAAC@lawyers.icir.org> (raw)
In-Reply-To: <1357658975.013413296@apps.rackspace.com>

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


David-

I completely agree with your "measure it" notion.  That is one of the
points of my paper.

> First, it's important to measure the "right thing" - which in this
> case is "how much queueing *delay* builds up in the bottleneck link
> under load"

That said, as often is the case there is no "right thing", but rather a
number of "right thingS" to measure.  And/or, when you go off to measure
the "right thing" there are additional facets that come to light that
one must understand.  

Certainly understanding how much possible delay can build up in a queue
is a worthwhile thing to measure.  There are good results of this in the
netalyzr paper.  Further, as Injong mentioned there are results of this
potential queue buildup from mobile networks in his recent IMC paper.

However, the point of my contribution is that if this queue buildup
happens only in the middle of the night on the second Sunday of every
leap year for 1.5sec, that'd be good to know and probably it'd make the
behavior something to not specifically engineer around in a best effort
network.  So, then, lets ask about the scale and scope of this behavior
and answer it with systematic, empirical assessment instead of anecdotes
and extrapolation.  Surely that is not a controversial position.

My results are modest at best.  Other people have different (probably
better) vantage points.  They should look at some data, too.

allman




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

  reply	other threads:[~2013-01-08 16:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-08  7:35 [Bloat] " Ingemar Johansson S
2013-01-08 10:42 ` [Bloat] [e2e] " Keith Winstein
2013-01-08 12:19   ` Ingemar Johansson S
2013-01-08 12:44     ` Keith Winstein
2013-01-08 13:19       ` Ingemar Johansson S
2013-01-08 15:29         ` dpreed
2013-01-08 16:40           ` Mark Allman [this message]
2013-01-09 14:07   ` Michael Richardson
2013-01-10  7:37     ` Keith Winstein
2013-01-10 13:46       ` Michael Richardson
2013-01-08 15:04 ` dpreed
2013-01-18 22:00 ` [Bloat] " Haiqing Jiang
2013-01-10 13:48 [Bloat] [e2e] " dpreed

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=20130108164026.367FC5AAAAC@lawyers.icir.org \
    --to=mallman@icir.org \
    --cc=bloat@lists.bufferbloat.net \
    --cc=dpreed@reed.com \
    --cc=end2end-interest@postel.org \
    --cc=ingemar.s.johansson@ericsson.com \
    --cc=keithw@mit.edu \
    /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