Exercise 4. Long fat pipes This exercise introduces the problem of "long fat pipes". We would like you to understand why the usual definition of TCP, due to its slow window increase, might be inadequate for links where the bandwidth-delay product is very large, e.g., either because the speed of the link is many Gbps or because the RTT delay is long as in the case of satellite links, where delays can be 800ms and more. We assume that TCP is used for sending data over a given data connection. We have already defined the bandwidth-delay product BDP as BWRTTd, where BW is the bitrate (or packet rate) of the data connection (at the bottleneck link) and RTTd is the total delay in the forward and backward path. The BDP corresponds then to the maximum amount of bits (or packets) that can travel on the communication medium (not in the intermediate buffers, which are anyway not relevant in this simple case). For an example of calculating such BDPs see Wikipedia 1. In the following, it is simpler (we use smaller size numbers) to work with the rate of packets instead of bits. We assume that the size of a packet is 1460 bytes and each byte has 8 bits. Hence, we measure BDP in packets. Assumptions: A1) Since the TCP window size is a 16-bit field in the TCP packet header, it limits the maximum size of the TCP window to 65535 bytes (because TCP ACKs refer to the last correctly received byte in its actual implementation), which corresponds to a maximum window size of MAX=44 packets (we assumed packet size =1460 bytes). Let's forget that discussion about bytes and assume from now on that each ACK acknowledges correctly received packets, as we did in class. A2) We assume that there are no losses and that TCP uses "congestion avoidance", i.e., increases its window size W by one (packet) every RTTd starting initially from W=1, unless i) it has reached W=MAX and cannot use larger values for W, or ii) for the given W the sender transmits packets at its maximum rate. If any of these two conditions occurs, the sender keeps W constant at this maximum value. In the next questions we assume that the sender and the receiver are directly connected through a single bi-directional link with no intermediate router (intermediate queue), and that the receiver can process packets at the maximum speed of the link (hence no losses) and send ACKs back to the sender. 1. Why is it true that for TCP to use efficiently the connection it must reach a window size at least equal to the BDP ? 2. In our single link network a window equal to the BDP of the sender-receiver connection corresponds to the case where the sender transmits continuously at the maximum speed the link allows. Is in this case BDP the largest practical/reasonable window size that the sender can ever use Unless otherwise mentioned, in the next questions BDP refers to the value of the BDP of the given sender-receiver connection. 3. Assuming your answer is yes in the previous question, and that a single TCP connection is using the link with no information loss, is it true that the evolution of its window size W is extremely simple: increase linearly from 1 until W=min(MAX,BDP) and then stay constant at this maximum value? 4. Consider a local LAN link such as an Ethernet link, connecting the sender and the receiver with 10Mbps, and RTTd=2ms. What is the BDP ? Is TCP eventually constrained by MAX or BDP ? What is the maximum rate achievable? How much time does it take to reach this maximum rate? 5. Consider a fibreoptic link of 10Gbps and RTTd=20ms. Repeat the previous questions. What do you observe? 6. Suppose we change the code of TCP and somehow remove the constraint that TCP uses MAX window size, i.e., we set MAX=. Repeat the previous question. What is the main issue here? 7. Suppose that we double the window size every RTd (again assuming MAX= ). How much time does it take to reach the maximum rate? 8. Think of the time it takes to transmit a file of say 20 Mbytes. Compare the time it takes if we use TCP (as in the previous question) and the time if we could use 100% of the 10Gbps link (transmit the file directly without using TCP). 9. Assuming that information is very rarely lost, e.g., a file is corrupted with prob. 103, propose a more efficient protocol to transmit files correctly over very fast links like in the previous example
