Part A -- Wireshark TCP lab
Complete the TCP Wireshark Lab and answer all questions (1-12):
03 Wireshark_TCP_v7.3.pdf
Complete the UDP Wireshark Lab and answer all questions (1-7):
04 Wireshark_UDP_v7.0.pdf
1) Is it possible to build a reliable data transport protocol that uses only NACKs (negative acknowledgements) instead of ACKs (positive acknowledgements).
a) Briefly, how would it operate?
b) In what scenarios would it fail or operate poorly?
c) In what scenarios would it perform more efficiently than TCP?
2) If a network has a max packet size (MTU) of 1500 bytes, its max throughput is 200Mbit/s, and end-to-end latency is 15ms (RTT is 30ms), what window size would be needed for TCP to achieve maximum throughput? (Please give an approximate answer by ignoring packet header overhead.)
3) Let's say NASA is trying to develop a communication protocol for streaming live video from the planet Mars to Earth. It takes 3 minutes for light to travel that distance. Thus, a packet retransmission would be delayed by at least 6 minutes! Let's assume that, unfortunately, each packet has a 10% chance of being lost due to radio noise. How would you design a live video streaming protocol to deliver on average at least 99% of video packets, without adding delays that would be caused by retransmission?
4) TCP splitting is described in the 7th edition of the book on page 275. How does the behavior of TCP allow a CDN to provide improved performance to end users requesting HTTP documents, even if the document being requested is not cached at the edge? In other words, how can performance improve even while the total distance traveled by the data remains identical and we are adding an intermediary stop?
5) What incentive do individuals have to follow some variant of TCP congestion control rules instead of just sending packets as quickly as they can? Obviously it's good for me when others slow their traffic to avoid network congestion, but, even if I don't care about others, why is it a good idea for me follow the same rules?
6) TCP Reno achieves an average of 75% of a link's maximum throughput by scaling the window up linearly in the congestion avoidance state and cutting the congestion window in half when seeing a triple duplicate ACK. This leads to 75% of the maximum because the window size (and thus the traffic) is cut in half whenever the link is saturated and there is a linear increase in traffic between T/2 and T (leading to an average of 3/4 T).
a) Let's say you changed the congestion avoidance behavior to simple reduce the window by a constant after seeing a triple duplicate ACK. What average throughput would you expect on a link (as a fraction of the maximum)?
b) Let's assume that this new congestion avoidance behavior (with constant window shrinking) is adopted. If a link is already being used at full capacity by one busy TCP connection and a second connection joins to share the link, what fraction of the link bandwidth will be allocated to the second connection, on average, in the long run?
7) TCP uses bytes, not packet numbers, in its sequence numbers. Thus, the congestion window indicates the maximum bytes of TCP payload data that may be in flight, not the number of packets that may be in flight. However, each packet has 40 bytes of header overhead, and these header bytes also contribute to network congestion. TCP's congestion control does not account for header overhead, and therefore a congestion window that was previously appropriate may suddenly become too small if an application starts sending smaller packets (particularly if TCP_NODELAY option is used). How might you change TCP congestion control to account for header overhead?
8)
a) What is a SYN flooding attack and how is it prevented?
b) After implementing this solution, are initial SEQ numbers still random?
9) Consider transferring data from Host A to Host B on a very fast network with relatively high latency (a "long fat pipe"). For example, we might have a 10Gbps link with 40ms RTT (due to the speed of light) for a high capacity fiber link between New Jersey and California.
a) How large must the window size be to achieve 10Gbps?
b) Assuming an MTU of 1500 bytes, how many segments is this?
c) When a packet is lost (and we get a triple duplicate ACK), the TCP congestion window is cut in half. The most common reason for loss is that we are sending too much data out on the network. However, packets may also be lost due to checksum failures (due to random errors while transmitting bits). In the congestion avoidance state, TCP Reno grows the congestion window by just one MTU every RTT. If there are thousands of packets in flight during a RTT, then there is a good chance that the congestion window will be unnecessarily reduced due to random, infrequent losses. This will cause the data transfer rate to be significantly lower than the 7.5Gbps average that we expect. How would you fix this problem and maintain close to the full 10Gbps of throughput on this "long fat pipe"?
For reference, see the paper by Mathis from 1997.
10) TCP is an end-to-end protocol. The routers in the network core do not add any information to TCP headers that are generated by the two hosts, so the end hosts have very little information about the internal state of the network. Give an example of how could a transport protocol like TCP could be "improved" by adding some kind of feedback from routers.