Table of Contents

Introduction

In this project, we will create a simple topology where we can design and implement a real queueing system. The goal is to demonstrate Little's Law as we play with queue parameters and observe traffic flow.

Design Topology

In order to implement a queue and to observe its effect on network traffic, we first need:

1. A couple hosts to generate and receive packets. Let's call these "host-1" and "host-2".
2. A switch on which to implement the queue. Let's call this VM the "switch".

As such, let's draw a GENI topology in Jacks to accomplish this. Our topology will have host-1 and host-2, each which is connected to the single switch. If a host-1 wants to relay packets to host-2, the packets must traverse the switch (ditto for host-2 to host-1).

It is important that the VM serving as the switch use the "Ubuntu 14 with OVS by Niky" image. The other VMs can use the default image; however, it is recommended you use the "Ubuntu 14 with OVS by Niky" image just to keep everything simple and versatile.

Once we finish our design, let's select an aggregate on which to deploy our GENI resources – make sure it's an InstaGENI aggregate. Recall that we can view the utilization of the various InstaGENI aggregates by visiting this page.

Setup Resources

On our host-1 and host-2, we will need to install iperf, which is the tool we will use to generate packets.

host-1$ sudo apt-get install iperf

and don't forget host-2:

host-2$ sudo apt-get install iperf

Next, let's setup the switch by adding an Open vSwitch (OVS) bridge:

switch$ sudo ovs-vsctl add-br my-switch			# add an OVS instance (i.e. a bridge)
switch$ sudo ovs-vsctl add-port my-switch ethX	# attach ethX to the switch
switch$ sudo ovs-vsctl add-port my-switch ethY	# attach ethY to the switch
switch$ sudo ifconfig ethX 0					# remove ethX IP address (and also remove route)
switch$ sudo ifconfig ethY 0					# remove ethY IP address (and also remove route)

where ethX and ethY are the interfaces associated with the LANs leading from the switch to host-1 and host-2. Hint: They're not eth0. (Please don't use eth0, please...)

Now, if we were to test connectivity from host-1 to host-2 via the switch using ping, we'd be unsuccessful. Why? Well, take a look at the route tables of host-1 and host-2 and you'll see they are not routable from one another. To fix this, we can assign host-1 and host-2 IPs on the same subnet. You can use whatever private IPs you want, but I'll use the following just so we can better understand the context of the iperf commands we'll run later:

host-1$ sudo ifconfig ethA 10.0.0.1/24	# set ethA IP on host-1
host-2$ sudo ifconfig ethB 10.0.0.2/24	# set ethB IP on host-2 (must be different from host-1 but on same subnet)

where ethA is the network interface on host-1 that connects to the LAN leading to the switch and ethB is the network interface on host-2 that connects to the LAN leading to the switch.

After this, we should be able to ping between host-1 and host-2. Verify that you can do this before proceeding.

Run Experiment without a Queue on the Switch

First, let's run an iperf test to establish a baseline. iperf essentially pumps either TCP or UDP packets into the network – whatever we specify – to test the network performance. TCP will attempt to completely saturate the network link without losing any data; UDP, on the other hand, will send data at a defined rate from the source without care for whether or not the data actually makes it to the recipient. We'll use UDP for this experiment to gain better control over the data rate.

We'll designate host-1 as the client and host-2 as the server, where the client will send data to the server (i.e. a file upload).

On host-2:

host-2$ iperf -s -u		# run an iperf server (-s) process to accept UDP (-u) on the default port of 5001

And on host-1:

host-1$ iperf -c 10.0.0.2 -u -i 1 -t 10		# run an iperf client (-c <ip>) process that sends UDP (-u) packets to iperf server 10.0.0.2

We'll see host-1 start to send data to host-2. The transfer will show us an update every second (-i 1) and will terminate after 10 seconds (-t 10). On host-1 and host-2, we can see the number of packets that failed to make it from host-1 to host-2. We should see that all packets make it – (0 lost)/(total transferred).

Questions

1. What do the results tell us about the utilization of the queueing system on the switch?
2. What is the service rate of the switch? You do not have to give an exact answer.

Setup Queue on the Switch

Let's make things more interesting and setup a queue that we can control on the switch. 

To set up our queue, we'll use a program called tc, or traffic control. This is a relatively nice and high level way to manipulate queueing on our VM network interfaces.

Question

1. We want to control the flow of traffic with our queue from host-1 to host-2. On which network interface of the switch should we set up the queue – the one connected to the LAN leading to host-1 or the one connected to the LAN leading to host-2? Hint: What is the "server" or resource of the queueing system our packets are trying to access at the switch VM with respect to host-1-to-host-2 traffic flow?

Run Experiments with a Queue on the Switch

blahdy blah

Submission

On the due date indicated in the calendar, please submit a hard copy of your responses to the questions posed inline above.

1. here?