CS 640, Spring 2014

Project 1: Exploring Networks

Grades are posted on Learn@UW. The rubric and question answers are available on the Project 1 Grading page.

Due: Tuesday, February 18 at 11:59pm

Clarifications

Overview

The assignment is divided into three parts:

  1. Real Network Measurements
  2. Mininet Tutorial
  3. Controlled Network Measurements
You must complete all three parts. Submission instructions are listed at the end of the project description.

Be aware that parts 2 and 3 require you to have access to a VM in the CS Department's Instructional Virtual Lab. It may take 1-2 business days to grant you access, so you should email Zuyu your group member's names and usernames well before the deadline to allow sufficient time to complete the assignment.

Part 1: Real Network Measurements

For the first part of the assignment, you will be measuring and analyzing the performance and structure of real networks. You will learn and use two common network tools ping and traceroute. These tools will be used in projects throughout the semester to help you test and debug code and understand how networks behave.

Each section below describes one of the tools, presents a set of experiments you should run, and asks you to answer a few questions about those results. You must include the output from your experiments and the answers to the questions in your submission -- see What to Submit at the bottom of the project description for a full list of what to submit.

You must conduct some of the measurements using a machine in the CS department and some of the measurements using a desktop or laptop connected to a home or public (e.g., library or coffee shop) network. Both tools are already installed on the Linux machines in the CS department. The ping utility is available by default in Linux, Mac OS, and Windows. The traceroute utility is installed in Windows (called tracert) and Mac OS by default. It can be installed in Linux using your package manager.

1.1 Ping

Network latency, specifically round trip time (RTT), can be measured using ping, which sends ICMP packets. The syntax for the command in Linux or Mac OS is:

ping [-c <count>] [-s <packetsize>] <hostname>
The syntax in Windows is:
ping [-n <count>] [-l <packetsize>] <hostname>
The default number of ICMP packets to send is either infinite (in Linux and Mac OS) or 4 (in Windows). The default packet size is either 64 bytes (in Linux and Mac OS) or 32 bytes (in Windows). You can specify either a hostname (e.g., cs.wisc.edu) or an IP address (e.g., 128.105.2.6).

To save the output from ping to a file, include a greater than symbol and a file name at the end of the command. For example:

ping -c 10 google.com > ping_c10_s64_google.log

1.1.1 Experiments with Ping

From one machine in one of the CS department labs (not a laptop or mobile device connected to the CS wireless network), ping the following hosts 10 times (i.e., packet count is 10) with a packet size of 64 bytes:

  1. narnia.wail.wisc.edu (Server in the third floor of the CS building)
  2. physics.wisc.edu (Server in the Department of Physics)
  3. mscs.mu.edu (Server at Marquette University in Milwaukee, WI)
  4. www.cs.grinnell.edu (Server at Grinnell College in Grinnell, IA)
  5. csail.mit.edu (Server at MIT in Cambridge, MA)
  6. cs.stanford.edu (Server at Stanford University in Stanford, CA)
  7. cs.manchester.ac.uk (Server at the University of Manchester in the United Kingdom)
Store the output of each ping command in a separate file named ping_c10_s64_HOSTNAME.log, replacing HOSTNAME with the hostname for the host you pinged (e.g., ping_c10_s64_narnia.wail.wisc.edu.log).

From one machine in one of the CS department labs, ping narnia.wail.wisc.edu 10 times with the following packet sizes:

  1. 100 bytes
  2. 500 bytes
  3. 1000 bytes
  4. 1400 bytes
Store the output of each ping command in a separate file named ping_c10_sSIZE_narnia.wail.wisc.edu.log, replacing SIZE with the size of the packets you used (e.g., ping_c10_s100_narnia.wail.wisc.edu.log).

From one machine outside of the CS department -- a machine at home, in one of the campus libraries, a coffee shop, etc. -- repeat the first set of experiments (i.e., pinging the seven different hosts 10 times with a packet size of 64 bytes). Store the output of each ping command in a separate file named ping_c10_s64_external_HOSTNAME.log, replacing HOSTNAME with the hostname for end-host you pinged (e.g., ping_c10_s64_external_narnia.wail.wisc.edu.log).

1.1.2 Questions About Latency

Now look at the results you gathered and answer the following questions about latency. Store your answers in a file named ping.txt.

  1. Does the average RTT vary between different hosts? What aspects of latency (transmit, propagation, and queueing delay) might impact this and why?
  2. Does the average RTT vary with different packet sizes? What aspects of latency (transmit, propagation, and queueing delay) might impact this and why?
  3. Where was the external machine you used (home, library, campus wireless in a specific building, coffee shop, etc.)?
  4. Compare the average RTTs you gathered with 64 byte packets in the CS department versus those you gathered from a different location. Which hosts have approximately the same RTT when measured from both locations and which hosts have different RTTs? Why?
  5. For the first set of RTTs you measured in the CS department (seven different hosts, 64 byte packets), look at the 10 individual RTTs gathered for each host. For a given hostname, compare the first measured RTT versus the subsequent nine RTTs. Are they different? If so, why might this be? If you run the same ping command twice (one right after the other), do you still observe differences the second time? Why or why not?

