bufferbloat

Posted Feb 11, 2011 0:28 UTC (Fri) by Lennie (subscriber, #49641)
In reply to: bufferbloat by dlang
Parent article: Increasing the TCP initial congestion window

What I was thinking is, browsers open many connections to webservers on many different domains and when we increase this window we will be sending a lot of data at a time.

This could induce or increase the effect of bufferbloat

bufferbloat

Posted Feb 11, 2011 6:31 UTC (Fri) by butlerm (subscriber, #13312) [Link] (7 responses)

The reason why multiple connections are useful is not so much to give you an unfair advantage (over yourself?) in the congestion control wars - it is rather because HTTP over TCP is a single stream protocol, which causes the serialization of all requests and responses to/from the same server. That is not remotely ideal.

Google has a proposal to fix this with a mid layer multi-stream protocol between HTTP and TCP. Even better would be a proper multi-streaming transport protocol like SCTP, but not so intelligent NAT devices appear to have killed that option for the time being. Meanwhile, Google Chrome appears to restrict the number of connections it uses pretty severely, which makes it noticeably slower than Internet Explorer on some applications which are not at all bandwidth constrained.

bufferbloat

Posted Feb 11, 2011 10:08 UTC (Fri) by Lennie (subscriber, #49641) [Link] (5 responses)

Yes I know about SPDY, I don't see it happening any time soon though. Because the specification process seems to be going really slow. Atleast from what has been published.

Also it is a model which might not yet fit wel with some current webservers. It won't be an easy module to add to Apache for example. A proxy could work though.

Ironicly of all the currently deployed browsers, IE6 and IE7 from Microsoft are actually open the least amount of connections and the one with the most connections: ie8 (and I presume ie9)

Proxies, multi-streaming, wireless, bufferbloat

Posted Feb 11, 2011 13:41 UTC (Fri) by mtaht (subscriber, #11087) [Link]

This is where I think a proxy running over sctp to the gateway has some potential - it could run http over a multi-streaming protocol like sctp.

https://lists.bufferbloat.net/pipermail/bloat/2011-Februa...

bufferbloatnpn

Posted Feb 12, 2011 6:53 UTC (Sat) by dtlin (subscriber, #36537) [Link] (3 responses)

Look for EnableSpdy in chromium/src/chrome/browser/browser_main.cc for 90% of Google Chrome users, the browser will switch protocols to SPDY whenever the server advertises the capability.

All secure Google services advertise SPDY as an alternate protocol (using the next_protocol_negotiation extension of TLS). That's a lot of real-world users.

bufferbloatnpn

Posted Feb 12, 2011 12:04 UTC (Sat) by Lennie (subscriber, #49641) [Link] (2 responses)

That is all very nice, but it is useless if it is not properly described and put forward as a standard. Atleast that one part is on the IETF site:

http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-01

I'm talking about this one, it's just sitting there (atleast that is what it looks like to me):

http://www.chromium.org/spdy/spdy-protocol

Without something at IETF or something which looks mostly final why would other browser vendors and webserver people implement it ? Without atleast that, it is useless.

This is the last status:

http://groups.google.com/group/spdy-dev/browse_thread/thr...

Who knows, maybe this is the reason why:

http://groups.google.com/group/spdy-dev/browse_thread/thr...

He is just to busy and there isn't anyone else to help him ?

;-)

bufferbloatnpn

Posted Feb 16, 2011 17:22 UTC (Wed) by mbelshe (guest, #72948) [Link] (1 responses)

Ha!

Well, I'm glad you guys are interested. I assure you that we're still hard at work on it. It just takes time.

This year, we'll be much more active and look to get IETF support. Unfortunately, some things just can't be rushed.

Mike

bufferbloatnpn

Posted Feb 17, 2011 9:28 UTC (Thu) by Lennie (subscriber, #49641) [Link]

For something as basic as the use of TCP for HTTP, I prefer to do it right instead of working around the problems. HTTP has always had this 'bug' that it only allowed one request at a time over HTTP (pipelining exists but did not find widespread use because backwardscompatibility).

SPDY sounds to me like the right way, instead of adding more TCP-connections all with a larger initial windows size.

Bufferbloat is a different problem, but adding more TCP-connections with larger initial window sizes wouldn't help either.

SPDY seems to also be about delivering fast TLS. That would help a lot, we've seen to many problems with cookies getting picked up by others.

Maybe we don't want to use it for certain static files, atleast that is what people think when they see what is happening with Google SSL/Google Images. Maybe it is just a loadbalancer/TLS-sessions problem, it breaks TLS Session Resumption ?

If browsers that use SPDY are shown to be faster and people flock to it, it will also help spread the support for SNI. Although I think people who use IE on XP are probably not speedfreaks anyway.

But the more reasons people have not use IE on XP the better. :-)

bufferbloat

Posted Feb 16, 2011 17:18 UTC (Wed) by mbelshe (guest, #72948) [Link]

The TCP congestion control heuristics are likely dated. Using an initial cwnd of 4KB is just too low for most users, and the data to increase this limit is compelling (see Chu/Dukkipati data). HTTP clients/servers are using multiple connections to achieve higher initial cwnds on the initial burst.

SCTP does centralize cwnd across all open streams, but it uses the same core algorithms as TCP and fails to address the initial burst. Unless the initial burst is increased, SCTP is slower than HTTP over lots of TCP connections out of the gate. This is measurable and demonstrable.

Oh, and SCTP doesn't work over NAT. So still waiting for IPv6.