Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

COMPARATIVE STUDY OF CONGESTION CONTROL MECHANISM OF TCP VAR

No description
by

prabhjot kaur

on 5 May 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of COMPARATIVE STUDY OF CONGESTION CONTROL MECHANISM OF TCP VAR

TCP NEW RENO
COMPARATIVE STUDY OF CONGESTION CONTROL MECHANISM OF TCP VARIANTS USING NS2
TCP TAHOE
NEW RENO
INTRODUCTION
TCP is a reliable connection oriented end-to-end protocol. It contains within itself, mechanisms for ensuring reliability by requiring the receiver the acknowledge the segments that it receives. The network is not perfect and a small percentage of packets are lost en route, either due to network error or due to the fact that there is congestion in the network and the routers are dropping packets. We shall assume that packet losses due to network loss are the packet losses are due to buffer overflows at router. Thus it becomes increasingly important for TCP to react to a packet loss and take action to reduce congestion.
TCP ensures reliability by starting a timer whenever it sends a segment. If it does not receive an acknowledgement from the receiver within the ‘time-out’ interval then it retransmits the segment.

BRAINSTORM
ELEMENTS
copy and paste as needed to add notes to your brainstorm
submitted by:
Prabhjot kaur(04813202810)
Sukhmeet Singh(0531202810)
Guneet Singh(05413202810)
Sunpreet kaur(06013202810)
Mentor- Mr. Puneet Singh

TCP RENO
TCP ALGORITHMS
SLOW START
Slow start is conducted in the beginning of every TCP connection and its main purpose is to find the maximum available bandwidth at which it can send data without using the network to be congested. It remarks that the rate at which new packets should be introduced into the network is same as the rate at which the acknowledgments are returned by the other end. It delimits a “congestion window” (cwnd) for a new connection with size one segment. Every time an ACK (acknowledgement) is received this window is increased by one window. Sender can send data up to cwnd or advertised window.
CONGESTION AVOIDANCE
If the receiver window is large enough, the slow start mechanism described in the previous routers in between the hosts will start discarding packets.TCP invokes the Congestion Avoidance mechanism. Packets are sent taking into account the minimum of cwnd and the receiver's advertised i.e one-half of the current window size but at least two segments. Congestion is indicated by a timeout or the reception of duplicate ACKs. When congestion occurs, one-half of the current window size is saved in ssthresh (slow start threshold) and cwnd is set to one segment (i.e., slow start). When new data is acknowledged by the other end, increases the cwnd depending on whether TCP is performing slow start or congestion avoidance.
FAST RETRANSMIT
A duplicate ACK is generated by TCP when an out- of-order segment is received. This immediate duplicate ACK briefs the other end that a segment was received out of order, and what sequence number is expected. It is assumed that if there is just a reordering of the segments, there will be only one or two duplicate ACKs before the reordered segment is processed, which will then generate a new ACK. If three or more duplicate ACKs are received in a row, it is a strong indication that a segment has been lost.
TCP then performs a retransmission of what appears to be the missing segment, without waiting for a retransmission timer to expire.The fast retransmit and fast recovery algorithms are usually implemented together as follows:
(a) When the third duplicate ACK in a row is received
– set ssthresh to one-half the current cwnd, but no less than two segments and Retransmit the missing segment.
(b) Each time another duplicate ACK arrives,
– increment cwnd by the segment size and Transmit a packet, if allowed by the new value of cwnd.
(c) When the next ACK arrives that acknowledges new data
– set cwnd to ssthresh.
– This ACK should acknowledge all the intermediate segments sent between the lost packet and the receipt of the first duplicate ACK.
– This step is congestion avoidance, since TCP is down to one-half the rate it was at when the packet was lost.


FAST RECOVERY
After fast retransmit is conducted, congestion avoidance is performed. This behavior is called Fast Recovery. Fast recovery is an algorithm that allows for higher throughput under congestion, especially when using large congestion windows. Receiving three duplicate acknowledgments tells TCP more than the expiration of the retransmission timer . Since the receiving, TCP only can generate duplicate acknowledgments when it is receiving other segments it is an indication that data still flows between the different hosts, and that the congestion is not that severe. By using this approach, skipping the slow start, the TCP does not reduce the transfer rate unnecessarily much.







