TCP Flow Control and Congestion Control

1 1 Mao W07 TCP Flow Control and Congestion ControlEECS 489 Computer Morley MaoMonday Feb 5, 2007 Acknowledgement: Some slides taken from Kurose&Ross and Katz&Stoica2 Mao W07 TCP Flow Control receive side of TCP connection has a receive buffer: speed-matching service: matching the send rate to the receiving app s drain rateapp process may be slow at reading from buffersender won t overflowreceiver s buffer bytransmitting too much,too fastflow control3 Mao W07 TCP Flow Control : how it works(Suppose TCP receiver discards out-of-order segments) spare room in buffer= RcvWindow= RcvBuffer-[LastByteRcvd -LastByteRead] Rcvr advertises spare room by including value of RcvWindowin segments Sender limits unACKed data to RcvWindow- guarantees receive buffer doesn t overflow4 Mao W07 TCP Connection ManagementRecall:TCP sender, receiver establish connection before exchanging data segments initialize TCP variables:- seq.

2 #s- buffers, flow Control info ( RcvWindow) client:connection initiatorSocket clientSocket = new Socket("hostname","port number"); server:contacted by clientSocket connectionSocket = ();Three way handshake:Step 1:client host sends TCP SYN segment to server- specifies initial seq #- no dataStep 2:server host receives SYN, replies with SYNACK segment- server allocates buffers- specifies server initial seq. #Step 3:client receives SYNACK, replies with ACK segment, which may contain data5 Mao W07 TCP Connection Management (cont.)Closing a connection:client closes ();Step 1:clientend system sends TCP FIN Control segment to serverStep 2:serverreceives FIN, replies with ACK. Closes connection, sends FIN. clientFINserverACKACKFIN closecloseclosedtimed wait6 Mao W07 TCP Connection Management (cont.)

3 Step 3:clientreceives FIN, replies with ACK. - Enters timed wait - will respond with ACK to received FINsStep 4:server, receives ACK. Connection closed. Note:with small modification, can handle simultaneous waitclosed7 Mao W07 TCP Connection Management (cont)TCP clientlifecycleTCP serverlifecycle8 Mao W07 Principles of Congestion ControlCongestion: informally: too many sources sending too much data too fast for networkto handle different from flow Control ! manifestations:- lost packets (buffer overflow at routers)- long delays (queueing in router buffers) a top-10 problem!9 Mao W07 Causes/costs of Congestion : scenario 1 two senders, two receivers one router, infinite buffers no retransmission large delays when congested maximum achievable throughputunlimited shared output link buffersHost A in: original dataHost B out10 Mao W07 Causes/costs of Congestion : scenario 2 one router, finitebuffers sender retransmission of lost packetfinite shared output link buffersHost A in: original dataHost B out 'in: original data, plus retransmitted data11 Mao W07 Causes/costs of Congestion : scenario 2 always: (goodput) perfect retransmission only when loss.

4 Retransmission of delayed (not lost) packet makes larger (than perfect case) for same in out= in out> in out costs of Congestion :more work (retrans) for given goodput unneeded retransmissions: link carries multiple copies of pktR/2R/2 in in in W07 Causes/costs of Congestion : scenario 3 four senders multihop paths timeout/retransmit inQ:what happens as and increase? infinite shared output link buffersHost A in: original dataHost B out 'in: original data, plus retransmitted data13 Mao W07 Causes/costs of Congestion : scenario 3 Another cost of Congestion :when packet dropped, any upstream transmission capacity used for that packet was wasted!Host AHost B out14 Mao W07 Approaches towards Congestion controlEnd-end Congestion Control : no explicit feedback from network Congestion inferred from end-system observed loss, delay approach taken by TCPN etwork-assisted Congestion Control : routers provide feedback to end systems- single bit indicating Congestion (SNA, DECbit, TCP/IP ECN, ATM)- explicit rate sender should send atTwo broad approaches towards Congestion Control :15 Mao W07 Case study: ATM ABR Congestion controlABR: available bit rate: elastic service if sender s path underloaded : - sender should use available bandwidth if sender s path congested: - sender throttled to minimum guaranteed rateRM (resource management) cells.

5 Sent by sender, interspersed with data cells bits in RM cell set by switches ( network-assisted ) -NI bit:no increase in rate (mild Congestion )-CI bit: Congestion indication RM cells returned to sender by receiver, with bits intact16 Mao W07 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 cell17 Mao W07 TCP Congestion Control end-end Control (no network assistance) sender limits transmission:LastByteSent-LastByteAcked CongWin Roughly, CongWinis dynamic, function of perceived network congestionHow does sender perceive Congestion ?

