A Comparative Analysis

Document Sample
A Comparative Analysis Powered By Docstoc
					            A Comparative Analysis of TCP Tahoe, Reno,
                  New-Reno, SACK and Vegas

    The purpose of this paper is to               losses due to network loss are
analyze and compare the different             minimal and most of the packet losses
congestion control and avoidance              are due to buffer overflows at the
mechanisms which have been proposed           router[1]. Thus it becomes increasingly
for TCP/IP protocols, namely: Tahoe,          important for TCP to react to a packet
Reno, New-Reno, TCP Vegas and                 loss and take action to reduce
SACK. TCP’s robustness is as a result of      congestion.
it’s reactive behavior in the face of             TCP ensures reliability by starting a
congestion, and fact that reliability is      timer whenever it sends a segment. If it
ensured by re-transmissions. All the          does not receive an acknowledgement
above     mentioned     implementations       from the receiver within the ‘time-out’
suggest mechanisms for determining            interval then it retransmits the segment.
when a segment should be re-transmitted           We shall start the paper by taking a
and how should the sender behave when         breif look at each of the congestion
it encounters congestion and what             avoidance algorithms and noting how
pattern of transmissions should it follow     they differ from each other. In the end
to avoid congestion. In this paper we         we shall do a head to head comparison to
shall discuss how the different               further bring into light the differences.
mechanism affect the through put and
efficiency of TCP and how they compare
with TCP Vegas in terms of                    TCP TAHOE:
performance.                                      Tahoe refers to the TCP congestion
                                              control algorithm which was suggested
                                              by Van Jacobson in his paper[1]. TCP is
Introduction:                                 based on a principle of ‘conservation of
    TCP is a reliable connection oriented     packets’, i.e. if the connection is running
end-to-end protocol. It contains within       at the available bandwidth capacity then
itself,    mechanisms       for   ensuring    a packet is not injected into the network
reliability by requiring the receiver the     unless a packet is taken out as well.
acknowledge the segments that it              TCP implements this principle by using
receives. The network is not perfect and      the acknowledgements to clock outgoing
a small percentage of packets are lost en     packets because an acknowledgement
route, either due to network error or due     means that a packet was taken off the
to the fact that there is congestion in the   wire by the receiver. It also maintains a
network and the routers are dropping          congestion window CWD to reflect the
packets. We shall assume that packet          network capacity[1]. However there are
                                              certain issues, which need to be resolved
                                              to ensure this equilibrium.
1)     Determination of the available
       bandwidth.                              Congestion Avoidance:
2)     Ensuring that equilibrium is                For congestion avoidance Tahoe uses
       maintained.                             ‘Additive       Increase    Multiplicative
3)     How to react to congestion.             Decrease’. A packet loss is taken as a
                                               sign of congestion and Tahoe saves the
Slow Start:                                    half of the current window as a
    TCP packet transmissions are               threshold. value. It then set CWD to one
clocked        by        the       incoming    and starts slow start until it reaches the
acknowledgements. However there is a           threshold value. After that it increments
problem when a connection first starts         linearly until it encounters a packet loss.
up cause to have acknowledgements you          Thus it increase it window slowly as it
need to have data in the network and to        approaches the bandwidth capacity.
put data in the network you need
acknowledgements. To get around this           Problems:
circularity Tahoe suggests that whenever           The problem with Tahoe is that it
a TCP connection starts or re-starts after     take a complete timeout interval to
a packet loss it should go through a           detect a packet loss and in fact, in most
procedure called ‘slow-start’. The reason      implementations it takes even longer
for this procedure is that an initial burst    because of the coarse grain timeout.
might overwhelm the network and the            Also since it doesn’t send immediate
connection might never get started. Slow       ACK’s,      it     sends      cumulative
starts suggests that the sender set the        acknowledgements, there fore it follows
congestion window to 1 and then for            a ‘go back n ‘ approach. Thus every
each ACK received it increase the CWD          time a packet is lost it waits for a
by 1. so in the first round trip time(RTT)     timeout and the pipeline is emptied. This
we send 1 packet, in the second we send        offers a major cost in high band-width
2 and in the third we send 4. Thus we          delay product links.
increase exponentially until we lose a
packet which is a sign of congestion.
When we encounter congestion we                TCP RENO:
decreases our sending rate and we                  This Reno retains the basic principle
reduce congestion window to one. And           of Tahoe, such as slow starts and the
start over again.                              coarse grain re-transmit timer. However
    The important thing is that Tahoe          it adds some intelligence over it so that
