Lab 4 - Fast & Reliable File Transfer

Team: Dynamo

LAB-4 Fast & Reliable File Transfer

Team: Dynamo Jui Shah Viral Barot Bhavin Shah Jay Gheewala

Lab 4 - Fast & Reliable File Transfer 1.1 SCP Secure Copy program

Team: Dynamo

An experiment is created with two computers linked by 100Mbps link. Initial delay is 2ms. .ns file: set ns [new Simulator] source tb_compat.tcl # two nodes set nodeA [$ns node] set nodeB [$ns node] #set OS for the nodes tb-set-node-os $nodeA FBSD62-STD tb-set-node-os $nodeB FBSD62-STD # Define link $ns duplex-link $nodeA $nodeB 100Mb 2ms DropTail # Go! $ns run

Q1)

What is the RTT delay between the nodes now? What is the bandwidth delay product?

Answer: The RTT Delay between the nodes when delay on the link is set to zero is as follows: Round-trip min/avg/max/stddev = 0.224/1.260/2.068/0.505 ms. Hence the average RTT delay is 1.260ms. Also the max Bandwidth obtained is 95.6 Mbps. The Bandwidth delay product is 0.12045Mb.

Q2)

Explain briefly what the above commands do

Answer: cd /tmp: To enter directory /tmp dd is a Unix program which is used in low-level copying and conversion of raw data. of=file(data.bin) : write the output to the file instead of normal output to be used. if=file(/dev/urandom): Read the input to the file instead of normal input to be used.. bs=n: It sets the input and output bytes to n bytes ie suppose 1Mb. Count=n: copy of n input blocks Q3) What transfer throughput do you get?

Answer: Transfer throughput is 11.1MB/s. 2

Lab 4 - Fast & Reliable File Transfer

Team: Dynamo

Q4)

Explore the problem: use the DETER website to increase the delay on the link. What happens to the throughput? Can you improve the performance using the kernel parameters (i.e. default and maximum TCP window sizes)? Make sure to explore RTT delays at least up to 50ms

Answer: Window Size at sender/receiver is 262144Bytes i.e. 256Kbyte. Delay 0ms 5ms 10ms 15ms 20ms 25ms RTT (ms) 1.26 10.16 22.08 32.596 42.878 52.985 Throughput 11.1 MB/s 2.5 MB/s 1.4 MB/s 966.0KB/s 734.1KB/s 598.8KB/s

Window Size at sender/receiver is 2MByte Delay 25ms RTT (ms) 52.113 Throughput 598.8KB/s

Window Size at sender/receiver is 8MByte Delay 25ms RTT (ms) 52.669 Throughput 598.8KB/s

Window Size at sender/receiver is 16MByte Delay 25ms RTT (ms) 52.673 Throughput 597.1KB/s

Hence, from the above observation, changing the kernel parameter (kern.ipc.maxsockbuf=2097152) does not improve performance.

Q5)

Does SCP seem to have some sort of built-in limitation? Can you guess what it is? Hint: SCP uses the SSH protocol to transfer data.

Answer: Yes, SCP performs well while transferring using TCP sockets based on SSH but does not have the facility to change the window size and due to the default window size there is a upper bound on the achievable throughput.

Lab 4 - Fast & Reliable File Transfer

Team: Dynamo

Q6)

Now set your delay back to zero. At the same time add a small amount of packet-loss to the link. Start at 0.1% (i.e. 1 packet dropped in 1000) and test at various loss levels up to 5%. Graph throughput vs. loss. Discuss these results. Does this seem extreme? Can you explain why this happens?

Answer: Throughput vs. Loss

Loss 0.000 0.001 0.005 0.010 0.015 0.020 0.025 0.030 0.035 0.040 0.045 0.050

Throughput 11.1 MB/s 6.9 MB/s 5.0 MB/s 4.0 MB/s 3.0 MB/s 2.2 MB/s 1.6 MB/s 1.2 MB/s 761.3 KB/s 656.4 KB/s 497.1 KB/s 391.6 KB/s

Throughput vs Loss
12 10 Throughput 8 6 4 2 0 0 0.01 0.02 0.03 Loss Factor 0.04 0.05 0.06

Yes it does seem extreme that throughput decreases exponentially, the packet loss is more than expected. The loss factor increases from 0.1% to 5%, the throughput decreases significantly. As the loss factor increases, the probability of packets getting dropped increases and so retransmissions increase. So, the throughput decreases.

Lab 4 - Fast & Reliable File Transfer Q7)

Team: Dynamo

