CS 457 Lecture 23 Congestion Fall 2011
Defining Fairness: MaxMin Given a resource utotal and several requests pi Assign allocations of ui to node i. Allocation is fair if No one receives more than they requested: ui <= pi for all i No other allocation has higher minimum allocation (for allocations meeting requirement above) Recursive true after removal of minimum node: let j = user with minimum allocation let utotal = utotal - uj remove user j above conditions should still hold
A Simple (Incorrect) Approach Allocate buffer space for each flow Only drop packet if individual flow buffer overflows Seems fair in terms of buffer allocation. Round-Robin Rule for Sending Packets Transmit packet from queue 1, then queue 2, etc. Is this approach fair? What should a sender do to optimize its share of bandwidth? Answer: Send VERY big packets!
A Simple (Impractical) Approach Allocate buffer space for each flow Only drop packet if individual flow buffer overflows Seems fair in terms of buffer allocation. Round-Robin Rule for Sending Bits Transmit one bit from queue 1, then queue 2, etc. Is this approach fair? Some notation: R(t) = the number of rounds up to time t Nac(t) = the number of active flows at time t S(i,a) = the time packet i from flow a arrives F(i,a) = the time packet i from flow a left
Notations Some notation: R(t) = the number of rounds up to time t Nac(t) = the number of active flows at time t S(i,a) = the round packet i from flow starts F(i,a) = the round packet i from flow finishes In which round is a packet transmitted? S(i,a) = Max(R(arrival_time), F(i-1,a)) F(i,a) = S(i,a) + P Can order packets by their finishing time F(i,a)
A Fair Queuing Algorithm Important factor is the finishing time F(i,a) Packet arrived bit by bit (impractical approach) But it does not matter how bits arrived Packet is not available until F(i,a) anyway Fair Queuing Approach Send packet with lowest F(i,a) Pre-emption What if packet arrives with lower F(i,a) then current packet? Could choose to pre-empt (easier to analyze) or wait (easier to implement)
Simple Congestion Detection Packet loss Packet gets dropped along the way Packet delay Packet experiences high delay How does TCP sender learn these? Loss Timeout Triple-duplicate acknowledgment Delay Round-trip time estimate
Simple Congestion Detection Packet loss Packet gets dropped along the way Packet delay Packet experiences high delay How does TCP sender learn these? Loss Timeout Triple-duplicate acknowledgment Delay Round-trip time estimate
TCP Congestion Control Basics Each source determines available capacity and how many packets is allowed to have in transit Congestion window Maximum # of unack ed bytes allowed to be in transit (the congestion-control equivalent of receiver window) MaxWindow = min{congestion window, receiver window} - send at the rate of the slowest component How to adapt the congestion window? Decrease upon losing a packet: back-off Increase upon success: explore new capacity
Additive Increase, Multiplicative Decrease How much to increase and decrease? Increase linearly, decrease multiplicatively A necessary condition for stability of TCP Consequences of oversized window are much worse than having an under-sized window Oversized window: packets dropped, retransmitted, pain for all Undersized window: lower throughput for one flow Multiplicative decrease On loss of packet, divide congestion window in half Additive increase On success for last window of data, increase linearly, adding one MSS per RTT
Window TCP Sawtooth Behavior Loss halved t
Practical Details Congestion window (cwnd) Represented in bytes, not in packets (Why?) Packets typically one MSS (Maximum Segment Size) Increasing the congestion window Increase by MSS on success for last window of data In practice, increase a fraction of MSS per received ACK # packets per window: CWND / MSS Increment per ACK: MSS * (MSS / CWND) Decreasing the congestion window Cut in half, but never below 1 MSS
Getting Started Need to start with a small CWND to avoid overloading the network. Window But, could take a long time to get started! t
Slow Start Phase Start with a small congestion window Initially, CWND is 1 MSS So, initial sending rate is MSS/RTT That could be pretty wasteful Might be much less than the available bandwidth Linear increase takes a long time to accelerate Slow-start phase (but in reality it s fast start ) Sender starts at a slow rate (hence the name) but increases the rate exponentially until the first loss event
Slow Start in Action Double CWND per round-trip time Src 1 2 4 8 D A D D A A D D D D A A A A Dest
What s Next Read Chapter 1, 2, 3, 4.1-4.3, and 5.1-5.2 Next Lecture Topics from Chapter 6.4 and 6.5 Congestion Control Homework Due Thursday in lecture Project 3 Report Any Changes in Your Project Group