Random Early Detection (RED) is the first active queue management algorithm proposed for deployment in TCP/IP networks. The basic idea behind an active queue management algorithm is to convey congestion notification early to the TCP end points so that they can reduce their transmission rates before queue overflow and sustained packet loss occur. "It is now widely accepted that the RED controlled queue performs better than a drop-tail queue. It is an active queue management algorithm" [1]. "The tail drop algorithm, a router buffer as many packets as it can, and drops the packet when it cannot buffer. If buffers are constantly full, the network is congested" [2]. RED addresses these issues. It monitor the average queue size and drops packets based on statistical probabilities. If the buffer is almost empty, all incoming packets reaccepted. As the queue grows, the probabilities for dropping incoming packet are dropped too. RED is more fair than trail drop in the sense of it does not possess a bias against burst traffic that use only a small portion of the bandwidth. The more the more a host transmits, likely it is that packets are dropped. The most common technique of queue management is a trail drop. In this method packets are accepted as long as there is space in the buffer when it becomes full, incoming packets are dropped. This approach results in dropping large number of packets in the time congestion. This can result in lower throughput and TCP synchronization [3]. However TCP includes eleven variants (Tahoe, FullTcp, TCP/Asym, Reno, Reno/Asym, Newreno/Asym, Sack1, DelAck and Sack1/DelAck) as source and five (TCPSink, TCPSink/Asym, Sack1, DelAck and Sack1/DelAck) as destination, implementation in NS-2 [4,5]. The base TCP has become known as TCP Tahoe. TCP Reno attaches one novel mechanism called Fast Recovery to TCP Tahoe [4]. In addition, TCP Newreno employs the most recent retransmission mechanism of TCP Reno. [6]. The use of Sacks allows the receiver to stipulate several additional data packets that have been received out-of-order within one dupack, instead of only the last in order packet received [5]. TCP Vegas offers its own distinctive retransmission and congestion control strategies. TCP Fack is Reno TCP with forward acknowledgment [7]. Transmission Control Protocol (TCP) Variants Reno, NewReno, Vegas, Fack and Sack1 are implemented in NS-2. RED supervises the average queue size and drops packets based on statistical likelihoods [3].
RANDOM EARLY DETECTION a) RED Parameter Setting Average queue size avg is formulated [1] as:
Where, wq is the queue weight, q is current queue size. wq should have lower value for bustier traffic; more weight is given in this case for the historic A III. We that when threshold increase then variation course in received among various TCP variants and all arriving packets are received when average queue size exceeds max threshold or less than minimum threshold then packets are dropped which is shown in above all tables and corresponding figure. We found that Newreno TCP variants is the best because mean number of received packet is high mean number of dropped packet is low.
2011 | |||||
October | |||||
46 | |||||
TCP variants | 15 | 20 | 25 | 30 | 35 |
Reno | 854 | 1185 | 845 | 711 | 733 |
Newreno | 721 | 763 | 752 | 774 | 741 |
Vegas | 821 | 777 | 685 | 686 | 625 |
Fack | 800 | 721 | 713 | 644 | 761 |
Sack1 | 864 | 870 | 749 | 813 | 786 |
TCP variants | 15 | 20 | 25 | 30 | 35 |
Reno | 1452 1532 1333 1778 1398 | ||||
Newreno | 1458 1465 1501 1631 1538 | ||||
Vegas | 1345 1578 1350 1498 1538 | ||||
Fack | 1412 1754 1252 2379 1422 | ||||
Sack1 | 1501 1339 1595 1358 1179 | ||||
TCP variants 15 | 20 | 25 | 30 | 35 | |
Reno | 2659 2635 2376 1946 2300 | ||||
Newreno | 2701 2546 2032 2169 2303 | ||||
Vegas | 2254 2255 2301 2432 2178 | ||||
Fack | 2802 2462 2897 2131 2376 | ||||
Sack1 | 2269 2416 2201 2554 2082 | ||||
TCP variants | 15 | 20 | 25 | 30 | 35 |
Reno | 3142 | 3403 | 3312 | 3323 | 2902 |
Newreno | 3383 | 3220 | 3204 | 3265 | 2928 |
Vegas | 2624 | 2749 | 2778 | 2538 | 2799 |
Fack | 3545 | 3088 | 2856 | 2681 | 4298 |
Sack1 | 3888 | 3216 | 3051 | 3232 | 3409 |
and TCP | |
Times 70s 140s 210s 280s | |
U | 15 675 1294 1996 2586 |
20 797 1222 1803 2694 | |
D | 25 758 1187 2127 2633 |
30 795 1484 2085 2794 | |
P | 35 749 1336 1963 2783 |
T | 15 566 1352 2725 2457 |
20 665 1606 2374 3284 | |
C | 25 637 1438 2425 3694 |
30 548 1656 2247 2832 | |
P | 35 834 1614 2413 3438 |
From the aforementioned comparison of the performance it is found that TCP is better than UDP because packet received is higher in it with respect to UDP. That is why packet loss is lower in TCP. In case of packet drop, it is clear those packet drop is higher in UDP than TCP and also occur more congestion in it. It is possible to control congestion in TCP using RED model.
IV. CONCLUSION 8.
The network simulator-ns-2. http://www.isi.edu/nsnam/ns5 The VINT Project, A Collaboration between researchers at UC Berkeley, LBL, USC/ISI, and Xerox PARC, 27. NS (The ns Manual)
NS Simulator for beginners. Lecture notes, (France