Re: [HEADS UP] Significant TCP work committed to head - CUBIC & H-TCP committed

Hi Ivan,

On 12/03/10 00:07, Ivan Voras wrote:
> On 12/02/10 12:53, Lawrence Stewart wrote:
> 
>> For the really interested (by now I suspect my audience is down to 0,
>> but still), you might want to load siftr and enable/disable it during
>> each test run and make your very own plot of cwnd vs time to see what's
>> really going on behind the scenes.
>>
>> Ok that's enough for now, but much more is on the way. Please let me
>> know if you have any feedback or run into any problems related to this
>> work.
> 
> Hi,
> 
> My question isn't very constructive but I'd like to know more about this
> topic. Have you seen this:
> 
> http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html
> http://developers.slashdot.org/story/10/11/26/1729218/Google-Microsoft-Cheat-On-Slow-Start-mdash-Should-You

Yes I'd seen the first one and just skimmed the slashdot thread now.

> ? In short: is the existance of slow-start a property of (New)Reno and

No, mostly unrelated. Slow start is one of 4 separate but related
algorithms which control a TCP flow's behaviour during startup and
general operation. See RFC5681 for useful discussion of the algorithms.

NewReno unfortunately is an overloaded term. In congestion control
circles, NewReno is used to refer to the congestion avoidance behaviour
of "increase cwnd by 1 max seg size per RTT and backoff cwnd by half
when congestion (3 dup ACKs) is detected" (which is the same basic
behaviour as Reno BTW). NewReno also refers to a set of tweaks (RFC3782)
to TCP's fast recovery algorithm (helps recover from multiple losses in
a window when SACK isn't available).

> will some of the new algorithms make it less "cautious", i.e. faster? I
> don't think it's critical but I'm often noticing it, especially on bulk
> transfers over LAN.

With respect to slow start, no. Congestion control algorithms tend to
focus on the increase/decrease of cwnd during congestion avoidance mode,
which is transitioned to after slow start completes. Slow start is left
untouched. There are proposals to modify/replace slow start e.g. RFC4782
and 'JumpStart' [1].

The reason Google and Microsoft are fiddling with things are because
they typically only need to push a small amount of data, so waiting for
slow start to complete eats up unnecessary RTTs. Google are pushing in
the IETF at the moment to have the initial window bumped to 10 segments
(see the tcpm, iccrg and tmrg IRTF/IETF mailing lists if interested).
There is some push back happening though and the discussions are
interesting.

Cheers,
Lawrence

[1] http://www.icir.org/mallman/papers/jumpstart-pfldnet07.pdf