Ns Simulation Final presentation Stella Pantofel Igor Berman Michael Halperin

Simulation of TCP Reno vs. TCP SACK over the network containing congested satellite or usual link, Using: Explicit Congestion Notification(ECN) and Random Early Detection(RED)

The outline of the project Using NS-2 simulator, we simulate a congested network that uses RED with ECN with following options: –TCP Reno / TCP SACK –Different RED threshold parameters. –Variable number of connections. –The network will have usual links with one of the links congested (either satellite or usual one). We will supply results (graphs) that compare the throughputs.

TCP SACK Overview Selective acknowledgement (SACK) is a TCP option designed for adopting the sender rate to the actual network conditions better. –Main purpose is increasing the throughput when multiple packets are lost from the same window. –Main idea: receiver tells the sender not only the next in-sequence expected byte, but also a range of bytes received out-of-order. It replies with a bit-mask of packets received rather than the last segment that was received in a continuity. SACK uses the Option field in the TCP header. –It is invoked only if both sides support it. Number of timeouts with SACK experienced during the connection is dramatically reduced.

Active Queue Management Queue management algorithms ’ purpose –manage the length of packet queues by dropping packets –detect congestion before the router queue overflows. Example: Random Early Detection(RED) –Drops packets when the buffer is full –Uses probabilistic drops of packets. It monitors the average queue size and randomly chooses connections to notify of the congestion –(average queue size) no packets are dropped. – (average queue size) > ( maximal threshold) => every arriving packet is dropped. –(minimal threshold) each arriving packet is dropped with a probability that is a function of the average queue size.

Explicit Congestion Notification (ECN) Routers may mark packets instead of dropping them. ECN-Capable Transport bit is set by the data sender to indicate that the end points of the transport protocol are ECN capable. CE (Congestion Experienced) bit is set by the router to indicate congestion to the end points. Upon the receipt of a single CE packet the congestion control algorithms followed at the end systems are the same as the response to the loss of a single packet.

Simulated Network 1.N sources permanently send ftp data to terminal2. 2.From each source there is one flow. 3.Single simulation lasts 60 seconds. 4.N is increased for next simulation, until it is 60.

Topology Definitions 1.When simulating congestion over regular links, delay of Terminal1- Satellite and Satellite-Terminal2 links is 5ms (instead of 125 ms). 2.Buffer capacity of Terminal packets. 3.Buffer capacity of Bridge – 100 packets. 4.Starting time for each connection varies uniformly between 0 and 1 seconds. 5.Bandwidth of each source’s link to Bridge is random and varies between 3 and 6Mb. 6.Same about delay – it varies between 3 and 6 ms.

Simulating satellite links in NS2 version 2.1b7a The available version of NS2 simulator (2.1b7a) doesn’t allow combining satellite links with regular links in one simulation. Therefore, we are trying to simulate satellite links using wired links with long propagation delay and high rate of loss error (if needed). To check validity of the above simulation we conducted several experiments over this topology.

Satellite link vs. Regular link with long delay With DropTail With RED

Satellite link vs. Regular link with long delay (con.) These graphs describe the throughputs of the satellite link vs. a regular link as a function of time. As we can see the throughput is almost identical. From this we conclude that despite minor differences, the overall behavior is very similar in both cases. Based on the results we believe that the use of regular link with long delay as a replacement for geo-stationary satellite link is valid, and that is what we did in our simulations.

TCP SACK vs. TCP Reno over satellite link and regular link with default RED parameters

TCP SACK vs. TCP Reno over satellite link and regular link with default RED parameters Results 1.The average improvement, over a satellite link, achieved by using TCP Sack vs. TCP Reno is around 5%. 2.The average improvement, over a regular link, achieved by using TCP Sack vs. TCP Reno is less than 0.5 %. 3.The average throughput over a regular link in both cases is higher by approximately 20%.

Red parameters 1.Formulas used in RED’s queue management algorithms Average queue size: Computation of probability for packet to be dropped/marked 2.The RED parameters we are playing with: min th (threshold_)- the minimum queue size threshold, default – 5. max th (maxthreshold_) - the maximum queue size threshold – default 15. w q (q_weight_) - the weight factor in computing the the average queue size - default max p (1/linterm) - the probability to be dropped when the average queue size equals max th – default 0.1 (linterm = 10)

Proposed Settings For RED Parameters 1.We increased the w q parameter relatively to its default value, so that it follows more closely the current queue size 2.max th was set to a considerably high value compared to queue buffer size. Once there is a heavy congestion, we are trying to absorb it, because sources will be aware of it only in a very long time as a result of a considerably large delay on the links. 3.min th was set to a considerably low value – increasing the chance for early “unforced” drop and slowing down some of connections before real congestion is experienced. 4.max p was decreased relatively to the default value, so that the rate of drops when the average queue size is between min th and max th is not too high.

Improving throughput of TCP Reno over satellite link by changing RED parameters

Improving throughput of TCP SACK over satellite link by changing RED parameters

TCP Reno vs. TCP Sack with default RED and changed parameters over satellite link

How errors harm the throughput?

1.Low loss rate of % doesn’t influence the throughput significantly, as only a few packets are dropped during the simulation (if any). 2.Medium loss rate of 0.1% causes the deterioration of the throughput when the number of sources is small. As the number of sources increases so is the throughput, because when any connection is affected by error, its load on the links is reduced and others can use available bandwidth. 3.High loss rate of 1% results in enormous degradation of throughput, and even increasing number of sources doesn’t allow to reach previous level.

Error of % Sack improves Reno by factor of This error rate means that on average only 1 packet out of is lost, and this is negligible when calculating average throughput over 60- second simulation. Thus,the results we got are very similar to the results without errors.

Error of 0.1% Sack improves Reno by factor of Compared to % loss rate, we can see that only at the end we are getting the same throughput, i.e. the more sources we have, the better they could backup each other in a case of losses.

Error of 1% Sack improves Reno by factor of In a case of 1% error rate we can observe severe decrease of throughput by more than 50%. However the pattern of improving as number of sources grows still exists.

Errors Tuning RED parameters helps even when we have errors on the links,however, when the loss rate is extremely high, changing Red parameters doesn’t help “much”. At the same time, as it can be observed from the last graph, relative improvement achieved by using SACK is slightly higher than it is usually. This is probably due to the fact that SACK allows to recover from several packet drops from the same window, and since we have 1% rate of losses there is a good chance that several packets from the same window will be actually dropped.

Conclusions From the presented graphs we can draw several conclusions: 1.TCP Sack improves the throughput and is preferable over TCP Reno. However, we must remember that there is a trade off when using TCP Sack: the processing time of a packet is longer than that of TCP Reno. 2.Red parameters: We observed that for given network it is worthwhile to change the default parameters of RED so they will suite the specific configuration of the network. It produces visible improvements in throughput. However, determining optimal values is not an easy task and depends on the characterization of the network traffic as well as on the physical characteristics of the network. 3.The best (by far) results are achieved while combining TCP SACK with Red parameters configured specifically for the given network. Not only RED and TCP SACK don’t interfere with each other but they are even improving each other.