Background
Discrete event simulation
Discrete-event simulation with continuous time is a very frequently used method for comparing and investigating new features in operating systems and networks. The method is are also at the core of many visual simulators in the wider sense, including the core functions of systems that render animated movies as well as interactive computer games.
When network simulation is used, the goal is frequently to understand whether a new protocol or a new behaviour introduced into an existing protocol provides an improvement. Examples are that simulations help to study whether the changes improve
- the protocol's properties in competition with other protocols
- the utilization of network capacities
- the support of a new kind of workload
- system scalability
- ... and many more
For this study, it is highly important to determine the state variables that are required to find the answer. To reach an understanding, it is usually not sufficient to just print the value of a particular state variable as it changes during a simulation run. Several state variable may have to be combined into a derived variable that makes more sense (a very simple example is the combination of a state variable bytes-sent and measured simulation times into the derived variable sending-rate). To answer the question, it is also frequently important to perform statistical analysis of the data and interpret and present a compact form instead of every individual measurement point of a state variable.
System-under-test
The transport control protocol (TCP) is a mainstay of communication over the Internet. It is used in everything from email to streaming video on-demand. With the changing scales, capacities and applications of and in the Internet, TCP has frequently found to have limitations. It has been improved many times, and attempts to improve it are still continuously ongoing. The main variations of TCP have their own names, and the ones that we look at in this assignment are TCP NewReno, TCP Vegas and TCP CUBIC.
Note: ns-3.36.1 includes also code for TCP BBR, the hottest TCP Congestion Control version right now. However, this fails with the dumbbell-sim.cc that we provide, maybe because of some missing settings, maybe because of bugs in the BBR ode. Solutions for the problem would be welcome.
Task
Use the ns3 simulator (version 3.36.1) to make a comparison of the three TCP variations TCP NewReno, Vegas and CUBIC.
Simulation setup and simulation state
Compare how the three TCP variations perform using the classical "dumbbell" topology. The topology is illustrated in the figure below.
An example of C++ code that creates a dumbbell topology and starts unlimited TCP flows can be downloaded from the teaching material: material-for-home-exam-1
The dumbbell topology consists of a number of TCP senders (S), TCP receivers (R), routers (X and Y) and several links. The links from S to X and from Y to R are usually configured to have abundant bandwidth, while the bandwidth for the point-to-point link from X to Y (in the following named XY) limits the bandwidth that TCP connections from an S node to an R node must share.
The bandwidth limit means that XY is a bottleneck, and because of this, it may not be capable of handling all data packets from an S node to an R node fast enough with the bandwidth that you define. In fact, unlimited rate TCP flows do slowly but certainly increase their sending speeds until the bottleneck bandwidth is exhausted. After this, some packets must be dropped at node X. To determine how many packets can be waiting at X, you must also specify a queue with a limited length. This queue should be a DropTail queue. This is the simplest of all queuing strategies, just dropping packets that arrive from an S node when the queue is already full.
The number of S nodes and R nodes is an input parameter that you should explore in your comparison of TCP variants. You do not have to use different TCP variants within a single simulation run (this requires some bigger changes to the example code), but there interesting things to find.
Besides the packet loss ratio at X, there are lots of other interesting variables that can be measured or derived. I'm mentioning just a few that are very frequently used:
- sending rate of a TCP sender
- throughput of the TCP connection ((bytes received)/second)
- goodput of a TCP connection ((bytes received only once)/second)
- fairness between different TCP connections (Jain's fairness index)
- RTT - a TCP sender's estimation of the round-trip-time from S to R, which should change with the queue length at X
- CWND - a TCP sender's congestion window, which is the computed number of bytes that the sender is allowed to send in the next RTT
Presentation
- Make a visual classroom representation, in the spirit of a short lecture. Each group will have 20 minutes to present. Select a tool such as Powerpoint or Google Slides which allows you do download and hand in complete assignments. Tools to present results more interactively (Matlab, Jupyter Notebook) are great in many contexts but not for delivery as a homework. Deliver a PDF version of your presentation as well.
- The presentation must:
- explain the goals of your simulation
- explain which state variable you have used to answer that question, and which derived variables you computed
- present your results visually using plots (there are many examples in the intro lecture)
- explain the results
- explain how the plots assist you in explaining these results
- Present in the classroom.
- The presentation that you deliver is not a report. It should be very brief (for example using bullets) for each requested explanation. The oral presentation in the classroom should be more detailed.
- It is important to select state variables that are relevant for the question.
- It is important to plot either raw data or data that has been processed using statistical tools in a way that supports your explanation.
Deadline
The presentation must be submitted on September 19 at 12:00 (lunchtime, before the course). This text will be updated to inform you of the means for delivery.