ADVANCED TOPICS FOR CONGESTION CONTROL

ADVANCED TOPICS FOR CONGESTION CONTROL

Congestion Control The Internet only functions because TCP s congestion control does an effective job of matching traffic demand to available capacity. TCP s Window Time (RTTs)

Limitations of AIMD Congestion Control (Additive Increase, Multiplicative Decrease) Very variable transmit rate is fine for bulk-transfer, but hard for real-time traffic. RFC3448: TCP-Friendly Rate Control (TFRC) RFC4340: Datagram Congestion Control Protocol (DCCP)

Limitations of AIMD Congestion Control Failure to distinguish congestion loss from corruption loss Wireless (already discussed) Limited dynamic range

AIMD: Limited Dynamic Range One loss every half hour, 200ms RTT, 1500bytes/pkt. 9000 RTTs increase between losses peak window size = 18000 pkts mean window size = 12000 pkts 18MByte/RTT 720Mbit/s Needs a bit-error rate of better than 1 in 10^12 Takes a very long time to converge or recover from a burst of loss

TCP Congestion Control Performs Poorly as Bandwidth or Delay Increases Shown analytically in [Low01] and via simulations 50 flows in both directions Buffer = BW x Delay RTT = 80 ms 50 flows in both directions Buffer = BW x Delay BW = 155 Mb/s Bottleneck Bandwidth (Mb/s) Round Trip Delay (sec)

TCP Congestion Control Performs Poorly as Bandwidth or Delay Increases Shown analytically in [Low01] and via simulations 50 flows in both directions Buffer = BW x Delay RTT = 80 ms Because TCP lacks fast response Spare bandwidth is available TCP increases by 1 pkt/rtt even if spare bandwidth is huge When a TCP starts, it increases exponentially Too many drops Flows ramp up by 1 pkt/rtt, taking forever to grab the large bandwidth 50 flows in both directions Buffer = BW x Delay BW = 155 Mb/s Bottleneck Bandwidth (Mb/s) Round Trip Delay (sec)

Trends in Future Internet Links High Bandwidth Gigabit Links optical fibers High Latency Satellite links Wireless links The Bandwidth delay products will increase

Efficiency vs. Fairness Efficiency Determined by congestion control algorithm Involves only aggregate traffic behavior To maximize it you need High utilization, few drops and small queues Has to be aggressive Fairness Relative throughput of all flows in the link Deals with every flow

Proposed Solution: Decouple Congestion Control from Fairness High Utilization; Small Queues; Few Drops Bandwidth Allocation Policy

Proposed Solution: Decouple Congestion Control from Fairness Coupled because a single mechanism controls both Example: In TCP, Additive-Increase Multiplicative-Decrease (AIMD) controls both How does decoupling solve the problem? 1. To control congestion: use MIMD which shows fast response 2. To control fairness: use AIMD which converges to fairness

Let s do it all over again Build new congestion control architecture Design goal: Stable + efficient + fair Ideas Packet loss is a poor signal of congestion Congestion is not a binary variable We want precise feedback Efficiency independent of number of flows Decouple congestion and fairness control

Design Ideas (cont.) Make the network intelligent Routers give explicit congestion feedback Controlling aggressiveness of source As delay increases rate change should be slower Explicit congestion notification (ECN) IP extension providing advance congestion notification Core-stateless fair queuing (CSFQ) Edge routers estimate incoming flow rates Use these rates to label packets

Characteristics of The Solution 1. Improved Congestion Control (in high bandwidth-delay & conventional environments): Small queues Almost no drops 2. Improved Fairness 3. Scalable (no per-flow state) 4. Flexible bandwidth allocation: min-max fairness, proportional fairness, differential bandwidth allocation,

XCP: An explicit Control Protocol 1. Congestion Controller 2. Fairness Controller

How does XCP Work? Round Trip Round Time Trip Time Congestion Congestion Window Window Feedback Feedback = + 0.1 packet Congestion Header

How does XCP Work? Round Trip Time Congestion Window Feedback = + - 0.3 0.1 packet

How does XCP Work? Congestion Window = Congestion Window + Feedback XCP extends ECN and CSFQ (Core-Stateless Fair Queueing) Routers compute feedback without any per-flow state

XCP Header H_cwnd (set to sender s current cwnd) H_rtt (set to sender s rtt estimate) H_feedback (initialized to demands) H_cwnd sender s current cong. Window H_rtt sender s current RTT estimate H_feedback Initialized by sender but modified by routers along path to directly control the congestion windows

The Players- XCP Sender Initialization steps: In first packet of flow, H_rtt is set to zero H_feedback is set to the desired window increase E.g. For desired rate r: H_feedback = ( r * rtt cwnd) / # packets in window When Acks arrive: Cwnd = max(cwnd + H_feedback, s) s => packet size

The Players- XCP Receiver When sending the ack to sender it copies the congestion header onto the packet No other difference than TCP

The Players XCP Router MIMD AIMD Computes the feedback for the host Makes decision every average RTT Operates on top of other dropping policy Efficiency controller and fairness controller

