EECS 489 Lab 7: Rate Control with Token Bucket Filter
This assignment is due on Friday,
8 April 2016, 6 pm.
Introduction
We have seen how sliding window flow control allows the receiver to
throttle sender's transmission so as not to overflow the receiver's
buffer. By relying on returning ACKs to slide the sender's window
forward, sliding window flow control is a close-loop system. In this
lab we investigate the use of open-loop sender rate control. The
advantage of open-loop control is obviously that we don't have to wait
one round-trip time for ACK packets to drive sender
transmission. Instead, the receiver specifies a token-bucket filter
that governs how bursty and how fast, on average, the sender can
transmit. Since rate control by itself does not provide reliability,
packets can still be dropped or arrive out of order.
We start with a UDP-based client-server code with no flow control nor
reliability, very similar to the client in Lab5. The only difference
is that the client takes an additional command line argument, -r,
which is used to specify the flow rate, in Kbps. (The reason the flow rate is
specified at the client side instead of the sender side will become
apparent in Lab8. Flow rate 0 is used in PA4.) You are provided with
the full client source
code, so no client reference binary is provided. A reference Linux
binary executable of the server refimgdb is available in
/afs/umich.edu/class/eecs489/w16/lab7/ where you can also find
a tarball of the
support code. The provided
Makefile builds both netimg and imgdb. The
two tasks you're asked to do in this lab are both server tasks.
Your implementation of the server must interoperate with the
provided client code. Since the provided client code reveals partial
solution to Lab5 and PA3, you will be granted access
only after you're done with your PA3 or have decided not to complete
it..
As usual, you can search for the string "YOUR CODE HERE" in
the code to find places where your code must go.
You may also want to consult the PA4 walk-through lecture notes.
Task 1: Token-Bucket Filter Sizing
The imgdb server in this lab does not take any command line
option. The image file the client queries must reside in the same
folder from which the server is launched. In
imgdb::handleqry(), the flow rate specified in the
client's query packet is stored in imgdb::frate for you.
Your first task is to compute, in imgdb::handleqry() the
token bucket size and token generation rate to regulate the sender's
transmission. The token bucket size should be large enough to hold
at least as many tokens as are needed to cover one mss segment,
excluding all headers. If the receiver's window, rwnd, is larger
than 1 mss, the token bucket size should be sized such that the
server can fill the receiver's window, but no larger. You may find
the macro IMGDB_BPTOK, defined in imgdb.h, useful in
doing this computation. This macro specifies the number of bytes
corresponding to a single token. For example, if your mss is
1460 bytes and IMGDB_BPTOK is 512 bytes, you'll need to have
2.852 tokens in your token bucket to send a single segment. To simplify
token accounting, we'll size the token bucket filter in unit of bytes
instead of tokens. Thus you can transmit the packet with 1460 bytes of
data if your token bucket filter contains that many bytes. To ensure
transmission progress, your token bucket must be sized large enough to
hold at least the number of tokens needed to send a single segment.
Next compute the token generation rate, which is simply a translation
of the user-specified sender's rate from Kbps to bytes/sec. Store
the computed token-bucket size in imgdb::bsize and the token
rate in imgdb::trate.
You can search for the string "Task 1" in imgdb.cpp to find
the one place to enter your 3 lines of code for sizing the
token-bucket filter. And that's all you have to do for Task 1.
Task 2: Rate-controlled Transmission
Your second task is to regulate the server's transmission rate. You
can search for the string "Task 2" in imgdb.cpp to find the
two places in imgdb::sendimg() where "Task 2" related code
must be filled in. First, decide what local variables you would need
to regulate packet transmission using the token bucket filter.
Initialize your local variables. Regulate only the transmission of
NETIMG_DATA packets. For a segment to be transmitted, there
must be enough bytes in the token bucket filter to cover the data
portion of the packet, i.e., mss minus all headers.
To send a segment, you first check if there's enough bytes in your
token-bucket filter to cover the segment. If there isn't enough
bytes, put the process to sleep. The amount of time the process
sleeps should be long enough to generate at least the number of bytes
needed to cover a single segment. Preferrably, it should sleep a
little longer than the minimum, to allow for more bytes to accumulate.
For example, you could sleep for an additional amount of time
sufficient to cover a random fraction of the token bucket size. On
Linux and Mac OS X, use usleep() instead of sleep()
to get microseconds granularity sleep time. On Windows, the support
code has usleep() redefined to call Sleep() in
netimg.h. In this assignment, to simplify the code, we don't
accumulate token during packet transmission time. Be sure to enforce
that the amount of bytes accumulated is not larger than
imgdb::bsize. Upon transmission of a segment, deduct the
bytes used from the amount of accumulated.
That's is for Task 2. It should take about 12 lines of code. That's right,
this whole assignment takes only about 15 lines of code in total.
Testing Your Code
Given appropriate receiver window size (-w) and sender's
flow rate (-r), you should be able to specify a token bucket
filter that allows you to transfer an image file without overflowing
the receiver buffer and therefore can be displayed with no gap in the
image, modulo dropped packets. A larger receiver window means that
the sender can send a large burst at once. So unlike in previous
assignments, a larger receiver window does not necessary result in
reliable transfer with no dropped packets. A smaller sender's rate
not only slows down transmission, it also slows down the token
(re)generation rate. For example, on localhost, with the default
receiver window of 10 packets and mss of 3KB:
% netimg -s localhost:<port> -q BlueMarble2004-08.tga -r 256
should take roughly twice as long to complete as
% netimg -s localhost:<port> -q BlueMarble2004-08.tga -r 512
and about three to four times as long as
% netimg -s localhost:<port> -q BlueMarble2004-08.tga -w 40 -r 1024
When connecting to CAEN from home over slow ADSL, I found that
% netimg -w 10 -r 10 -m 10248
works for most images, just be prepared to wait 5 to 20 minutes
for the image to be displayed (and your mileage may vary).
Submission Instructions
To incorporate publicly available code in your solution, or to pass
off the implementation of an algorithm as that of another are both
considered cheating in this course. If you can not implement a
required algorithm, you must inform the teaching staff when turning in
your assignment.
Your submission must compile and run without errors on CAEN
eecs489 hosts using the provided Makefile, unmodified, without any additional libraries or
compiler options.
Your "Lab7 files" comprises your imgdb.cpp.
To turn in your Lab7, upload a zipped
or gzipped
tarball of your Lab7 files to the CTools Drop Box. Keep your own backup copy! The timestamp on your
uploaded file is your time of submission. If this is past the
deadline, your submission will be considered late. You are allowed
multiple "submissions" without late-policy implications as
long as you respect the deadline. We highly recommend that you use a
private third party repository such as github
or M+Box or Dropbox or Google Drive to keep the back up copy of your
submission. Local timestamps can be easily altered and cannot be used
to establish your files' last modification times (-10 points). Be
careful to use only third-party repository that allows for
private access. To put your code in publicly accessible
third-party repository is an Honor Code
violation.
Turn in ONLY the files you have modified. Do
not turn in support code we provided that you haven't modified (-4 points).
Do not turn in any binary files (object, executable, dll,
library, or image files) with your assignment (-4 points). Your code
must not require other additional libraries or header files other
than the ones listed in the Makefile (-10 points).
Do remove all printf()'s or
cout's and cerr's and any other logging statements
you've added for debugging purposes. You should debug using a
debugger, not with printf()'s. If we can't understand the
output of your code, you will get zero point.