Two TCP Senders Competing

Now let us create a simulation in which two TCP Reno senders compete for the bottleneck link, and see how fair an allocation each gets. According to the analysis in 20.3 TCP Reno Fairness with Synchronized Losses, this is really a test of the synchronized-loss hypothesis, and so we will also examine the ns-2 trace files for losses and loss responses. We will start with “classic” TCP Reno, but eventually also consider SACK TCP. Note that, in terms of packet losses in the immediate vicinity of any one queue-filling event, we can expect TCP Reno and SACK TCP to behave identically; they differ only in how they respond to losses.

The initial topology will be as follows (though we will very soon raise the bandwidths tenfold, though not the propagation delays):

An Introduction to Computer Networks, Release 2.0.4





Broadly speaking, the simulations here will demonstrate that the longer-delay B–D connection receives less bandwidth than the A–D connection, but not quite so much less as was predicted in 20.3 TCP Reno Fairness with Synchronized Losses. The synchronized-loss hypothesis increasingly fails as the B–R delay increases, in that the B–D connection begins to escape some of the packet-loss events experienced by the A–D connection.

We admit at the outset that we will not, however, obtain a quantitative answer to the question of bandwidth allocation. In fact, as we shall see, we run into some difficulties even formulating the proper question. In the course of developing the simulation, we encounter several potential problems:

1. The two senders can become synchronized in an unfortunate manner

2. When we resolve the previous issue by introducing randomness, the bandwidth division is sensitive to the method selected

3. As R’s queue fills, the RTT may increase significantly, thus undermining RTT-based measurements (31.3.9 The RTT Problem)

4. Transient queue spikes may introduce unexpected losses

5. Coarse timeouts may introduce additional unexpected losses

The experiments and analyses below divide into two broad categories. In the first category, we make use only of the final goodput measurements for the two connections. We consider the first two points of the list above in 31.3.4 Phase Effects, and the third in 31.3.9 The RTT Problem and 31.3.10 Raising the Bandwidth. The first category concludes with some simple loss modeling in Possible models.

In the second category, beginning at 31.4 TCP Loss Events and Synchronized Losses, we make use of the ns-2 tracefiles to extract information about packet losses and the extent to which they are synchronized. Examples related to points four and five of the list above are presented in 31.4.1 Some TCP Reno cwnd graphs. The second category concludes with 31.4.2 SACK TCP and Avoiding Loss Anomalies, in which we demonstrate that SACK TCP is, in terms of loss and recovery, much better behaved than TCP Reno.

The Tcl Script

Below is a simplified version of the ns-2 script for our simulation; the full version is at basic2.tcl. The most important variable is the additional one-way delay on the B–R link, here called delayB. Other defined variables are queuesize (for R’s queue_limit), bottleneckBW (for the R–D bandwidth), endtime (the length of the simulation), and overhead (for introducing some small degree of randomization, below). As with basic1.tcl, we set the packet size to 1000 bytes total (960 bytes TCP portion), and increase the advertised window size to 65000 (so it is never the limiting factor).

An Introduction to Computer Networks, Release 2.0.4

We have made the delayB value be a command-line parameter to the Tcl file, so we can easily experiment with changing it (in the full version linked to above, overhead, bottleneckBW, endtime and queuesize are also parameters). The one-way propagation delay for the A–D path is 10 ms + 100 ms = 110 ms, making the RTT 220 ms plus the bandwidth delays. At the bandwidths above, the bandwidth delay for data packets adds an additional 11 ms; ACKs contribute an almost-negligible 0.44 ms. We return to the script variable RTTNL, intended to approximate RTTnoLoad, below.

With endtime=300, the theoretical maximum number of data packets that can be delivered is 30,000. If bottleneckBW = 0.8 Mbps (100 packets/sec) then the R–D link can hold ten RÝÑD data packets in transit, plus another ten DÝÑR ACKs.

In the finish() procedure we have added code to print out the number of packets received by D for each connection; we could also extract this from the trace file.

To gain better control over printing, we have used the format command, which works something like C’s sprintf. It returns a string containing spliced-in numeric values replacing the corresponding %d or %f tokens in the control string; this returned string can then be printed with puts.

The full version linked to above also contains some nam directives, support for command-line arguments, and arranges to name any tracefiles with the same base filename as the Tcl file.

# NS basic2.tcl example of two TCPs competing on the same link.

# Create a simulator object set ns [new Simulator]