Estimate or measure the delay and loss from Los Angeles to Switzerland. If you had a physicist for a colleague, and he wanted to download some data from the new atom smasher at CERN, would you expect him to come to you for help? Can you help him? If so, how?

Answer: Estimated Loss: 9%, average RTT: 7ms. If we had a physicist for a colleague, and he wanted to download some data from the new atom smasher at CERN, then we would expect him to come to for help. Yes we can help him by this new FTP protocol build by us.

Lab 4 - Fast & Reliable File Transfer

Team: Dynamo

1.2 FTU File Transfer Utility

Describe, in detail, the concept(s) behind your File transfer utility, results, and the analysis. The file transfer utility that we made ensures reliability and tries to achieve throughput which is close to the theoretical value required. The file transfer protocol over here is tested over large delays and losses. Concepts: UDP is fast but not reliable whereas TCP is reliable but slow. So, we decided to use UDP and designed UDP to work in such a way that the file is transferred faster than TCP and also some reliability was implemented to ensure correctness of the received file. To fulfill above mentioned requirements and achieve the required results (in terms of throughput & reliability) timeouts and retransmission mechanisms were used over UDP. Our client and server application are both multithreaded. Client reads the file to be transmitted, divides it into packets, appends sequence number to each packet and transmits over the UDP connection. Client also has two threads running in parallel along with the former main thread. A retransmission thread keeps on retransmitting the sent packets every timeout interval. Another thread dedicated to the task of receiving acknowledgements waits on receive system call and in turn removes the packets stored for retransmission on receiving the ACK for that packet. Server has two main threads one thread is for receiving the packets sent by the client & acknowledging it and the other thread writes the received data in order in the output file.

Results:

File Size 1GB 1GB 1GB 1GB

Delay (ms) 0 10 200 200

Loss Factor (%) 0 1 20 40

Throughput (Mbps) 89.1388 84.5668 65.26 49.56

Lab 4 - Fast & Reliable File Transfer

Team: Dynamo

Analysis: TCP achieves reliability at the cost of throughput. It has the retransmission mechanism such that the efficiency and throughput is very less. Whereas, UDP just focuses on efficiency. It never retransmits a packet if it gets lost. So, we send the packet through UDP and also the ack and retransmission through UDP. We have customized the analysis below:

UDP It has high throughput and then introduce some scheme to handle the packet loss is a much better option than TCP. It floods the receiver with packets as it is sent at a higher rate so one must buffer packets to avoid packet loss Based on performance results of our implementation of the transfer utility, we feel that the major factors affecting the performance are the Kernel Socket buffer sizes at both ends and retransmissions mechanism for resending particular loss packet. Kernel Buffer size increase the throughput to a certain extent but beyond that the throughput is not affected. When Packet size is increased the throughput increases. However beyond certain limit the throughput decreases.

TCP The rate to be transferred from a sender can also be limited by the send socket buffer size while the receive socket buffer size will help us to achieve the maximum receive window for a TCP connection. Window size plays a deciding role in TCP throughput. An application will override the TCP send and receive socket buffer sizes by using the system call of setsockopt.

Efforts: Earlier Versions of file transfer protocol

We have used UDP to transmit the file from source to destination. We maintain the count for which packets are acknowledged. If we do not receive the acknowledgement for a particular packet, the source will re-transmit the packet to destination. This continues until the whole file is transmitted properly (all contents are properly received by the destination in presence of loss). We have used the above design as the other designs didnt fetch us good results. Those designs are mentioned below. Cumulative acknowledgement: UDP was used to transmit the file from source to destination. We maintain the count for the packets. After receiving the packets and if there a drop in receive packets, and then there will be a Cumulative ACK. If we do not receive the ACK for a particular 7

Lab 4 - Fast & Reliable File Transfer

Team: Dynamo

packet, the source will re-transmit the packet to destination. This continues until the whole file is transmitted properly (all contents are properly received by the destination in presence of loss). But it had lots of computation and so the throughput decreased. NACK: UDP was used to transmit the file from source to destination. We maintain the count for which packets are acknowledged. If we do not receive the acknowledgement for a particular packet, the source will re-transmit the packet to destination via TCP Nack ack. This continues until the whole file is transmitted properly with reliability. But this introduced lot of overhead on the receiver. TCP: TCP was the mode of communication used to transmit the file from source to destination. We maintain the count for which packets are acknowledged. If we do not receive the acknowledgement for a particular packet, the source will re-transmit the packet to destination. This continues until the whole file is transmitted properly with reliability. But it had very less throughput as per TCPs constrain in presence of loss and delay.