Crimson Traffic Aware Active Queue Management

1
Crimson - Traffic Aware Active Queue Management

• Mark Claypool
• CS Department
• Worcester Polytechnic Institute
• Worcester, MA 01609
• http//www.cs.wpi.edu/claypool

2
Collaborators

• Robert Kinicki, Associate Professor
• Jae Chung, Ph.D. student
• Choong-Soo Lee, Ph.D. student
• Matt Hartling, M.S. student
• Vishal Phirke, M.S. student

3
Congestion at an Internet Router

• Incoming packets placed in outgoing queue
• Arrival rate may be larger than service rate
• ? Queue fills up
• Packets that arrive to a full queue are dropped
• ? Drop-tail

• Upon loss, responsive flows (ex TCP) will reduce
  rate
• May have many flows simultaneously reduce rate
• ? Underutilization of outgoing link
• Or, can have persistently full queues
• ? High delays from waiting in queue

4
Active Queue Management (AQM)

• Detect impending congestion at the router
• Before queue is filled
• Drop (mark) packets to signal congestion
• Avoid dropping too many packets overall
• Avoid dropping too many packets from one flow
• Potential AQM benefits
• Higher link utilization
• Lower queuing delay
• Great! So, whats the problem?

5
AQM Challenge (1)

• Wide range of traffic conditions
• Static
• Ex WPI with 45 Mbps to Sprint 622 Mbps
• Dynamic
• Wide range of offered traffic loads
• Time of day variations
• Flash crowds
• Router configuration parameters must be easy to
  set (static) and robust over load variations
  (dynamic)

6
AQM Challenge (2)

• Not all drops have equal impact
• Transport protocols respond to drops differently
• Ex TCP variants, TCP Friendly Rate Control
• (Floyd et al 2000)
• Window sizes vary (with flow lengths)
• Ex Web browsing, File transfer
• Round-trip times vary
• 10 milliseconds up to 1000 milliseconds
• Must provide scalable solution
• No per-flow state at core routers

7
AQM Challenge (3)

• Unresponsive flows
• AQM only effective if flows reduce data rate upon
  congestion notification
• TCP-Friendly rate
• At best, unresponsive flows reduce AQMs to
  drop-tail
• At worst, unresponsive flows can lead to
  congestion collapse (Floyd and Fall 1999)

8
AQM Challenge (4)

• Diverse application delay and throughput (QoS)
  requirements

9
Meeting the Challenges Crimson

• Wide range of traffic conditions
• Analysis of Active Queue Management, TR 2003
• Not all drops have equal impact
• Active Queue Management for Web Traffic, TR
  2002
• Chablis - Achieving Fair Bandwidth Allocation
  with Priority Dropping Based on Round Trip Time
  , TR 2002
• Unresponsive flows
• Diverse application QoS requirements
• Traffic Sensitive Active Queue Management for
  Improved Multimedia Streaming, QoS-IP 2003

10
Outline

• Introduction ?
• Related Work ?
• Crimson
• Evaluation
• Ongoing Work
• Conclusions

11
Related Work - AQM Support for QoS
12
Outline

• Introduction ?
• Related Work ?
• Crimson ?
• Evaluation
• Ongoing Work
• Conclusions

13
The Crimson Approach
Source provides content-aware hints
Edge monitors flow hints for cheating
Core makes per-packet decisions using rate-based
AQM
14
Source Hints

• Labels that carry information about the flow
• Examples Data rate, Protocol state
• Embedded in IP header (to avoid layer violation)
• Allow routers to differentiate between the
  contexts of flows
• Currently, Crimson uses Round-trip time, Window
  size, Delay sensitivity

15
Edge Monitoring

• Router may give favorable treatment based on
  source hint
• ?So do per-flow monitoring at edge to prevent
  cheating
• Example
• Flow i source hints of Window Size (Wi) and RTT
  (Ti)
• Edge monitors arrival rate of each flow (Ri)
• if Ri gt ((Wi x mtu) / Ti) then
• modify source hint or impose rate limit or
• Note, that Crimsons delay hint doesnt need
  monitoring!

