1. Recently, a number of wireless networks for carrying digital Internet traffic have been deployed. Wireless communication links are typically much more likely to suffer bit errors than traditional "wired" networks, with drop rates approaching 1 in 4 packets. These networks are also usually just for the final "hop"; Internet packets traverse some number of wired links and routers before being sent over the wireless link, which delivers packets directly to the receiving host (for example, a portable PC with a wireless LAN connection).

(a) When these wireless networks were first deployed, observed TCP bandwidth over the wireless link was often an order of magnitude worse than the peak bandwidth the hardware could deliver. Give a qualitative explanation for why this might happen.

(b) One proposed solution to this problem is to cache packets at the upstream router just prior to being sent over a wireless link. If the packet is garbled, the packet can be resent without having to wait for a retransmission from the source host. Of course, this solution is easier to deploy if it doesn't require changing the protocol stack at either the sender or the receiver. Consider the case where the packets are being sent to a wireless host and all the traffic is TCP. Can an intelligent router detect when retransmissions are needed without modifying the receiver? If so, how? If not, why not? Hint: assume the router can observe TCP acknowledgments.

2. One configuration parameter for Internet routers is how many packets they can buffer. Naively, one might think that adding buffering would always improve performance, but that is not the case, given that TCP is continually probing to increase bandwidth.

(a) What would happen to performance (latency, bandwidth, and drop rate) if Internet routers had infinite buffering? Consider both the case where there is a single TCP connection through the router, and where there are multiple connections.

(b) At the other extreme, what would happen to performance if Internet routers had only a single buffer?

(c) A rule of thumb is to provide each router with buffering equal to the bandwidth delay product, computed end to end. For the example in class, we configured the router with four buffers; the bandwidth delay product was also four. Why would this optimize performance, and why might it be hard as a practical matter for the administrator of a router to know the bandwidth-delay product of connections traversing the router?

(d) One way to sidestep this tradeoff between small vs. large amounts of router buffering, is Random Early Detection (RED), where the router randomly drops packets when it detects congestion, even if there is space in its buffers for the packet. How could dropping packets when there is space in fact improve performance?

3. Tcpdump is a common program for monitoring network activity. The following shows a tcpdump of the exchange of packets seen by the machine "me" while serving a 9287 byte web page. The output is fairly terse. The tcpdump tool normalizes the sequence numbers in the conversations so that they are small integers. That is, the machine "them" chooses 1629852695 as its Initial Sequence Number, but tcpdump subtracts this number from all future sequence numbers seen from "them." Other notation describes (in rough order) timestamps, whether the packet had the SYN (S) or PUSH (P) flags set, sequence number ranges and packet lengths (e.g., 1:726 (725)), whether the packet is acknowledging data (e.g., ack 726), the advertised flow control window (e.g., win 16060), and that the packet was marked to "don’t fragment (DF). The first thing you should do for this question is to read the tcpdump man page (documentation), which is linked from the course web page, to make sure you understand what the trace output means.

1. Draw a packet time sequence diagram (of the kind shown in lecture and Peterson with time moving down the page) that shows all packets of the transfer. Your diagram should be approximately to scale. For each packet, label it with the type (SYN, ACK) and sequence number range.

4. RTT Estimators.

1. For the previous trace, calculate the seven RTT samples for data being sent by the machine "me". (Note that TCP actually only takes one sample per round trip time, but you are gathering all available samples in order to work with a smaller trace!)
2. Using the samples, calculate the estimated timeout based on the exponentially-weighted moving average of round trip time samples. This algorithm is given on page 390 in Peterson and Davie. Use alpha = 0.8, and a multiplier of 2 between the estimated RTT and the timeout. Since the weighted moving average needs an initial estimate, use an initial RTT estimate of 500ms (this is the UNIX default). Present your answer as a graph of timeout versus time. Your graph should be roughly to scale, and should include the RTT samples too.