Congestion Control for High Bandwidth Delay product Environments

1
Congestion Control for High Bandwidth Delay
product Environments
Dina Katabi , Mark Handley,Charlie Rohrs
Ajit Kulkarni Virginia Tech CS 6504 Advanced
Networking 16th October 2007
2
Forecast

• TCP inefficient in high bandwidth delay product
  networks
• Solution Develop a new protocol
• eXplicit Control Protocol - XCP
• Explicit congestion notifications from routers
• Treats efficiency and fairness differently

3
Outline

• Introduction
• Whats wrong with TCP?
• Efficiency vs Fairness
• Do it all over ? Any ideas?
• XCP- Is it better than TCP?
• XCP Performance
• Other issues with XCP

4
Trends in Future Internet

• Links
• High Bandwidth
• Gigabit Links optical fibers
• High Latency
• Satellite links
• Wireless links
• The Bandwidth delay products will increase

5
Whats wrong with TCP?

• Unstable
• Becomes oscillatory as delay bandwidth product
  increases
• Inefficient
• Transfer delay doesnt improve as link capacity
  increases
• Additive increase of 1pkt/RTT is too slow
• Unfair
• Biased against long RTT flows

6
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

7
Decoupling Efficiency and Fairness

• Both AIMD in TCP
• Control theory suggests they should be
  independent
• Use different control laws
• Efficiency -gt MIMD -gt fast response
• Fairness -gt AIMD -gt converges to fairness
• Flexible
• Can be modified independently

8
Lets 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

9
Design Ideas contd.

• 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

10
And finally XCP

• eXplicit Control Protocol
• Window based congestion control
• Active congestion notification
• Separate XCP header attached to packet

11
How does XCP work?
Feedback 0.1 packet
Slide modified from www.ana.lcs.mit.edu/dina/XCP/S
igcomm2002.ppt
12
How does XCP Work?
Feedback - 0.3 packet
Slide modified from www.ana.lcs.mit.edu/dina/XCP/S
igcomm2002.ppt
13
How does XCP Work?
Congestion Window Congestion Window Feedback
XCP extends ECN and CSFQ
Routers compute feedback without any per-flow
state
Slide modified from www.ana.lcs.mit.edu/dina/XCP/S
igcomm2002.ppt
14
XCP Header
H_ewnd (set to senders current cwnd)
H_rtt (set to senders rtt estimate)
H_feedback (initialized to demands)

• H_cwnd senders current cong. Window
• H_rtt senders current RTT estimate
• H_feedback Initialized by sender but modified
  by routers along path to directly control the
  congestion windows

15
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 gt packet size

16
The Players- XCP Receiver

• When sending the ack to sender it copies the
  congestion header onto the packet
• No other difference than TCP

17
The Players XCP Router
Efficiency Controller
Fairness Controller
Packet flow
New H_feedback

• Computes the feedback for the host
• Makes decision every average RTT
• Operates on top of other dropping policy
• Efficiency controller and fairness controller

18
Efficiency Controller

• Purpose
• Match input traffic to link capacity and drain
  the queue
• Maximize link utilzn. minimize drop rate and
  persistent queues
• Looks at aggregate traffic and queue
• Does not care about fairness
• Algorithm
• Aggregate traffic changes by ?
• ? ? spare bandwidth and ? ? queue size
• ? ? d S - ? Q
• ?, ? constant, d average RTT, Sgtspare bandwidth,
  Qgt persistent queue size

19
Fairness Controller

• Purpose
• Divides ? between flows to converge to fairness
• Looks at flows state in congestion header
• Algorithm
• Convergence to min-max fairness (? ! 0)
• If ? gt0 gt divide ? equally between flows
• If ? lt0 gt divide ? proportional to current flow
  rates
• Bandwidth shuffling (? 0)
• h max(0, ??y-?)
• ? constant 0.1, y input traffic
• At least 10 of traffic is redistributed using
  AIMD

20
The theory behind them

• Efficiency controller
• System converges to optimal utilizn. for any link
  bandwidth, delay and no. of sources if
• 0 lt ? lt p/4?2 and ? ? exp2 ?2
• No parameter tuning required
• Fairness controller
• Need to estimate number of flows N
• N ? (1/(T (cwnd /RTT))) for every packet
• No per flow state maintained

21
Computing per packet feedback

• H_feedback pi ni
• pi gt positive feedback

• ni gt negative feedback

22
XCP Performance
23
The Setup
ns2 simulation Link capacity -gt 1.5Mb/s to
4Gb/s Delay -gt10ms to 1.4s Source -gt1 to 1000 and
2 way traffic 2 topologies-gtsingle bottleneck
-gtparking lot
24
Active Queue Management

