CSS432 Congestion Control Textbook Ch6.1 – 6.4 Prof. Athirai Irissappane http://courses.washington.edu/css432/athirai/ athirai@uw.edu CSS432: Congestion Control

CSS432: Congestion Control Taxonomy Network Congestion: Too many packets in the network (more than its capacity) Too many packets in the switch/router buffer Congestion control is closely related to resource allocation How many packets can be sent in the network at a time Can the switch handle requests from many hosts Two sides of the same coin Pre-allocate resources so as to avoid congestion Control congestion that leads to resource restrictions Flow control versus congestion control Flow control: to keep a fast sender from overrunning a slow receiver Congestion control: to keep a set of senders from sending two much data into the network. CSS432: Congestion Control

Taxonomy of resource allocation mechanisms Router Centric: Router makes decisions about resource allocation When to forward, drop packets Inform hosts how many packets can be sent to them Host Centric: Host makes decisions Observe network conditions and adjust E.g., advertised window Reservation-based Reserve necessary resources prior to transmission Host can reserve capacity in the network for transmission Feedback-based No prior reservation Host send data without reserving then adjust sending rate based on observation Rate Based Limit Transmission rate Window Based Advertised Window Router Centric QoS-based service (guarantees QOS) Reservation-based Rate-based Host Centric Best-effort service (no QOS guarantee) Feedback-based Window-based CSS432: Congestion Control

CSS432: Congestion Control Connectionless Flow Datagrams No connection Switched independently Flowing through a particular set of routers if transmitted from the same source/destination pair Connectionless Flows maintain state information of each flow at router for better resource allocation decisions: e.g., what should be done to the packets of the same flow Routers No state if they follow purely connectionless service Hard state if they follow purely connection-oriented service Soft state used to make resource allocation decision for each flow – How? Router Source 2 1 3 Destination CSS432: Congestion Control

CSS432: Congestion Control Queuing Discipline First-In-First-Out (FIFO) w/ Tail Drop Does not discriminate between traffic sources (flows) Fair Queuing (FQ) Work conserving: link is never left idle (if data to be sent) Explicitly segregates traffic based on flows Ensures no flow captures more than its share of capacity If there are n flows sending data, each is allocated 1/n bandwidth Variation: weighted fair queuing (WFQ) Problem: Variable packet length Flow 1 Flow 2 Flow 3 Flow 4 Round-robin service CSS432: Congestion Control

Bit-Round Fair Queuing (BRFQ) Algorithm For each queue, compute the virtual finish time (F) upon arrival of a new packet. Choose a packet with the lowest virtual finish time. No preemption – Cannot interrupt a transmitting packet A new packet with shorter F than a waiting (large) packet will be transmitted first F = S (Start time) + P (Packet length) StartTime = Max(F_prev, Arrival Time) Clock ticks for one bit transmitted Pros and Cons Emulates bit-by-bit fair queuing Not perfect: can’t preempt a large packet currently being transmitted Virtual finish time: router finishes transmitting the packet Example of fair queuing in action: (a) packets with earlier finishing times are sent first; (b) sending of a packet already in progress is completed CSS432: Congestion Control

Congestion in Packet-Switched Network Source cannot directly observe the traffic on the slow network A congested link could be assigned a large edge weight by the route propagation protocol All packets may have to flow through the same (bottleneck) router to the destination. Destination 1.5-Mbps T1 link Router Source 2 1 100-Mbps FDDI 10-Mbps Ethernet FQ or BRFQ drops off overflowed packets. CSS432: Congestion Control

TCP Congestion Control Created by Van Jacobson, 1980s, ~8 years after TCP/IP protocol stack became operational Immediately preceding this time, the Internet was suffering from congestion collapse hosts would send their packets into the Internet as fast as the advertised window would allow, congestion would occur at some router (causing packets to be dropped), and the hosts would time out hosts retransmit their packets, resulting in even more congestion CSS432: Congestion Control

