Spring Computer Networks1 Congestion Control II Outline Queuing Discipline Reacting to Congestion Avoiding Congestion DECbit Random Early Detection (RED) TCP Vegas

Spring Computer Networks2 TCP Congestion Control Idea assumes best-effort network (FIFO or FQ routers) each source determines network capacity for itself –determines how many packets it can safely have in transit –safely: without having to retransmit

Spring Computer Networks3 TCP Congestion Control (continued I) ACKs pace transmission (self-clocking) arrival of an ACK signals that one of the TCP connection packets left network it is safe to insert a new packet without adding to the level of congestion

Spring Computer Networks4 TCP Congestion Control (continued II) Challenge determining the available capacity in the first place adjusting to changes in the available capacity

5 Additive Increase/Multiplicative Decrease (AIMD) Congestion Control Mechanism Objective: adjust to changes in the available capacity New state variable per connection: CongestionWindow –limits how much data the source has in transit MaxWin = MIN(CongestionWindow, AdvertisedWindow) EffWin = MaxWin - (LastByteSent - LastByteAcked)

Spring Computer Networks6 Additive Increase/Multiplicative Decrease (cont) Idea: –increase CongestionWindow when congestion goes down –decrease CongestionWindow when congestion goes up TCP source is allowed to send no faster than the slowest component— the network or the destination host —can accommodate.

Spring Computer Networks7 Additive Increase /Multiplicative Decrease,AIMD (cont) Question: how does the source determine whether or not the network is congested? Answer: a timeout implies congestion –timeout signals that a packet was lost –packets are seldom lost due to transmission error –lost packet implies congestion

Spring Computer Networks8 AIMD (cont) In practice: increment a little for each ACK Increment = MSS * ( MSS/CongestionWindow) CongestionWindow += Increment Algorithm –increment CongestionWindow by one packet per RTT (linear increase) –divide CongestionWindow by two whenever a timeout occurs (multiplicative decrease) SourceDestination

Spring Computer Networks9 AIMD (cont) Trace: sawtooth behavior CongestionWindow

Spring Computer Networks10 Draw Back of AIMD After a Connection is Established SourceDestination AIMD mechanism takes too long to ramp up a connection when it is starting from scratch Sending an entire advertised window’s all at once may lead to congestion (or make it worse) TCP provides a second mechanism for increasing CongestionWindow at start of data transmission called Slow Start

Spring Computer Networks11 Slow Start Increases the congestion window rapidly from a cold start –exponentially, rather than linearly Idea: –begin with CongestionWindow = 1 packet –double CongestionWindow each RTT (increment by 1 packet for each ACK) SourceDestination

Spring Computer Networks12 Slow Start (cont) Although growth of CongestionWindow is exponential, it is slower than all at once Used 1.when first starting connection slow start doubles CongestionWindow each RTT until there is a loss a timeout causes multiplicative decrease to divide CongestionWindow by 2

Spring Computer Networks13 Slow Start (cont I ) 2.Also used when connection goes dead waiting for timeout a packet is lost  source reaches a point where it has sent as much data as allowed »it blocks while waiting for an ACK Eventually, a timeout happens  source receives a single cumulative ACK that reopens entire advertised window source uses slow start rather than dumping a whole window’s worth of data on network

Spring Computer Networks14 Slow Start: After A Dead Connection source has a “useful” current value of CongestionWindow –the value that existed prior to the last packet loss, divided by 2 as a result of the loss –this value is stored in CongestionThreshold and used as a “target” CongestionWindow After timeout and when retransmission is restarted, CongestionWindow is reset to one packet –double CongestionWindow each RTT until it reaches CongestionThreshold (slow start) –incremented by one packet per RTT after CongestionThreshold is reached (Additive Increase)

Spring Computer Networks15 Slow Start: Typical Trace 34 KB 22 KB 17 KB 11 KB Legend: Colored line: value of CongistionWindow Solid Bullets: time outs hash marks at top: time when packets are transmitted vertical bars: time when a packet that was eventually retransmitted was first transmitted 1.t= 0; Initial slow start phase: rapid increase in the CongestionWindow 2.t= 0.4; several packets are lost: CongestionWindow flattens out at 34 KB  No ACKs arriving, due to the fact that several packets were lost  No new packets are sent 3.t= 2; a timeout  CongestionThreshold = current divided by 2 (i.e., cut to 17 KB)  Slow start resets CongestionWindow to one packet and increases it to CongestionThreshold  Additive Increase kicks in after 17KB and will get CongestionWindow to 22KB 4.t= 4; CongestionWindow flattens out (due to a lost packet) 5.t= 5.5; a timeout happens, CongestionWindow divided by 2 to give a new CongestionThreshold ( 22 KB/ 2 ) which is set to 11  slow start causes CongestionWindow to grow exponentially until it reaches 11 then it grows linearly 6.Behavior repeated at 8… 34 KB 17 KB

