Why Congestion Control. Congestion Control and Active Queue Management. TCP Congestion Control Behavior. Generic TCP CC Behavior: Additive Increase

Transcription

1 Congeston Control and Actve Queue Management Congeston Control, Effcency and Farness Analyss of TCP Congeston Control A smple TCP throughput formula RED and Actve Queue Management How RED works Flud model of TCP and RED nteracton Other AQM mechansms XCP: congeston for large delay-bandwdth product Router-based mechansm Decouplng congeston control from farness TCP Vegas: TCP delay based Congeston Control Use delay as congeston sgnal Why Congeston Control Ineffcency and Congeston Collapse self-nterest vs. socal welfare Ineffcency: a smple artfcal example source 1 rate λ 1 =100kb/s source 2 rate λ 2 =1000kb/s s1 s2 C1 =100kb/s x C2 =1000kb/s C3 =110kb/s y C4 =100kb/s C5 =10kb/s Assumpton: when total offered traffc exceeds lnk capacty, all sources see ther traffc reduced n proporton of ther offered traffc (e.g., when FIFO s used) d1 source 1 throughput µ 1 =10kb/s! d2 source 2 throughput µ 2 =10kb/s BISS 2010: FAN 1 BISS 2010: FAN 2 TCP Congeston Control Behavor congeston control: decrease sendng rate when loss detected, ncrease when no loss routers dscard, mark packets when congeston occurs nteracton between end systems (TCP) and routers? want to understand (quantfy) ths nteracton TCP runs at end-hosts congested router drops packets Generc TCP CC Behavor: Addtve Increase wndow algorthm (wndow W ) up to W packets n network return of ACK allows sender to send another packet cumulatve ACKS ncrease wndow by one per RTT W < W +1/W per ACK W < W +1 per RTT seeks avalable network bandwdth Ignorng the slow start phase durng whch wndow ncreased by one per ACK W < W +1 per ACK W < 2W per RTT BISS 2010: FAN 3 BISS 2010: FAN 4

2 Generc TCP CC Behavor: Multplcatve Decrease recever sender W wndow algorthm (wndow W) ncrease wndow by one per RTT W < W +1/W per ACK loss ndcaton of congeston decrease wndow by half on detecton of loss, (trple duplcate ACKs), W < W/2 BISS 2010: FAN 5 BISS 2010: FAN 6 Generc TCP CC Behavor: After Tme-Out (TO) recever sender TD wndow algorthm (wndow W) ncrease wndow by one per RTT W < W +1/W per ACK halve wndow on detecton of loss, W < W/2 tmeouts due to lack of ACKs > wndow reduced to one, W < 1 BISS 2010: FAN 7 BISS 2010: FAN 8

3 Generc TCP Behavor: Summary recever sender wndow algorthm (wndow W) ncrease wndow by one per RTT (or one over wndow per ACK, W < W +1/W) halve wndow on detecton of loss, W < W/2 tmeouts due to lack of ACKs, W < 1 successve tmeout ntervals grow exponentally long up to sx tmes TO BISS 2010: FAN 9 BISS 2010: FAN 10 Understandng TCP Behavor can smulate (ns-2) + fathful to operaton of TCP - expensve, tme consumng determnstc approxmatons + quck - gnore some TCP detals, steady state flud models + transent behavor - gnore some TCP detals W TCP wndow sze W/2 TCP Throughput/Loss Relatonshp loss occurs Idealzed model: W s maxmum supportable wndow sze (then loss occurs) TCP wndow starts at W/2 grows to W, then halves, then grows to W, then halves one wndow worth of packets each RTT to fnd: throughput as functon of loss, RTT tme (rtt) BISS 2010: FAN 11 BISS 2010: FAN 12

