================== 0. LOGISTICS, REVIEW, OUTLINE ================== * Please start looking at Assignment 1. * Review: last class * Stop-And-Wait, ReTx timers * This class: The Sliding Window protocol * Review ReTx timers * The Sliding Window protocol * Throughput of sliding window ================== 1. ReTx timers ================== * Main idea: set a timeout for retransmitting packets * Model RTT as a random variable. * Timeout should be such that the probability of a packet's RTT actually exceeding this timeout is low. * How do you do this: Pick mean plus a few standard deviations as the timeout * Online calculation of mean and standard deviation mean = (1 - alpha) * mean + (alpha) * RTT deviation = (1 - beta) * deviation + beta * |RTT - mean| * How do you get the RTTs? Add a timestamp to the packet % DEMO: Could show them timestamp in Wireshark. * What if the retransmitted packet also needs to be re-re-transmitted? * Sign that you may have no idea what the real RTT is. * Can happen if there is a sudden burst of new applications on the network. * Keep doubling the timeout until you get an ACK (and hence RTT sample) ================== 2. Sliding Window ================== * Stop and Wait: too inefficient, send one packet, and wait for ACK * Throughput is only 1 every RTT, which can lead to very bad network utilization * Sliding window protocol: * send multiple packets while waiting for ACK. Don't let the network idle. * Every new ACK gives you permission to transmit another packet * Packet conservation principle. * Window: * Refers to number of outstanding packets without ACKs * Sliding window: * Refers to the fact that this window is continuously sliding. It starts at 1, 2, ... W, Then moves to 2, 3, 4, ...W+1 and so on. * Sliding window sender: * Keep track of the number of unacked packets. * Ensure that it is never greater than W. * Every time you get an ACK send out a new packet. * Window can get fragmented on packet loss: multiple fragments of packets with continuous sequence numbers * When packets are lost: * Retransmit as before. * Same retx timer as Stop-And-Wait: power of modularity. * Sliding window receiver: * ACK every packet * Maintain a list of packets received out of order. * Maintain a variable for next packet expected in order. * Update this variable if a newly received packet fills a hole in the packet sequence. Deliver in-order packets to the application. * In Sliding Window next_in_order can jump over many packets. In Stop And Wait, it only ever advances by 1. This is the source of higher throughput ================== 3. Sliding window throughput ================== * Again, assume little loss for simplicity * Internet loss rates are on the order of 1%, so this is reasonable. * Can you guess the form of the throughput? * Simple model for computing throughput * Sender ---> Link (Capacity C packets/second) ---> Receiver * Minimum round-trip time (excluding queueing and transmission delays) of RTT * Sometimes called RTT_{min}. We'll use RTT for simplicity. * Reasonable model even for an Internet path between the sender and the receiver * Replace C with the speed of the slowest link on the path (also called bottleneck) * Still somewhat simplified, because C depends on the other senders and receivers on the network * W packets are sent out at time 0. * The last bits of each of these packets leaves the sender at times 1/C, 2/C, ... W/C * Receiver receives them RTT/2 later: RTT/2 + 1/C, RTT/2 + 2/C, ... * ACK comes back RTT/2 later: RTT + 1/C, RTT + 2/C , ... (assuming transmission delay of ACKs can be ignored). * After RTT + W/C, W packets have been acked * After RTT + W/C + 1/C, the 2Wth packet has been sent out * It is received RTT/2 later, and acked another RTT/2 later. * 2Wth packets are acked at the end of RTT + W/C + 1/C + RTT * 3W packets are acked at the end of RTT + W/C + 1/C + RTT + 1/C + RTT * kW packets at the end of k*RTT + W/C + (k-1)/C * Throughput is kW/(k*RTT + W/C + (k-1)/C), which is W/RTT * For large k * assuming 1 << C*RTT, which was the argument for sliding windows in the first place * Throughput goes up with W. Can we just keep increasing the throughput this way? * At some point W/RTT crosses C, or W exceeds C*RTT * This corresponds to the rounds on the timeline overlapping * C*RTT is called the bandwidth-delay product. * So what if W is much more than C*RTT. * Where do the packets go? * There is no time to accommodate them on the timeline, unless you create parallel lanes and increase capacity. * They start going into queueing delay, but throughput does not increase * Is queueing delay useful? * No. Can destroy interactivity for SSH (btw SSH runs on TCP) * So we should set W to C*RTT * Unfortunately, we don't know C and RTT, and setting W to values much more than C*RTT can be problematic. * Next lecture: what happens when the window is too large (congestion collapse) * Lecture afterwards: How do multiple independent senders and receivers decide on the right window?