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

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

[Oliver Hohlfeld]

(cross posting to bloat)

On 03/13/2013 04:28 PM, Fred Baker (fred) wrote:
> On Mar 13, 2013, at 10:23 AM, Eliot Lear <lear@cisco.com> wrote:
> 
>> I don't have an answer to that question, but Mark Allman from ICIR did
>> attempt to characterize buffer bloat on the Internet through an
>> empirical study that appeared in the January edition of CCR.  You can
>> find a reference to that paper at the following URL:
>>
>> http://www.sigcomm.org/ccr/papers/2013/January/2427036.2427041
>>
>> Eliot
> 
> Well, yes, he says that in his gigabit FTTH network he doesn't see megabit-scale problems.

Marks paper is /not/ about measuring buffer bloat in an FTTH network.
While he uses the FTTH network as /vantage point/, the paper actually
measures buffer bloat in various remote networks.

Marks paper is not the only study suggesting the extend of the problem
to be modest. The presented results are in line with recent findings by
Chirichella and Rossi [1]. Based on unpublished work, I can confirm the
low magnitude of the problem. I analyzed passive measurements of
residential users traffic from multiple continents (~60 million IPs
originating from 50\% of all ASes) and rarely find excessive RTTs that,
among other problems, can indicate the presence of buffer bloat.

In summary, bloated buffers exist and buffer bloat can be demonstrated,
but current findings suggest that it rarely occurs in practice. One
potential reason being that users do not often sustainably utilize
their uplink capacity and fill-up their potentially large queues.

Oliver

[1] To the Moon and back: are Internet bufferbloat delays really that large?
http://perso.telecom-paristech.fr/~drossi/paper/rossi13tma-a.pdf

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

[Jim Gettys]

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

On Thu, Mar 21, 2013 at 1:50 PM, Oliver Hohlfeld <
oliver@net.t-labs.tu-berlin.de> wrote:

> (cross posting to bloat)
>
> On 03/13/2013 04:28 PM, Fred Baker (fred) wrote:
> > On Mar 13, 2013, at 10:23 AM, Eliot Lear <lear@cisco.com> wrote:
> >
> >> I don't have an answer to that question, but Mark Allman from ICIR did
> >> attempt to characterize buffer bloat on the Internet through an
> >> empirical study that appeared in the January edition of CCR.  You can
> >> find a reference to that paper at the following URL:
> >>
> >> http://www.sigcomm.org/ccr/papers/2013/January/2427036.2427041
> >>
> >> Eliot
> >
> > Well, yes, he says that in his gigabit FTTH network he doesn't see
> megabit-scale problems.
>
> Marks paper is /not/ about measuring buffer bloat in an FTTH network.
> While he uses the FTTH network as /vantage point/, the paper actually
> measures buffer bloat in various remote networks.
>
> Marks paper is not the only study suggesting the extend of the problem
> to be modest. The presented results are in line with recent findings by
> Chirichella and Rossi [1]. Based on unpublished work, I can confirm the
> low magnitude of the problem. I analyzed passive measurements of
> residential users traffic from multiple continents (~60 million IPs
> originating from 50\% of all ASes) and rarely find excessive RTTs that,
> among other problems, can indicate the presence of buffer bloat.
>

I believe you are actually measuring the *fraction of the time* your
measurements show bad latency, rather than the fraction of paths that may
suffer from significant bufferbloat at various times due to excessive
buffering.

Buffers only fill when they are being used and that only happens when
saturation occurs.

The best data I've seen on how widespread the problem is is the ICSI
Netalyzr scatter plots results, which (in color) are in my blog.
http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/
These must be flavored by understanding that those tests top out at about
20Mbps, and that (to keep the time that netalzyr takes to run sane) stops
at about 5 seconds of buffering.

I encourage everyone to run netalyzr and/or the mlabs tests for bufferbloat
on your own broadband connections, or do simple copy and ping tests inside
your own house over wifi to your local file servers....
                                                               - Jim


> In summary, bloated buffers exist and buffer bloat can be demonstrated,
> but current findings suggest that it rarely occurs in practice. One
> potential reason being that users do not often sustainably utilize
> their uplink capacity and fill-up their potentially large queues.
>
> Oliver
>
> [1] To the Moon and back: are Internet bufferbloat delays really that
> large?
> http://perso.telecom-paristech.fr/~drossi/paper/rossi13tma-a.pdf
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #2: Type: text/html, Size: 4756 bytes --]

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