TCP Congestion Control Idea Determines network capacity at each source host Uses implicit feedback Uses ACKs to pace packet transmission (self-clocking) Challenge Determining the available capacity in the first place Adjusting # in-transit packets in response to dynamic changes in the available capacity Increase in capacity? CSS432: Congestion Control

Additive Increase/Multiplicative Decrease (AIMD) New state variable per TCP connection: CongestionWindow Limits how much data source can send: Previously: EffectiveWindow = AdvertisedWindow – (LastbyteSent - LastByteAcked) Now: = Min( CongestionWindow, AdvertisedWindow) – (LastByteSent – LastByteAcked) Idea: Increase CongestionWindow when congestion goes down Decrease CongestionWindow when congestion goes up Sending application LastByteWritten TCP LastByteSent LastByteAcked LastByteSent – LastByteAcked ≤ AdvertisedWindow EffectiveWindow = AdvertisedWindow – (LastByteSent – LastByteAcked) y CSS432: Congestion Control

CSS432: Congestion Control AIMD (cont) Question: how does the source determine whether or not the network is congested? Answer: a timeout occurs Timeout signals that a packet was lost Packets are seldom lost due to transmission error Lost packet implies congestion CSS432: Congestion Control

AIMD (cont) Algorithm Divide CongestionWindow by 2 whenever a timeout occurs(halved) (multiplicative decrease) Increment CongestionWindow by 1 packet per RTT (linear increase) If all packets (of congestion window) sent are ACKed increment window by 1 In practice: increment a little for each ACK Increment = MSS * (MSS/CongestionWindow) CongestionWindow += Increment Source Destination …

AIMD (cont) Congestion Window 60 20 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 KB Time (seconds) 70 30 40 50 10 10.0 Saw Tooth Window increases at slower rate and decreases at a faster rate

CSS432: Congestion Control Slow Start Source Destination … Objective: reach the available capacity as fast as possible Idea: Begin with CongestionWindow = 1 packet Double CongestionWindow each RTT (increment by 1 packet for each ACK) When timeout occurs/packet loss: Set congestionThreashold to CongestionWindow / 2 Begin with CongestionWindow = 1 packet again CSS432: Congestion Control

CSS432: Congestion Control Slow Start Linear exponential http://www.6test.edu.cn/~lujx/linux_networking/0131777203_ch24lev1sec4.html CSS432: Congestion Control

CSS432: Congestion Control Slow Start Exponential growth, but slower than all at once Used… when first starting connection (do not know anything about network) When Nagle’s algorithm is used and packets are lost, (timeout occurs and the congestion window is already 0) Final Algorithm: CongestionThreshold = INF while (true) { CongestionWindow = 1 while ( CongestionWindow < CongestionThreshold ) CongestionWindow *= 2 (based on slow start, exponential growth) while ( ACK returned ) CongestionWindow++ (based on additive increase, linear growth) if timeout occurs, CongestionThreshold = CongestionWindow / 2 Continue } CSS432: Congestion Control

CSS432: Congestion Control Slow Start (cont) 60 20 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 Congestion Window KB 70 30 40 50 10 congestion Multiplicative decrement Multiplicative decrement congestion Additive increase Slow start on startup Additive increase Slow start after timeout CSS432: Congestion Control

CSS432: Congestion Control Slow Start (cont) Trace: Flat out: Packets lost and no ACKs arrive (Timer running) Problem: lose up to half a CongestionWindow’s worth of data Capacity 16packets, first time send 16packets and receive ACK Double congestion window (drop 16 packets) 60 20 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 KB 70 30 40 50 10 Timeout Packets lost The actual congestion threshold Congestion window CSS432: Congestion Control

CSS432: Congestion Control Fast Retransmit Sender Receiver Packet 1 Packet 2 Problem: coarse-grain TCP timeouts lead to idle periods If no retransmit: Say window full after Packet 6, When ACK 2 arrives, no action is taken, wait for time out and retransmit Packet 3 (idle period) ACK for 1 Packet 3 Packet 4 ACK for 2 Duplicate Packet 5 ACK for 2 Packet 6 Duplicate ACK for 2 ACK for 2 Duplicate Time Out Retransmit packet 3 ACK for 6 CSS432: Congestion Control

