TCP Fairness in Wired and Wireless Networks

Overview

The objectives of this assignment are to (1) familiarize yourself with the ns network simulator, (2) to explore the behavior of TCP in both wired and wireless networks, (3) to understand the process of conducting a simulation and evaluating the simulation data, and (4) to learn how to clearly present your work to others.

The ns2 simulator

For this assignment, we will be using the ns2 network simulator. This is the most commonly used software in the Internet research community, and because of this popularity there are many protocols written for it. Most TCP research uses ns, so it has a large set of TCP variants.
ns2 is an event-driven, packet-level simulator. This means that the simulator steps through a series of events using a simulated notion of time, and it simulates each packet in a connection. As a result, ns2 is very effective at simulating the detailed behavior of a single TCP connection, but it is somewhat harder to use it to study a very large number of connections with a peer-to-peer protocol.

Using ns2

To run ns2, you call a Tcl script to create a network topology; define which applications will be running, what transport protocol the applications will use, and where the senders and receivers are located; and configure a series of events. The file oneflow.tcl lists an example ns2 Tcl script. This script sets up the following topology:
The first part of the script:

set ns [new Simulator]

creates a new instance of the simulator and sets it equal to a variable so that we can reference this in later steps.
Next the script opens a file and tells ns to store all trace output in this file:

set f [open oneflow.tr w]
$ns trace-all $f

This will record all packet events in the listed file, including every time a packet is queued, dequeued, or dropped at a router and every time a packet is received by a host.

Next the script creates a network topology:

set n0 [$ns node]
set n1 [$ns node]
$ns duplex-link $n0 $n1 1.5Mb 10ms DropTail
$ns queue-limit $n0 $n1 10

This creates two nodes with a two-way link between then, running at 1.5 Mbps and with a propagation delay of 10 ms. The link has a DropTail (FIFO) queue that can hold a maximum of 10 packets.
Next the script sets up a one-way TCP flow:

set tcp [new Agent/TCP/Newreno]
set sink [new Agent/TCPSink]
$ns attach-agent $n0 $tcp
$ns attach-agent $n1 $sink
# connect the sender and receiver
$ns connect $tcp $sink

Here I have excerpted only the necessary code for a TCP Reno connection. The full script shows you how to substitute a different variant of TCP. Each TCP flow should have a separate source and sink, running on a particular node in the topology. These are then connected together, telling ns which one will transmit packets and which one will receive them..
Next the script traces some of the dynamics of TCP:

set ftcp [open oneflow-cwnd.tr w]
$tcp attach $ftcp
$tcp trace cwnd_

In this case, the script traces only the congestion window, but there are many other TCP variables that you could also trace. The script places this information in a separate file since the structure of the data is different from that of the packet trace.
Next the script establishes the traffic source for the TCP connection:

set ftp [new Application/FTP]
$ftp attach-agent $tcp

This tells ns to generate the TCP traffic using an FTP application. Notice that this doesn't have any of the usual FTP semantics of transferring a particular file of a certain size. Instead, this simulates an infinite stream of traffic, so that we can focus on TCP behavior of any duration that we choose.
Next, we schedule some events for our simulation:

$ns at 0 "$ftp start"
$ns at 5 "$ftp stop"

These events tell ns to start the ftp application at time 0 and to end it at time 5.
Next, the script provides a procedure to call when the simulation ends:

$ns at 5.1 "finish"

proc finish {} {
    global ns f ftcp
    $ns flush-trace
    close $f
    close $ftcp
    exit 0
}

The script finishes up its trace and closes the trace files, then exits. Note that we call this slightly after the stopping time to give all the packets a chance to reach the destination.
Finally, the script tells the simulator to run:

$ns run

ns2 Traces

The following shows the format of the ns2 packet trace:
where

• Event: '+': a packet was enqueued, '-': a packet was dequeued, 'd': a packet was dropped, or 'r': a packet was received at the end of a link
• Time: The time at which the event occurred
• From: The starting node for the link on which the event occurred
• To: The ending node for the link on which the event ocurred
• Type: The packet type, for example 'tcp'
• Size: The size of the packet in bytes
• Flags: You can ignore this field
• Class: The 'class' of the packet, which can be used to identify a particular TCP connection
• Source: The source address of the packet, given as "node.port"
• Dest: The destination address of the packet
• Sequence: The sequence number of the packet
• Identifier: The unique identifier of the packet

The congestion window trace is relatively easy to interpret: the first field is the time of the event and the last field is the size of the congestion window (in segments) at that time.

Running ns2

I have setup my Linux account so that you can run ns from my directory /users/faculty/zappala/ns. For ns to run properly, you need to set the LD_LIBRARY_PATH environment variable equal to /users/faculty/zappala/libraries. You can do this with bash by typing:

export LD_LIBRARY_PATH=/users/faculty/zappala/libraries

You can put this command in your .bashrc file to do this automatically each time you log in.

Additional References

You should be able to complete this program without any other knowledge of ns2. However, if you would like to know more, please see the extensive documentation on the ns web site. In particular, look at the ns manual, ns for Beginners, and these papers.

Practice with ns2

If you have never run ns2 before, then you should try this simple experiment. Use the oneflow.tcl script to run an experiment with a single TCP connection over a network of two nodes. Using the generated trace files, produce graphs for the following:

• The receiver's rate over time. Calculate the rate every time the receiver gets a packet by averaging the rate over the previous 12 packets. This is the metric used in the TCP Vegas paper.
• The queue size over time and each packet drop event. You can calculate the queue size at any time by observing all packet enqueue, dequeue, and drop events. Plot each drop event at the maximum queue size (10) when the drop occurs using an "X" symbol.
• The congestion window over time. You can plot this directly from the TCP trace file.

Note that for all of these graphs you will need to exclude ACK packets, which are listed in the trace file along with TCP data packets.
Repeat this experiment for TCP Tahoe, NewReno, and Vegas, except do not produce a congestion window plot for Vegas. See if you can answer the following questions:

1. Examining the results for TCP NewReno, why is TCP able to have a sawtooth pattern for the congestion window, but a relatively smooth rate as observed at the receiver?
2. What differences do you observe between Tahoe and NewReno, and why do these differences occur?
3. TCP Vegas uses a radically different rate-based congestion control algorithm. Instead of waiting for packet loss as the sign of congestion, it examines its RTT measurements and slows down when the RTT starts to increase. Explain why this helps to avoid congestion and explain what effect this has on the graphs you produce.

Part 1: Multiple TCP Flows on a Wired Network

For this section, you will examine the fairness of multiple TCP flows when they share a bottleneck link. Modify the oneflow.tcl script to run an experiment with a multiple TCP connections over the same network of two nodes. Your topology should look like this:
Vary the number of connections from 2 to N. When creating connection i, you will need to include the following line:

$tcp set class_ $i

where $i is the number of the connection. This will use the class field to distinguish your TCP connections in the packet trace. For each experiment, calculate Jain's fairness, which is given by:
where x_i is the rate achieved by flow i. Plot the Fairness Index versus the number of flows to determine whether TCP remains fair as the number of flows increases. Also, plot the arrival rate for each flow to determine how well TCP is working in this environment. Repeat for different TCP variants, including NewReno and SACK.
Now try mixing TCP variants. Start one Vegas flow and vary the number of NewReno flows that compete with Vegas. How does Vegas compete in a network of NewReno flows? Repeat for SACK.

Part 2: Multiple TCP Flows on a Wireless Network

For this section, you will examine the fairness of multiple TCP flows when they share a bottleneck link in a wireless network. Modify the oneflow-wireless.tcl script to run an experiment with a multiple TCP connections over a wireless network of two nodes. Your topology should look like this:
Vary the number of connections from 2 to N and plot the Fairness Index versus the number of flows to determine whether TCP remains fair as the number of flows increases. Also, plot the arrival rate for each flow to determine how well TCP is working in the wireless environment. Repeat for different TCP variants, including NewReno and SACK.
Now try mixing TCP variants. Start one Vegas flow and vary the number of NewReno flows that compete with Vegas. How does Vegas compete in a network of NewReno flows? Repeat for SACK.
Finally, try varying the length of the path from one to M hops. How does the path length affect TCP behavior?

Lab Report

Write a report describing the results of your experiments. Your audience for your report is your fellow students and other networking researchers -- you can assume that they know about networking in general but don't know about the exact topic you have studied. The style of the report should be a formal paper, as if you were submitting it to a conference.
The report should contain the following sections:

1. Introduction: Describe the purpose of your project and summarize your important results.
2. Part I: Describe the purpose of these experiments, your methodology, and the data you collected. You methodology should include everything a fellow student would need to replicate your results, including the topologies, workload, and metrics. Then show your results. Emphasize the most important things and provide a logical structure for your results. You do not need to include every graph you produced. Instead, include only those graphs where you see something significant. If several graphs all show the same thing, then show one graph and summarize the other results.
3. Part II: Describe the purpose of these experiments, your methodology, and the data you collected. Then show your results.
4. Conclusions: Discuss any conclusions you have drawn from your study and any areas for future work that this project has inspired.
5. References: List references for related work. These should be complete references, including at a minimum the full names of the authors, the title of the paper, the conference or journal in which it was published, and the date of publication.

Your paper can be any length, as long as you thoroughly describe your project and results. The paper must use 11 point type, single spacing, and one column per page. The paper must be written using LaTeX and the IEEE article and bibliography styles. These styles are typically used for submission to many IEEE conferences; there are others for ACM conferences. These files include documentation on how to use them, and you can see me for any help you need. LaTeX is a useful publishing tool in the academic work, as it automatically formats in many commonly-used styles. I also find it helps me to focus on content, rather than style, when I am writing a paper. To help you learn LaTeX, I am including a LaTeX tutorial I wrote, complete with tables, figures, and bibliography.
Where they are helpful, you are encouraged to include your own figures in your paper. I suggest using biggles for plotting graphs if you use python, otherwise gnuplot works well.
If you need to draw figures for inclusion in your report (e.g. to diagram the topologies), I suggest using Inkscape or a similar vector drawing program.