Subject: Re: slow start and large windows
From: [email-masked] (Chris O'Neill)
To: [email-masked]
Date: Mon, 20 Sep 1993 15:28:02 +1000

Sean O'Malley in the original article of this thread stated that:

>Thus the time it takes (the congestion control algorithm of 
>TCP)to reach the original congestion window is:
>
>        (log2(n/2) + n/2) * the round trip time(RTT)
>        where n = window size/maximum segment size(MSS)
>
>Where n is large this algorithm will take a great deal of
>time to achieve the original window after a dropped packet.

I believe that most of the replies to this article so far have 
not given attention to what is often the most important term in 
the above expression, i.e.

            (n/2) * the round trip time (RTT)

so even though the Reno version of the algorithm avoids the 
slow start, it does not avoid the congestion avoidance phase 
which leads to the above term.

This is not necessarily a problem, of course, because the 
throughput and the window are not the same thing.  Their 
relationship to each other depends on the sizes of the 
delay-bandwidth product and the buffer at the bottleneck 
(as Shenker, Zhang and Clark illustrate in 'Some Observations 
on the Dynamics of a Congestion Control Algorithm' in Computer 
Communications Review, Oct 1990).  For example, if the buffer 
is larger than the (round trip delay)-bandwidth product, then 
full throughput is still achieved even with the window at half 
maximum size.  As the window is gradually increased, this 
simply leads to an increase in the number of packets in the 
buffer, without affecting throughput.

However, if the bottleneck buffer is smaller than the (round 
trip delay)-bandwidth product then throughput will be reduced 
when the window size is at half maximum size.  If the buffer 
is small compared with the delay-bandwidth product then the 
throughput will be just over half of the bottleneck speed.  
The throughput will slowly rise with the window size and take 
the time given in the above expression to reach the full 
bottleneck speed.  The Reno version of the algorithm, just 
like the Tahoe version, does not avoid this problem (as far 
as I know).

Also, at the beginning of a transmission, if the bottleneck 
buffer is relatively small then slow start will only get the 
window up to a relatively small value (with either Tahoe or 
Reno, I believe) and either version then takes a long time to 
get the window and throughput up to substantial values.

Hence I believe the Reno version does have its performance 
limitations in cases where the bottleneck buffer size is 
significantly smaller than the (round trip delay)-bandwidth 
product.

Chris O'Neill
Telecom Australia Research Labs