Slow Start And Delayed ACK
----------------------------------
  
   The TCP specification requires an algorithm known as "slow start". The
   algorithm applies to the sender side and is described in RFC2001.
   
   The intent of the slow start algorithm is to avoid a "congestion
   collapse" in a network by ensuring that each TCP sender doesn't
   overwhelm the network. The algorithm mandates that the first
   transmission be a single packet. If the recipient acknowledges the
   first packet successfully (i.e. the communication doesn't time out and
   the recipient believes that the packet has arrived without error), the
   sender sends two more packets. Successful transmission results in the
   sender sending yet more packets in parallel, until the capability of
   the underlying network is reached and one or more packets are not
   acknowledged successfully. Essentially the sender uses ACKs as a
   "clock" to regulate and gradually increase the rate packets are
   injected into the network until it reaches an equilibrium.
   
   The TCP specification describes another technique known as "delayed
   ACK", which concerns the receive side. The technique calls for an
   acknowledgement of a data packet to be delayed for a short period of
   time - the delayed-ACK interval. Different TCP implementations use
   different delay intervals. The TCP specification (RFC1122) mandates
   that the delayed-ACK interval must be less than 0.5 second. Delayed
   ACK serves to give the application an opportunity to send an immediate
   response, in which case the ACK can be piggyback'ed with the packet
   carrying the response. This technique is very useful, both in saving
   the network bandwidth and in reducing the protocol processing
   overhead, and is widely adopted by TCP implementations. The TCP
   standard also recommends that an ACK not to be delayed for more than
   two data packets. This is to keep the slow start algorithm on the
   sender side flowing, which counts on the ACK packets coming back from
   the receive side in order to strobe more data packets into the
   network.
   
  TCP Sender/Reciever Deadlock - The IDLE Time
----------------------------------------------------
  
   A simplistic implementation of delayed ACK can cause unnecessary idle
   time during the initial data transfer phase in a client-server network
   environment. The scenario is as follows. When a sender request can't
   fit in one TCP packet, TCP will break it up into multiple packets.
   During the initial slow start phase, the sender is allowed to send
   only one packet. Therefore only a partial sender request is sent. The
   receiver application, upon receiving the data in the packet, is not
   able to respond because the data is incomplete. In the mean time, the
   receiver TCP is holding back the ACK, waiting for the second data
   packet to show up. But the sender TCP is waiting for an ACK to come
   back before sending more data - a temporary deadlock. Eventually, the
   receiver TCP will give up the waiting after a delayed-ACK interval,
   and send back an ACK.
   
   This interplay of a simplistic delayed-ACK implementation with
   slow-start algorithm accounts for the idle time problem seen in a
   number of WEB benchmarks. These benchmarks employ HTTP response
   messages of at least 8KB and usually more. On a typical network, this
   size of data requires more than one TCP packet to carry.
   
   During the idle time, the client TCP holds back the acknowledgement of
   the first packet while the client HTTP is waiting for the rest of the
   response data from the server before it can issue the next HTTP
   request. But the server is waiting for the client TCP to ACK before it
   can send the rest of response data.
   
   Note that the effect is to delay packet transmission, the delay is
   much shorter than the initial retransmission delay of three seconds so
   this does not cause retransmissions by the server or client.


----------------------------------------------------------------------