Spring Computer Networks16 Timeout Triggered Retransmission Problem: coarse-grain TCP timeouts lead to idle periods

Spring Computer Networks17 Fast Retransmit Fast Retransmit: –When a packet is lost, does not wait for a time out to retransmit –Uses duplicate ACKs to trigger retransmission second transmission of same acknowledgment called a duplicate ACK a duplicate ACK implies other side received a packet out of order (i.e. a packet has been DELAYED or LOST) –TCP sender waits until it sees three duplicate ACKs before concluding that a packet is LOST and retransmitting that packet With Fast Retransmission

Spring Computer Networks18 a version of TCP with the fast retransmit mechanism compared with the trace where fast retransmit was not implemented –the long periods during which the congestion window stays flat and no packets are sent have been eliminated

Spring Computer Networks19 Fast Recovery Fast Recovery: additional improvement possible When the fast retransmit mechanism signals congestion –Slow start is not used – ACKs clock sending of packets congestion window is not dropped to one packet go directly to half the last successful CongestionWindow (i.e. CongestionThreshold ) Then use of additive increase begins This is “Fast Recovery” because: skip the slow start phase go directly to CongestionThreshold

Spring Computer Networks20 Fast Recovery (continued) Slow start is only used 1.At the beginning of a connection 2.Whenever a coarse-grained timeout occurs At all other times, the congestion window follows pure additive increase/multiplicative decrease In general, Fast Retransmit Fast Recovery –eliminate about half of the coarse-grained timeouts –roughly a 20% improvement in the throughput

Spring Computer Networks21 Congestion Avoidance TCP’s strategy –control congestion once it happens –repeatedly increase load in an effort to find the point at which congestion occurs, and then back off Alternative strategy –predict when congestion is about to happen –reduce rate before packets start being discarded –call this congestion avoidance, instead of congestion control Two possibilities –router-centric: DECbit and Random Early Detection (RED) Gateways –host-centric: TCP Vegashost-centric: TCP Vegas

Spring Computer Networks22 DECbit Router monitors load Explicitly notifies end nodes when congestion is about to occur –Sets a congestion bit in header Destination copies congestion bit into ACK The source adjusts its sending rate to avoid congestion

23 DECbit (continued) Router –monitors average queue length over last “busy + idle” cycle and the current busy cycle –set congestion bit if average queue length > 1 –attempts to balance Significant queuing (hence higher throughput) Increased idle time (hence lower delay)

Spring Computer Networks24 DECbit & Power Function –a queue length of 1 seems to optimize the power function

Spring Computer Networks25 End Hosts Destination echoes congestion bit back to source Source records how many packets resulted in a “set congestion bit” If less than 50% of last window’s worth had bit set –increase CongestionWindow by 1 packet If 50% or more of last window’s worth had bit set –decrease CongestionWindow by times

Spring Computer Networks26 Random Early Detection (RED) Notification is implicit: –dropped packets indicate congestion Could make notification explicit (Explicit Congestion Notification, ECN; see pp ) –Current standard proposal for explicit notification (old method: DECbit) –Mark packet as queue gets full, reduce sending rate when marks are seen RED drops packets to force sources to back off (versus tail drop) –rather than wait for queue to become full, drop each arriving packet with some drop probability whenever the queue length exceeds some drop level

Spring Computer Networks27 RED Details Let SampleLen be queue length measured each time a packet arrives Use a constant, Weight, such that 0 < Weight < 1 (usually 0.002) Compute average queue length AvgLen = (1 - Weight) * AvgLen + Weight * SampleLen

28 RED Details two queue length thresholds trigger certain activity When a packet arrives at the gateway if AvgLen <= MinThreshold then enqueue the packet if MinThreshold < AvgLen < MaxThreshold then calculate probability P drop arriving packet with probability P if MaxThreshold <= AvgLen then drop arriving packet

