================== 0. LOGISTICS, REVIEW, OUTLINE ================== * Assignment 1, send submissions via email, not Piazza * Review: last class * Application layer: DNS and Sockets * This class: transport layer * Finish up TCP sockets ** Not covering select, and won't test this. But may be useful for assignment 5. * Implementing a reliable bytestream (Stop-And-Wait) * Retransmission timers ================== 1. TCP SOCKETS ================== * Need to synchronize sender and receiver so that they agree where bytestream starts * Three new functions: listen(), connect(), accept() * accept() returns a new socket? Why? ** Can't tie up original listening socket in data communication * After accept(), communication similar to TCP, but a few key differences ** UDP is message oriented. TCP is bytestream oriented. * What's the connection between DNS and Sockets? ** Can use hostnames instead of IP addresses in Sockets API. ================= 2. RELIABILITY: STOP AND WAIT ================= 2.1 The setup for reliability ----------------- * Need to provide a reliable, in-order bytestream despite: ** Arbitrarily delayed packets ** Arbitrarily reordered packets ** Arbitrarily dropped packets, so long as a packet is eventually delivered ** Arbitrarily duplicated packets * We'll provide a reliable in-order packet stream instead. * But will assume network is not awful: ** Sender-to-receiver path can carry > 0 bits/sec on average ** Sender and receiver do not crash 2.2 The Stop-And-Wait protocol --------------- * Sender ** Send a packet ** Wait for an ACK by setting a retransmission timer ** When retransmission timer times out, retransmit packet, wait for ACK again ** Once packet is received and ACKed, move on to the next one. * Receiver ** ACK every packet ** Maintain next_in_order variable corresponding to the next packet that is expected to maintain reliable in-order abstraction ** If packet number equal next_in_order, increment it. Otherwise do nothing and discard the packet. * Need to identify packet by a number in both data and ACKs ** Commonly called a sequence number ** TCP sequences bytes ** TCP segments carry both a sequence number and an ACK number (they are bidirectional) (DEMO: TCP segments with sequence numbers) * Throughput of Stop-And-Wait ** Roughly once every RTT: round-trip time between sender and receiver ** RTT is an important concept in networking. ** 1/RTT is quite bad. For a 100 ms, 10 Mbit/s WiFi link, it's 1% of the link. ** Can do better: Sliding window in next lecture *** Start packet transmissions while waiting for ACKs. *** Similar to pipelining in computer architecture ========================== 3. RETRANSMISSION TIMERS ========================== 3.1 Deciding when to retransmit -------------------------- * Too soon and you'll flood the network with duplicate packets, wastes network capacity * Too late and you'll be not utilizing the network * Need to find the right balance * Let's think about this: needs to be at least an RTT. * But the RTT isn't precisely known. It's a random variable. * Want to pick a threshold so that P(RTT > Th) (i.e., tail probability) is small. * One possibility: Pick mean of random variable plus a few standard deviations * Tail probability falls off quickly with number of standard deviations * timeout = mean + 4.sigma in TCP (very conservative) 3.2 Estimating mu ------------------------- * Ideally could collect many RTT samples and estimate mean offline * But network conditions change (queueing delay, path changes, mobility, etc.) * Need to estimate it online => must be fast * EWMA: Exponentially Weighted Moving Average ** mu <--- mu * (1 - alpha) + alpha * RTT * Why does this make sense? ** First, it's fast. ** Second, it weighs new samples more than old ones. *** Older samples are exponentially decayed depending on how far back they are *** Hence the name ** Third, it is an average in a real sense *** If RTT settless to a new value, mu gets there quickly * How quickly depends on alpha (also called the gain) ** Higher alpha means faster convergence ** But also means it might react to transient RTT changes, like the first packet of a new connection, which needs a DNS lookup ** TCP uses alpha = 0.125 * How do you get the RTT? ** Could you just maintain a timestamp at the sender? ** What if there was a retransmission? ** Add a timestamp to the packet instead. ** Subtract this timestamp from wall clock time when ACK is received. 3.3 Estimating sigma -------------------------- ** Similar EWMA, but with a different gain called beta of 0.25 ** sigma <--- sigma * (1 - beta) + beta * | RTT - mu | ** Use absolute deviation instead of standard deviation *** It's easier to compute 3.4 Exponential backoff -------------------------- ** What if retransmitted packet is lost? ** Might indicate that you may have *no* idea what the RTT is. *** Could happen on startup (timeout is set to some default value) *** Or some sudden shock to the system (flash crowds) ** Double timeout until something is ACKed and you can start computing RTTs again ** Called exponenential backoff and is useful in other scenarios as well *** This is how your laptop backs off when colliding with another laptop on the WiFi channel.