CSS432: Congestion Control Fast Retransmit Sender Receiver Packet 1 Packet 2 Problem: coarse-grain (use timer) TCP timeouts lead to idle periods. Fast retransmit: use duplicate ACKs to trigger retransmission The receiver sends back the same ACK as the last packet received in the correct sequential order. The sender retransmits the packet whose ID is one larger than this duplicate ACK, upon receiving three ACKs. ACK 1 Packet 3 Packet 4 ACK 2 Duplicate ACK 1 Packet 5 ACK 2 Packet 6 ACK 2 Duplicate ACK 2 ACK 2 Duplicate ACK 3 Time Out Retransmit packet 3 Since TCP does not know whether a duplicate ACK is caused by a lost segment or just a reordering of segments, it waits for a small number of duplicate ACKs to be received. It is assumed that if there is just a reordering of the segments, there will be only one or two duplicate ACKs before the reordered segment is processed, which will then generate a new ACK. If three or more duplicate ACKs are received in a row, it is a strong indication that a segment has been lost. ACK 6 CSS432: Congestion Control

CSS432: Congestion Control Results A packet lost Duplicate Acks allowing to keep transmitting more packet CongestionWindow is divided in a half upon retransmits rather than timeouts Too many packets sent A half of them dropped off No ACKs returned CongestionWindow stays in flat Coarse-grained timeouts 70 60 50 40 KB 30 20 10 1.0 2.0 3.0 4.0 5.0 6.0 7.0 CSS432: Congestion Control

CSS432: Congestion Control Fast Recovery Fast recovery skip the slow start phase go directly to half the last successful CongestionWindow (threshold) Slow start Only at beginning Coarse timeout occurs CSS432: Congestion Control

CSS432: Congestion Control 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: RED Gateways Explanation in the following slides host-centric: TCP Vegas Compare measured and expected throughput rate, and shrink congestion window if the measured rate is smaller. Throughput = number of bytes outstanding in the network/RTT, as packets queue up before causing congestion, RTT is going to increase and throughput is going to decrease CSS432: Congestion Control

Random Early Detection (RED) Job of congestion control - router Router notifies host Notification is implicit just drop the packet (TCP will timeout) could make explicit by marking the packet Early random 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 Congestion avoidance Global synchronization avoidance CSS432: Congestion Control

CSS432: Congestion Control RED Details Compute average queue length AvgLen = (1 - Weight) * AvgLen + Weight * SampleLen 0 < Weight < 1 (usually 0.002) SampleLen is queue length each time a packet arrives MaxThreshold MinThreshold A vgLen CSS432: Congestion Control

CSS432: Congestion Control RED Details (cont) Two queue length thresholds 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 CSS432: Congestion Control

RED Details (cont) Computing probability P Drop Probability Curve TempP = MaxP * (AvgLen - MinThreshold)/ (MaxThreshold - MinThreshold) P = TempP/(1 - count * TempP) Drop Probability Curve P increases between min thresholg and max Threshold Sharply increases to 1 for MaxThreshold Typically 0.02 Keep track of how many newly arriving packets have been queued while AveLen has been between the two thresholds P(drop) 1.0 MaxP MinThresh MaxThresh A vgLen

Summary of TCP Versions RFC 1122 TCP Tahoe TCP Reno TCP Vegas RTT Estimation X Karn’s Algorithm Slow Start AIMD Fast Retransmit Fast Recovery Throughput-rate congestion control Linux – TCP cubic CSS432: Congestion Control

CSS432: Congestion Control Reviews Queuing disciplines: FIFO FQ TCP congestion control: AIMD, cold/slow start, and fast retransmit/fast recovery Congestion avoidance: RED and TCP vegas Exercises in Chapter 6 Ex. 2 (Avoidance) Ex. 6 (Router congestions) Ex. 25(Slow start) Ex. 27 (AIMD, slow start) Ex. 34 (RED) CSS432: Congestion Control