Subject: Re: [aqm] [Bloat] [tsvwg] how much of a problem is buffer bloat today?

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 22 Mar 2013 05:27:31 +0100 (CET)

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: [email-masked]

---

From: grenville armitage <[email-masked]>
Date: Fri, 22 Mar 2013 17:00:29 +1100

On 03/22/2013 15:27, Mikael Abrahamsson wrote:
	[..]
> 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?

Of possible relevance, recent FreeBSDs have SIFTR -- a kernel resident
module for collecting TCP state-machine stats (like cwnd, rtt estimator,
etc) as packets arrive and depart.

http://www.freebsd.org/cgi/man.cgi?query=siftr

cheers,
gja

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 22 Mar 2013 14:23:56 +0100 (CET)

> http://www.freebsd.org/cgi/man.cgi?query=siftr

This seems exactly like what I'm after.

On another note, is there software that can get mirrored traffic from 
another host and do TCP analysis of flows when it comes to buffer bloat, 
packet loss etc. If there was, I am in the position of running this 
against a large number of customers over time and can present the results.

---

From: Dave Taht <[email-masked]>
Date: Fri, 22 Mar 2013 06:31:35 -0700

On Fri, Mar 22, 2013 at 6:23 AM, Mikael Abrahamsson <[email-masked]> wrote:
> packet loss etc. If there was, I am in the position of running this against
> a large number of customers over time and can present the results.

http://web10g.org/ and ihttp://www.web100.org/ are also potentially
very useful. My concern with this used to be that it gets it's fingers
into the tcp hot path, but in practice modern gear is so fast it's
hard to notice.

I used to patch this into cerowrt but it was hard to keep the patches
in sync with the linux mainline code I was also tracking. Might
consider adding it again, but in the general case it seems more useful
on the end points than elsewhere (my use case was against the local
test suites on cero and on the polipo web proxy resident on the
router)

> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 26 Mar 2013 18:25:47 +0100

Hi,

+1. Would be nice to have such statictics available for the user in every OS!

Mirja

-- 
-------------------------------------------------------------------
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: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 26 Mar 2013 17:49:49 +0000

Hmm...

TCP measures RTT; 

one could create a global histogram of all measured RTTs by TCP (whenever a valid measurement is taken), and export that with "netstat -sp tcp"... Of course, vastly different paths would be gobbled up together, but when investigating specific paths, that should be good enough as a high level starting point.

Richard Scheffenegger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mirja Kuehlewind
> Sent: Dienstag, 26. März 2013 18:26
> To: [email-masked]
> Cc: bloat; [email-masked]
> Subject: Re: [tsvwg] [aqm] [Bloat] how much of a problem is buffer bloat
> today?
> 
> Hi,
> 
> > > 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.
> >
> University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart
> 
> tel: +49(0)711/685-67973

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Tue, 26 Mar 2013 21:02:16 +0100

* Scheffenegger, Richard | 2013-03-26 17:49:49 [+0000]:

>TCP measures RTT; 
>
>one could create a global histogram of all measured RTTs by TCP (whenever a
>valid measurement is taken), and export that with "netstat -sp tcp"... Of
>course, vastly different paths would be gobbled up together, but when
>investigating specific paths, that should be good enough as a high level
>starting point.

For Linux tcp-probe[1] is your friend. The last colum is the smoothed round trip
time. The port filter is optional and can be 0 to disable filtering. Not sure
if Linux Distribution ship this module by default. But via tcp-probe you get
accurate per-path rtt statistics without any effort (just a few CPU cycles).

Hagen

[1] http://www.linuxfoundation.org/collaborate/workgroups/networking/tcpprobe