Let's make TCP faster

http://googlecode.blogspot.com/2012/01/lets-make-tcp-faster.html

by flardinois • 15 years ago

287 36 15 years ago

googlecode.blogspot.com

wazoox• 15 years ago

Of course I don't know much about this, but I find the first call to action a bit surprising:

1. Increase TCP initial congestion window to 10 (IW10).

It seems contradictory with the general concept that too much buffering harms latency and may actually be aggravating congestion: http://queue.acm.org/detail.cfm?id=2071893

wmf2• 15 years ago

Bufferbloat is caused by buffering hundreds of packets, not 10. Bandwidth-delay product has increased so much that the initial congestion window also needs to increase so that TCP can ramp up in a reasonable time.

ck22• 15 years ago

Their own paper shows that it's still a controversial issue and after a certain point decreases performance.

giulivo• 15 years ago

I found this part to be the real great news:

All our work on TCP is open-source and publicly available. We disseminate our innovations through the Linux kernel, IETF standards proposals, and research publications.

newman3142• 15 years ago

I can't see to find kernel patches for #2 or #3. Anyone else have better luck?

Also, I would like to see more emphasis given to research on mobile networks, which is my area of interest. Perf for large stable networks is not the same for choppy 3G-ish mobile networks.

newman3142• 15 years ago

Ninja commenting here...

After more digging, I was able to find this. If you scroll all the way to the end, there is some verbiage about just setting TCP_RTO_MIN to 1. However, the author claims this causes issues with delayed ACK unless another (missing) patch is applied.

https://github.com/vrv/linux-microsecondrto http://www.pdl.cmu.edu/PDL-FTP/Storage/sigcomm147-vasudevan....

DrCatbox• 15 years ago

Will this effect other uses of TCP than HTTP? Like IRC or SSH?

lorax• 15 years ago

Most of these changes seem focused on improving small, short-lived connections. IRC and SSH are mostly long-lived and I don't think it will have a noticeable impact on them. For large bulk data transfers (like sep or ftp) the Proportional Rate Reduction for TCP (PRR) should help.

tmcw• 15 years ago

I hope that this really actually helps everyone. SPDY has been in Chrome & on Google Maps and such for a long time, but not elsewhere: it's disabled on Firefox, unavailable on Safari and the like. And it's not implemented elsewhere: node-spdy is getting awesome but has taken a while to get there. Working for a place that could really benefit from something like SPDY, it seemed a bummer that only a duo of competitors products would work with an open protocol, for lack of documentation, interest, or what-have-you.

msmith• 15 years ago

This post is talking about changing TCP, not SPDY. The changes mentioned here would probably benefit SPDY as well, but to a lesser degree than HTTP, since SPDY was designed to handle multiple concurrent HTTP requests on a single TCP session.

modeless2• 15 years ago

SPDY seems poised for widespread adoption. It's only a matter of time before Firefox enables it, and the combined share of Chrome and Firefox is now over 50%. That should spur server adoption, and once it starts affecting benchmark scores the other browsers will be scrambling to implement it.

ajross• 15 years ago

OK, dumb question which I'm too lazy to look up for myself: what is TCP Fast Open, and how is it different from T/TCP? My vague memory is that the latter was dropped because allocating port numbers without requiring an explicit round trip simply could not be made robust vs. DDOS attacks. What tricks is TFO using that T/TCP didn't?