4 TCP Throughput/Loss Relatonshp # packets sent per perod = W TCP wndow sze W/2 perod W TCP wndow sze W/2 TCP Throughput/Loss Relatonshp perod # packets sent per perod = W W W = 2 2 W = 2 W W / 2 2 n= 0 n W / 2 n= 0 W ( + n) 2 W W W / 2( W / 2+ 1) = = W 2 + W 8 4 tme (rtt) tme (rtt) 3 W 8 2 BISS 2010: FAN 13 BISS 2010: FAN 14 W TCP wndow sze W/2 TCP Throughput/Loss Relatonshp perod 3 2 # packets sent per perod W 8 1 packet lost per perod mples: 8 8 or: W = 3W 3p loss 3 packets B = avg._thruput= W 4 rtt p loss 2 B = avg._thruput= 1.22 p loss packets rtt Drawbacks of FIFO wth Tal-drop Sometmes too late a sgnal to end system about network congeston n partcular, when RTT s large Buffer lock out by msbehavng flows Synchronzng effect for multple TCP flows Burst or multple consecutve packet drops Bad for TCP fast recovery tme (rtt) B throughput formula can be extended to model tmeouts and slow start [PFTK 98] BISS 2010: FAN 15 BISS 2010: FAN 16

5 FIFO Router wth Two TCP Sessons Actve Queue Management Droppng/markng packets depends on average queue length -> p = p(x) Advantages: sgnal end systems earler absorb burst better avods synchronzaton Examples: RED REM Markng probablty p 1 p max 0 average queue length x BISS 2010: FAN 17 BISS 2010: FAN 18 RED: Parameters mn_th mnmum threshold max_th maxmum threshold avg_len average queue length avg_len = (1-w)*avg_len + w*sample_len Dscard Probablty RED: Packet Droppng If (avg_len < mn_th) enqueue packet If (avg_len > max_th) drop packet If (avg_len >= mn_th and avg_len < max_th) enqueue packet wth probablty P Dscard Probablty (P) mn_th max_th queue_len Average Queue Length 0 mn_th max_th queue_len Average Queue Length BISS 2010: FAN 19 BISS 2010: FAN 20

6 RED: Packet Droppng (cont d) P = max_p*(avg_len mn_th)/(max_th mn_th) RED Router wth Two TCP Sessons Dscard Probablty max_p P 1 0 mn_th max_th queue_len Average Queue Length avg_len BISS 2010: FAN 21 BISS 2010: FAN 22 Issues wth RED Parameter senstvty how to set mn th, max th, and max p Goal: mantan avg. queue sze below mdpont between mn_{th} and max_{th} max th needs to be sgnfcantly smaller than max. queue sze to absorb transent peaks max p determnes drop rate In realty, hard to set these parameters RED uses avg. queue length, may ntroduce large feedback delay, lead to nstablty Other AQM Mechansms Adaptve RED (ARED) BLUE Vrtual Queue Random Early Markng (REM) Proportonal Integral Controller Adaptve Vrtual Queue Improved AQMs are desgned based on control theory to provde better faster response to congeston and more stable systems BISS 2010: FAN 23 BISS 2010: FAN 24

7 Explct Congeston Notfcaton (ECN) Standard TCP: Losses needed to detect congeston Wasteful and unnecessary ECN (RFC 3168): Routers mark packets nstead of droppng them Recever returns marks to sender n ACK packets Sender adjusts ts wndow accordngly Two bts n IP header: ECT: ECN-capable transport (set to 1) CE: congeston experenced (set to 1) ECN Bts n IP Header 2 bts => 4 ECN Codeponts Value Name Not-ECT (Not ECN Capable Transport) ECT(0) (ECN Capable Transport (0) ) ECT(1) (ECN Capable Transport(1) ) CE (Congeston Experenced) BISS 2010: FAN 25 ECN Bts n TCP Header Negotaton between TCP transport enttes sender recever ECE flag -ECN-Echo flag CWR flag -Congeston Wndow Reduced flag TCP Sender sets both ECE and CWR n SYN TCP Recever sets only ECE n SYN-ACK A host must not set ECT n SYN or SYN-ACK Some faulty frewalls ether drop an ECN-setup SYN packet or respond wth an RST TCP-PDU

