Description

In this project you will implement weighted fair queuing. As in the previous projects, we will again be using UDP packets as our transport mechanism

The primary goals of this project:

To gain experience with the techniques for implementing weighted fair queuing.
To observe first-hand the behavior of multiple clients competing for available link bandwidth using FIFO queuing and weighted fair queuing.

You will once again use two programs, a sender and a receiver, connected by an emulator. Unlike the previous projects, I am not running the link emulator for you in this project. Instead it will be integrated with your simulated router (although I have supplied the needed code). The sender and receiver for this project are very simple -- your project 1 or project 2 sender and receiver, or even the code from homework one, will serve as starting points The meat of this project is in the implementation of the "router" that connects the sender and receiver.

Behavior of the sender: send UDP packets to the "router". The data payload of the UDP packets should look like:

source ip	destination ip
source port	destination port
weight	flow id
up to 1400 bytes of data

The first 24 bytes of the UDP payload are the "Project 3 Header". It turns out to be remarkably hard to get the source IP address at the sender, so the code I have provided for the router will fill it in for you. The sender should act as though it had a small congestion window -- just a few packets -- so it is willing to have a few un-acked packets all the time. You will be running several senders simultaneously for the experiements.

Behavior of the receiver: send ack packets back to the sender. We will assume no packet loss for this project, so the acks can be trivial -- any packet at all received by the sender can be treated as an ack. The receiver should send the acks to the source IP address and port number from the "Project 3 Header" in the packets it receives: they do not go back through the simulated "router". [Caution: the port numbers in the Project 3 Header are 4-bytes each, rather than IP's standard 2-bytes each. In the receiver you will need to extract the source port and put it into a struct sockaddr_in for use in a call to sendto. Make sure to make this assignment correctly. The following is safe:

sin.sin_port = htons(ntohl(pkt.src_port))

Other approaches may not produce what you need.] A single receiver can handle all of the simultaneous senders.

Behavior of the router: the router implements weighted fair queuing to allocate the bandwidth of the emulated link amongst the flows passing through it. For simplicity you may assume that the weight associated with any particular flow is unchanging. (That is, you can just use the weight seen in the first packet of a flow and ignore the weights in subsequent packets.) The weighted fair queuing algorithm is described in Chapter 6 of the textbook, but you may wish to refer to some of the technical papers referenced by the book for details. You will also implement a randomized weighted fair queuing algorithm (details provided separately) and perform the experiments again using that router.

I have provided a skeleton for the router coupled with a link emulator in /net/cs555/assignments/project3/router.c. There is also a makefile in that directory. The skeleton file also contains a FIFO router. I suggest using the FIFO router to get your sender and receiver working before beginning to build the FQ routers.

Experiments

With each of the routers (FIFO, WFQ and RWFQ) perform the following experiment. Start a sender with FlowID=1, Weight=1 and packet size 1024. After a couple of seconds, start another sender with FlowID=2, Weight=1, and packet size 512. After another couple of seconds, start a third sender with FlowID=3, Weight=2, and packet size 1024. After two more seconds stop the second sender, and 2 seconds later stop everything. You will probably want to use a shell script (or C program) to manage this starting and stopping of senders. The 2 second intervals are not critical.

Provide a graph of the total bytes received on each flow vs. time. The provided link emulator logs a line containing the time, the flow ID, and the packet size each time it completes a packet. You can process this information to produce the required graph. Please use a separate graph for FIFO, WFQ and RWFQ.

What to turn in

The following are to be placed in your cs555 directory in SNIF lab. Everything goes below /net/cs555/students/youruserid/project3/. Please follow the directions carefully about where to place things: it makes life a lot easier for Jin and me if everyone follows the same conventions about file placement.
In the doc/ subdirectory: a design document that describes all the important decisions you made in implementing the various algorithms. This file may be ASCII text, MS-Word, HTML or PDF.
In the programs/ subdirectory: all the source code for your sender, receiver, and router including a Makefile, as well as the executables. If you have a shell script for running the experiments, include that here as well, otherwise include instructions for how to run your programs.
In the report/ subdirectory: your report. Provide the command line used to invoke your sender and receiver for each experiment, your report on the expected and observed performance for each router. Assess the pros and cons for using RWFQ instead of WFQ. At the end of your report include a summary of what you learned in doing this project. The report file (only one please) may be ASCII text, MS-Word, HTML or PDF.
In addition to storing the files, print the design document, all source code and the report and turn in hard copy in class on the due date.

Notes

You may use the programming language of your choice as long as I agree to it ahead of time. C, C++, Java and Python are already blessed. I’m inclined to agree to Perl and Visual Basic but I want to talk to you ahead of time if you are considering either of these or another programming language.
The sender, receiver, and router can all be run on a single machine -- but they don't have to be. Since the emulated link is quite slow compared with the speed of the processors, running on a single machine should cause very little distortion of the results. Feel free to play with the emulated link speed, but if you raise it over 0.5Mb/s please only do so if you are running everything on a single machine -- I don't want to disrupt the EECS network by imposing high loads.
This emulator does not drop packets, it only delays them.
Have fun!

Consider the following approach to weighted fair queuing. Each time that the router is ready to send another packet, it randomly picks a packet from amongst the flows with available packets. If the weights are all the same and the packets are all the same size this will give an approximation to FQ. If we "load the dice" so that we pick flow i with probability w_i/W where W is the sum of the weights of flows with available packets, we have an approximation to WFQ. But again, this only works if the packets are all the same size.

We still need to adjust for different size packets in the different flows and varying size packets within a single flow. I leave it to you to find a suitable method of doing so.