1.2 Traceroute

The path taken through a network, can be measured using traceroute. The syntax for the command in Linux or Mac OS is:

traceroute <hostname>
The syntax in Windows is:
tracert <hostname>
You can specify either a hostname (e.g., cs.wisc.edu) or an IP address (e.g., 128.105.2.6).

1.2.1 Experiments with Traceroute

From one machine in one of the CS department labs (not a laptop or mobile device connected to the CS wireless network), traceroute to the following hosts:

  1. narnia.wail.wisc.edu
  2. physics.wisc.edu
  3. mscs.mu.edu
  4. www.cs.grinnell.edu
  5. csail.mit.edu
  6. cs.stanford.edu
  7. cs.manchester.ac.uk
Store the output of each traceroute command in a separate file named traceroute_HOSTNAME.log, replacing HOSTNAME with the hostname for end-host you pinged (e.g., traceroute_narnia.wail.wisc.edu.log).

1.2.2 Questions About Paths

Now look at the results you gathered and answer the following questions about the paths taken by your packets. Store your answers in a file named traceroute.txt.

  1. Is any part of the path common for all hosts you tracerouted?
  2. Is there a relationship between the number of nodes that show up in the traceroute and the location of the host? If so, what is this relationship?
  3. Is there a relationship between the number of nodes that show up in the traceroute and latency of the host (from your ping results above)? Does the same relationship hold for all hosts?

Part 2: Mininet Tutorial

For the second part of the assignment, you will learn how to use Mininet to create virtual networks and run simple experiments. According to the Mininet website, Mininet creates a realistic virtual network, running real kernel, switch and application code, on a single machine (VM or native), in seconds, with a single command. We will use Mininet in projects throughout the semester.

2.1 Running Mininet

To run Mininet, you need a virtual machine (VM). There are many VMs available from vendors, many of which are free. Oracle's VirtualBox is available in the mumble lab in the CS department. We also have the Instructional Virtual Lab, which runs on VMware. You are welcome to conduct your experiments, and later in the semester test your code, on your personal systems, but we will grade all projects using the Instructional Virtual Lab.

To be assigned a VM with Mininet from the Instructional Virtual Lab, you must send an email to Zuyu (zuyu {at} cs.wisc.edu) with the names of your group members and your CS usernames. He will provide you with the name of a VM and a username and password you can use to login. Please note that it will take 1-2 business days for you to be assigned a VM because the Computer Systems Lab (CSL) must grant the appropriate permissions to each VM. It is up to you and your group members to request a VM well before the deadline to ensure you have enough time to complete the project. As noted on the syllabus, late projects will be penalized 5 points per day.

If you want to setup Mininet on your own system, there are instructions on the Mininet website.

A graphical environment (X11) is not installed in the VM by default. If you are connecting to the VM using SSH from a machine with X11 installed (Linux machines in the CS department or a personal machine with Linux or Mac OS), you can tunnel the X11 traffic over SSH using by including the "-X" option in your ssh command. Alternatively, you can install a graphical environment in the VM by running:

sudo apt-get update
sudo apt-get install gdm gnome-shell gnome-terminal
sudo reboot
To start the graphical environment, run:
sudo service gdm start

2.2 Mininet Walkthrough

One you have a Mininet VM, you should complete the following sections of the standard Mininet walkthrough:

At some points, the walkthrough will talk about software-defined networking (SDN) and OpenFlow. We will discuss these during the second half of the semester, so you do not need to understand what they mean right now; you just need to know how to run and interact with Mininet.

You do not need to submit anything for this part of the assignment.

Part 3: Controlled Network Measurements

For the third part of the assignment, you will be measuring and analyzing the performance of small networks with specific topologies in a controlled environment. You will use Mininet, ping, and one new tool -- iperf.

Each section below describes one network topology, presents a set of experiments you should run, and asks you to answer a few questions about those results. You must include the output from your experiments and the answers to the questions in your submission -- see What to Submit at the end of this project description for a full list of what to submit.

Pythons scripts to run Mininet with the topologies described below are in the TAR file at: http://cs.wisc.edu/~agember/cs640/s14/files/project1.tgz. To download these scripts in your Mininet VM, run:

wget http://cs.wisc.edu/~agember/cs640/s14/files/project1.tgz
tar xzvf project1.tgz

3.1 Point-to-Point Network

The first network is a simple point-to-point network with two hosts connected by a single 10Mbps link.

To run Mininet with this topology file, run the Python script project1_point.py using sudo:

sudo python project1_point.py
The Python script will automatically start Mininet with the appropriate topology and provide you a Mininet command prompt. Do not use the Mininet command (mn) with the --custom argument.

3.1.1 iperf

You will measure the bandwidth between the two hosts using iperf, which sends TCP or UDP packets between hosts. One host must server as the server and one as the client. The command to run on the server is:

iperf -s
The command to run on the client is:
iperf -c <ip>
Replace ip with the IP address of the server.

You can also pass several other options to iperf, including:
-i <seconds> to specify how frequently to report the bandwidth
-t <seconds> to specify for how long the client should transmit (this option can only be passed if also using -c)