detects packet losses by timeouts. In          lost packets are detected earlier and the
usual      implementations,         repeated   pipeline is not emptied every time a
interrupts are expensive so we have            packet is lost.
coarse      grain      time-outs      which        Reno requires that we receive
occasionally checks for time outs. Thus        immediate acknowledgement whenever
it might be some time before we notice a       a segment is received. The logic behind
packet loss and then re-transmit that          this is that whenever we receive a
packet.                                        duplicate acknowledgment, then his
                                               duplicate acknowledgment could have
                                               been received if the next segment in
sequence expected, has been delayed in         reduce the CWND to SSthresh. If we
the network and the segments reached           had previously received (w-1) duplicate
there out of order or else that the packet     ACK’s then at this point we should have
is lost. If we receive a number of             exactly w/2 segments in the pipe which
duplicate acknowledgements then that           is equal to what we set the CWND to be
means that sufficient time has passed          at the end of fast recovery. Thus we
and even if the segment had taken a            don’t empty the pipe, we just reduce the
longer path, it should have gotten to the      flow. We continue with congestion
receiver by now. There is a very high          avoidance phase of Tahoe after that.
probability that it was lost. So Reno
suggest an algorithm called ‘Fast Re-          Problems:
Transmit’. Whenever we receive 3                   Reno perform very well over TCP
duplicate ACK’s we take it as a sign that      when the packet losses are small. But
the segment was lost, so we re-transmit        when we have multiple packet losses in
the segment without waiting for timeout.       one window then RENO doesn’t
Thus we manage to re-transmit the              perform too well and it’s performance is
segment with the pipe almost full.             almost the same as Tahoe under
    Another modification that RENO             conditions of high packet loss. The
makes is in that after a packet loss, it       reason is that it can only detect a single
does not reduce the congestion window          packet losses. If there is multiple packet
to 1. Since this empties the pipe. It enters   drop then the first info about the packet
into a algorithm which we call ‘Fast-Re-       loss comes when we receive the
Transmit’[2]. The basic algorithm is           duplicate ACK’s. But the information
presented as under:                            about the second packet which was lost
    1)Each time we receive 3 duplicate         will come only after the ACK for the re-
ACK’s we take that to mean that the            transmitted first segment reaches the
segment was lost and we re-transmit the        sender after one RTT.
segment immediately and enter ‘Fast-               Also it is possible that the CWD is
Recovery’                                      reduced twice for packet losses which
2)Set SSthresh to half the current             occurred in one window. Suppose we
window size and also set CWD to the            send packets 1,2,3,4,5,6,7,8,9 in that
same value.                                    order. Suppose packets 1, and 2 are lost.
3)For each duplicate ACK receive               The ACK’s generated by 2,4,5 will
increase CWD by one. If the increase           cause the re-transmission of 1 and the
CWD is greater than the amount of data         CWD is reduced to 7. Then when we
in the pipe then transmit a new segment        receive ACK for 6,7,8,9 our CWD is
else wait. If there are ‘w’ segments in        sufficiently large to allow to us to send
the window and one is lost, the we will        10,11. When the re-transmitted segment
receive (w-1) duplicate ACK’s. Since           1 reaches the receiver we get a fresh
CWD is reduced to W/2, therefore half a        ACK and we exit fast-recovery and set
window of data is acknowledged before          CWD to 4. Then we get two more
we can send a new segment. Once we re-         ACK’s for 2(due to 10,11) so once again
transmit a segment, we would have to           we enter fast-retransmit and re-transmit
wait for atlease one RTT before we             2 and then enter fast recovery. Thus
would receive a fresh acknowledgement.         when we exit fast recovery for the
Whenever we receive a fresh ACK we             second time our window size is set to 2.
Thus we reduced our window size twice        and sets the number of duplicate ACKS
for packets lost in one window.              received to zero.
    Another problem is that if the widow         It exits Fast recovery when all the
is very small when the loss occurs then      data in the window is acknowledged[3].
we would never receive             enough
duplicate acknowledgements for a fast-       Problems:
retransmit and we would have to wait for         New-Reno suffers from the fact that
a coarse grained timeout. Thus is cannot     its take one RTT to detect each packet
effectively detect multiple packet losses.   loss. When the ACK for the first re-
                                             transmitted segment is received only
                                             then can we deduce which other segment
NEW-RENO:                                    was lost.
    New RENO is a slight modification
over TCP-RENO. It is able to detect
multiple packet losses and thus is much      SACK:
more efficient that RENO in the event of         TCP           with          ‘Selective
multiple packet losses.                      Acknowledgments’ is an extension of
    Like Reno, New-Reno also enters          TCP Reno and it works around the
