Ns SimulationFinal presentation

Stella Pantofel 304026354

Igor Berman 313879942

Michael Halperin 317321982

Simulation of TCP Reno vs. TCP SACK

over the network containing congested satellite or usual link,

Using:Explicit Congestion Notification(ECN)

andRandom 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) < ( minimal threshold ) =>

no packets are dropped.– (average queue size) > ( maximal threshold) =>

every arriving packet is dropped. – (minimal threshold) < (average queue size) < (maximal 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 Terminal1 - 100 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

Throughput

0

50000

100000

150000

200000

250000

300000

0 10 20 30

Time

KB

/ s

Sat-Repeater

Regular

Throughput

0

50000

100000

150000

200000

250000

300000

0 10 20 30 40

TimeK

B/ s

Sat-Repeater

Regular

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

Throughput with Default RED

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40 50

Number of Sources

SatLink-TCPSack

RegLink-TCPSack

SatLink-TCPReno

RegLink-TCPReno

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%.

Throughput with Default RED

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40 50

Number of Sources

SatLink-TCPSack

RegLink-TCPSack

SatLink-TCPReno

RegLink-TCPReno

Red parameters1. 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:

• minth(threshold_)- the minimum queue size threshold, default – 5.• maxth (maxthreshold_) - the maximum queue size threshold – default 15.• wq(q_weight_) - the weight factor in computing the the average

queue size - default 0.002 .• maxp(1/linterm) - the probability to be dropped when the average queue

size equals maxth – default 0.1 (linterm = 10)

thth

thpbavgavgp minmax

minmax)( *

qwavgwavg qq **)1(

Proposed Settings For RED Parameters

1. We increased the wq parameter relatively to its default value, so that it follows more closely the current queue size

2. maxth 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. minth 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. maxp was decreased relatively to the default value, so that the rate of drops when the average queue size is between minth and maxth is not too high.

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

throughput of TCP Reno over satellite link with different RED parameters

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40 50 60

number of sources

SatRenoRed10_85_0.043_17Err0

SatRenoRed30_90_0.04_13Err0

SatRenoRed-default

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

throughput of TCP Sack over satellite link with different RED parameters

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 20 40 60

number of sources

SatSackRed10_85_0.043_17Err0SatSackRed30_90_0.04_13Err0

SatSackRed-defaultErr0

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

satellite link Comparing throughputs

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40 50 60

number of sources

SatRenoRed10_85_0.043_17Err0

SatRenoRed-defaultErr0

SatSackRed10_85_0.043_17Err0

SatSackRed-defaultErr0

How errors harm the throughput?Throughputs of Reno with defaultRED and variable loss rate over satellite link

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 5 10 15 20 25 30 35 40 45 50 55 60 65

number of sources

Error 0

Error 0.0001%

Error 0.1%

Error 1%

How errors harm the throughput?1. Low loss rate of 0.0001% 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 0.0001%Improving throughputs over satellite links with low

error rate by changing RED parameters

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 20 40 60

number of sources

sat.reno.red10_85_0.043_17

sat.reno.red-def

SatSackRed10_85_0.043_17

SatSackRed-def

Sack improves Reno by factor of 1.0493956

This error rate means that on average only 1 packet out of 1000000 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%Improving throughputs over satellite links with medium

error rate by changing RED parameters

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 20 40 60

number of sources

SatRenoRed10_85_0.043_17

SatRenoRed-def

SatSackRed10_85_0.043_17

SatSackRed-def

Sack improves Reno by factor of 1.047830594.

Compared to 0.0001% 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%Improving throughputs over satellite links with high

error rate by changing RED parameters

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0.45

0 20 40 60number of sources

SatRenoRed10_85_0.043_17

SatRenoRed-def

SatSackRed10_85_0.043_17

SatSackRed-def

Sack improves Reno by factor of 1.06464

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.