Date: Fri, 22nd Aug, 2003
ACN Lecture no:11
Scribe by: Rajesh Chepuri (Y3111036)

TCP Round trip estimation:

    TCP os an acknowledgement based protocol, and it needs to timout before it can retransmit. The variance  in RTT is very huge, so we need to estimate it dynamically.

Estimation measures:

EWMA : Exponentially Weighted Moving Average
SRTT : Smoothed RTT

The formula for calulating SRTT is ..
    SRTT = alpha * SRTT + (1 - alpha) * RTT_i
In this we have used the feedback of the previous SRTT value to caluculate the present SRTT. RTT_i is the present estimate of RTT. So here the change in SRTT is controlled by 'alpha'.  The range of 'alpha' is.
0 < alpha < 1
If 'alpha' value is large then the value of SRTT is retaining much of its previous value. It is resilient to spikes in RTT. If 'alpha' value is small then the SRTT value will change more rapidly with the present RTT. Experiment results shows that the RTT usually does not vary rapidly, spikes are short lasting. The typical value of 'alpha' is choosen to be 7/8.

Retransmission Time Out (RTO):
    Initially, RTO = beta * SRTT.
    Then the question is What should be the value of beta? If beta is smaller eg: 1 then there is a greater chance that the timeout will occur before ack will be received. This is really not desired. It wastes bandwidth. If the value of beta is larger then eg:5 then the delay in retransmitting the lost packets is large. Then the sender need to wait longer times. Initially people thought that beta  = 2 is sufficient. But generally the value of beta is not fixed, it must be varied according to the present network conditions. The value of RTO is caluculated by following formula which includes variance in RTT.
 RTO = SRTT  + 4 * RTT_Var.
    RTO Backoff :
            We can change RTO according the number of retrasmits of a given packet. We use exponential back off algorithm for his. In this first time when we send a packet if timeout occured, then the packet is sent again but we now double the RTO. In this way the RTO is keeps on incresing upto some value, after that we can declare that the host is unreacheable.

    RTT Sampling Ambiguity:
    There is a problem in caluculating the RTT_i(the present RTT estimate) whenever retransmit occur. When the retrasmit is occured the same  packet may be sent many times utill it reaches. The problem is taking which trasnmission into consideration in caluculating RTT_i.
    The choices are   ...
                                1. First Transmission.
                                2. Last Transmission.
                                3. Ignore RTT sample.

The  problems in each case are discussed below.
                1. First Transmission:
When we are considering the first transmission of a retransmitted packet in caluculating the RTT estimate, then there is a good chance of underestimating the RTT. Because in most cases the lost of packet is due to congestion, and if we use the same value in caluculating the RTT then the chance is that next packet will also need to be retransmitted.
                2. Last Transmission:
                                The problem with the above choice can be reduced by using the last retrasmission into consideration for caluculating the RTT estimate, but sometimes there is a chance of underestimating the value of RTT. Let us see how this happens.

                                       First                                 Timeout            Ack of             Ack of
                                Transmission                     Retransmission    First Trans.    Retransmission
Time Line -------------------|-----------------------------------|------------------|--------------------|----------------------------------------------------------------------------
                                                                                                        We will take this
                                                                                               as the ack for the retrasmission
        So after retrasmitting the paket if the ack for the initial trasmission comes then we decide that it is ack for retrasmission and we use this time for estimating RTT.
                3. Ignore RTT sample:
In this case we can neglect the sample in estimating the RTT sample. And so we will keep the previous value as it is. In the first look it seems that this has no problems. But there is a big problem in doing this. After all the loss of packet is due to congession and the retrasmission is due to timeout. So if we donot change the RTT value because we neglected the retransmitted sample, there is a great chance that the next packet will also need to be retrasmitted. We will neglect this packet too in RTT caluculation. In this way if congestion occurs it wont be known to the sender and every packet is then retrasmitted.
                            This is really big problem,  because what we really need is to change the RTT according the network conditions. But we are not doing it here.
                The Solution:
The solution to this problem is Karn's Algorithm.
                   Karn's Algorithm: It states that, if a retransmission occured then ignore the sample in caluculating the RTT, but maintain backed-off RTO until valid RTT sample comes.
                    We can also use timestamps to solve this problem. But it involves overhead and the present algorithms for header compression doesnot include timestamps.
(Header Compression: In modem connection all TCP headers will have common bytes, so we can give a tag, compress and that tag can be reffered to whole header.)

Fast Retransmission / Fast Recovery:

                Fast Retransmission:         
                    When in a transmission if a packet is lost then the receiver send ack reqesting that lost packets. The sender will send packet if timeout for that packet occurs. But in fast retransmission, the sender will not wait for timeout, it will retransmit if there are consequetive acks for the request of packet is received. The sender will retransmit a packet after it receives three duplicate acks for request of that packet comes. This is called Fast retransmission because it is not waiting for timeout before retranmitting the lost packet.
               ie, TCP detects packet loss by lookingfor packet reordering. Three out-of-order packets => Three dup-acks => Conclude packet loss.
               Fast Recovery:
When ever a retransmit occur, the congession window follows slow start algorithm in which it starts from the start. But a more effient algorithm can be used called Fast Recovery. In this the congession window is reduced to half instead of reducing it to 1. And for each ack it receives it will increse the congession window by 1(linearly). Like this, it can recover from the packet loss in more effiecient way.
        The following algorithm is Fast Recovery.
                            ssthresh = CWND / 2    /* When the number of dup-acks =3 then the congession window must be halved. */
                            CWND = ssthresh + 3
                            CWND++ for each dup-ack received.
                            On receiving first "fresh" ack
                                CWND = ssthresh.
 ( terms:- ssthresh : slow start thresh hold., CWND : congestion window)

        Congestion avoidance:
                            Now let us see how the congestion window behaves if retransmit occurs.
                            Let the size of congestion window is W, ie CWND = W, and the seqence number U is dropped. Let us assume that U is the starting of window. Therefore the packets in transit are [U,U+W). Now when the ack for the request of U arrives, the congestion window is pulled back to W/2. The size of congestion window is W, so in one RTT, W-1 dup-acks arrives.The number of new packets sent are W/2 - 1. Therefore the total number of packets sent are [U,U+W/2+W-1].  So now the new ack arrives asking for packet sequence U+W. So in total for W-1 acks the sender has sent only W/2 -1 new packets and for first W/2 dup-acks the sender does nothing. So the bottleneck clears.