into fast-retransmit when it receives        problems face by TCP RENO and TCP
multiple duplicate packets, however it       New-Reno, namely detection of multiple
differs from RENO in that it doesn’t exit    lost packets, and re-transmission of more
fast-recovery until all the data which was   than one lost packet per RTT.
out standing at the time it entered fast-        SACK retains the slow-start and fast-
recovery is acknowledged. Thus it            retransmit parts of RENO. It also has the
overcomes the problem faced by Reno of       coarse grained timeout of Tahoe to fall
reducing the CWD multiples times.            back on, incase a packet loss is not
    The fast-transmit phase is the same      detected by the modified algorithm.
as in Reno. The difference in the fast-          SACK TCP requires that segments
recovery phase which allows for              not be acknowledged cumulatively but
multiple re-transmissions in new-Reno.       should be acknowledged selectively.
Whenever new-Reno enters fast-               Thus each ACK has a block which
recovery it notes the maximums segment       describes which segments are being
which is outstanding. The fast-recovery      acknowledged. Thus the sender has a
phase proceeds as in Reno, however           picture of which segments have been
when a fresh ACK is received then there      acknowledged and which are still
are two cases:                               outstanding. Whenever the sender enters
    If it ACK’s all the segments which       fast recovery, it initializes a variable
were outstanding when we entered fast-       pipe which is an estimate of how much
recovery then it exits fast recovery and     data is outstanding in the network, and it
sets CWD to ssthresh and continues           also set CWND to half the current size.
congestion avoidance like Tahoe.             Every time it receives an ACK it reduces
                                             the pipe by 1 and every time it re-
   If the ACK is a partial ACK then it       transmits a segment it increments it by 1.
deduces that the next segment in line        Whenever the pipe goes smaller than the
was lost and it re-transmits that segment    CWD window it checks which segments
                                             are un received and send them. If there
are no such segments outstanding then it        acknowledgment to get back. Whenever
sends a new packet[5]. Thus more than           a duplicate acknowledgement is received
one lost segment can be sent in one             it checks to see if the (current time-
RTT.                                            segment transmission time)> RTT
                                                estimate; if it is then it immediately re-
Problems:                                       transmits the segment without waiting
    The biggest problem with SACK is            for 3 duplicate acknowledgements or a
that          currently      selective          coarse timeout[6]. Thus it gets around
acknowledgements are not provided by            the problem faced by Reno of not being
the receiver To implement SACK we’ll            able to detect lost packets when it had a
need       to    implement   selective          small window and it didn’t receive
acknowledgment which is not a very              enough duplicate Ack’s.
easy task.                                           To catch any other segments that
                                                may have been lost prior to the re-
                                                transmission, when a non duplicate
VEGAS:                                          acknowledgment is received, if it is the
    Vegas is a TCP implementation               first or second one after a fresh
which is a modification of Reno. It             acknowledgement then it again checks
builds on the fact that proactive measure       the timeout values and if the segment
to encounter congestion are much more           time since it was sent exceeds the
efficient than reactive ones. It tried to get   timeout value then it re-transmits the
around the problem of coarse grain              segment without waiting for a duplicate
timeouts by suggesting an algorithm             acknowledgment[6]. Thus in this way
which checks for timeouts at a very             Vegas can detect multipple packet
efficient schedule. Also it overcomes the       losses.
problem of requiring enough duplicate                Also it only reduces its window if
acknowledgements to detect a packet             the re-transmitted segment was sent after
loss, and it also suggest a modified slow       the last decrease. Thus it also overcome
start algorithm which prevent it from           Reno’s shortcoming of reducing the
congesting the network. It does not             congestion window multiple time when
depend solely on packet loss as a sign of       multiple packets are lost.
congestion. It detects congestion before
the packet losses occur. However it still
retains the other mechanism of Reno and         Congestion avoidance:
Tahoe, and a packet loss can still be               TCP Vegas is different from all the
detected by the coarse grain timeout of         other implementation in its behavior
the other mechanisms fail.                      during congestion avoidance. It does not
    The three major changes induced by          use the loss of segment to signal that
Vegas are:                                      there is congestion. It determines
                                                congestion by a decrease in sending rate
New Re-Transmission Mechanism:                  as compared to the expected rate, as
    Vegas extends on the re-transmission        result of large queues building up in the