8 Typcal sequence of events(1) ECT s set n IP-PDU s carryng data transmtted by the sender to ndcate that ECN s supported by transport enttes for ths PDU ECN Negotated durng connecton establshment Typcal sequence of events(2) ECN-capable router detects ncpent congeston, and sees that ECT s set n the IP-PDU The router sets CE n the IP-PDU ECT set Incpent Congeston, set CE ECT set CE set ECN enabled sender ECN enabled recever th max th mn ECN enabled router Typcal sequence of events(3) ECN enabled recever receves the IP-PDU wth CE set. Recever conveys the congeston nformaton to the transport sender by settng ECE n the ACK TCP- PDU Congeston!!! Let me nform the sender Typcal sequence of events(4) TCP sender receves the TCP-PDU wth ECE set Sender becomes aware of ncpent congeston n network Sender reacts as f a TCP-PDU was dropped (sender s cwnd reduced). Incpent Congeston, reduce cwnd ECN enabled sender CE set ECE set n ACK ECN enabled recever ECN enabled sender ECE set ACK ECN enabled recever

9 Typcal sequence of events(5) TCP sender sets CWR n the next new TCP- PDU to the recever Indcates that the sender has reacted to congeston by reducng the cwnd Incpent Congeston, reduce cwnd, Set CWR Typcal sequence of events(6) Recever stops sendng ACKs wth ECE set after gettng a TCP-PDU wth CWR set f there s no new congeston n the network Sender has reduced cwnd, stop settng ECE flag ECE set ACK CWR set ECN enabled sender ECN enabled recever ECN enabled sender ECN enabled router CWR set ECN enabled recever Rules of the Game - Sender On recept of ECE ACK packet, TCP sender SHOULD react n the same way as t would for a congeston loss n non-ecn-capable TCP Sender TCP SHOULD NOT react more than once every RTT to the ECE ACK packet Why? We saw that recever keeps sendng ECE set ACKs untl Recever gets a TCP-PDU wth CWR set from the sender For CWR set TCP-PDU to reach the recever and get acked takes at least 1 RTT. So any more ECEs receved n ths tme span s for the same nstance of congeston Rules of the Game - Sender TCP sender should set CWR n the frst new TCP- PDU the sender transmts after recevng an ECE set ACK What f a CWR set TCP-PDU s lost? Sender TCP detects the loss The loss s treated as a new nstance of congeston n network Sender wll have to agan reduce ts cwnd and retransmts the lost TCP-PDU Fst new packet wll have CWR set Retransmtted TCP-PDU wthout CWR set

10 Rules of the Game - Recever To overcome dropped ECE ACK packets, recever MUST keep sendng ECE ACKs untl t gets a TCP- PDU wth CWR set In delayed ACKs, ECE n ACK s set f CE s set for any of the IP-PDUs beng acknowledged Advantages of ECN Prevents unnecessary packet drops at routers less retransmssons mprovement n the GOODPUT Avods tmeouts by gettng faster notfcaton to end hosts Less retransmssons also means less traffc on the network ECN Performance Improvements ECN+ - allow SYN ACKs to be marked Internet draft currently RED* - mark packets usng ECN, don t drop TCP congeston control performs poorly as bandwdth or delay ncreases Shown analytcally n [Low01] and va smulatons 50 flows n both drectons Buffer = BW x Delay RTT = 80 ms 50 flows n both drectons Buffer = BW x Delay BW = 155 Mb/s 10/3/2005 Because TCP lacks fast response Spare bandwdth s avalable TCP ncreases by 1 pkt/rtt even f spare bandwdth s huge When a TCP starts, t ncreases exponentally Too many drops Flows ramp up by 1 pkt/rtt, Bottleneck takng forever Bandwdth to grab (Mb/s) the large Round bandwdth Trp Delay (sec) BISS 2010: FAN 40

