From: Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de>
To: aqm@ietf.org
Cc: bloat <bloat@lists.bufferbloat.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Subject: Re: [Bloat] [aqm] [tsvwg] how much of a problem is buffer bloat today?
Date: Tue, 26 Mar 2013 18:25:47 +0100 [thread overview]
Message-ID: <201303261825.47601.mirja.kuehlewind@ikr.uni-stuttgart.de> (raw)
In-Reply-To: <alpine.DEB.2.00.1303220521370.2309@uplift.swm.pp.se>
Hi,
+1. Would be nice to have such statictics available for the user in every OS!
Mirja
On Friday 22 March 2013 05:27:31 Mikael Abrahamsson wrote:
> On Thu, 21 Mar 2013, Jim Gettys wrote:
> > Every more modern TCP can easily fill any sized buffer given time with a
> > single TCP connection.
>
> I agree with this, I made this discovery myself back in 2004 or so, and
> had to implement Fairqueue and WRED on my home connection to make it
> bearable to use any interactive application while transferring files.
>
> In IETF75 in Stockholm in 2009, I made proposals in both TCP and at open
> mic in one of the sessions, that I would like to see statistics and
> performance numbers on packet loss, delay variation etc from actual
> traffic. The IP stack has great insight in what the network conditions are
> (especially with TCP Timestamping), but as far as I know it's not really
> exported in any usable format to the user. My idea was to have some kind
> of dashboard for the user to show if currently the network was the
> limiting factor, if the tcp window was maxed out etc. Would also be nice
> if there was output that could be cut/pasted and attached to a fault
> report in case the customer talks to customer support. It would be good if
> this was actually a standard so all OSes did the same.
>
> I am not aware of any such work going on, so I'd like to know if anyone
> else is aware of work in this area?
--
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart
tel: +49(0)711/685-67973
email: mirja.kuehlewind@ikr.uni-stuttgart.de
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------
next prev parent reply other threads:[~2013-03-26 17:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <51408BF4.7090304@cisco.com>
[not found] ` <8C48B86A895913448548E6D15DA7553B7D020F@xmb-rcd-x09.cisco.com>
2013-03-21 17:50 ` [Bloat] " Oliver Hohlfeld
2013-03-21 18:01 ` Jim Gettys
2013-03-21 18:14 ` Oliver Hohlfeld
2013-03-21 18:28 ` Jim Gettys
2013-03-21 18:36 ` Dave Taht
2013-03-21 19:08 ` Oliver Hohlfeld
2013-03-21 19:25 ` Mikael Abrahamsson
2013-03-21 20:05 ` Jim Gettys
2013-03-22 4:27 ` Mikael Abrahamsson
2013-03-22 6:00 ` [Bloat] [aqm] " grenville armitage
2013-03-22 13:23 ` Mikael Abrahamsson
2013-03-22 13:31 ` Dave Taht
2013-03-26 17:25 ` Mirja Kuehlewind [this message]
2013-03-26 17:49 ` [Bloat] [tsvwg] [aqm] " Scheffenegger, Richard
2013-03-26 20:02 ` Hagen Paul Pfeifer
2013-03-21 20:04 ` [Bloat] [tsvwg] " David Lang
2013-03-21 20:47 ` Oliver Hohlfeld
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=201303261825.47601.mirja.kuehlewind@ikr.uni-stuttgart.de \
--to=mirja.kuehlewind@ikr.uni-stuttgart.de \
--cc=aqm@ietf.org \
--cc=bloat@lists.bufferbloat.net \
--cc=tsvwg@ietf.org \
/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