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

From: Dave Taht <[email-masked]>
Date: Thu, 21 Mar 2013 11:36:11 -0700

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

---

From: David Lang <[email-masked]>
Date: Thu, 21 Mar 2013 13:04:21 -0700 (PDT)

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
> [email-masked]
> https://lists.bufferbloat.net/listinfo/bloat
>

---

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: 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:
> On Fri, 22 Mar 2013, grenville armitage wrote:
>
>>
>>
> 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: [email-masked]
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

-- 
Dave Täht