6 Loss event = timeout or3 duplicate acks TCP sender reduces rate (CongWin) after loss eventthree mechanisms:-AIMD- slow start- conservative after timeout eventsrate =CongWinRTTB ytes/sec18 Mao W07 TCP AIMD8 Kbytes16 Kbytes24 Kbytestimecongestionwindowmultiplicative decrease:cut CongWinin half after loss eventadditive increase:increase CongWinby 1 MSS every RTT in the absence of loss events: probingLong-lived TCP connection19 Mao W07 TCP Slow Start When connection begins, CongWin= 1 MSS- Example: MSS = 500 bytes & RTT = 200 msec- initial rate = 20 kbps available bandwidth may be >> MSS/RTT- desirable to quickly ramp up to respectable rateWhen connection begins, increase rate exponentially fast until first loss event20 Mao W07 TCP Slow Start (more) When connection begins, increase rate exponentially until first loss event:- double CongWinevery RTT- done by incrementing CongWinfor every ACK received Summary:initial rate is slow but ramps up exponentially fastHost Aone segmentRTTHost Btimetwo segmentsfour segments21 Mao W07 Refinement After 3 dup ACKs:-CongWinis cut in half- window then grows linearly Butafter timeout event:-CongWininstead set to 1 MSS.

7 - window then grows exponentially- to a threshold, then grows linearly 3 dup ACKs indicates network capable of delivering some segments timeout before 3 dup ACKs is more alarming Philosophy:22 Mao W07 Refinement (more)Q:When should the exponential increase switch to linear? A:When CongWingets to 1/2 of its value before : Variable Threshold At loss event, Threshold is set to 1/2 of CongWin just before loss event23 Mao W07 Summary: TCP Congestion Control When CongWinis below Threshold, sender in slow-startphase, window grows exponentially. When CongWinis above Threshold, sender is in Congestion -avoidancephase, window grows linearly. When a triple duplicate ACKoccurs, Thresholdset to CongWin/2and CongWinset to Threshold.

8 When timeoutoccurs, Thresholdset to CongWin/2and CongWinis set to 1 W07 TCP sender Congestion controlCongWin and Threshold not changedIncrement duplicate ACK count for segment being ackedSS or CADuplicate ACKE nter slow startThreshold = CongWin/2, CongWin = 1 MSS,Set state to Slow Start SS or CATimeoutFast recovery, implementing multiplicative decrease. CongWin will not drop below 1 = CongWin/2, CongWin = Threshold,Set state to Congestion Avoidance SS or CALoss event detected by triple duplicate ACKA dditive increase, resulting in increase of CongWin by 1 MSS every RTTCongWin = CongWin+MSS * (MSS/CongWin)CongestionAvoidance (CA) ACK receipt for previously unacked dataResulting in a doubling of CongWin every RTTCongWin = CongWin + MSS, If (CongWin > Threshold)set state to Congestion Avoidance Slow Start (SS)ACK receipt for previously unacked data CommentaryTCP Sender Action StateEvent 25 Mao W07 TCP throughput What s the average throughout of TCP as a function of window size and RTT?

9 - 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/2 RTT. Average throughout: .75 W/RTT26 Mao W07 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: L = 2 10-10 Wow New versions of TCP for high-speed needed!LRTTMSS W07 Fairness goal:if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/KTCP connection 1bottleneckroutercapacity RTCP connection 2 TCP Fairness28 Mao W07 Why is TCP fair?Two competing sessions: Additive increase gives slope of 1, as throughout increases multiplicative decrease decreases throughput proportionally RRequal bandwidth shareConnection 1 throughputConnection 2 throughputcongestion avoidance: additive increaseloss: decrease window by factor of 2congestion avoidance: additive increaseloss: decrease window by factor of 229 Mao W07 Fairness (more)Fairness and UDP Multimedia apps often do not use TCP- do not want rate throttled by Congestion Control Instead use UDP:- pump audio/video at constant rate, tolerate packet loss Research area: TCP friendlyFairness and parallel TCP connections nothing prevents app from opening parallel cnctions between 2 hosts.

10 Web browsers do this Example: link of rate R supporting 9 cnctions; - new app asks for 1 TCP, gets rate R/10- new app asks for 11 TCPs, gets R/2 !30 Mao W07 Delay modelingQ:How long does it take to receive an object from a Web server after sending a request? Ignoring Congestion , delay is influenced by: TCP connection establishment data transmission delay slow startNotation, assumptions: Assume one link between client and server of rate R S: MSS (bits) O: object size (bits) no retransmissions (no loss, no corruption)Window size: First assume: fixed Congestion window, W segments Then dynamic window, modeling slow start31 Mao W07 TCP Delay Modeling: Slow Start (1)Now suppose window grows according to slow startWill show that the delay for one object is:RSRSRTTPRORTTL atencyP)12(2 +++=where Pis the number of times TCP idles at server.