Wireless Ad Hoc and Sensor Networks

Congestion Control in ATM Networks and the Internet 1233.6 Simulation ResultsIn this section, we present the simulation studies that are used to studythe behavior of the algorithm. The section discusses the network topology,traffic sources, parameters, and constants used in the simulations andresults. NS-2 is used in the simulations. We compare the proposed schemewith the New Reno-TCP protocol (Fall and Floyd 1996), as the latterreflects the current packet switched networks (e.g., Internet) quite well.3.6.1 Network Topology and Traffic SourcesIn our simulations, we use a typical “dumb-bell” topology as shown inFigure 3.18. All links, except the bottleneck link, are sufficiently provisionedto ensure that any drops/delays that occur are only due to congestionat the bottleneck link. All links are drop-tail links.The default buffer length at each link is set to 50 packets. A packet isof 1 kB in size. The bandwidth of each link is set to 10 Mbps. The bottlenecklink delay is 10 msec, other link delays are at 5 msec. The simulationlength is taken to be 30 sec. In the simulation, totally six traffic sourcesS1 to S6 are used. Because the proposed methodology is compared withNew-Reno TCP (which in turn is based on AIMD), they are discussed next.3.6.2 New-Reno TCP MethodologyReno TCP refers to TCP (Fall and Floyd 1996) and prevents the communicationpath from going empty after fast retransmit, thereby avoidingthe need to slow-start to refill it after a single packet loss. Fast recoveryoperates by assuming each duplicate ACK received represents a singlepacket having left the pipe. During fast recovery the sender inflates itswindow by the number of duplicate ACKs it has received. Thus, duringfast recovery, the TCP sender is able to make intelligent estimates of theamount of outstanding data. After entering fast recovery and retransmittinga single packet, the sender effectively waits until half a window ofduplicate ACKs have been received, and then sends a new packet for eachadditional duplicate ACK that is received. Reno TCP has performanceproblems when multiple packets are dropped from one window of databecause it has to wait for the expiration of the retransmission timer beforereinitiating data flow.The New-Reno TCP (Fall and Floyd 1996) includes a small change tothe Reno algorithm at the sender. Partial ACKs received during fast recoveryare treated as an indication that the packet immediately following theacknowledged packet in the sequence space has been lost, and should be