On 16/05/15 01:17, Stephen Hemminger wrote:
On Fri, 15 May 2015 12:16:56 -0400
Jim Gettys <[email protected]> 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
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
