CS43 Lab 4: Reliable Transport

We will be building a stop-and-wait protocol with ACKs, timeouts, retransmissions and RTT estimation on top of an unreliable channel. We will use UDP socket calls to get an unreliable channel, and use mininet, our network emulator to force losses to occur in a controlled manner.

Protocol API: You are responsible for writing/editing only the following functions:

Application layer: lab4_sender.c and lab4_receiver.c implement the application layer that calls your library functions. lab4_sender.c and lab4_receiver.c each get their own copy of your library functions.

To setup a virtual machine you will have to first download and install VirtualBox. VirtualBox is handy for setting up VMs for numerous instances, outside of this course and lab.

Next, open up your terminal and cd into the folder where you would like to keep your VM. And use scp to copy the following image file:

$ cd <your_chosen_directory>
# don't forget the trailing period in the line below - we want to copy the file to the current directory.
$ scp username@lab.cs.swarthmore.edu:/home/chaganti/public/cs43/f20/CS43-Mininet-VM.ova .

The file is about 1.2G in size, and will take a couple of minutes to download. Once you download the file, you can follow these steps to setup your VM.

After you have completed these steps, you should see your VM in the list of VMs available to start. Go ahead and turn it on.

To get started, first ssh into your machine and cd into /local. You should see a file in /local called CS43-Mininet-VM.ova

# ssh into your chosen CS_machine
$ ssh username@<CS_machine>.cs.swarthmore.edu
$ cd /local
$ ls
 CS43-Mininet-VM.ova

We will now import a copy of the starter VM image. Run the following command with the --dry-run option. This will allow you to simulate an actual run and make sure you have the right settings before actually running the command. .Dry-run option with VBoxManage image::Stop-and-wait.png[align="center",300,300]]

You should see an output similar to that shown below. Verify the the file location and name settings have the path pointing to /local and have your username in vmname.

If everything looks good, we are ready to create our vm. Run the following command

$ VBoxManage import CS43-Mininet-VM.ova --vsys 0 -vmname CS43-Mininet-VM-your_username --vsys 0 --basefolder /local/

Now run vboxmanage list vms at the terminal, to see the new vm that we created. You should see something like the following:

$ vboxmanage list vms
"CS43-Mininet-VM-vchagan1" {c0546631-0846-4747-864c-df06851056c5}

Storing things on /local has two major implications that you need to account for:

After you have completed these steps, you should see the your VM in the list of VMs available to start. Let’s go ahead and turn it on.

Running your VM:

Before going any further, you should use the passwd command to set a new password to protect your VM. Keep this simple so you remember it.

After that, you’ll need to configure an SSH key so that you can access GitHub. Create a new key for the VM and add it to your GitHub account. (Instructions)

You can now git clone your lab repo into your VM.

When you’re done working on your VM, you should shut it down nicely: sudo shutdown -h now. We still have work to do in our VM so if you shut it down at this stage, you’ll have to restart it with either the vboxheadless -startvm command or from the GUI.

Run ifconfig on each of the two end hosts. You will see that h1 has an IP address of 10.0.0.1 and h2 has 10.0.0.2.

mininet> h1 ifconfig
mininet> h2 ifconfig

You can also transmit data between the two end hosts. Test this by running the ping command at h1:

mininet> h1 ping h2

You will find the example code in the lab4 directory, which is shared between the VM and each of the virtual hosts. (Try ls on the two hosts to see the shared folder).

mininet> h1 ls
mininet> h2 ls

Your packet header in lab4.h should look like the following:

struct lab4_hdr {
    uint32_t sequence_number;
    uint32_t ack_number;
};

You can add maybe one more variable to keep track of a close packet.

Your code does not need to implement the TCP header! The state we have (seg #, ack #, <blank>) should be all we need.

This function is responsible for reliable delivery of data packets from the sender to the receiver. Only lab4_sender.c will call my_send.

To implement reliable delivery, you want to keep sending your data in a loop until, you have received an ACK from the receiver.

To figure out if a packet has been successfully sent we will use select to implement our timeout functionality. Type man select at the terminal and take a look at the last parameter to select.

Using select to implement sending: To implement sending a packet and setting a timeout value with select, your code should implement the following functionality:

1: setup your packet and initial state, timeout, etc.
2: if not received an ack:
3: FD_SET your socket for reading
4: send packet
5: set value of timeout struct using: msec_to_timeval(timeout_val, &timeout_struct)
6: call select(sock +1, params, &timeout_struct)
7: check if select has timed out, and double the timeout value if so.
8: if not, receive an ACK using recvfrom()
9: only return from the function *after* receiving ACK from receiver.

Your implementation will need to perform RTT estimation to determine how you should set timeout values.

Use current_msec() to get an estimate of the current time stamp and use msec_to_timeval() to fill out struct timeval.

To estimate RTT, we will use an exponentially weighted moving average (EWMA) estimate that we discussed in class.

EstimatedRTT  = (1 – a) * EstimatedRTT + a * SampleRTT, with a = 1/8
DevRTT = (1 – B) * DevRTT + B * | SampleRTT – EstimatedRTT |, with b = 1/4
TimeoutInterval = EstimatedRTT + 4*DevRTT + 15

Your starter code has an initial RTT of 1000. You can change that to around 100 and let your code converge to the network RTT.

Like TCP, you should compute your timeout as a function of the current RTT estimate, sampling only those segments for which no retransmission is necessary. If a timeout occurs, you should double the timeout for each subsequent retransmission of the same segment.

The receiver is responsible for sending ACKs to the sender. Since we are only sending one packet at a time, it’s worth thinking about what you want to set as your ACK value.

Only lab4_receiver.c will call my_recv.

The receiver should use UDP recvfrom to receive data, and send an ACK for every packet received.

my_recv should only return to the application if a new packet has been received. Your might want some sort of a loop to implement this functionality.

Since the receiver is only responsible for sending ACKs, we do not need to keep timeouts, or use select on the receiver side.

Like TCP though, in my_close(), you may want to wait for some time, to make sure the last ACK didn’t get lost (leaving one end hanging).

HINT: since you are closing reliably, you can call my_send in my_close.

You should NOT rely on ICMP error messages to help your closing procedure. To be safe, it’s best to disable ICMP from both hosts before starting the sender and receiver with:

mininet> h1 iptables -I OUTPUT -p icmp -j DROP
mininet> h2 iptables -I OUTPUT -p icmp -j DROP

The syntax above lets us create a pointer to the packet of type struct lab4_hdr. This means, that anytime we want to pack values into the header we can use a more intuitive representation of the data we are packing.

uint32_t ack_number = 1;

/* without struct casting */
memcpy(packet+4, htonl(ack_number))            //packing
ack_number = ntohl(*((uint32_t *) &packet[4])) //unpacking

/* with struct casting */
hdr->ack_number = htonl(ack_number);          //packing
ack_number = ntohl(hdr->ack_number);          //unpacking