mechanism of Reno. It keeps track of            routers. It uses a variation of Wang and
when each segment was sent and it also          Crowcroft;s Tri-S scheme. The details
calculates an estimate of the RTT by            can found in [6]. Thus whenever the
keeping track of how long it takes for the      calculated rate is too far away from the
expected rate it increases transmissions          congestion avoidance and slow
to make use of the available bandwidth,           start     algorithms       measure
whenever the calculated rate comes too            incipient congestion and very
close to the expected value it decreases          accurately measure the available
its transmission to prevent over                  bandwidth        available     and
saturating the bandwidth. Thus Vegas              therefore use network resources
combats congestion quite effectively and          efficiently and don’t contribute to
doesn’t waste bandwidth by transmitting           congestion.
at too high a data rate and creating
congestion and then cutting back, which        2)Reno:
the other algorithms do.                       • More than half of the coarse-
                                                  grained timeouts of Reno are
Modified Slow-start:                              prevented by Vegas as it detects
    TCP Vegas differs from the other              and re-transmits more than one
algorithms during it’s slow-start phase.          lost packet before timeout
The reason for this modification is that          occurs.
when a connection first starts it has no       • It doesn’t have to always wait for
idea of the available bandwidth and it is         3 duplicate packets so it can re-
possible that during exponential increase         transmit sooner.
it over shoots the bandwidth by a big          • It doesn’t reduce the congestion
amount and thus induces congestion. To            window too much prematurely.
this end Vegas increases exponentially         • The advantages that it has in
only every other RTT, between that it             congestion      avoidance    and
calculates the actual sending through put         bandwidth utilization over Tahoe
to the expected and when the difference           exist here as well.
goes above a certain threshold it exits
slow start and enters the congestion           3)New-Reno:
avoidance phase.                               • It prevents many of the coarse
                                                  grained timeouts of New-Reno as
                                                  it doesn’t need to wait for
                                                  3duplicate ACK’s before it
                                                  retransmits a lost packet.
Conclusion:                                    • Its       congestion      avoidance
    Thus it is clear that TCP Vegas is            mechanisms to detect ‘incipient’
definitely better than                            congestion are very efficient and
    1)Tahoe:                                      utilize nework resources much
    • Cause it is much more robust in             more efficiently.
        the face of lost packets. It can       • Because        of    its   modified
        detect and retransmit lost packet         congestion avoidance and slow
        much sooner than timeouts in              start algorithm there are fewer re-
        Tahoe.                                    transmits.
    • It also has fewer re-transmissions
        since it doesn’t empty the whole       4)SACK:
        pipe whenever it loses packets.        TCP Vegas doesn’t have a clear cut
    • It is better at congestion            advantage over SACK TCP. The only
        avoidance and its modified
fields where it apprears to outperform        References:
SACK is:                                      [1]V.Jacobson. “Congestion Avoidance
• In its estimation of incipient                 and            Control”.SIGCOMM
    congestion,    and    its   efficient        Symposium      no     Cummunication
    estimation    of   congestion     by         Architecture and protocols.
    measuring change in throughput
    rather than packet loss. This would       [2]V.Jacobson “Modified TCp
    result in a better utilization of            Congestion Control and Avoidance
    bandwidth and lesser congestion.             Alogrithms”.Technical     Report
                                                 30,Apr 1990.
•   Also it appears more stable than
    SACK. The reason for this being that      [3]S.Floyd, T.Henderson “The New-
    SACK uses packet losses to denote            Reno Modification to TCP’s Fast
    congestion. So that the sender               Recovery Algorithm” RFC 2582,
    continually increase sending rate            Apr 1999.
    until there is congestion and then
    they cur back. This cycle continues       [4]O. Ait-Hellal, E.Altman “Analysis of
    and the system keeps on oscillating..        TCP Reno and TCP Vegas”.
    TCP Vegas flattens out its sending
    rate at the optimal bandwidth             [5]K.Fall, S.Floyd “Simulation Based
    utilization point thus inducing              Comparison of Tahoe, Reno and
    stability.                                   SACK TCP” .

•   Another advantage of TCP Vegas or         [6]L.S.Brakmo, L.L. Peterson, “TCP
    rather the disadvantage of SACK is           Vegas: End to End Congestion
    that it is not very easy to incorporate      Avoidance on a Global Internet”,
    SACK in the current TCP. We need             IEEE Journal on Selected Areas in
    fields to acknowledge the selective          Communication, vol. 13[1995],(1465-
    segments and this requires changes           1490).
    at the receiver as well, whereas all
    the other mentioned algorithms only
    require changes at the sender side.

Shared By: