As a preparation for this laboratory assignment you shall read Simulation-based Comparisons of Tahoe, Reno and Sack TCP.

In this laboratory assignment you will use the simulation tool ns that was originally developed at Lawrence Berkeley National Laboratory (operated by the University of California as part of the U.S. Department of Energy's national laboratory system). The ns development is now an ongoing collaboration with the VINT (Virtual InterNetwork Testbed) project and it's one of their latest releases of ns version 2 that you will be using.

ns is an event-driven network simulator. An extensible simulation engine is implemented in C++ that uses MIT's Object Tool Command Language, Otcl (an object oriented version of Tcl) as the command and configuration interface.

You will also use the tool nam that offers a graphical visualization of the ns simulations and gnuplot to create graphs.

Simulation scripts

The class Simulator provides methods for configuring your simulation. The first thing you need is a reference to this class, which can be accomplished by the following command:

set ns [new Simulator] ;# Now the variable ns is a handle to a instance of the Simulator class.

A network topology is realized using three primitive building blocks: nodes, links, and agents, where nodes represent hosts and routers, links represent the cables, phone lines etc and the agents represents endpoints where network-layer packets are constructed or consumed. (An agent must be attached to a node.) Some types of agents may have sources attached to them while others may generate their own data. For example, you can attach ``ftp'' and ``telnet'' sources to ``tcp'' agents but ``constant bit-rate'' agents generate their own data. Currently ns mostly supports so called one-way-agents which means that you have to create a sender agent and a receiver agent and then connect the two. The supplied one-way TCP agents don't perform the three-way-handshake, they are intended for studying congestion and error control behaviors of the TCP implementations and are not faithful replicas of real-world TCP implementations.

The focus of this laboratory assignment is not on how to write ns simulation scripts, it's on analyzing simulation results. For this reason you don't have to write any simulation scripts from scratch you'll only need to make some small alterations to scripts already provided for you. The instructions given in this laboration specification should provide enough information to do this, but if you'd like to look at the manual page anyway you can find it as: or by typing man ns in a shell.


Early TCP implementations followed a go-back-n model using cumulative positive acknowledgment and requiring a retransmit timer expiration to resend data lost during transportation.

Modern TCP implementations contain a number of algorithms aimed at controlling network congestion while maintaining good user throughput. Below, a short description of the different TCP implementations that you shall analyze is given.

Tahoe TCP

Tahoe TCP utilizes the Slow-Start algorithm ( RFC 2001) . It's implemented the following way:

An other algorithm used by Tahoe TCP is Congestion Avoidance ( RFC 2001). That works the following way.

You can read more about this in Congestion avoidance and Control by Van Jacobson and Michael J. Karels.

Congestion Avoidance and Slow-Start are independent algorithms with different objectives. But in practice they are implemented together. This gives the effect that when the Slow-Start algorithm is invoked, it switches and starts using the Congestion Avoidance algorithm after reaching a certain size of cwnd. For details please see RFC 2001

TCP Tahoe also use the Fast Retransmit algorithm ( RFC 2001) that works the following way: After receiving a small number of duplicate acknowledgments for the same TCP segment, the data sender infers that a packet has been lost and retransmits the packet without waiting for a retransmisson timer to expire.

Reno TCP

The Reno TCP is similar to the Tahoe TCP, except it also includes Fast Recovery ( RFC 2001), where the current congestion window is "inflated" by the number of duplicate ACK:s the TCP sender has received before receiving a new ACK. In addition, the Reno TCP agent does not return to slow-start during Fast Retransmit , instead it reduces the congestion window to half the current window size.

New-Reno TCP

New Reno modifies the action taken when receiving new ACK:s. In order to exit fast recovery, the sender must receive an ACK for the highest sequence number sent. Thus new "partial ACK:s" (those which represent new ACK:s but do not represent an ACK of all outstanding data) do not deflate the usable window back to the size of the congestion window.


TCP may experience poor performance when multiple packets are lost from one window of data. With the limited information available from cumulative acknowledgments, a TCP sender can only learn about a single lost packet per round trip time. An aggressive sender could choose to retransmit packets early, but such retransmitted segments may have already been successfully received.

A Selective Acknowledgment (SACK) mechanism, combined with a selective repeat retransmission policy, can help to overcome these limitations. The receiving TCP sends back SACK packets to the sender informing the sender of data that has been received. The sender can then retransmit only the missing data segments.

If you want to know more about SACK TCP check out RFC 2018.

Getting started

You have to be logged on a machine that runs Solaris 2.5, e.g if you are sitting in 1413 you need to log on some machine runing Solaris 2.5 for instance:
> ssh
> export DISPLAY="<your_machin_name>:0.0"

As ns and nam isn't installed in the global environment you need to add their location to your path and manual path environment variables. You can achive this by giving the following commands in your bash shell:

> export PATH="$PATH:/stud/docs/kurs/datakom2/bin"
> export MANPATH="$MANPATH:/stud/docs/kurs/datakom2/man"

or if you have a csh/tcsh shell

> setenv PATH "$PATH:/stud/docs/kurs/datakom2/bin"
> rehash
> setenv MANPATH "$MANPATH:/stud/docs/kurs/datakom2/man"

All scripts used in this assignment can be found in the directory:
You can either copy them from this location, or download them with help of your web browser, as their first appearance in this document is linked.

This part don't have to be accounted for it's just to help you get a feel for the tools, but you should do it before seeking assistance.

Copy the file simple.tcl and run ns with it as input. This will make a nam window pop up. The circles you see represents nodes and the line is a link. Use the help menu to find out what the control icons do. Try them out! When you run the simluation you will see the packets (red) transported on the link.

Open the file in emacs and study the simulation script. Try to do the following modifications and run the script through ns again.


The assignment is to analyze simulations of different TCP implementations. To your assistance you have some questions and exercises marked Q<number> and E<number>.

The first simulation is defined by the script tcp1.tcl and use Tahoe TCP. This script creates the following topology

and sets up a FTP-session between the node 0 and 2. Observe the scenario in nam.

E1: Describe what happens.
Q1: When does the TCP agent start using the whole bandwidth continuously? (Answers with in a reasonable margin for error will be accepted.)

In this simulation the two links are the same length. Now make the link between node 1 and 2 longer by setting a the delay to 100ms on this link. Run the simulation again.

E2: Describe what happens now.
E3: Explain why this happens.

Copy the file tcp_drop.tcl , with help of this simulation script you should repeat the simulations performed by Kevin Fall and Sally Floyd accounted for in their paper Simulation-based Comparisons of Tahoe, Reno and SACK TCP. They studied the scenarios when one, two, three and four packages where dropped. The following topology is used in creating these scenarios:

From the host represented by node 0 to the one represented by node 4 we have the TCP-connection we want to study, on the hosts represented by node 1 and 2 we have additional connections to node 4 on which limited amount of data is sent in order to cause packet drops on the connection we are studying. Do the following for one, two, three and four packet losses.

Answer the following questions about the simulation of Tahoe TCP with one package drop. (You'll find the answers to these questions by observing the simulation in nam):

Q2: Approximately at which point is the Fast Retransmit algorithm activated?
Q3: Approximately when does the TCP connection switch over from the Slow-Start algorithm to the Congestion Avoidance algorithm?

Then answer these more comprehensive questions:

Q4: Did you get the same results as Sally and Kevin? If you didn't describe the differences.
Q5: Do you agree with the conclusions in the article? Motivate your answer.
Q6: Is there a implementation that works best for all scenarios?
E4: Depending on your answer to question 6, explain why/why not.
E5: Describe the Slow-Start algorithm on the basis of yore observations of the simulations. (You should not copy the description of the implementation at the begining of this document you should describe the visualization.)

Your analysis and answers to questions should be handed in to laboratory tutor.

Ingela Anderton,
Last modified: Wed Apr 22 16:07:55 CEST 1998