General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Jim Gettys <jg@freedesktop.org>
Cc: aqm@ietf.org, "tsvwg@ietf.org" <tsvwg@ietf.org>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [tsvwg] how much of a problem is buffer bloat today?
Date: Fri, 22 Mar 2013 05:27:31 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.00.1303220521370.2309@uplift.swm.pp.se> (raw)
In-Reply-To: <CAGhGL2DHrNUEnVF-Qn6OeeD9LvST06c0QaTxSJ+zbKdpQq2Y7g@mail.gmail.com>

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?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

  reply	other threads:[~2013-03-22  4:27 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   ` 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 [this message]
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
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=alpine.DEB.2.00.1303220521370.2309@uplift.swm.pp.se \
    --to=swmike@swm.pp.se \
    --cc=aqm@ietf.org \
    --cc=bloat@lists.bufferbloat.net \
    --cc=jg@freedesktop.org \
    --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