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 --]
next prev parent 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