If you’re a SPDY server implementor, you’ve likely already read about the impact of CWND. Fortunately, the TCP implementors now largely agree that we can now safely increase CWND, and the standard will likely change soon. The default linux kernel implementation already has.
But, there is a second cwnd-related kernel flag which is not often mentioned. It’s important in all cases, but particularly important if you’re trying to establish long-lived connections. It’s not just important to SPDY – it’s important for HTTP keepalives or pipelines too. And many of the large web service providers are already tuning it:
> sysctl -a | grep tcp_slow_start_after_idle net.ipv4.tcp_slow_start_after_idle = 1
At casual glance, you probably think “this sounds good, after a minute or so, it will go back into slow start mode”. That is fine, right?
Not quite. “Idle” in this case doesn’t mean a ‘minute or so’. In fact, it doesn’t even mean a second. This flag comes from RFC2861‘s recommendation, which states that cwnd be cut in half with each RTT of idleness. That means that a persistently held open connection soon degrades back to the performance of an un-warmed connection very quickly.
So why does this matter? If you’re attempting to use a long-lived SPDY connection and think that the initial CWND won’t affect you because you’re only opening one connection anyway, you’re wrong. The slow-start-after-idle will still get you.
While there has been a tremendous amount of investigation and discussion about the initial cwnd value, I’m not aware of any recent debate about the slow-start-after-idle. I know that many websites are already disabling this flag to make HTTP keepalive connections perform more reasonably. Sadly, I can’t find any research which actually measured the effects of this behavior in the real world, so I can’t fall back on any real data. Given how aggressive TCP already is at backing off should network congestion change, I see no reason to enable this flag. Further, if you’re helping the net by dropping from N connections to 1, there is no reason you should be further penalized for your good deeds! Turn this one off.
Good article Mike. We have actually worked on this problem intensively – a recent IETF draft on this topic:
http://tools.ietf.org/html/draft-fairhurst-tcpm-newcwv-02. You can also check out some papers in this topic from the informative references..
I do not see the need for TCP to follow slow-start after idle..It can keep the same cwnd before idle, but must ensure it responds to congestion appropriately. A few RTTs of aggressiveness may not be harmful IMHO..