Spring Computer Networks29 RED Details: Computing Probability P TempP = MaxP * (AvgLen - MinThreshold)/ (MaxThreshold - MinThreshold) P = TempP/(1 - count * TempP) count = number of newly arriving packets that have been queued (not dropped) while AvgLen has been between two thresholds P increases slowly with count

Spring Computer Networks30 Computing Probability P (cont) Drop probability is a function of both AvgLen and how long it has been since the last drop. –As count increases, time since last drop increases, and drop probability increases –makes closely spaced drops less likely prevents clusters of drops  multiple drops might send a connection back into slow start  a single drop is enough to cause connection to reduce window size

Spring Computer Networks31 RED Details (cont) Drop Probability Curve RED is good at keeping avg. queue size steady

Spring Computer Networks32 Tuning RED MaxP is typically set to 0.02, meaning that when the average queue size is halfway between the two thresholds, the gateway drops roughly one out of 100 packets. TempP =.02 * 1/2 =.01 P =.01 TempP = MaxP * (AvgLen – MinThreshold )/ (MaxThreshold - MinThreshold) P = TempP/(1 - count * TempP) initially count = 0

Spring Computer Networks33 Tuning RED (continued) Thresholds are hard to determine If traffic is bursty, then MinThreshold should be sufficiently large to allow link utilization to be maintained at an acceptably high level Difference between two thresholds should be larger than the typical increase in the calculated average queue length in one RTT; setting MaxThreshold to twice MinThreshold is reasonable for traffic on today’s Internet

Spring Computer Networks34 TCP Versions: Tahoe and Reno Transmission round congestion window size (segments) Series1Series2 threshold TCP Reno Tahoe Assume: 3 rd duplicate ACK at time 9 TCP Tahoe (series 1 in figure) –First (old) version –Reduce Congestion Window to 1 on any loss event –Set CongestionThreshold to ½ of current cong. window size TCP Reno (series 2 in figure) –Newer –Most popular version –Reduce Congestion Window To 1 on timeout By half on 3 rd duplicate ACK –Set CongestionThreshold to ½ of current congestioin window size

Spring Computer Networks35 TCP Vegas Introduces variation of Reno implementation of TCP Detects congestion in routers BEFORE loss occurs

36 Congestion Avoidance using: TCP Vegas Idea: source watches for some sign that router’s queue is building up and congestion will happen too. e.g. –RTT grows –sending rate flattens Congestion window Avg. source send rate Buffer space at bottleneck router In shaded region the cogestion widow increases. We expect throughput to increase but it cannot increase beyond available bandwidth Any increase in the window size only results in packets taking up buffer space at bottleneck router

Spring Computer Networks37 Goals of Vegas Algorithm Vegas tries NOT to send at a rate that causes buffers to fill “Amount of extra data a connection has in transit” is –Data that the source would not have transmitted had it been trying to match exactly the available bandwidth of the network The goal of TCP Vegas is to maintain the “right” amount of extra data in the network. –Too much extra data long delays and possibly lead to congestion –Too little extra data Source cannot respond rapidly to transient increases in available network bandwidth

Spring Computer Networks38 Vegas Algorithm Definitions: A flow’s BaseRTT : RTT of a packet when the flow is not congested –TCP Vegas sets BaseRTT to the minimum of all measured round-trip times Commonly the RTT of first packet sent by connection Expected throughput = ExpectRate = CongestionWindow/BaseRTT –CongestionWindow is the TCP congestion window Assume to be equal to the number of bytes in transit

Spring Computer Networks39 Vegas Algorithm (cont.) Source calculates sending rate ( ActualRate ) once per RTT –Pick one packet per RTT, –Timestamp send/ACKreceive time –ActualRate = number of bytes in transit / RTT Source compares ActualRate with ExpectRate –Define two thresholds, α < β, roughly corresponding to having too little and too much extra data in the network, respectively. –Diff = ExpectedRate – ActualRate –if Diff <  increase CongestionWindow linearly –else if Diff >  decrease CongestionWindow linearly –Else leave CongestionWindow unchanged

Illustrating the Algorithm Black line = actual rate Green line = expected rate Shaded = region between  and  The goal is to keep the ActualRate between these two thresholds, that is, within the shaded region. Whenever ActualRate falls below shaded region (i.e., gets too far from Expected Rate), TCP Vegas decreases the congestion window because it fears that too many packets are being buffered in the network. Whenever ActualRate goes above the shaded region (i.e., gets too close to the Expected Rate), TCP Vegas increases the congestion window because it fears that it is underutilizing the network. congestion window Throughput