Assignment 2: Network emulation
The goal of this assignment is to experience the contrast between performing the performance analysis of a computer network through emulation and simulation. It is typical to assess new algorithms with simulation, and validate the simulation through a real-world or emulation study.
The goal of this assignment is to learn how the performance of protocols as they are implemented in real operating system can be assessed by means of network emulation. The same approach to performance assessment is also valid for distributed systems that are not emulated, but deployed in the real world.
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 changed, this research goal has stayed highly important. TCP Goodput in this context denotes the average speed in kilobit/second 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 included data that is sent more than once). This research has led to an abundance of TCP variants, several of which are implemented in the Linux kernel. While we can read the source code of Linux's TCP variants, several operating systems hide theirs; passive measurements --the technique used in this assignment-- can then be used to assess their performance and varying conditions
Compare the downloading performance of 2 of Linux's TCP variants
If you don't use our machine sets, you have to set up a testbed consisting of three virtual machines (if you have three physical machines available, you may also use these). Configure them as a server, a network emulator and a client. The network emulator runs Linux and the tool netem is used to control the emulation. The emulator machine does not have to run a routing demon; packet forwarding (e.g. using route add ...) is sufficient.
- Install programs on server and client that you want to use for performing download tests. You can choose, but keep in mind that a download operation is characterized by an application that tries to move data as quickly as possible.
- Configure the emulated networks. You must choose the bandwidth on both outgoing interfaces of the network emulator as 10 Mbps. The latency on both outgoing interfaces is fixed to 100ms. Do not introduce artificial packet loss of jitter.
- Parameter 1: Select the TCP same variant on server and client. You must test the variants New Reno (called "reno") and CUBIC (called "cubic"). Do not mix.
- Parameter 2: For various tests, change the queue length on all interfaces. Papers indicate that a small concurrent TCP connections if necessary (but also required) to consume nearly the entire 10 Mbps of available bandwidth, and that CUBIC is better.
- 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 very small.
- Perform tests to answer the following questions:
- How is the throughput of each TCP connection influenced by these parameters?
- How is the round-trip time of these TCP connections influenced by these parameters?
- How do the simulated performance results from Assignment 1 compare to the emulated performance results that you achieved here?
- Write a report. Choose appropriate means of presenting the answers to these questions graphically. It is generally not a good idea to simply plot one line for each experiment into a time-vs.-download-byte graph. The report must be no longer than 4 pages.
Solve the task in a group of two (or alone). Present your experiences and results orally in the course on October 1. It is mandatory to write a report that in the specified format and deliver it by October 1, using Devilry. Keep in mind that it is possible to update the report until November.
It is mandatory to present your group's results on October 1. 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.
These should be virtual machines. The OS that is used on these machines should be Linux, since the assignment asks for 2 Linux variants (New Reno and Cubic). These machines should be used exclusively by one group at a time. How to set up the network in the machines, see the networking tools guide.
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.