This test has six questions. The test runs the entire class period, starting at 4:30 and ending at 6:20. When you finish the test, you may leave. Always justify answers unless the question explicitly states it’s not necessary. Some questions require reasonable assumptions in order to be answered. In such cases the answer should clearly state the assumptions made.
• Flow control• Duplicate ACK• Additive increase, multiplicative decrease• Receive window• Fast retransmit
• Flow control:A technique that matches the sender’s and receiver’s transmission rates to prevent a less-capable receiver from being overwhelmed by a more capable sender.• Duplicate ACK:An acknowledgment that has been received more than once by the sender. Meaning depends on the protocol, but usually interpreted to some problem in the network.• Additive increase, multiplicative decrease:The pattern of change exhibited by the TCP sender’s congestion window under slow start. The additive increase (by one per congestion window) occurs once the congestion-window size is greater than the threshold; the multiplicative decrease (by half) occurs when congestion is detected.• Receive window:A TCP sender value indicating the space available in the receiver’s buffer. The receiver sets the receive-window size, although it may never receive that many unacknowledged segments if the congestion window is smaller than the receive window.• Fast retransmit:A TCP optimization that responds more quickly to lost segments by retransmitting after receiving three duplicate acks instead of waiting for the timeout.
Statistical demultiplexing doesn’t make any sense. Once the data have been multiplexed, there are no choices to make, and so there are no statistical advantages to be had when demultiplexing.
Interpreting the act of starting the game as the first moves, the exchange would go something like this:
Answer 1: Drop the UDP PDU. UDP provides best-effort service, and lost PDUs are an expected part of the service (presumably the application using UDP can deal with lost data, otherwise it wouldn’t have used UDP). TCP provides reliable byte-stream service, and dropping a TCP PDU would cause the protocol to expend resources to recover the lost data.
Answer 2: Drop the TCP PDU. TCP interprets a dropped PDU as network congestion, and adjusts its transmission rate to reduce its contribution to overall network congestion. Dropping the UDP PDU has no effect other than reducing the total number of PDUs in the network by one, which is the smallest possible change that reduces congestion.
Set the initial threshold value to a large value so the congestion window grows to the congestion limit as quickly as slow-start allows. If the threshold is a small number, the congestion window stops growing exponentially early, most likely far below the congestion limit, and approaches the limit linearly, which is much slower than an exponential approach.
Virtual circuits provide (mostly) reliable transport: data are delivered without duplication, in order, and without loss (but PDUs could incur bit-errors during transmission). Because virtual circuits reserved network resources, congestion isn’t a problem if the circuit can allocate resources (and if resources aren’t available, the TCP connection will fail).
Virtual circuits make TCP congestion control unnecessary, so no more congestion window, no more slow start, and no more round-trip timeouts. You might want to keep timeouts to deal with corrupted PDUs, but it would more effective to add better forward error detection and correction to TCP PDUs. It is still possible to mismatch sender and receiver transmission rates, so the receive window and acks are still necessary to provide flow control (acks would also be necessary if retransmission deals with PDU corruption).