• Algorithms -gt identify packets to drop or mark -gt
  AQM schemes
• Random Early Discard/Detection (RED) drops
  packets with probability according to its average
  queue length
• Random Early/Exponential Marking (REM) marks
  packets with probability according to its queue
  length and the marks will be carried back by ACKs
• Adaptive Virtual Queue (AVQ) computes virtual
  capacity used by the router to drop or mark a
  real packet depending on congestion notification
• Core Stateless Fair Queuing (CSFQ) Core routers
  do not need to perform per flow management,
  instead, edge routers do the flow classification

Sourcewww.cs.rice.edu/animesh/comp620/presentati
ons/KHR02_D.ppt
25
XCP Efficiency vs Bandwidth or Delay
Utilization as a function of Delay
Utilization as a function of Bandwidth
Avg. Utilization
Avg. Utilization
Bottleneck Bandwidth (Mb/s)
Round Trip Delay (sec)
Source www.ana.lcs.mit.edu/dina/XCP/Sigcomm2002.p
pt
26
XCP Efficiency vs Bandwidth or Delay
Utilization as a function of Bandwidth
Utilization as a function of Delay
Avg. Utilization
Avg. Utilization
Bottleneck Bandwidth (Mb/s)
Round Trip Delay (sec)
Source www.ana.lcs.mit.edu/dina/XCP/Sigcomm2002.p
pt
27
XCP - Faster Response than TCP
Source www.ana.lcs.mit.edu/dina/XCP/Sigcomm2002.p
pt
28
XCP Deals Well with Short Web-Like Flows
Average Utilization
Average Queue
Drops
Source www.ana.lcs.mit.edu/dina/XCP/Sigcomm2002.p
pt
29
XCP is Fairer than TCP
Same RTT
Different RTT
Avg. Throughput
Avg. Throughput
Flow ID
Flow ID
Source www.ana.lcs.mit.edu/dina/XCP/Sigcomm2002.p
pt
30
Performance Summary

• Efficient for any bandwidth and any delay
• Scalable
• Almost no packet drop
• High utilization-gt close to bottleneck bandwidth
• Fast converging to fair bandwidth and optimal
  utilization
• Very fair among flows

31
Summary XCP Features

• MIMD -gt Fast response -gt high utilization
• AIMD -gt Fairness-gt converges faster than TCP
• Per flow state not maintained in routers
• Router performs few additions and multiplications
  per packet
• Change fairness controller to provide
  differential bandwidth services
• Distinguish error and congestion losses
• Detects misbehaving sources

32
Differential Bandwidth Allocation

• Supports QoS schemes addressing bandwidth
  allocation
• Replace AIMD policy of fairness controller
• Flows throughputs converge to different bandwidth
  allocation
• e.g. Users get bandwidth in proportion to the
  price they pay, decided by fairness controller

33
Security

• Policing agents at network edges
• Monitor flow behavior
• Detect network attacks ,unresponsive sources
• Explicit feedback helps in detecting misbehaving
  sources faster
• Explicitly specifying RTT makes monitoring easier
• Testing a flow
• Send test feedback requiring flow to decrease
  window
• Flow doesnt respond in single RTT -gt Unresponsive

34
XCP Deployment

• XCP based CSFQ
• Map TCP or UDP into XCP flow across a network
  cloud
• Mapping to XCP done at enter an exit routers to
  cloud
• TCP friendly XCP
• Routers have 2 queues for TCP and XCP traffic
• Average throughput of XCP flows average
  throughput of TCP flows, independent of number of
  flows
• Use weighted fair queuing with 2 queues and
  updating weights dynamically

35
My Opinion

• Strengths
• Finally a protocol that uses the routers as
  congestion is not an end to end issue
• Exhaustive performance analysis to validate
  protocol and its deployment
• Advantages of differential bandwidth, security
  gained though not part of initial goal
• Weaknesses
• Bandwidth shuffling may cause disturbance which
  can reduce utilization
• estimation errors-gtTradeoff between efficiency
  and time to converge to fairness
• Requires per packet computations -gt Scalability?
• Makes short flows last 2 orders of magnitude,
  longer worse than TCP
• (srchttp//100x100network.org/presentations/c
  ongestioncontrol-whytcpisapoorchoice-nan
  ditad.pdf)
• What can be done differently
• Lets send the explicit congestion information in
  TCP options field
• No separate header backward compatibility
  achieved

36
Conclusions

• Has explicit congestion feedback from routers
• Decouples fairness and congestion control
• Handles high bandwidth delay product links
• Does not maintain per flow state
• Has virtually zero drops

37
Further work

• Cited 339 times
• Future research on XCP deployment
• XCP_at_ISI -gt project to implement and deploy XCP-gt
  supported by NSF

38
Questions

• Thank You