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