(edit: Not so lazy after all I guess. The draft RFC here: http://tools.ietf.org/html/draft-cheng-tcpm-fastopen-00 and after a very quick perusal I don't see an attempt to solve the DOS problem either. It seems like it just requires apps to handle the transactions really fast and then close the connection?)

nzmsv• 15 years ago

The "Fast Open Cookies" are designed to protect against the DDoS attacks. These are acquired by the client on the first TFO connection. Subsequent SYN packets reuse the cookie. The number of outstanding TFO cookies is limited. The paper on TCP Fast Open explains this in more detail than the RFC (http://research.google.com/pubs/pub37517.html)

necro• 15 years ago

2 years ago we were discussing a few of the direct advantages of this in a comment here http://news.ycombinator.com/item?id=1143317 including tcp_slow_start_after_idle which also interacts with icwnd.

Also it's much easier as of late to get the benefit from a larger initial cwnd. Back then you needed to recompile the kernel with source tweaks, now you just use a backport or depending on your distro version you already have the benefit as kernel 2.6.39 has the change... http://kernelnewbies.org/Linux_2_6_39

youngtaff• 15 years ago

If you need it IW10 can now be implemented on Windows Server 2008 R2 see - http://www.andysnotebook.com/2011/11/increasing-the-tcp-init...

Jim Gettys article "IW10 Considered Harmful" is worth a read too - http://tools.ietf.org/html/draft-gettys-iw10-considered-harm...

vy8vWJlco4• 15 years ago

TCP fast open (TFO) effectively fires data in the blind in the establishment phase and then handles the timeout gracefully. That sounds like vanilla UDP (or your favorite best-effort protocol) to me.

X-Istence2• 15 years ago

Except that it is handled by the kernel, rather than by the program itself.

vy8vWJlco4• 15 years ago

Do you mean that being ring-0 makes TCP faster, or insulates existing code?

JoeAltmaier2• 15 years ago

Lots of things about TCP&Co are stale, and don't work well in a modern network. That paper covers connection establishment. Other issues include network address establishment, device discovery and LAN broadcast.

In my last job creating mobile wireless drivers, we had a problem with wireless roaming. TCP/DHCP are set up assuming IP address establishment is a very infrequent operation. Typically it could take several seconds, which is fine if it only happens at boot or when a human trips over a cable and plugs it back in.

But wireless devices 'plug back in' each time they roam to a new AP. In an industrial environment (warehouse, 60 APs installed over several acres, forklift driving 20MPH) you may need to roam every second or so.

Its time to examine every aspect of TCP for large (huge) installations, very frequent device discovery (power-save in handheld devices), rapidly changing network topologies and so on.

IgorPartola• 15 years ago

Apparently Mac OS has a somewhat non-standard way to join networks with DHCP address assignment very fast. Otherwise, I agree.

sc68cal• 15 years ago

HN discussion of OS X dhcp fast resolution:

http://news.ycombinator.com/item?id=2755461

While it works, and works fast, many people raised concerns about the implications.

A broad summary of the trade-offs are here: http://news.ycombinator.com/item?id=2758576

wmf2• 15 years ago

It appears that Windows 8 has copied those optimizations as well. http://blogs.msdn.com/b/b8/archive/2012/01/20/engineering-wi...

modeless2• 15 years ago

I don't understand why LAN DHCP address assignment is so slow. RTT to the DHCP server is almost always in the single-digit millisecond range, so why does DHCP often take multiple seconds? Can someone explain this?

Karellen• 15 years ago

Hmmmm....the article prelude, and points 1 and 3, and the rationale document linked for point 2, all seem to be about optimising TCP for HTTP/the Web.

The thing is, a heck of a lot more runs over the Internet/TCP than just HTTP/the web. Also, it can very well be argued that a lot of the "end-user" perceived problems they are trying to fix (e.g. HTTP total request-response round trip latency) are acutally problems with HTTP, rather than TCP - notably the fact that for "small" web requests all HTTP effectively does is re-implement a datagram protocol (albeit with larger packets than UDP) on top of TCP, with all the consequent overhead of setting up and tearing down a TCP connection.

It's an interesting set of fixes. But are they the right fixes, at the right level? Would moving to SPDY instead of HTTP fix the problems better, at a more appropriate level? With less chance of impacting all the other protocols that run (and are yet to run) over TCP?

drucken• 15 years ago

Agreed. 1, 2 and 4 seem uncontroversial to non-TCP experts like me. But I do think we'd need a lot more re-assurance from old-hand TCP crafters as to whether 3 (TCP Fast Open) makes much sense, let alone worth the huge deployment effort.

Changing the fundament of the Internet purely for the sake of a higher level protocol (albeit an important one) in the stack seems dangerous. This would be the case, if for no other reason that it sets a precedent for future changes. Changes at each layer should always be as stack-agnostic as possible. This is by design.

forcefsck• 15 years ago

Furthermore 1,2 and 3 seem to make an impact only in establishing the initial connection, which is not that much time, even 40% latency decrease would be less than half a second gain in most situations, and if I got it right, the article states in point 3 that only 33% of http traffic is preceded with a new connection establishment.

Flenser• 15 years ago

I'm guessing googlebot creates a lot of initial connections and if this was implemented widely it would speed up crawling.

exor• 15 years ago

Why do us small business owners care about optimizing TCP?

Why does Google? Because web search is behind billions of dollars of revenue. Micro-optimizations matter to them.

Let's make TCP faster

Related Stories