Assignment 1: Network simulation

Background

The goal of this assignment is to learn how the performance of (transport) protocols by means of network simulation. It is typical to assess new algorithms with simulation, and later validate the simulation through a real-world or emulation study (assignment 2).

Motivation

One of the busiest research topics in the networking research community throughout the existance of the Internet has been the maximization of the goodput of TCP. Although the properties of the Internet, such as the dominant link layers in LANs and WANs, the available bandwidths, the speed of routers and many more things, have changed continuously, this research goal has stayed highly important. TCP Goodput in this context denotes the average speed in kilobits per second (kbps) that is achieved by applications that perform download operations using TCP (in contrast to throughput, which can be interpreted as the bandwidth that is consumed, and which may include data that is sent more than once). This research has led to an abundance of TCP variants, several of which are implemented in operating system kernels (like Linux). These variants implement mechanisms that have undergone a lot of performance testing before their integration into kernels, and such performance testing under a variety of conditions is usually first done using SIMULATION -- the technique used in this assignment.

Simulation is usually used for evaluating new mechanisms before they become available for emulation (comes in assignment 2); also if an algorithm is theoretically intractable and if a mechanism needs large-scale validation. The latter is quite typical in industry, where an ISP may use a high-end commercial simulator to assess the impact of a network upgrade on the overall network performance. This is probably the only drag-and-drop usage scenario for network simulators; most other uses concern testing and comparison of algorithms and involve programming.

Task

Compare the downloading performance of 2 of Linux's TCP variants using the simulator NS3

You should use your own complete installation of NS3.

1. Adapt one of NS3's test setups (found in ns-allinone-3.14.1/ns-3.14.1/examples/tcp of your NS3 installation) to simulate a 3-machine setup: sender (end-host) --> network --> receiver (end-host). tcp-large-transfer.cc provides a good idea of the test that you are meant to perform, while tcp-nsc-lfn.cc provides an example for choosing TCP Cubic. Look at these as best starting points for running tests with both TCP New Reno and TCP Cubic. Keep in mind that a download operation is characterized by an application that tries to move data as quickly as possible.

2. Configure the simulation. Use a bandwidth of 10 Mbps, a latency of 50ms on each link and no random packet loss or jitter. Note that every simulated link has latency; the total latency should be 100ms. Set the queue length on the network machine ("router", "intermediate node") to 150 packets. For the application setup, keep in mind that a download operation is characterized by an application that tries to move data as quickly as possible.

3. Parameter 1: Select the same TCP variant on the end hosts for each test run. Don't mix. You must test the variants New Reno and Cubic.

4. Parameter 2: Change the queue length on both outgoing interfaces.

5. Parameter 3: Measure the download performance between server and client with a varying number of concurrent TCP connection, which are used for separate concurrent downloads. Note that research indicates that you should expect interesting differences only if the number of concurrent connections is small.

6. Perform tests to answer the following 2 questions:

   • How is the throughput of each TCP connection influenced by these 4 parameters?

   • How is the round-trip time of these TCP connections influenced by these 4 parameters?

7. Write a report. ​Choose appropriate means of presenting the answers to these questions graphically. The report must be no longer than 4 pages.

Assignment

Solve the task in a group of two. Present your experiences and results orally in the course on September 10. It is mandatory to write a report that is in the specified format and deliver it using Devilry. We will use this report to give you feedback on the way in which you use, or should use, graphs in a report.

It is then possible to update the report until late November.

It is mandatory to present your group's results on September 10. You do not need to prepare a formal presentation (like a Powerpoint foilset); however, you must show the measurement results that are included in your report and that you discuss in class. The discussions in class are supposed to help you improve your report for final delivery. It is recommended that you have a web page or a PDF document that is web-accessible from an arbitrary computer.

Machines

To approach this assignment, you need 1 machine. NS3 runs as a process in user space and requires no virtual machines. NS3 runs on all Unix variants. You are free to use any IFI machine or your own.

Report

The written report has up to 4 pages in ACM format (see right column). It is expect that such a report includes: a description of the assignment, a description of the testbed, an explanation of the metrics that were chosen to present the measurement results visually, graphs showing the results, an interpretation of the graphs.

The results must be based on the own tests.

