1 Your Task

1. Download our copy of NS-3 with additions described below:

   git clone -b cs4457-dist https://github.com/charlesreiss/ns-3-dev ./ns-3-dev

2. Make sure you can run the scratch/mytcpvother simulation; see instructions below.

1.1 Part 1

1. Using (and modifying, if you want) mytcpvother produce:

   • A graph of congestion window size over time (for the MyTCP flow) with default settings.

   • A table with at least two rows, each of which represents a different maxBytes parameter, and columsn representing:

     • the maxBytes parameter;
     • the average goodput (rate of data bytes usefully transmitted) for each flow;
     • the average combined goodput for both flows

     You may, at your option, include additional columns.

2. Modify the mytcpvother to support changing the delay of the shared link. Then,

   • Produce a graph of the congestion window size over time (for the MyTCP flow) with a different link delay; and

   • Add a column of shared link delay to the table from the previous part, and at least one new row with a different delay than the others.

3. Based on your goodput results, estimate an emperical formula for how goodput changes (or does not change) as delay varies. An example way to do this would include plotting the results and estimating the regression line visually. (We are not expecting any mathematical modeling.) Briefly explain:

   • how you derived your formula;

   • what factor(s) you think you make goodput change in the way your formula specifies;

4. Submit your graphs, table, formula, and the explanations to the two points above, and any code modifications via the submission site.

1.2 Part 2

1. Customize the MyTcpCongestionOps so that on a simulation with default settings or with --linkBandwidth=10Mbps:

   • when the myTcpMode parameter is 1, the MyTCP flow completes at least 10% faster in the mytcpvother simulation

   • when the myTcpMode parameter is 2, the other flow completes at least 10% faster and the MyTCP flow completes no more than 30% slower;

   (Your customizations may not query information not ordinarily sent to the MyTcpCongestionOps object, like the exact configuration of the simulated links.)

2. Include in a report (in text, HTML, or PDF format; preferably with seperate sections for each of the below items):

   • What changes you made to MyTcpCongestionOps.

   • graphs of the congestion window size over time for MyTCP with your modifications (one for each added mode);

   • How you decided to make those changes. If your changes involve selecting numerical parameters, describe how you choose those parameters. (If you choose the parameters thorugh experimentation, that’s fine; explain what you tried to decide on the final values.)

   • Your assessment (ideally based on some experimentation) of what extent your technique could easily be extended to a substantially larger/smaller speed difference

3. Submit your report and your code modifications via the submission site.

2 Setting up NS-3 on portal

1. NS-3 needs cmake and ninja to build. These are available on portal through the module system:

   module load gcc cmake ninja

2. Before you first run NS-3, you need to configure it with

   ./ns3 configure

   (from the ns-3-dev directory)

3. You can run our example simulation (source code in scratch/mytcpvother.cc) using

   ./ns3 run scratch/mytcpvother

   The first time you do this, NS-3 will need to compile and link everything, which will take a while. NS-3 should avoid recompiling things that don’t change.

4. If you have compilation trouble or similar, it might be fixed by rebuilding things by running

   ./ns3 clean

   then rerunnning ./ns3 configure

3 Our NS-3 additions

3.1 MyTcpCongestionOps

In contrib/mytcp/model/mytcp.cc, we’ve created MyTcpCongestionOps. This implements a customizable congestion control policy. To change the congestion control policy, I would recommend changing IncreaseWindow and GetSsThresh functions.

We have arranged so the myTcpMode value is available as an instance variable.

3.2 mytcpvother

This simulation program is located in scratch/mytcpvother.cc.

You can run this with

./ns3 run scratch/mytcpvother

You can provide command line options to the simulation; see

./ns3 run scratch/mytcpvother -- --help

to see what options are available — or look at the code in main() that asks for the options.

You can pass values for options by doing something like

./ns3 run scratch/mytcpvother -- --maxBytes=180000000

The simulations uses a topology with 4 nodes, which is configured by the SetupTopology function:

• Node 1 and 2 are the source of flows (meaning it only sends data);
• Node 3 is a sink for the flows (meaning it only receives data)
• Node 0 is a router connected to all other nodes using point-to-point links.

The simulation sets a TCP connection from node 1 to node 3 using the MyTcpCongestionOps TCP implementation, and a connection from node 2 to node 3 using the NewRenoTcp implementation.

If you passing the --tracing option, the simulation will produce output files:

• mytcpvother-X-Y.pcap: a packet capture file for packets sent from node X’s interface number Y
• mytcpvother.tr: a text file listing all the events in the simulation
• mytcpvother-cwnd-X.csv, mytcpvother-ssthresh-X.csv: CSV files containing the values of the cwnd (congestion window size) and ssthresh (slow start threshold) values for node X’s TCP connections; the columns of the CSV file are time (in nanoseconds), socket number, and value.

4 Resources

In addition to the official NS-3 website and our slides, you might refer to Doral’s chapter on NS-3

5 Hints

5.1 Computing goodput

1. The reason we are asking for goodput and not throughput is that we don’t want to include the bandwidth used for TCP and IP headers, retransmissions, and other overhead.

2. You can figure out the total number of bytes received from main()’s output and the option supplied for maxBytes, or by looking at the packet traces in wireshark (to count how many bytes are received in the TCP connections).

3. main() prints out the time the last byte was received, or you can look at when the last byte was received in the packet traces.