To use these commands in Mininet, you should start an xterm for both hosts (h1 and h2) and run one of the commands in each xterm:

mininet> xterm h1 h2
h2$ iperf -s
h1$ iperf -c 10.0.0.2 -i 10 -t 60
Note, you must use the IP address for a host, and not the name of a host, when running commands in a host's xterm. In other words, you need to run iperf -c 10.0.0.2, not iperf -c h2. For all of the virtual networks you will use for this assignment, the number in the hostname (h1, h2, h3, ...) is the same as the last octet in the IP address (10.0.0.1, 10.0.0.2, 10.0.0.3, ...).

3.1.2 Experiments with a Point-to-Point Network

Run iperf for 60 seconds, outputting the bandwidth every 10 seconds. Store the output from the iperf client (not the server) in a file named iperf_point.log. While iperf is running, ping the server from the client, sending 10 packets 100 bytes in size; store the output from ping in a file named ping_used.log. In particular, you should execute the following set of commands:

mininet> xterm h1 h2
h2$ iperf -s
h1$ iperf -c 10.0.0.2 -i 10 -t 60 > iperf_point.log &
h1$ ping -c 10 -s 100 10.0.0.2 > ping_used.log

After iperf completes, run the same ping and store the output in a file named ping_idle.log.

3.1.3 Questions About a Point-to-Point Network

Now look at the results you gathered and answer the following questions about bandwidth and latency. Store your answers in a file named point.txt.

  1. Does the bandwidth measured by iperf match the bandwidth of the link? If it does not match, what might be the cause?
  2. Is the latency different when measuring bandwidth versus not? What aspects of latency (transmit, propagation, and queueing delay) might impact this and why?

3.2 Switched Network

The second network is a simple switched network with four hosts all connected to a single switch with 10Mbps links.

To run Mininet with this topology file, run the Python script project1_switch.py using sudo.

3.2.1 Experiments with a Switched Network

For the first experiment, run iperf for 60 seconds, outputting the bandwidth every 10 seconds. The node h1 should be the client and h2 should be the server. Store the output from the iperf client in a file named iperf_onepair_switch.log. While iperf is running, ping the node h4 from the node h3, sending 10 packets 100 bytes in size; store the output from ping in a file named ping_onepair_switch.log.

For the second experiment, run iperf simultaneously (or as close as you can) between two pairs of nodes. The nodes h1 and h3 should be clients and h2 and h4 should be servers; h1 should use h2 as its server and h3 should use h4 as its server. As above, run iperf for 60 seconds, outputting the bandwidth every 10 seconds. Store the output from iperf on h1 in a file named iperf_h1h2_switch.log and the output from iperf on h3 in a file named iperf_h3h4_switch.log.

3.2.2 Questions About a Switched Network

Now look at the results you gathered and answer the following questions about bandwidth and latency. Store your answers in a file named switch.txt.

  1. How does the latency measured in the first experiment compare to the latency stored in ping_idle.log from the point-to-point topology? Why?
  2. Does the bandwidth measured by iperf in the second experiment match the bandwidth of the links? Why or why not?

3.3 Network of Networks

The third, and final, network is a networks. All hosts are connected to the switches with 10Mbps links. Switches s1 and s2 and connected by a 10Mbps link, s2 and s3 are connected by a 15Mbps link, and s3 and s4 are connected by a 20Mbps link.

To run Mininet with this topology file, run the Python script project1_network.py using sudo.

3.3.1 Experiments with a Network of Networks

For the first experiment, run iperf (for 60 seconds, outputting bandwidth every 10 seconds) between two pairs of nodes simultaneously: h1 -> h3 and h2 -> h4. Store the output from the iperf clients in files named iperf_h1h3_network.log and iperf_h2h4_network.log.

For the second experiment, run iperf (for 60 seconds, outputting bandwidth every 10 seconds) between one pair of nodes: h1 -> h3. Store the output from the iperf client in a file named iperf_h1h3only_network.log.

For the third experiment, run iperf (for 60 seconds, outputting bandwidth every 10 seconds) between two pairs of nodes simultaneously: h3 -> h5 and h4 -> h6. Store the output from the iperf clients in files named iperf_h3h5_network.log and iperf_h4h6_network.log.

For the fourth experiment, run iperf (for 60 seconds, outputting bandwidth every 10 seconds) between two different pairs of nodes simultaneously: h5 -> h7 and h6 -> h8. Store the output from the iperf clients in files named iperf_h5h7_network.log and iperf_h6h8_network.log.

3.3.2 Questions About a Network of Networks

Now look at the results you gathered and answer the following questions about throughput and multiplexing. Store your answers in a file named network.txt.

  1. How do the bandwidths measured in the first experiment compare to the bandwidth measured in the second experiment? Why?
  2. How do the bandwidths measured in the first experiment compare to the bandwidths measured in the third experiment? Why?
  3. How does the bandwidth measured in the second experiment compare to the bandwidths measured in the fourth experiment? Why?

What to Submit

Create a single zip file containing the following:

Upload the zip file to the Project 1 dropbox on Learn @ UW. Please submit only one zip file per group.