11 XCP: explct congeston Control Protocol Soluton: Decouple Congeston Control from Farness Hgh Utlzaton; Small Queues; Few Drops Bandwdth Allocaton Polcy Why Decouplng? Soluton: Decouple Congeston Control from Farness Coupled because a sngle mechansm controls both Example: In TCP, Addtve-Increase Multplcatve- Decrease (AIMD) controls both How does decouplng solve the problem? 1. To control congeston: use MIMD whch shows fast response 2. To control farness: use AIMD whch converges to farness BISS 2010: FAN 41 BISS 2010: FAN 42 Characterstcs of XCP Soluton 1. Improved Congeston Control (n hgh bandwdthdelay & conventonal envronments): Small queues Almost no drops 2. Improved Farness 3. Scalable (no per-flow state) 4. Flexble bandwdth allocaton: max-mn farness, proportonal farness, dfferental bandwdth allocaton, XCP: An explct Control Protocol 1. Congeston Controller 2. Farness Controller BISS 2010: FAN 43 BISS 2010: FAN 44

12 How does XCP Work? How does XCP Work? Round Trp Round Tme Trp Tme Congeston Congeston Wndow Wndow Feedback Feedback = packet Round Trp Tme Congeston Wndow Feedback = packet Congeston Header BISS 2010: FAN 45 BISS 2010: FAN 46 How does XCP Work? How Does an XCP Router Compute the Feedback? Congeston Controller Farness Controller Goal: Matches nput traffc to lnk capacty & drans the queue Goal: Dvdes between flows to converge to farness Congeston Wndow = Congeston Wndow + Feedback XCP uses ECN and Core Stateless mechansm (.e. state carred n packet header) Routers compute feedback wthout any per-flow state Looks at aggregate traffc & queue Algorthm: MIMD Aggregate traffc changes by ~ Spare Bandwdth ~ - Queue Sze So, = α d avg Spare -βqueue Looks at a flow s state n Congeston Header Algorthm: AIMD If > 0 Dvde equally between flows If < 0 Dvde between flows proportonally to ther current rates BISS 2010: FAN 47 BISS 2010: FAN 48

13 Gettng the devl out of the detals Congeston Controller = αd avg Spare -βqueue Theorem: System converges to optmal utlzaton (.e., stable) for any lnk bandwdth, delay, number of sources f: Farness Controller Algorthm: If > 0 Dvde equally between flows If < 0 Dvde between flows proportonally to ther current rates Need to estmate number of flows N Smulaton Network S 1 S 2 Bottleneck R1, R2,, Rn π 2 0< α < and β= α N = 1 T ( Cwnd pktsnt pkt / RTT pkt ) S n No Parameter Tunng (Proof based on Nyqust Crteron) No Per-Flow State RTT pkt : Round Trp Tme n header Cwnd pkt : Congeston Wndow n header T: Countng Interval BISS 2010: FAN 49 Let α= 0.4 and β = for all smulatons Utlzaton Vs. Bandwdth 50 long-lved TCP flows 80ms Prop. Delay 50 flows n reverse drecton to create 2-way traffc XCP s near optmal! Utlzaton Vs. Delay 50 long-lved TCP flows 150 Mb/s Capacty 50 flows n reverse drecton to create 2-way traffc XCP wns agan by adjustng t s aggressveness to round trp delay

14 Is XCP Far? Sudden Traffc Demands? No Problem! 30 long-lved FTP flows Sngle 30 Mb/s bottleneck Flows are ncreasng n RTT from ms To the left s Throughput vs. flow. XCP s Very Far! TCP Vegas TCP Vegas Proposed by Brakmo and Peterson n Congeston control algorthm: usng RTT tme to measure the network stuaton. Compare the expected effcency and actual effcency to decde whether ncreasng or decreasng the cwnd value. There are three ways proposed n Vegas to ncrease delvery throughput and decrease packet loss. Modfed Slow-Start Mechansm Modfed Slow-Start Mechansm New Congeston Avodance Mechansm New Retransmsson Mechansm

