Reliable File Transfer

Due date Wednesday, Mar 14, 11:59pm Reliable File Transfer CS 5565 Spring 2012, Project 2 This project is worth 100 points. You may form teams of up to two students for this project. You are not required to team with the same student as in 1, but you may not switch partners after you started this project. Please update your group status at https://courses.cs.vt.edu/~cs5565/spring2012/grouper/ Introduction Reliable data transmission forms the basis of data communication. In this project, you will implement a reliable transport protocol that runs on top of an unreliable network layer. You will perform a set of experiments to evaluate the performance of the protocol you developed. Network Architecture The network architecture for this project consists of two bidirectional links with a forwarding router in between. dl_client dl_server Reliable Transport UDP 1rx UDP Router 2tx Reliable Transport UDP Host A 1tx Host B 2rx Host C The UDP Router (or forwarder) is implemented as a piece of software that can be run on Linux (on the rlogin cluster); the source is available for download from the class website also. It forwards regular UDP packets received from 1rx to 2tx and UDP packets received from 2rx to 1tx. The underlying LAN connecting hosts A, B, and C determines bandwidth, latency and loss rates for all links except 2tx, whose characteristics is under software control. This control allows us to introduce variable bandwidth, delay and loss rates to evaluate the performance of the reliable data transmission protocol you will implement. Link 2tx s output queue is limited to 32 packets. The router will drop packets as the traffic intensity approaches 1, that is, if it receives packets from 1rx faster than it can send them using the specified bottleneck bandwidth along 2tx. The maximum packet size that can pass through link 2rx is 500 bytes. The maximum 1/8

