CSS 432 Congestion Control Textbook Ch 6 1

CSS 432 Congestion Control Textbook Ch 6. 1 – 6. 4 Professor: Munehiro Fukuda CSS 432: Congestion Control 1

Taxonomy n Resource in network systems Link bandwidth ¨ Buffer size in routers or switches ¨ n Two sides of the same coin ¨ ¨ n 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. ¨ n Two points of implementation Router Centric Qo. S-based service Reservation-based Rate-based Host Centric Feedback-based Window-based Best-effort service CSS 432: Congestion Control 2

Connectionless Flow n Datagrams ¨ ¨ n Switched independently Flowing through a particular set of routers if transmitted from the same source/destination pair n Connectionless Flows 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? Source 1 Router Destination 1 Router Source 2 Router Destination 2 Source 3 CSS 432: Congestion Control 3

Queuing Discipline n First-In-First-Out (FIFO) ¨ n Does not discriminate between traffic sources Fair Queuing (FQ) Work conserving: link is never left idle ¨ Explicitly segregates traffic based on flows ¨ Ensures no flow captures more than its share of capacity n If there are n flows sending data, 1/nth bandwidth is at most given ¨ Variation: weighted fair queuing (WFQ) ¨ n Problem? Flow 1 Flow 2 Round-robin service Flow 3 Flow 4 CSS 432: Congestion Control 4

Bit-Round Fair Queuing (BRFQ) n Algorithm For each queue, compute the virtual finish time upon the arrival of a new packet. Choose a packet with the lowest virtual finish time. ¨ ¨ n Pros and Cons Emulate bit-by-bit fair queuing Not perfect: can’t preempt the current large packet. ¨ ¨ Time Queue A Queue B Queue C 0 Queue A Queue B Queue C Packet 1 Packet 2 Packet 1 Real arrival time ti 0 2 1 2 3 Transmission time Pi 3 1 1 4 2 Virtual start time Si 0 3 1 2 3 Virtual finish time Fi 3 4 2 6 5 Fq =Sq i i 2 3 4 5 6 7 Real arrival FQ BRFQ + Sq = max[Fq -1, R(tq )] R(t) = R(t + 1) + 1/#rounds i Pq max( ) 1 i i i 8 9 10 11 12 CSS 432: Congestion Control 5

Congestion in Packet-Switched Network n n n 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. Source 10 -M 1 bps Ethe rnet Router 1. 5 -Mbps T 1 link Destination DI Source 2 s FD p b M - 100 FQ or BRFQ drops off overflowed packets. CSS 432: Congestion Control 6

TCP Congestion Control n Idea ¨ Assumes best-effort network (FIFO or FQ routers) ¨ Determines network capacity at each source host ¨ Uses implicit feedback ¨ Uses ACKs to pace packet transmission (self-clocking) n Challenge ¨ Determining the available capacity in the first place ¨ Adjusting # in-transit packets in response to dynamic changes in the available capacity CSS 432: Congestion Control 7

Additive Increase/Multiplicative Decrease (AIMD) n New state variable per connection: Congestion. Window ¨ Limits how much data source can send: ¨ Previously: Sending application TCP Effective. Window = Advertised. Window – (Lastbyte. Sent - Last. Byte. Acked) ¨ y Now: Effective. Window = Min( Congestion. Window, Advertised. Window) – (Last. Byte. Sent – Last. Byte. Acked) n Last. Byte. Written Idea: ¨ Increase Congestion. Window when congestion goes down ¨ Decrease Congestion. Window when congestion goes up Last. Byte. Acked Last. Byte. Sent – Last. Byte. Acked ≤ Advertised. Window Effective. Window = Advertised. Window – (Last. Byte. Sent – Last. Byte. Acked) CSS 432: Congestion Control 8

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

AIMD (cont) n Algorithm Increment Congestion. Window by one packet per RTT (linear increase) ¨ Divide Congestion. Window by two whenever a timeout occurs (multiplicative decrease) KB ¨ 70 60 50 40 30 20 10 1. 0 2. 0 3. 0 4. 0 5. 0 6. 0 7. 0 8. 0 9. 0 10. 0 Time (seconds) n In practice: increment a little for each ACK Increment = MSS * (MSS/Congestion. Window) Congestion. Window += Increment CSS 432: Congestion Control 10

