In this assignment, you will use Mininet to understand buffer sizing and how Mininet can be used for modeling real world research .
All Internet routers contain buffers to hold packets during times of congestion. The size of the buffers is dictated by the dynamics of TCP’s congestion control algorithm. The goal is to make sure that when a link is congested, it is busy 100% of the time, which is equivalent to making sure the buffer never goes empty. Until 2004, the common assumption was that each link needs a buffer of size RTT x C where RTT is the average round-trip time of a flow passing across the link, and C is the data-rate of the bottleneck link.
A paper published at Stanford outlines a new “rule of thumb” for buffer sizing showing that a link with N flow requires a buffer size at most (RTT x C) / sqrt(N). This means smaller buffer sizes for links with large numbers of flows and potentially cost savings. The original paper included results from simulation and measurements from a real router, but not for a real network. Later, Neda Beheshti created a hardware testbed to test the buffer sizing results in the Internet2 backbone, and demonstrated it at Sigcomm 2008. We highly recommend watching the five-minute YouTube video of the experiment.
You will reproduce this experiment using Mininet.
In the hardware experiments, a number of TCP flows were started from two end-hosts at Stanford University to a server at Rice University (Houston, Texas), via a router in the Internet2 POP in Los Angeles (see Figure 1). The link from LA to Houston was constrained to 62.5Mb/s to create a bottleneck, and the end-to-end RTT was measured to be 87ms. Once the flows were established, a script ran a binary search to find the buffer size needed for 99% utilization on the bottleneck link.
Since you don’t have access to the hardware setup, your goal is to recreate key characteristics of the hardware topology in Mininet (see Figure 2). Mininet uses software rate limiters (htb from the “tc” suite) and software delay queues (netem) to emulate wide-area network links.
The goal is to show how the link utilization at the bottleneck link varies with the buffer size allocated to it. Your submitted code will use the following algorithm, and the provided code implements most of the steps for you:
For each number of flows N=1,2, … [large number, up to 800]:
You will use many instances of iperf, one per flow, to generate equal numbers of long-lived TCP flows from clients A and B to server C. For example, to generate 400 flows total, you must start up 200 iperf clients on host A and then the remaining 200 on host B. The iperf code has been modified in two small ways: (1) the maximum number of connections a server can handle has been increased to 1024, and (2) the code waits for a few seconds after the handshake completes to start sending data. NOTE : bw_host is used to specify the bandwidth of the hosts( A to switch, B to switch ) bw_net is used to specify the bandwidth of the hosts( C to switch )
The binary search test in this assignment requires a modified iperf. Download and compile a modified iperf as follows (from within the final_project folder):
sudo pip install termcolor
Your task is to fill the missing pieces in buffersizing.py and buffersizing-sweep.sh. Here’s a summary of the functions in
buffersizing.py, which includes the set of functions you need to fill, marked by
TODO comments in the code. Once you have filled in the below functions, please follow the steps below to complete your task.
StarTopo: The definition of the topology used in the assignment. Make sure to add the links to the switch in sequential order i.e. add link from host A to the switch, then from host B, and finally host C. This will ensure the interface from the switch to host C is <switch-name>-eth3, where <switch-name> is the string name you assigned to the switch. Note that when you set the delay you will split the total equally across both sides of the switch such that the delay for any link is 43.5ms and the total round trip time is 87ms as in the original topology.
do_sweep: Does a binary search across sizes to find the minimum buffer size that achieves 98% utilization. It uses the following helper functions:
set_q: set buffer size
set_speed: set the link bandwidth
get_rate: get current aggregate throughput of the flows over the bottleneck link
ok: check if achieved throughput is greater than 98% of the available bandwidth
verify_latency: Verify the latency settings of the topology you’ve created (HINT : use ping)
verify_bandwidth: Verify the bandwidth settings of the topology you’ve created (HINT : use iperf)
main: The main function where the execution begins
buffersizing-sweep.sh: you will have to set the value of iface to the name of the interface you change the buffer size on.
Run buffersizing.py for N=1. The cwnd and bottleneck buffer occupancy are automatically plotted (run buffersizing-sweep.sh from command line to generate the plots) and saved in the output directory for you:
sudo python buffersizing.py --bw-host 1000 --bw-net 62.5 --delay 43.5 --dir test --nflows 200 --iperf ~/iperf-patched/src/iperf
Increase N and repeat the above experiment. What happens to cwnd and buffer occupancy?
buffersizing-sweep.sh, binary search for the minimum buffer size required for 98% utilization. Compare against hardware results by viewing the
result.png in the log output folder.
Submit your topology file
buffersizing.py and also the
buffer-size-result.txt file created in your log folder on the assignment submission page.
Once you submit your project, send an email to firstname.lastname@example.org with the following information:
Before you move on, take a stab at answering the quiz questions below and feel free to discuss your responses in the forum. Good luck !
Note: When you run
buffersizing.py, you may see an error message about
tcp_probe. Don’t panic!
tcp_probe is a utility that the program uses to track congestion window of your flows. The program tries to make sure it removes all existing instances of
tcp_probe before loading a new instance. The error message shows up if there was no previously running instance of
Mininet is not a simulator. Hardware is not a simulator. Neither of these use synchronized virtual time, like a simulator. Any process can temporarily block something time-critical, like a byte-counter read or a packet send, which a simulator might run at perfectly equal intervals. You cannot expect identical results between runs when there is noise in the measurements as well as variability in the behavior of TCP. That said, we have written the starter code to add some robustness to variability. In particular,
get_rates() waits before reading values, corrects for variability in the precision of the sleep timing, takes multiple samples spaced a configurable period apart, and returns those to you to filter as necessary. We provide
avg() functions for you to do this filtering to yield more stable results in the presence of measurement noise in
Consider: when using binary search, how does random noise affect the distribution of queue thresholds? Would you expect that the determined queue threshold might vary by one or two occasionally, or by more than that? Is the median or mean going to be more tolerant to noise?
This rubric is here to help you understand the expectations for the assignment. It is the same rubric that the person evaluating your project will use. We recommend you look at the rubric before you begin working on your project and again before you decide to submit it.
|Criteria||Does Not Meet Expectations||Meets Expectations||Exceeds Expectations|
|Buffer sizing code|
|Buffer sizing code follows guidelines in step 2.||Buffer sizing code does not follow the guidelines in step 2 and/or the binary search is not implemented correctly.||Buffer sizing code does follow the guidelines in step 2 and the binary search is implemented correctly.||There is no “Exceeds Expectations” option for this criteria.|
|Buffer size output|
|Output looks reasonable.||Output does not pass the sanity check when it is submitted. Output does not approximate the (RTT x C) / sqrt(N) line in the result graph (blue line).||Output does pass the sanity check and approximates the (RTT x C) / sqrt(N) line in the result graph.||There is no “Exceeds Expectations” option for this criteria.|
 Based on CS 244 assignment.