Re: [Bloat] General Bufferbloat Testing Document.

[Alan Jenkins <alan.christopher.jenkins@gmail.com>]

On 16/05/15 01:17, Stephen Hemminger wrote:
> On Fri, 15 May 2015 12:16:56 -0400
> Jim Gettys <jg@freedesktop.org> wrote:
>
>> Even before I knew about the wonderful DSLreports bufferbloat test, I had
>> started working on a document to help people like that (e.g. Ookla)
>> understand how to do bufferbloat testing.  The document also grew a bit
>> beyond that topic, by the time it was done....
>>
>> The document is at:
>>
>> https://docs.google.com/document/d/1z5NN4WRKQKK-RtxtKR__XIwkybvsKEmunek2Ezdw_90/edit?usp=sharing
>>
>> Comments welcome.
>>
>> It's intended long term home is the bufferbloat.net wiki, but I've found
>> Google doc's commenting feature really useful.
>>                             - Jim
>
> Great to see, I think it does a good job of being detailed without overwhelmingly
> research oriented.
>
> What makes you believe SPDY and QUIC will be better than TCP? I know they do
> pacing but if they get the rate estimation wrong or get hit by transient congestion
> it could have same failing that doomed TCP Vegas.

HTTP/2 has working multiplexing.  This means you can reduce several 
simultaneous 'slow start' bursts to one.  Yay!

c.f. "These transients are caused by normal users in everyday use cases 
such as routine web surfing, due to embedded images inducing large 
numbers of TCP connections, and TCP’s initial window and TCP “slow 
start” (currently unpaced) landing in a single FIFO queue"

There's some hope sites will stop "sharding".  I.e. stop hosting 
resources on multiple domains to game how many connections the browser 
opens.  I guess it would let them avoid a round-trip from opening extra 
secondary connections.

Alan