
TCP Flow Control and Congestion Control EECS 489 Computer Networks http://www.eecs.umich.edu/courses/eecs489/w07 Z. Morley Mao Monday Feb 5, 2007 Acknowledgement: Some slides taken from Kurose&Ross and Katz&Stoica Mao W07 1 TCP Flow Control flow control sender won’t overflow receive side of TCP receiver’s buffer by connection has a receive transmitting too much, buffer: too fast speed-matching service: matching the send rate to the receiving app’s drain rate app process may be slow at reading from buffer Mao W07 2 TCP Flow control: how it works Rcvr advertises spare room by including value of RcvWindow in segments Sender limits unACKed data to RcvWindow - guarantees receive buffer (Suppose TCP receiver discards doesn’t overflow out-of-order segments) spare room in buffer = RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead] Mao W07 3 TCP Connection Management Recall: TCP sender, receiver Three way handshake: establish “connection” before exchanging data segments Step 1: client host sends TCP SYN segment to server initialize TCP variables: - seq. #s - specifies initial seq # - buffers, flow control info - no data (e.g. RcvWindow) Step 2: server host receives SYN, client: connection initiator replies with SYNACK segment Socket clientSocket = new - server allocates buffers Socket("hostname","port - specifies server initial seq. # number"); Step 3: client receives SYNACK, server: contacted by client replies with ACK segment, Socket connectionSocket = welcomeSocket.accept(); which may contain data Mao W07 4 TCP Connection Management (cont.) Closing a connection: client server client closes socket: close clientSocket.close(); FIN Step 1: client end system sends TCP FIN control ACK segment to server close FIN Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN. ACK timed wait closed Mao W07 5 TCP Connection Management (cont.) Step 3: client receives FIN, client server replies with ACK. closing - Enters “timed wait” - will FIN respond with ACK to received FINs Step 4: server, receives ACK. ACK Connection closed. closing FIN Note: with small modification, can handle simultaneous FINs. ACK closed timed wait closed Mao W07 6 TCP Connection Management (cont) TCP server lifecycle TCP client lifecycle Mao W07 7 Principles of Congestion Control Congestion: informally: “too many sources sending too much data too fast for network to handle” different from flow control! manifestations: - lost packets (buffer overflow at routers) - long delays (queueing in router buffers) a top-10 problem! Mao W07 8 Causes/costs of congestion: scenario 1 Host A λ λ : original data out two senders, two in receivers one router, infinite Host B unlimited shared buffers output link buffers no retransmission large delays when congested maximum achievable throughput Mao W07 9 Causes/costs of congestion: scenario 2 one router, finite buffers sender retransmission of lost packet Host A λ λin : original data out λ'in : original data, plus retransmitted data Host B finite shared output link buffers Mao W07 10 Causes/costs of congestion: scenario 2 λ = λ always: in out (goodput) “perfect” retransmission only when loss: λ > λ in out retransmission of delayed (not lost) packet makes λ larger (than in perfect case) for same λ out R/2 R/2 R/2 R/3 out out out R/4 λ λ λ R/2 R/2 R/2 λin λin λin “costs”a. of congestion: b. c. more work (retrans) for given “goodput” unneeded retransmissions: link carries multiple copies of pkt Mao W07 11 Causes/costs of congestion: scenario 3 four senders Q: what happens as λ multihop paths in and λ increase ? timeout/retransmit in Host A λout λin : original data λ'in : original data, plus retransmitted data finite shared output link buffers Host B Mao W07 12 Causes/costs of congestion: scenario 3 H λ o s o u t A t H o s t B Another “cost” of congestion: when packet dropped, any “upstream transmission capacity used for that packet was wasted! Mao W07 13 Approaches towards congestion control Two broad approaches towards congestion control: End-end congestion control: Network-assisted congestion no explicit feedback from control: network routers provide feedback to congestion inferred from end- end systems system observed loss, delay - single bit indicating approach taken by TCP congestion (SNA, DECbit, TCP/IP ECN, ATM) - explicit rate sender should send at Mao W07 14 Case study: ATM ABR congestion control ABR: available bit rate: RM (resource management) “elastic service” cells: if sender’s path sent by sender, interspersed with “underloaded”: data cells - sender should use bits in RM cell set by switches available bandwidth (“network-assisted”) if sender’s path congested: - NI bit: no increase in rate - sender throttled to (mild congestion) minimum guaranteed rate - CI bit: congestion indication RM cells returned to sender by receiver, with bits intact Mao W07 15 Case study: ATM ABR congestion control two-byte ER (explicit rate) field in RM cell - congested switch may lower ER value in cell - sender’ send rate thus minimum supportable rate on path EFCI bit in data cells: set to 1 in congested switch - if data cell preceding RM cell has EFCI set, sender sets CI bit in returned RM cell Mao W07 16 TCP Congestion Control end-end control (no network assistance) How does sender perceive sender limits transmission: congestion? LastByteSent-LastByteAcked loss event = timeout or 3 duplicate acks ≤ CongWin TCP sender reduces rate Roughly, (CongWin) after loss event three mechanisms: -AIMD CongWin is dynamic, function of - slow start perceived network congestion - conservative after timeout events CongWin rate = Bytes/sec RTT Mao W07 17 TCP AIMD multiplicative decrease: additive increase: increase cut CongWin in half CongWin by 1 MSS every after loss event RTT in the absence of loss events: probing congestion window 24 Kbytes 16 Kbytes 8 Kbytes time Long-lived TCP connection Mao W07 18 TCP Slow Start When connection begins, When connection begins, CongWin = 1 MSS increase rate exponentially fast - Example: MSS = 500 bytes & until first loss event RTT = 200 msec - initial rate = 20 kbps available bandwidth may be >> MSS/RTT - desirable to quickly ramp up to respectable rate Mao W07 19 TCP Slow Start (more) Host B Host A When connection begins, one segment increase rate exponentially until first loss event:every RTT s - double CongWin two segment RTT - done by incrementingfor every ACK CongWin four segments received initial rate is Summary: slow but ramps up exponentially fast time 20 Mao W07 Refinement Philosophy: After 3 dup ACKs: - CongWin is cut in half • 3 dup ACKs indicates - window then grows linearly network capable of But after timeout event: delivering some segments - CongWin instead set to 1 MSS; • timeout before 3 dup - window then grows exponentially ACKs is “more alarming” - to a threshold, then grows linearly Mao W07 21 Refinement (more) Q: When should the exponential increase switch to linear? A: When CongWin gets to 1/2 of its value before timeout. Implementation: Variable Threshold At loss event, Threshold is set to 1/2 of CongWin just before loss event Mao W07 22 Summary: TCP Congestion Control When CongWin is below Threshold, sender in slow- start phase, window grows exponentially. When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly. When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold. When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS. Mao W07 23 TCP sender congestion control Event State TCP Sender Action Commentary ACK receipt for Slow Start CongWin = CongWin + MSS, Resulting in a doubling of previously (SS) If (CongWin > Threshold) CongWin every RTT unacked data set state to “Congestion Avoidance” ACK receipt for Congestion CongWin = CongWin+MSS * Additive increase, resulting previously Avoidance (MSS/CongWin) in increase of CongWin by unacked data (CA) 1 MSS every RTT Loss event SS or CA Threshold = CongWin/2, Fast recovery, detected by CongWin = Threshold, implementing multiplicative triple duplicate Set state to “Congestion decrease. CongWin will not ACK Avoidance” drop below 1 MSS. Timeout SS or CA Threshold = CongWin/2, Enter slow start CongWin = 1 MSS, Set state to “Slow Start” Duplicate ACK SS or CA Increment duplicate ACK count CongWin and Threshold not for segment being acked changed Mao W07 24 TCP throughput What’s the average throughout of TCP as a function of window size and RTT? - Ignore slow start Let W be the window size when loss occurs. When window is W, throughput is W/RTT Just after loss, window drops to W/2, throughput to W/2RTT. Average throughout: .75 W/RTT Mao W07 25 TCP Futures Example: 1500 byte segments, 100ms RTT, want 10 Gbps throughput Requires window size W = 83,333 in-flight segments Throughput in terms of loss rate: 1.22⋅ MSS RTT L ➜ L = 2·10-10 Wow New versions of TCP for high-speed needed! Mao W07 26 TCP Fairness Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K TCP connection 1 bottleneck TCP router connection 2 capacity R Mao W07 27 Two competingsessions: multiplicative decreasedecreases throughputproportionally Additive increasegivesslope of 1,asthroughoutincreases R Connection 1throughput Connection 2 throughput Why isTCPfair? equal bandwidthshare loss: decreasewindow byfactorof2 congestion avoidance: additive increase avoidance:additive congestion congestion avoidance: additive increase avoidance:additive congestion loss: decreasewindow
Details
-
File Typepdf
-
Upload Time-
-
Content LanguagesEnglish
-
Upload UserAnonymous/Not logged-in
-
File Pages55 Page
-
File Size-