15 TCP Vegas Modfed Slow-Start Mechansm Lmted Slow-Start Mechansm 1. To be able to detect and avod congeston durng slow-start, Vegas reduce the ncreasng rate of cwnd. TCP Vegas Modfed Slow-Start Mechansm When Vegas detect there s queung n network, the queue length exceed γ,and the actual rate falls below the expected rate, Vegas wll change ts state from slow-start mode to congeston avodance mode, and set cwnd to 7/8 of current value. 2. Cwnd s allowed exponental growth only every other RTT. (doubles the sze of cwnd every 2 RTT tme whle there are no losses). 3. In between, the cwnd stayed fxed so a vald comparson of the expected and actual rate can be made. TCP Vegas New Congeston Avodance Mechansm TCP Reno congeston control mechansm decde whether the network s congested or not by detectng the packet loss. As a result, TCP Reno wll ncrease the sze of wndow untl packet loss happens, so Reno wll face packet loss problem perodcally. TCP Vegas has another New Congeston Avodance Mechansm to control the sze of cwnd by observng the varaton of RTT. When the sender receves an ACK, Vegas calculate the dfference between the expect send rate and the actual send rate. TCP Vegas New Congeston Avodance Mechansm Every RTT, Vegas calculates 3 thngs: Expected Throughput: Max throughput attanable wth current w w Expected = BaseRTT BaseRTT = mn of all RTTs d Actual Throughput: Measured throughput (< Expected tput) Data transmtted n 1 RTT Actual= RTT RTT = BaseRTT + Queueng Delay

16 TCP Vegas New Congeston Avodance Mechansm Contnued Dff Dff = ( Expected Actual )BaseRTT=(w r d )>0 Dff represents the extra data n the network,.e. data n excess of what the avalable bandwdth can support Too much extra data causes congeston, too lttle cannot take advantage of bandwdth ncreases. Vegas tres adjust w so as to keep between α = 1 and β =3 extra buffers of data n the network TCP Vegas New Congeston Avodance Mechansm TCP Vegas Congeston Control Algorthm w Dff = Actual BaseRTT BaseRTT w= w+ 1, Dff < α w= w 1, Dff > β w= w, α Dff β BISS 2010: FAN 62 TCP Vegas New Retransmsson Mechansm Vegas mproved the Fast retransmt mechansm n order to detect packet loss earler and retransmt mmedately. 1.When a duplcate-ack s receved, Vegas checks f the RTT tme, whch s the dfference of the current tme and the tmestamp recorded for the relevant segment, s greater than the tmeout value. If t s, Vegas retransmt the segment mmedately wthout 3 duplcate-acks. TCP Vegas New Retransmsson Mechansm 2.When a non-duplcate ACK s receved, f t s the frst or second one after a retransmsson, Vegas agan checks f the tme nterval snce the segment was sent s larger than the tmeout value. If t s, retransmt the segment.

17 TCP Vegas Performance Experments have shown that TCP Vegas acheves % throughput ncrease over TCP Reno % less losses (retransmssons) Vegas Problem 1: Re-routng What f the route used by a Vegas connecton changes? If new route s shorter, no ssues BaseRTT gets updated and Vegas contnues to operate normally If new route s longer, BaseRTT has really ncreased. We have a problem TCP Vegas behavor durng Reroutng 1. Imagne connecton as beng a data ppe 2. Vegas wndow sze s the volume of ppe + extra data 3. Suppose a longer route s selected for the connecton r r < r 4. Correct Behavor: Wndow sze should ncrease to keep ppe full 5. Vegas Behavor: Msnterprets throughput decrease (RTT ncrease) to represent congeston w = rd + q d = BaseRTT d > d Dff = w rd IF Dff > β, w Soluton to Re-routng Problem Soluton Idea: If mnmum RTT for N consecutve pkts s consstently hgher than BaseRTT, Update BaseRTT Increase wndow sze proportonately

18 Vegas Problem 2: Persstent Congeston What f the network s already congested when a Vegas connecton starts? 1. Network s already congested when Vegas connecton starts 2. Vegas ncorrectly estmates BaseRTT 3. Vegas overestmates wndow sze 4. New connectons ncrease congeston. Correct strategy would be to back off. r d = BaseRTT Vegas operaton: w = dr + extra Perceved BaseRTT = d Queued pkts (Incorrect Sze) [Note: w = dr + extra (Correct Sze) Error = q ]