Slow Start Source n Objective: reach the available capacity as fast as possible Idea: ¨ Begin with Congestion. Window = 1 packet ¨ Double Congestion. Window each RTT (increment by 1 packet for each ACK) ¨ When timeout occurs: n n Set congestion. Threashold to Congestion. Window / 2 Begin with Congestion. Window = 1 packet again … n Destination ¨ Observe slow start with tcpdump in assignment 3. CSS 432: Congestion Control 11

Slow Start (cont) n n n Exponential growth, but slower than all at once Used… ¨ when first starting connection ¨ When Nagle’s algorithm is used and packets are lost, (timeout occurs and the congestion window is already 0) Final Algorithm: Congestion. Threshold = INF ¨ While (true) { n Congestion. Window = 1 n While ( congestion. Window < congestion. Threshold ) ¨ Congestion. Window *= 2 (based on slow start, exponential growth) n While ( ACK returned ) ¨ Congestion. Window++ (based on additive lincrease, linear growth) n If timeout occurs, ¨ Congestion. Threshold = Congestion. Window / 2 ¨ Continue ¨ } ¨ CSS 432: Congestion Control 12

Slow Start (cont) Trace: KB n 70 60 50 40 30 20 10 1. 0 n 2. 0 3. 0 4. 0 5. 0 6. 0 7. 0 8. 0 9. 0 Problem: lose up to half a Congestion. Window’s worth of data Timeout Packets lost The actual congestion threshold CSS 432: Congestion Control Congestion window 13

Fast Retransmit n Problem: coarse-grain TCP timeouts lead to idle periods Sender Receiver Packet 1 Packet 2 Packet 3 ACK 1 Packet 4 ACK 2 Packet 5 ACK 2 Duplicate ACK 1 Packet 6 n ACK 2 Duplicate ACK 3 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. ¨ Retransmit packet 3 CSS 432: Congestion Control ACK 6 14

Results Too many packets sent A packet lost A half of them dropped off Duplicate Acks allowing to keep transmitting more packet No ACKs returned Congestion. Window stays in flat Congestion. Window is divided in a half upon retransmits rather than timeouts KB Coarse-grained timeouts 70 60 50 40 30 20 10 1. 0 2. 0 3. 0 4. 0 CSS 432: Congestion Control 5. 0 6. 0 7. 0 15

Fast Recovery n Fast recovery ¨ skip the slow start phase ¨ go directly to half the last successful Congestion. Window (ssthresh) CSS 432: Congestion Control 16

Congestion Avoidance n 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 ¨ n Alternative strategy predict when congestion is about to happen ¨ reduce rate before packets start being discarded ¨ call this congestion avoidance, instead of congestion control ¨ n Two possibilities router-centric: RED Gateways n Explanation in the following slides ¨ host-centric: TCP Vegas n Compare measured and expected throughput rate, and shrink congestion window if the measured rate is smaller. ¨ CSS 432: Congestion Control 17

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

Random Early Detection (RED) n Notification is implicit ¨ just drop the packet (TCP will timeout) ¨ could make explicit by marking the packet n 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 n Global synchronization avoidance n CSS 432: Congestion Control 19

RED Details n Compute average queue length Avg. Len = (1 - Weight) * Avg. Len + Weight * Sample. Len 0 < Weight < 1 (usually 0. 002) Sample. Len is queue length each time a packet arrives Max. Threshold Min. Threshold Avg. Len CSS 432: Congestion Control 20

RED Details (cont) n Two queue length thresholds if Avg. Len <= Min. Threshold then enqueue the packet if Min. Threshold < Avg. Len < Max. Threshold then calculate probability P drop arriving packet with probability P if Max. Threshold <= Avg. Len then drop arriving packet CSS 432: Congestion Control 21

RED Details (cont) n Computing probability P Typically 0. 02 Temp. P = Max. P * (Avg. Len - Min. Threshold)/ (Max. Threshold - Min. Threshold) P = Temp. P/(1 - count * Temp. P) n Drop Probability Curve P(drop) Keep track of how many newly arriving packets have been queued while Ave. Len has been between the two thresholds 1. 0 Max. P Avg. Len Min. Thresh Max. Thresh CSS 432: Congestion Control 22

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