How Does an XCP Router Compute the Feedback? Congestion Controller Goal: Matches input traffic to link capacity & drains the queue Looks at aggregate traffic & queue MIMD Algorithm: Aggregate traffic changes by ~ Spare Bandwidth (diff between the input traffic rate and link capacity) ~ - Queue Size So, = d avg Spare - Queue Fairness Controller Goal: Divides between flows to converge to fairness Looks at a flow s state in Congestion Header AIMD Algorithm: If > 0 Divide equally between flows If < 0 Divide between flows proportionally to their current rates feedback in byte Average RTT

Getting the Devil out of the Details = d avg Spare - Queue Theorem: System converges to optimal utilization (i.e., stable) for any link bandwidth, delay, number of sources if: 0 Congestion Controller 4 2 0.4 and 2 No Parameter Tuning 0.226 (Proof based on Nyquist Criterion) 2 Fairness Controller Algorithm: If > 0 Divide equally between flows If < 0 Divide between flows proportionally to their current rates Need to estimate number of flows N N pkts int 1 T ( Cwnd pkt / RTT pkt ) RTT pkt : Round Trip Time in header Cwnd pkt No : Congestion Per-Flow Window State in header T: Counting Interval

Implementation Implementation uses few multiplications & additions per packet Practical! Liars? Policing agents at edges of the network or statistical monitoring Easier to detect than in TCP Gradual Deployment XCP can co-exist with TCP and can be deployed gradually

Performance: Subset of Results S 1 Bottleneck S 2 R1, R2,, Rn S n Similar behavior over:

XCP Remains Efficient as Bandwidth or Delay Increases Utilization as a function of Bandwidth Utilization as a function of Delay Bottleneck Bandwidth (Mb/s) Round Trip Delay (sec)

XCP Remains Efficient as Bandwidth or Delay Increases Utilization as a function of Bandwidth Utilization as a function of Delay XCP increases proportionally to spare bandwidth and chosen to make XCP robust to delay Bottleneck Bandwidth (Mb/s) Round Trip Delay (sec)

XCP Shows Faster Response than TCP Start 40 Flows Stop the 40 Flows Start 40 Flows Stop the 40 Flows

XCP Shows Faster Response than TCP Start 40 Flows Stop the 40 Flows Start 40 Flows Stop the 40 Flows XCP shows fast response!

XCP Deals Well with Short Web-Like Flows Arrivals of Short Flows/sec

XCP is Fairer than TCP Same RTT Different RTT Flow ID Flow ID (RTT is 40 ms 330 ms )

XCP Summary XCP Outperforms TCP Efficient for any bandwidth Efficient for any delay Scalable Benefits of Decoupling Use MIMD for congestion control which can grab/release large bandwidth quickly Use AIMD for fairness which converges to fair bandwidth allocation NS Code & More Information at: http://www.isi.edu/isi-xcp/

COMPOUND TCP: A SCALABLE AND TCP-FRIENDLY CONGESTION CONTROL FOR HIGH-SPEED NETWORKS Kun Tan, Jingmin Song, Qian Zhang, Murari Sridharan Microsoft Research Asia

Motivation The protocol design requirements for high-speed are mainly two things: Efficiency effectively utilize the high-speed link even with large delay TCP fairness be able to be progressively deployed It is easy to meet efficiency requirement, but it is difficult to be both efficient and TCP fairness

Existing Protocols Loss-based HSTCP, STCP, BIC -> aggressive Cause self-induced packet losses TCP unfairness Delay-based FAST React to RTT increase to avoid self-induced loss Not competitive to loss-based protocols How about combine these two classes together?

The Compound TCP A synergy of both delay-based approach and lossbased approach Two components A loss-based component The standard TCP Reno, provide base-line perf A scalable delay-based component Aggressively obtain bandwidth if the link is underutilized Gracefully retreat if the queue is built

Realization Two window state variables cwnd Congest window dwnd Delay window win = min(cwnd + dwnd, awnd) cwnd updated as standard Reno cwnd = cwnd + 1/win upon an ACK cwnd = cwnd / 2 upon a loss Advertised window from the receiver

Design of Delay Component Scalable The overall CTCP window evolves binomially Reduce on detecting queue on the link By sensing backlogged packets with the RTT increases React to loss efficiently Multiplicatively reducing window

Delay Window Control Calculate diff (backlogged pkts) samely as in TCP Vegas: Control functions:

Parameters Setting Set directly and Set by Comparing Aggressiveness with HSTCP k = 0.75, =1/8

Parameters Setting (cont.) Fixed Gamma value A tradeoff between efficiency and TCP fairness Auto-tuning Gamma algorithm to dynamically select gamma, based on link configuration Conditions for ineffective of gamma settings for early congestion detection Choosing gamma as

Simulation NS 2 Dumbbell topology

Results Random Link Loss(1)

Results Random Link Loss(2)

Results Various Link Speed

Testing on MS Production Network MS high-speed intranet: Tukwila -> San Francisco Speed: 1 Gbps, RTT = 30ms Light-loaded background traffic Low-buffer provision Windows implementation of CTCP

Results: Throughput

Results: TCP Fairness Fixed gamma CTCP steal more bandwidth from NewReno with the increase of flow number

Conclusion CTCP is a synergy of loss-based and delay-based approach Effectively use the high-speed link bandwidth Maintain good TCP fairness Promising to safely progressively deploy