[Oliver Hohlfeld]

> I believe you are actually measuring the *fraction of the time* your
> measurements show bad latency

Yes.

> The best data I've seen on how widespread the problem is is the ICSI
> Netalyzr scatter plots results

One has to be extremely careful on what to conclude from this data.
The Netalyzr data shows that bloated buffers _exist_, not that they
are _used_ in practice. Or as Mark has put it: "[it] shows that large
delays due to buffering can happen, not that they do happen."
Empirical evidence cited in my previous mail suggests that buffer
bloat does not happen often.

> I encourage everyone to run netalyzr and/or the mlabs tests for
> bufferbloat on your own broadband connections, or do simple copy and
> ping tests inside your own house over wifi to your local file servers....

While this will identify bloated buffers, it does not help in answering
what fraction of Internet users actually experience the problem.

Oliver

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

[Jim Gettys]

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

On Thu, Mar 21, 2013 at 2:14 PM, Oliver Hohlfeld <
oliver@net.t-labs.tu-berlin.de> wrote:

> > I believe you are actually measuring the *fraction of the time* your
> > measurements show bad latency
>
> Yes.
>
> > The best data I've seen on how widespread the problem is is the ICSI
> > Netalyzr scatter plots results
>
> One has to be extremely careful on what to conclude from this data.
> The Netalyzr data shows that bloated buffers _exist_, not that they
> are _used_ in practice. Or as Mark has put it: "[it] shows that large
> delays due to buffering can happen, not that they do happen."
> Empirical evidence cited in my previous mail suggests that buffer
> bloat does not happen often.
>

Heh.

6% of the time isn't "often"?  The measurements is much more a measurement
of how much of the time your competing with someone else (or yourself in
background) for the bottleneck than anything else.

Start up any long lived TCP connection (using a modern TCP; that leaves out
Windows XP).

Stand back a few seconds.

Measure latency.

Think uploading/downloading files/videos, or sending email with images
attached, etc.


More insidious is what visiting a web page with lots of embedded images can
do.

The cross product of:
   1) current web browsers using many more than 2 TCP connections.
   2) web site "sharding".
   3) the initial window of data in those TCP connections.

This causes transients of what is up to hundreds of milliseconds of head of
line blocking even
on very high speed broadband/wifi connections.  Again, I encourage you to
do this measurement on your own broadband connection, by visiting any image
heavy web site and running ping....



>
> > I encourage everyone to run netalyzr and/or the mlabs tests for
> > bufferbloat on your own broadband connections, or do simple copy and
> > ping tests inside your own house over wifi to your local file servers....
>
> While this will identify bloated buffers, it does not help in answering
> what fraction of Internet users actually experience the problem.
>

We've not come across any broadband equipment buffered "correctly".  If
thought is given at all to buffering, it's been sized to the maximum
buffering the device might ever need for a single TCP flow at its maximum
bandwidth.  Example, plug a current DOCSIS 3 modem (capable up to 300Mbps
these days) and use it at 20Mbps; unless the buffersizing amendment has
been turned on (no ISP I am aware of yet does so), you'll be overbuffered
by a factor of 15.