#Open the trace file set trace
[open w]
$ns trace-all $trace

############## some globals (modify as desired) ############## #

queuesize on bottleneck link
set queuesize 20
# default run time, in seconds set endtime 300
# "overhead" of D>0 introduces a uniformly randomized delay d, 0?d?D; 0 ãÑturns it off. set overhead 0
# delay on the A--R link, in ms set basedelay 10
# ADDITIONAL delay on the B--R link, in ms set delayB 0
# bandwidth on the bottleneck link, either 0.8 or 8.0 Mbit set bottleneckBW 0.8
# estimated no-load RTT for the first flow, in ms set RTTNL 220

############## arrange for output ##############

set outstr [format "parameters: delayB=%f overhead=%f bottleneckBW=%f" ãÑ$delayB $overhead $bottleneckBW]
puts stdout $outstr

An Introduction to Computer Networks, Release 2.0.4

# Define a 'finish' procedure that prints out progress for each connection proc finish {}      {
global ns tcp0 tcp1 end0 end1 queuesize trace delayB overhead RTTNL
set ack0 [$tcp0 set ack_]
set ack1 [$tcp1 set ack_]
# counts of packets *received*
set recv0 [expr round ( [$end0 set bytes_] / 1000.0)]
set recv1 [expr round ( [$end1 set bytes_] / 1000.0)]
# see numbers below in topology-creation section set rttratio [expr (2.0*$delayB+$RTTNL)/$RTTNL]
# actual ratio of throughputs fast/slow; the 1.0 forces floating point set actualratio [expr 1.0*$recv0/$recv1]
# theoretical ratio fast/slow with squaring; see text for discussion ãÑof ratio1 and ratio2
       set rttratio2 [expr $rttratio*$rttratio]
       set ratio1 [expr $actualratio/$rttratio]
       set ratio2 [expr $actualratio/$rttratio2]
        set outstr [format "%f %f %d %d %f %f %f %f %f" $delayB $overhead ãÑ$recv0 $recv1 $rttratio $rttratio2 $actualratio $ratio1 $ratio2 ]
       puts stdout 
      $outstr $ns flush-trace
      close $trace
       exit 0

############### create network topology ##############

#  A
#       \
#          \
#            R---D (Destination)
#          /
#      /
#  B
#Create four nodes
set A [$ns node]
set B [$ns node]
set R [$ns node]
set D [$ns node]
set fastbw [expr $bottleneckBW * 10]
#Create links between the nodes; propdelay on B--R link is 10+$delayB ms $ns duplex-link $A $R ${fastbw}Mb ${basedelay}ms DropTail $ns duplex-link $B $R ${fastbw}Mb [expr $basedelay + $delayB]ms DropTail #
this last link is the bottleneck; 1000 bytes at 0.80Mbps => 10 ms/packet
# A--D one-way delay is thus 110 ms prop + 11 ms bandwidth
# the values 0.8Mb, 100ms are from Floyd & Jacobson

$ns duplex-link $R $D ${bottleneckBW}Mb 100ms DropTail

$ns queue-limit $R $D $queuesize

Frequently Asked Questions

Ans: A Single TCP Sender| The ns-3 Network Simulator view more..
Ans: The ns-2 simulator|NETWORK SIMULATIONS: NS-2 view more..
Ans: Wireless|The ns-3 Network Simulator view more..
Ans: Two TCP Senders Competing|THE NS-3 NETWORK SIMULATOR view more..
Ans: Wireless Simulation|NETWORK SIMULATIONS: NS-2 view more..
Ans: Epilog|NETWORK SIMULATIONS: NS-2 view more..
Ans: Installing and Running ns-3|THE NS-3 NETWORK SIMULATOR view more..
Ans: Installing Mininet|MININET view more..
Ans: A Simple Mininet Example|MININET view more..
Ans: Multiple Switches in a Line|Mininet view more..
Ans: IP Routers in a Line|Mininet view more..
Ans: IP Routers With Simple Distance-Vector Implementation|Mininet view more..
Ans: TCP Competition: Reno vs BBR|Mininet view more..
Ans: Linux Traffic Control (tc)|Mininet view more..
Ans: OpenFlow and the POX Controller|Mininet view more..
Ans: Forward Secrecy|Public-Key Encryption view more..
Ans: Trust and the Man in the Middle|Public-Key Encryption view more..

Rating - NAN/5