Goal bandwidth across 2tx is 4Mbps. Link 2tx adds a transmission delay which can be specified with 1 millisecond accuracy. This delay is in addition to the delay imposed by the LAN over which the UDP packets travel. Link 2tx has a programmable packet loss rate that ranges from 0 to 100% in steps of 0.1%. Your reliable transmission protocol should ensure that messages sent by the client are successfully received at the server. For the purposes of this project, you may implement any of the sliding window protocols (go back N, selective acknowledgement) discussed in class, or any other equivalent sliding window scheme such as TCP, or a protocol representing a subset of it. As a last resort, you may implement a stop and wait protocol for partial credit. Your reliable transmission protocol should ensure that messages sent by the client are successfully received at the server in the same order that they were transmitted. Since the router will drop packets if packets are injected too fast, you must also implement a form of congestion control. You may assume that you are the only user of the network, hence congestion control amounts to controlling the flow of packets to avoid queuing losses at the router. How to run the Router The router is controlled using the following parameters: The UDP port on which it is should listen for packets from 1rx, also referred to as local port The hostname and UDP port to which it should forward packets along 2tx, also referred to as remote host/remote port. The hostname is the name of host C where you run dl_server. The router learns the host address and source port number of link 1tx after it receives the first UDP packet on link 1rx. See the Router Options section for additional parameters used to control the packet loss, delay, and bandwidth along 2tx. As an example, suppose dl_server runs on host ghestal, the router runs on host strago, and dl_client runs on host celes. You start dl_server on ghestal first 1 : [you@ghestal> dl_server 9999 Then you start the router on strago, connecting it to the server running on ghestal: [you@strago> router C 9998:ghestal:9999 This will create a router instance with the default values for bandwidth and delay on 2tx and with no packet loss. On celes, you ll then run 1 I m using 9999 as port number, but you should use the same number p as in project 1. 2/8

[you@celes> dl_client strago 9998 input.dat After the file has been transmitted, use the Unix command cmp to compare the contents of input.dat and output.dat 2. Router Options Running the router with h gives the following help. Usage: router -C <localport:remotehost:remoteport> localport is the port on which router is receiving packets from Link 1 remotehost/port is the host/port to which Link 2 connects -B <bandwidth> link bandwidth in bps -D <delay> link delay in microseconds -L <tx_loss_prob> transmit loss probability, in fractions of 1000 -b introduce bandwidth variation -t introduce link delay variation -u use plain udp forwarding, this overrides L, -b, and -t flags -v vary random sequence for bandwidth/rtt variations The DROPS field shown in the statistics has the format m(+n) m is the number of packets intentionally lost along Link 2 or dropped for bad length n is the number of UDP packets dropped by this machine since the router program started, as shown in /proc/net/snmp Udp: InErrors. The latter is a host-wide indicator, so it may not show loss due to this instance of router if other students are running another router instance on the same machine. Only the C switch is required. When you start the router, it will print the values that are used for the current run. Pay attention to the units used for the B, D, and L switches. To test your project s basic functionality, we will run it with L 100 (10% packet loss) and transfer an 8Mbit file. Important: Since the router learns the source address and port number of Link 1 from the first packet it receives, be sure to restart your router for every run! 3 On a related note, you must use the same UDP socket in your client to send and receive packets to ensure the router learns the correct port number. The u switch turns off any artificial delay and bandwidth bottleneck, making the router forward packets in both directions as fast as it can. 2 I used port numbers 9998 and 9999 for illustrative purposes above, but you should use your assigned port number p in both cases, or use p and p+1 if you wish to run A and C on the same lab machine. 3 It may appear as though this is not necessary when you re testing your project, but this appearance is only created because the OS on host A immediately reuses the same number when binding a socket to any unused port. 3/8

The v switch is related to the L, b, and t switches. When given, the random number generator is seeded with the current time, which creates a different sequence of random numbers every time. Otherwise, the random sequence is the same every time the router is run. This means that the same packets are dropped every time when using the L switch without the v switch. The b and t switches are not used in the standard portion of the assignment. Read the extra credit section for possibilities for extra credit. Router Statistics The router will output transfer statistics similar to the following while it is running: LINK 1 RX: 0XX TX: 0XX LINK 2 RX: 0XX TX: 0XX DROPS: 9 (+ 3) QUEUE 4 The numbers 0XX shown after RX:, TX:, etc. are the number of bytes the router received and sent across the respective link. The number after DROPS: (here: 9) is the number of packets dropped when the L switch is given. The number after QUEUE (here: 4) is the number of packets currently waiting in the output queue of 2tx. The number inside the parentheses (here: +3) is an estimate of the number of packets that were dropped because the router s input queue overflowed. Because of the implementation of the router, the input queue for 1rx is the receive buffer of the UDP socket on which the router receives packets from Link 1. While sending across Link 2, the router does not service that socket, possibly causing the OS to drop packets if they arrive faster than packets can be sent out Link 2tx. Linux keeps a global counter for all packets that were dropped because they couldn t be added to their socket s queue 4. Unfortunately, Linux does not provide a way to extract queue capacity related per socket packet drop information. Therefore, the value shown here includes UDP packets dropped for any reasons across all applications and all users of the machine. The router program will display the change in this value from when it was started to the current point in time. If you share the machine with other students, losses you see there may or may not be yours. Use another machine if you have doubts. (For most purposes, there is no need for you to distinguish packet losses due to queuing in the router s input queue from losses artificially introduced by the router after all, an end system in a network also has no way of telling what causes the packet losses it experiences. I added this option mainly as a debugging help. Experiment 4 is an exception where you need to prevent queuing losses to avoid affecting the accuracy of the experiment.) 4 This counter can be read from /proc/net/snmp, look for Udp: InErrors. 4/8

Deliverables When developing a reliable transport protocol, reliability is paramount. Therefore, you should first make sure your protocol handles packet losses well (use v in connection with L). Only after your protocol works reliably should you think about tuning its performance. Reliably means that your protocol works every time we run it. We will stress test your submission to check for race conditions, and we reserve the right to use dynamic race condition detection tools (where available.) For full credit, you should be able to achieve a throughput that is at least 70% of the nominal link bandwidth of link 2tx. You should exploit the layered architecture you developed in project 1. You will replace the transport layer on top of which dl_client and dl_server are running with a reliable one. You may have to extend the service model of your layer and the interface used to access your layer for this purpose. Make sure that your code is protocol independent and supports both IPv4 and IPv6 addresses. The machines on our cluster have global IPv6 addresses, and there are DNS AAAA records provided by the local name server. Be sure to test both IPv4 and IPv6. You do not need to worry about connection setup/tear down, or transport layer multiplexing or demultiplexing. However, you must ensure that your client does not exit until it has received an acknowledgement for the last packet it sent. The client may assume the server is running and ready to receive packets when it starts. Handle all errors that might occur, such as illegal port numbers or IP addresses, nonexisting hostnames, and or non existing input files gracefully. Do not send UDP packets larger than 500 bytes. In other words, your MTU (maximum transmission unit) should be 500 bytes, which includes file data as well as any headers your protocol may add. Instructions for all Experiments Once your protocol works reliably, you should perform a set of experiments to evaluate its performance. For each experiment, record the throughput as reported by dl_server and take the average of at least 3 runs (3 runs would not be acceptable in a publication, I m suggesting 3 runs here to limit your workload. Feel free to measure 5 or more runs.) You may use a 4Mbit input file for experiments 1, 2, and 3. Use an 8Mbit input file for experiment 4. Report the results of the experiments in your report. For each experiment, include all settings you used for the adjustable parameters of your protocol, if your protocol has any statically adjustable parameters. Include the raw measured data in a table, and include the required plot. Include an interpretation of your results for each experiment. If you do not understand the results of an experiment, explain the steps you took to diagnose them and discuss if they failed or succeeded. 5/8

Experiment 1: Window Size vs Throughput In this experiment, you will evaluate the impact of window size on throughput. Use a bandwidth of 1Mbps ( B 1000000) and a delay of 50ms ( D 50000) for this experiment. Measure the throughput for the following window sizes W: W=1, 2, 4, 8, 10, 12, 16, 20, 24, 28, 30, 32. Finally, use the highest window size your implementation supports (based on your header format). Explain your results! What is the highest throughput you achieved? Use the window size that provided the highest throughput for the following experiments! Experiment 2: Bandwidth vs. Throughput Use a delay of 150ms for this experiment. Plot the throughput you achieve for the following bottleneck bandwidths B: B=100, 200, 300,, 1000 Kbps! Experiment 3: Delay vs. Throughput Now fix the bandwidth at 1 Mbps and vary the delay. Plot the throughput you achieve for at least the following delays D: D=0, 50, 75, 100, 150, 200, 250, 300, 400, 500, 600ms. Experiment 4: Packet Loss vs. Throughput Hints Now use a bandwidth of 1Mbps and a delay of 0ms. Plot the throughput for at least the following loss rates L, expressed as fractions of 1000: L=10,20,40,60,80,100,150,200,250, and 300. Note: depending on how your mechanism for acknowledgement and retransmission works, you may need to reduce the window size here to avoid queuing losses at the router these losses would perturb the accuracy of your L setting. In other words, reduce the window size if you see any losses in the (+ ) output of the router. To test your protocol without the router, point your client directly at the server as in project 1 this must still work. Use the u switch to test without artificial bottleneck bandwidth and delay. Keep in mind that a lower bound of the total round trip time is 2x the round trip time introduced by the UDP layer between two hosts, plus the delay specified by D at the router, plus the processing delay at the router. Use ping s 500 to get an estimate for the first component, the round trip time between two machines. If you wish, you may pass a suitable retransmission timeout to your client as an optional command line switch or environment variable that overrides a hardwired default or implement round trip time estimation as in TCP for extra credit. Submission You must ensure that your project runs on the Linux rlogin cluster reachable via rlogin.cs.vt.edu. 6/8

Submit your source code along with instructions on how to build your project. Use the zip archive format. Do not include object file or executables or other intermediary files in your submission. If you use a graphical IDE, be sure to include instructions on how to build and run your programs from the command line. Include a Makefile as appropriate. You must include a detailed project report that describes the results of your experiments, as outlined in the section Deliverables. The report must be in PDF format. Please also include the source format you used (such as MS Word, Open Office, or others.) Include the report in your submission s zip archive. Your submission should include the names and email addresses of all team members in all source files and in the project report. The majority of the credit for this project will come from your report; simply providing a reliable protocol will account for less than 50% of your total score. The project must be submitted using the web based submission form linked from the class website, or submitted as p2 via ~cs5565/bin/submit.pl. Extra Credit Opportunities There are numerous ways in which you could improve your protocol. The following list is intended to give you suggestions and in no way limits what you may do. Tune your protocol s performance and see how close you can get to TCP s performance on a point to point link. Use the ttcp benchmark to measure TCP throughput. Implement a TCP style round trip time estimation scheme. (Perform experiment 4 with and without it.) Implement TCP style fast retransmit. (Perform experiment 4 with and without it.) Implement TCP style delayed acknowledgement. Implement a bidirectional transport. Implement variable sized windows that adapt to packet loss rates and/or receiver buffer capacity. (Turn this off for experiment 1.) Implement transport layer multiplexing and demultiplexing. Implement connection setup and teardown. Note: simply exchanging additional packets at the beginning does not implement setup & teardown. Change the router so it occasionally reorders packets and develop a protocol that can handle reordered packets. Tune your protocol for variable bandwidth and delay (use the b and t switches for that.) 7/8

Your own idea. For any extra credit extension, you must demonstrate the set of experiments you used to test it, and, if applicable, the results of the experiments you used to demonstrate its effectiveness. You will not receive extra credit if you do not prove experimentally that you improved your protocol in some way. A Final Comment If you have any questions about the project, please do not hesitate to ask us either by email or drop by during office hours or schedule appointments. Do not procrastinate on this project keep in mind that just to get the numbers for your final report, you will have to time well over 100 runs, and this will have to happen after you get your protocol working and tuned. While not extremely difficult, this project wants to be taken seriously, especially with respect to the concurrency prevalent in the implementation of the sender s state machine. Happy hacking! 8/8