16
Crimson Active Queue Management
Router
Congestion Controller
10 Mbps
p

(hint)

p
QoS Controller
q
(hint)


5 Mbps
q
Packet queue
10 Mbps
17
Outline

• Introduction ?
• Related Work ?
• Crimson ?
• Evaluation
• Delay Hints ?
• Ongoing Work
• Conclusions

18
Using Delay Hints An Example

• T1 link
• H.261 Videoconference

19
Using Delay Hints An Example

• T1 link
• H.261 Videoconference

20
Using Delay Hints An Example

• T1 link
• H.261 Videoconference

21
Crimsons Moving Target
(Delay Hints, in ms)
Typical AQM
Typical AQM
22
Crimsons Weighted Insert
(Starting Delay Hints, in ms)
23
Crimsons QoS AQM

• On receiving packet pkt
• target AdjustTarget(target, pkt.delay)
• if (qavg gt maxth) then
• dropPacket(pkt, 1)
• elseif (qavg gt minth) then
• p calcDropP(qavg , minth, maxth, maxp)
• p p ? (delayavg/pkt.delay)
• if (!dropPacket(pkt,p)) then
• weight arrival_time pkt.delay
• insertPacket(pkt, weight)
• Every interval seconds (from Floyd et al 2001)
• if (qavg gt target) then
• maxp ?
• elseif (qavg lt target) then
• maxp ? ?

24
QoS Evaluation Setup
NS-2 Implementation
ARED/Crimson
25
QoS Evaluation Traffic
Throughput Sensitive ?1, ? 0
Delay Sensitive ?.5, ? .5
26
QoS Evaluation Delay Sensitive Flows
Normalized QoS (QoS T 0.5/D 0.5)
27
QoS Evaluation Throughput Sensitive Flows
Normalized QoS (QoS T 1/D 0)
28
Ongoing Work

• Completion of rate-based core AQM
• Extension of core to handle unresponsive flows
• Combination of source hints
• Development of application that uses source hints

29
Conclusions

• Diversity of Internet traffic poses challenges to
  AQM
• Robustness - Context-aware drops
• QoS support - Protection
• Crimsons source-edge-core provides architecture
  to meet challenges
• Results thus far
• Improved QoS for all flows
• Improved response time for Web traffic
• Improved performance for heterogeneous flows

30
Crimson - Traffic Aware Active Queue Management

• Mark Claypool
• CS Department
• Worcester Polytechnic Institute
• Worcester, MA 01609
• http//www.cs.wpi.edu/claypool

31
Outline

• Introduction ?
• Related Work ?
• Crimson ?
• Evaluation
• Traffic QoS ?
• Web Traffic ?
• Ongoing Work
• Conclusions

32
Web Traffic

• Web pages composed of objects
• One object per TCP flow (HTTP 1.0)
• (Even with HTTP 1.1, objects across servers)
• Object sizes are small (median lt 10 Kbytes)
• ? Small TCP windows
• Small windows problematic
• Lower bandwidth
• Greater likelihood of timeout during drops
• ITO about 3 seconds, RTO about 1 second
• Greatly increases response time
• ? Send Window Size as hint

33
Crimsons Window Size AQM
minth_mod minth (maxth minth) x (1
pkt.cwnd / cwndavg) maxp_mod maxp x (maxth
minth_mod ) / (maxth minth) p maxp_mod x
(qavg minth_mod) / (maxth - minth_mod)
34
Window Size Evaluation Traffic

• Web traffic only
• Web traffic plus FTP traffic
• 10 FTP flows
• Variable number of Web flows
• Heavy-tailed object size
• pareto 1.2 shape, mean 10 kbytes
• Objects per page 1, 1-8, 1-16, 1-32
• FTP traffic only

Object Transmission Time Response Time Throughput
Performance Metrics
35
Window Size Evaluation Setup
36
Evaluation Object Transmission Time
37
Window Size Evaluation Improvement