TCP VARIANTS
TCP TAHOE
Tahoe, as suggested by Van Jacobson, refers to the TCP congestion control algorithm. An acknowledgement connotes delivery of the packet to the receiver. TCP uses these acknowledgements to time the retiring packets implementing the principle of ‘conservation of packets’, i.e. if the connection is running at the available bandwidth capacity then a packet is not inserted into the network unless a packet is taken out as well. It also maintains a congestion window CWD to exhibit the network capacity.
LIMITATIONS-To detect a packet loss TCP takes a complete timeout interval and as a matter of fact, in most enactments it takes even longer because of the coarse grain timeout and since it doesn’t send immediate ACK’s, it sends cumulative acknowledgements; therefore it follows a ‘go back N’ approach. Thus every time a packet is lost it waits for a timeout and the pipeline is emptied. This offers a major cost in high band-width delay product links and hence poses a major drawback.
TCP RENO
TCP Reno is the most widely adopted Internet TCP protocol. Four transmission phases: slow start, congestion avoidance, fast retransmit, and fast recovery are deployed. The sender receives three duplicate acknowledgments or the sender’s retransmission timeout (RTO) timer expires on encountering a packet loss in a congested link owing to buffer overflow in the intermediate routers. TCP fast retransmit and recovery algorithms are activated by the sender and its congestion window size is reduced to half when three duplicate ACKs are received. Then congestion window increases linearly, similar to the case of congestion avoidance. This boost in transmission rate is slower than in the case of slow start and helps dismisses congestion. TCP Reno fast recovery algorithm improves TCP performance in case of a single packet loss within a window of data. However, performance of TCP Reno suffers in case of multiple packet losses within a window of data.
LIMITATIONS-Reno’s congestion detection and control mechanismsuse the loss of segments as a signal that there is congestion inthe network. TCP Reno has therefore no mechanism to detectthe developing stages of congestion before losses occur and cannot prevent such losses. Further it can only detect a single packet loss and hence its performance is almost the same as Tahoe under conditions of multiple packet loss. In the case of multiple packet dropthe information about the first packet loss comes when the duplicate ACK’s are received, but about the second lost packet will come only after the ACK for the first retransmitted segment reaches thesender after one RTT. Alsothe CWD sometimes is reduced twice for packet losses which occurred in one window. Also if the widow is very small when the loss occurs then we would never receive enough duplicate acknowledgements for a fast retransmit and we would have to wait for a coarse grained timeout. Thus it cannot effectively detect multiple packet losses
New RENO is a slight modification over TCP-RENO. It is able to detect multiple packet losses and thus is much more efficient that RENO in the event of multiple packet losses. Like Reno, New-Reno also enters into fast-retransmit when it receives multiple duplicate packets, however it differs from RENO in that it doesn’t exit fast-recovery until all the data which was out standing at the time it entered fast recovery is acknowledged. Thus it overcomes the problem faced by Reno of reducing the CWND multiples times. The fast-transmit phase is the same as in Reno. The difference in the fast recovery phase which allows for multiple re-transmissions in new-Reno. Whenever new-Reno enters fast recovery it notes the maximum segment which is outstanding. The fast-recovery phase proceeds as in Reno, however when a fresh ACK is received then there are two cases: If it ACK’s all the segments which were outstanding when we entered fast recovery then it exits fast recovery and sets CWND to ssthresh and continues congestion avoidance like Tahoe. If the ACK is a partial ACK then it deduces that the next segment in line was lost and it re-transmits that segment and sets the number of duplicate ACKS received to zero. It exits Fast recovery when all the data in the window is acknowledged.

LIMITATIONS-: New-Reno suffers from the fact that it takes one RTT to detect each packet loss. When the ACK for the first retransmitted segment is received only then can we deduce which other segment was lost. Round-trip time until all of the lost packets from that window has been retransmitted.
TCP VEGAS
Vegas extend Reno’s retransmission mechanisms as follows. First, Vegas reads and records the system clock each time a segment is sent. When an ACK arrives, Vegas reads
the clock again and does the RTT calculation using this time and the timestamp recorded for the relevant segment. Vegas then uses this more accurate RTT estimate to decide to retransmit in the following two situations
􀀀 When a duplicate ACK is received, Vegas checks to see if the difference between the current time and the timestamp recorded for the relevant segment is greater than the timeout value. If it is, then Vegas retransmits the segment without having to wait for (3) duplicate ACKs. In many cases, losses are either so great or the window so small that the sender will never receive three duplicate ACKs, and therefore, Reno would have to rely on the coarse-grained timeout mentioned above.
􀀀 When a non-duplicate ACK is received, if it is the first or second one after a retransmission, Vegas again checks to see if the time interval since the segment was sent is larger than the timeout value. If it is, then Vegas retransmit the segment. This will catch any other segment that may have been lost previous to the retransmission without having to wait for a duplicate ACK.
Problems: If there are enough buffer in the routers it means that Vegas congestion avoidance mechanism can function effectively a higher throughput and a faster response time result. As the load increase or the number or router buffer decrease, Vegas congestion avoidance mechanism is not as effective and Vegas start to behave more like Reno. Vegas is less aggressive in its use of router buffer than Reno because Vegas is limited. Finally Vegas congestion detection algorithm depends on the accurate value for Base RTT.

COMPARISON OF TCP VARIANTS
The comparison of variants is done on the basis of:
1.packet received 5. Packet retransmitted
2. Throughput 6. Packet loss
3. Average transmission delay
4.end to end delay
FIG 1. BANDWIDTH
FIG 2. CONGESTION WINDOW AND QUEUE LENGTH
FIG 3. PACKET DROP
FIG 4. BANDWIDTH
FIG 5. CONGESTION WINDOW AND QUEUE LENGTH
FIG 6. PACKET DROP
FIG 8. CONGESTION WINDOW AND QUEUE LENGTH
FIG 9. PACKET DROP
FIG 7. BANDWIDTH
TCP VEGAS
FIG 10. BANDWIDTH
FIG 11. CONGESTION WINDOW AND QUEUE LENGTH
FIG 12. PACKET DROP
TAHOE
RENO
NEW RENO
VEGAS
PACKET RECEIVED
THROUGHPUT
AVG TRANSMISSION DELAY
END TO END DELAY
PACKET RETRANSMIT
PACKET DROP
2281
238506.67
0.05028
0.03047
10
24

809813.33
0.0479
0.02751
15
25
485
0.0421
0.02637
15
448355.556
26
Full transcript