And all the operating systems have problems, to one degree or another (and
as they are all adjacent to wireless links these days, they also contribute
to the problem.

Bufferbloat just waits in hiding to get you when you try to use the network.
                                        - Jim


> Oliver

_______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #2: Type: text/html, Size: 6014 bytes --]

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

[Dave Taht]

Moreover, bloat, when it occurs, changes user behavior. Yesterday for
example, I was on a skype call that became unusable. What did we do?

Hung up, and switched to a landline.

There's whole songs written about the problem at this point...

https://www.youtube.com/watch?v=n_ZvkrLkQxY

-- 
Dave Täht

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

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

[Oliver Hohlfeld]

On 03/13/2013 03:23 PM, Eliot Lear wrote:
> I don't have an answer to that question, but Mark Allman from ICIR did
> attempt to characterize buffer bloat on the Internet through an
> empirical study that appeared in the January edition of CCR.  You can
> find a reference to that paper at the following URL:
> 
> http://www.sigcomm.org/ccr/papers/2013/January/2427036.2427041

The full extend of the answer is still unclear to me. We have recently
attempt to complement the rather technical and QoS centric view on the
buffer bloat problem by estimating the user experience impact:

BufferBloat: How Relevant? A QoE Perspective on Buffer Sizing.
Oliver Hohlfeld, Enric Pujol, Florin Ciucu, Anja Feldmann, Paul Barford
http://downloads.ohohlfeld.com/paper/bufferbloat-qoe-tr.pdf

The paper studies the impact of buffer sizes on VoIP, IPTV, and web
browsing Quality of Experience (QoE). We find that:

- oversized buffers indeed degrade QoE when they are sustainable filled.
- however, large buffers do not always degrade user experience.
- the level of congestion significantly degrades QoE, oftentimes more
  than buffer sizes.

One example discussed in the paper is web browsing. When the level of
congestion is low, HTTP transactions benefit from "large" buffers as
they reduce losses by absorbing transient bursts. When the level of
congestion is high, transfer times become RTT dominated and the queuing
delays start to kick in.

Note that objective QoE metrics used in our paper also do not provide
the full picture:
(i) objective QoE metrics and subjective user experience are not
    always correlated.
(ii) the influence memory effects is still unclear (e.g., for how
     long will a user be influenced by a single degradation and how
     does it alter his behavior?). Psychological insights are only
     available for short-time scales.
(ii) even if service degradations exist that would degrade the user
     experience, the user might not always notice them.

In summary, the question on how much of a problem buffer bloat currently
is cannot be fully answered and still requires further research.

Oliver

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

[Mikael Abrahamsson]

On Thu, 21 Mar 2013, Oliver Hohlfeld wrote:

> In summary, the question on how much of a problem buffer bloat currently 
> is cannot be fully answered and still requires further research.

Buffer bloat is a problem on basically all access forms apart from ETTH. 
Usually ETTH is produced using L2 or L3 switches with very small buffers 
(5 ms or so), and policing is used instead of buffering for limiting 
service rate. This means high speed TCP flows will sawtooth their 
performance over time because of large amount of consecutive drops, 
meaning low bw interactive flows are less impacted.

So it's my belief that your measurements means most people don't actually 
put congestion pressure on their accesses, thus the large buffers are 
seldom used and you're not seeing buffering.

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

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

[David Lang]

On Thu, 21 Mar 2013, Oliver Hohlfeld wrote:

> On 03/13/2013 03:23 PM, Eliot Lear wrote:
>> I don't have an answer to that question, but Mark Allman from ICIR did
>> attempt to characterize buffer bloat on the Internet through an
>> empirical study that appeared in the January edition of CCR.  You can
>> find a reference to that paper at the following URL:
>>
>> http://www.sigcomm.org/ccr/papers/2013/January/2427036.2427041
>
> The full extend of the answer is still unclear to me. We have recently
> attempt to complement the rather technical and QoS centric view on the
> buffer bloat problem by estimating the user experience impact:
>
> BufferBloat: How Relevant? A QoE Perspective on Buffer Sizing.
> Oliver Hohlfeld, Enric Pujol, Florin Ciucu, Anja Feldmann, Paul Barford
> http://downloads.ohohlfeld.com/paper/bufferbloat-qoe-tr.pdf
>
> The paper studies the impact of buffer sizes on VoIP, IPTV, and web
> browsing Quality of Experience (QoE). We find that:
>
> - oversized buffers indeed degrade QoE when they are sustainable filled.
> - however, large buffers do not always degrade user experience.
> - the level of congestion significantly degrades QoE, oftentimes more
>  than buffer sizes.
>
> One example discussed in the paper is web browsing. When the level of
> congestion is low, HTTP transactions benefit from "large" buffers as
> they reduce losses by absorbing transient bursts. When the level of
> congestion is high, transfer times become RTT dominated and the queuing
> delays start to kick in.

Actually, I see performace dropping off when saturating a link with HTTP 
traffic, instead of a smooth flow, the flow becomes very bursty (looking at 
traffic with MRTG set to very short sample times shows graphs like ||||| instead 
of a smooth -----) This results in me getting substantially less than the 
theoretical throughput of my DSL line.

Bufferbloat perfectly accounts for this (sender sends really fast, but the 
traffic is not getting through, so it stalls waiting for the acks, packets get 
lost/time out, speed collapses and you end up starting again from slow speeds)


Also, if you measure the impact of bufferbloat in terms of how many seconds a 
day the line is impacted, you get a horribly skewed view of the impact.

Remember that out of 24 hours, a typical residential line is idle for 8 hours 
because the occupants are sleeping and about 10 hours because they are at work. 
Most people do not spend the remaining 6 hours using their computer, so for most 
people, they are only using their machine somewhere in the order of 3 hours/day, 
which is only 12% of the time. (although things like netflix and other streaming 
video services may adjust this upwards)

If you say bufferbloat only happens 6% of the day, that means that it's 
happening about 50% of the time that people are trying to use their systems.

If you then add in to this the fact that even while using the computer, most 
people have times when the network is idle, the percentage of time that 
bufferbloat impacts the user climbs even higher.

David Lang

> Note that objective QoE metrics used in our paper also do not provide
> the full picture:
> (i) objective QoE metrics and subjective user experience are not
>    always correlated.
> (ii) the influence memory effects is still unclear (e.g., for how
>     long will a user be influenced by a single degradation and how
>     does it alter his behavior?). Psychological insights are only
>     available for short-time scales.
> (ii) even if service degradations exist that would degrade the user
>     experience, the user might not always notice them.
>
> In summary, the question on how much of a problem buffer bloat currently
> is cannot be fully answered and still requires further research.
>
> Oliver
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

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

[Jim Gettys]

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

Also, Windows XP is still significantly in use in the Internet
(unfortunately).



On Thu, Mar 21, 2013 at 3:25 PM, Mikael Abrahamsson <swmike@swm.pp.se>wrote:

> On Thu, 21 Mar 2013, Oliver Hohlfeld wrote:
>
>  In summary, the question on how much of a problem buffer bloat currently
>> is cannot be fully answered and still requires further research.
>>
>
> Buffer bloat is a problem on basically all access forms apart from ETTH.
> Usually ETTH is produced using L2 or L3 switches with very small buffers (5
> ms or so), and policing is used instead of buffering for limiting service
> rate. This means high speed TCP flows will sawtooth their performance over
> time because of large amount of consecutive drops, meaning low bw
> interactive flows are less impacted.
>
> So it's my belief that your measurements means most people don't actually
> put congestion pressure on their accesses, thus the large buffers are
> seldom used and you're not seeing buffering.



Due to the fact TCP window scaling is off by default in Windows XP, the
most a single TCP connection will have in flight on Windows XP is 64K bytes.

This both limits the ability of a Windows XP system to saturate a link in
the first place (thereby sometimes avoiding filling buffers at the
bottleneck at all), and limits the amount of latency a single TCP
connection will inflict.

Every more modern TCP can easily fill any sized buffer given time with a
single TCP connection.
                                   - Jim

>
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
>
> ______________________________**_________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/**listinfo/bloat<https://lists.bufferbloat.net/listinfo/bloat>
>

[-- Attachment #2: Type: text/html, Size: 3147 bytes --]

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

[Oliver Hohlfeld]

On Thu, Mar 21, 2013 at 01:04:21PM -0700, David Lang wrote:
> Also, if you measure the impact of bufferbloat in terms of how many
> seconds a day the line is impacted, you get a horribly skewed view of
> the impact.

I agree that such a temporal view will skew the results. The approach
taken in Mark Allman's paper is to measure the magnitude by measuring
the number of affected packets relative to the total number of packets.
This implies the amount of time a user can potentially suffer from
buffer bloat when actively using the line. It's not relative to when
the user is idle.

Oliver

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

[Mikael Abrahamsson]

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

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

[grenville armitage]

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

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

[Mikael Abrahamsson]

On Fri, 22 Mar 2013, grenville armitage wrote:

>
>
> 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

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.

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

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

[Dave Taht]

On Fri, Mar 22, 2013 at 6:23 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Fri, 22 Mar 2013, grenville armitage wrote:
>
>>
>>
>> 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
>
>
> 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.

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)

>
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm



-- 
Dave Täht

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

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

[Mirja Kuehlewind]

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
-------------------------------------------------------------------

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

[Scheffenegger, Richard]

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: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of
> Mirja Kuehlewind
> Sent: Dienstag, 26. März 2013 18:26
> To: aqm@ietf.org
> Cc: bloat; tsvwg@ietf.org
> Subject: Re: [tsvwg] [aqm] [Bloat] how much of a problem is buffer bloat
> today?
> 
> 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
> -------------------------------------------------------------------

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

[Hagen Paul Pfeifer]

* 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