In this assignment you will perform real network performance tests. The objective is that you see how Internet technologies/protocols may impact on the performance of end-user applications.
This assignment must be performed in a group of 2. Individual submissions, or submissions where one person has obviously done all the work, will be penalised.
Measure and observe the performance of Internet transport layer protocols (TCP, UDP) under different conditions, including different transport protocol parameters and different network conditions (such as packet loss and delay).
You can choose your own network topology (including types of hosts, links and intermediate devices). You need to use your own computers or you can use any of the available labs (including the ``Hacking Lab''). The simplest topology which you may use is direct connection between two computers (either via a cross-over cable or wireless LAN). You may use more complex topologies (with switches and routers) if you wish.
You should use the same topology for all experiments.
Your hosts can use any operating system that supports the test software (see below). However to experiment with the effect of lost packets, I recommend using tc which is only available for Linux operating systems (e.g. Ubuntu). I am not aware of any other software that has equivalent functionality that runs on Windows or BSD (MacOS) operating systems. Hence you probably will need at least one computer running Ubuntu or similar Linux operating system.
You should use iperf (or similar software) to measure the performance of TCP and UDP. You may also use the Java-based GUI to iperf, called jperf, if you desire (note, jperf is available from the iperf website and also includes a Windows binary executable). iperf/jperf is open-source software that runs on Linux, Windows and Mac.
Some tasks require you to force packets to be dropped and delayed. tc, which is part of the Linux Advanced Routing and Traffic Control (LARTC) tools, is excellent for this purpose. I don't know of any software that provides equivalent functionality that runs on Windows or BSD (MacOS) operating systems. If you do, then tell me! (You may be able to use firewall software ...)
Some hints on using the software are provided below.
You need to run a set of experiments, measuring the performance for each. Some of the most important/interesting parameters are: transport protocol; buffer size; packet size; window size; sending rate; packet loss; delay. Of course, not all parameters are relevant for both transport protocols (TCP/UDP).
Some optional parameters, which you may consider (but don't need to), include: different link data rates, re-ordering, duplication, corruption. The program tc can be used to introduce these network conditions.
You should start with the default values (used by iperf). And then consider a range of values that are likely to give results that will demonstrate the impact of that parameter on performance. For example, the default value packet size was 1000 Bytes, then you could try tests for 2000 Bytes and 3000 Bytes. The results from these three tests should indicate what other values to try: if the throughput doesn't change for each value, then maybe try a much higher (10000 B) or lower value (100 B). You may need to apply some trial-and-error. Finally, you should arrive at some measurements that if plotted in a graph would show the trend in performance as the parameter value changes. In most cases, you will need between 3 and 10 values.
For each experiment you need to measure a set of statistics that characterise the performance of the network. You should measure at least the statistics provided by iperf (e.g. throughput, delay, jitter, packet loss). You may think of other statistics. Make sure you understand what the iperf statistics mean.
Two things that you must consider when running performance experiments are: How long should each test run for? How many tests should be run?
By default, an iperf TCP test is for 10 seconds. This time should be sufficient, unless you notice significant changes in the performance over time. Think about whether running for a longer or shorter time would give more accurate results.
You should consider repeating each test multiple times. For example, run a 10 second TCP test and then repeat the same test (possible several times). Compare the results. If the performance results are about the same, then you may record just one value or the average of all values. However, if the results change significantly you may repeat more times and/or record the average results and discuss the difference. For example, if 3 tests gave you the throughput results of 10.1, 10.7 and 9.6MB/s, then they are quite similar. But if the results were 2.3, 10.7 and 25.6MB/s, then may need to repeat more times until you see a trend. If you do not notice any trend, then discuss this in your report.You should record all your test results in a file (or files). A spreadsheet is a good choice for most of you (e.g. .xls or .ods), as you can then easily create plots of your results. You need to submit this results file, however I will NOT look at it in detail. Therefore it doesn't have to be presented professionally - it is just your own record of the results. I am not interested in the exact data values - I am interested in how you present and interpret the data values you record.
You will be assessed on a report from your group. Read on for what is expected in the report...
On the command line, a simple way to use iperf is:
Read the man page and online instructions for using different iperf options.
See the ITS413 Mailing List archives, specifically questions from the course in 2008 about:
In Linux, tc is a traffic control application. It allows you to control packets being sent/received by your computer. For this assignment, you can use tc to delay and drop packets. Some simple examples, taken from this webpage, are given below:
To add a random delay of between 90 and 110ms (average 100ms) to every packet your computer sends do this (probably as sudo, assumes you are using your Ethernet interface eth0):
tc qdisc add dev eth0 root netem delay 100ms 10ms
To test that it works, ping another computer and record the average RTT. To remove this delay, use the del option:
tc qdisc del dev eth0 root netem delay 100ms 10ms
Now perform the ping again and you should see the difference in RTT from the delay introduced by tc.
To drop 1% of packets (randomly):
tc qdisc add dev eth0 root netem loss 1%
And again you can remove it by replacing add with del. Also you can change existing commands by using change instead of add and del.
Return to: ITS413 Home | Course List | Steven Gordon's Home | SIIT