The report is evaluated by writing quality, by the trustworthiness and correctness of the results. The evaluation does not consider whether related work (citations of other papers) is included. It is not necessary to cite existing work in this report.

FAQ

- Does it exist any good tutorials or HOWTOs for NS3?

May be hard to find, but an ok start is https://www.nsnam.org/ns-3-14/documentation/

- How do I compile ns3 on IFI machines?

The old Linux distribution on IFI gave an unexpected problem. However, a solution that seems to work with gcc-4.1.2 on Redhat is to use version 3.11. The build.py seems to use very long time and fail. A fix seems to be to enter the ns3 directory and run

./waf --configure disable-python enable-testing enable-examples
./waf

If one then later calls 
./waf tcp-nsc-zoo
or
./waf tcp-nsc-lfn
the simulator generates log files (pcap) which looks ok in wireshark. 

- How can you change the queue length of interfaces?

Det avhenger litt av grensesnittene dere bruker, men anta at dere bruker PointToPointNetDevices (http://www.nsnam.org/doxygen/classns3_1_1_point_to_point_net_device.html) så finnes det en metode der: 
"SetQueue (Ptr< Queue > queue)".

For å lage en kø kan man da gjøre noe sånt som:
Ptr<DropTailQueue> q = CreateObject<DropTailQueue>();

DropTailQueues (http://www.nsnam.org/doxygen/classns3_1_1_drop_tail_queue.html) har tre attributter (hvis du blar litt ned på den siden jeg linket til, kommer du til GetTypeId metoden så har du oversikt over alle attributes der): Mode, MaxPackets, MaxBytes. For å forandre disse:

q->SetAttribute("Mode", EnumValue (DropTailQueue::QUEUE_MODE_PACKETS));
q->SetAttribute("MaxPackets", UintegerValue(100);

Til slutt kan man sette køen med SetQueue():
enEllerAnnenPppNetDevice->SetQueue(q);

- How can you change congestion control?

By default er det NewReno som brukes. Informasjon om det her finner dere her: https://www.nsnam.org/docs/release/3.14/models/singlehtml/index.html#document-tcp.

For å bytte congestion control på alle noder kan dere gjøre dette:
Config::SetDefault ("ns3::TcpL4Protocol::SocketType", StringValue ("ns3::TcpTahoe"));

Litt usikker på hvilke versjoner som er implementert i ns-3, men det kan se ut som mulighetene er rfc793 (ingen congestion control), tahoe, reno, og new reno. Det er også mulig å bruke stack implementasjonen fra den virkelige verden ved bruk av "The Network Simulation Cradle", men dette har vi ikke testet... ;-( (Noen tips kan kanskje sees i starten av main-funskjonen på denne siden: http://eugen.dedu.free.fr/publi/ns3/tcp-nsc.cc)

- Can you change congestion control on one single node?

For å bytte congestion control på enkeltnoder kan man gjøre noe som dette:
TypeId tid = TypeId::LookupByName ("ns3::TcpTahoe");
Config::Set ("/NodeList/*/$ns3::TcpL4Protocol/SocketType", TypeIdValue (tid));

I Config-pathen der må man bytte ut * med den noden man ønsker å bytte congestion control på. NodeList er en global liste med alle noder i hele simuleringen. Hvis man ikke vet hvilket nummer noden du ønsker å bytte congestion control på, kan du finne denne ved:

TypeId tid = TypeId::LookupByName ("ns3::TcpTahoe");
std::stringstream nodeId;
nodeId << n0n1.Get (0)->GetId ();
std::string specificNode = "/NodeList/" + nodeId.str () + "/$ns3::TcpL4Protocol/SocketType";
Config::Set (specificNode, TypeIdValue (tid));
 

hvor n0n1 da er en Node.

- What are good tools to process the results?

The logs returned by ns3 is pcap files. These can be opened for example using wireshark, or processed using tools like tcptrace. Or you could use libpcap for writing your own analysis tool....

- We can't set up two TCP interfaces giving us a problem on the middle node?

The middle node does not need to process the TCP layer - it is just forwarding packets, thus you do not need to use TCP on this node.

- I cannot get the congestion window and the RTT out from the simulation?

The simulation delivers a PCAP file. Here you should be able to match the packets with the corresponding ACKs and then calculate the values you need, e.g., using tcptrace...