Subject: TCP Slow-Start

From: "Chadi M. BARAKAT" <[email-masked]>
Date: Thu, 25 Feb 1999 13:44:19 +0100

Hello, 

I am interested in my current work in the slow start phase of TCP. It is
clear that this algorithm is necessary to increase gradually the
congestion window so that to not overwhelm the network buffers and to
activate smoothly the ACK clock. At the beginning of the connection, it
serves also to estimate the available capacity of the network. 
But such slow increase deteriorates the performance of the protocol when
long delay paths such as satellite links are crossed by the connection.
Large initial window avoids some Round Trips at the beginning of the
connection but it may result in losses because this initial window is
transmitted in a burst. I think that the appropriate solution to this
problem is a kind of available bandwidth estimation. However, estimating
the available bandwidth is difficult to be implemented. I am
investigating another solution which lets TCP send many packets at the
beginning of the connection but not in a bursty manner as with large
initial window.

A timer of value smaller than timeout (saying 50ms or 100ms) is set when
the first packet is sent. This timer is canceled when an ACK is
received. If the timer expires, this means that an ACK has not been
received. The source supposes here that a long delay path has been
crossed by the connection and therefore it transmits a new packet and
sets again the timer. The absence of an ACK may be due to the loss of
the first packet. This loss is still detected via timeout.  
This timer is set in the first Round Trip Time at the beginning of the
connection. We can set it also whenever a timeout occurs. Once we
receive an ACK, a normal slow start is done. The window is increased by
one MSS for every new ACK.

This solution results in many packets transmitted at the beginning of
the connection (proportional to RTT) but spaced so that to not overload
the network. It functions only in case of long delay paths. With small
RTTs, an ACK is received before the expiration of the added timer and a
single packet is thus transmitted in the first RTT (the delayed ACK at
the receiver may affect this behavior). I think that spreading out the
first packets sent during slow start may result in separate bursts
during the subsequent RTTs. It is known that bursts sent during slow
start overload the network buffers due to their high rate. Reducing the
size of these bursts may avoid some losses. 

The idea is at the beginning, I don't know exactly what will be its
negative effect on TCP and on the network. Also, the overload it causes 
to the operating system must be investigated. Any feedback on this issue
will be very appreciated. 

Thanks in advance 

Chadi
-- 
                    **  Chadi Mohamad BARAKAT  **
           http://www.inria.fr/mistral/personnel/Chadi.Barakat
                                  /\
PhD Student - MISTRAL - INRIA    /  \   [email-masked]
2004, Route des Lucioles BP 93   \  /   Phone : + 33 4 92 38 71 99
06902 Sophia Antipolis - France   \/    Cell  : + 33 6 10 42 36 30

---

From: Neal Cardwell <[email-masked]>
Date: Thu, 25 Feb 1999 09:47:52 -0800 (PST)

> sets again the timer.

Resetting this new timer sounds risky. It implicitly makes an assumption
about the absolute magnitude of the bandwidth of Internet paths, an
assumption which could be incorrect in some common cases. For example,
what happens if there is a low bandwidth link on this path (say, a 28Kbps
modem)? With MSS=1460 and using 100ms for this timer, by the end of the
first RTT (more than 500ms later) this scheme will have sent 5 packets, or
7300 bytes, when the bandwidth-delay of the path is closer to 28Kbps*.5s =
1750 bytes, slightly more than one packet.

> I think that spreading out the

This will smooth out some of the burstiness, but there will still be a lot
left. Consider that when the sender gets ACKs, usually for two packets, it
will send out a burst of three packets. This burst of three will result in
another (in general, larger) burst when the ACKs for these packets are
received in the next RTT, and so on...

neal