February 7, 2003BU Computer Science Colloquium Crimson - Traffic Aware Active Queue Management Mark...

February 7, 2003 BU Computer Science Colloquium

Crimson - Traffic Aware Active Queue Management

Mark Claypool

CS DepartmentWorcester Polytechnic Institute

Worcester, MA 01609

http://www.cs.wpi.edu/~claypool


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


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

Router

RoutingTable

Packetqueue

10 Mbps

10 Mbps

5 Mbps

• 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


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, what’s the problem?”


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)


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


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)


AQM Challenge (4)

•Diverse application delay and throughput (QoS) requirements

Delay Sensitivity

Th

roughput

Sensi

tivit

y

FTP, E-mail

Web Browsing

Interactive Multimedia

(Large queues)

(Medium queues)

(Small queues)


Meeting the Challenges: Crimson

1) Wide range of traffic conditions• “Analysis of Active Queue Management”, TR 2003

2) 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

3) Unresponsive flows4) Diverse application QoS requirements

• “Traffic Sensitive Active Queue Management for Improved Multimedia Streaming”, QoS-IP 2003


Outline

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


Related Work - AQM Support for QoS


Outline

•Introduction •Related Work

•Crimson •Evaluation •Ongoing Work •Conclusions


The Crimson ApproachSource

Source EdgeCore

EdgeCore

Source provides content-aware “hints”

Edge monitors flow hints for cheating

Core makes per-packet decisionsusing rate-based AQM


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


Edge Monitoring

• Router may give favorable treatment based on source hintSo 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 > ((Wi x mtu) / Ti) then

modify source hint or impose rate limit or …

• Note, that Crimson’s delay hint doesn’t need monitoring!


Crimson Active Queue Management

Congestion Controller

Packet queue

10 Mbps

10 Mbps

5 Mbps

p

p’

Router

=QoS

Controller

(hint)

q(hint) +

q’

=

+ q+Rate

+


Outline


•Crimson •Evaluation

– Delay Hints •Ongoing Work •Conclusions


Using Delay Hints – An Example

• T1 link• H.261 Videoconference


Target Queue

Target Queue

Target Queue

8032

8080808080803280

Typical AQM

FTP MM

80 32

Crimson’s Moving Target

8080

3280328032328032

Typical AQM 32

32

3232803232328032

Typical AQM

(Delay Hints, in ms)


7880

757060554032159

32159

Average Queue

Crimson’s Weighted Insert

FTP MM

80 32

32t0

32

80

7578

70605540

80

7578

7060554032 weight = arrival_time + pkt.delay

p’ = p (delayavg/pkt.delay)

(StartingDelay Hints,

in ms)


Crimson’s QoS AQM• On receiving packet pkt:

target = AdjustTarget(target, pkt.delay)if (qavg >= maxth) then

dropPacket(pkt, 1)

elseif (qavg >= minth) thenp = calcDropP(qavg , minth, maxth, maxp)

p’ = p (delayavg/pkt.delay)

if (!dropPacket(pkt,p’)) thenweight = arrival_time + pkt.delayinsertPacket(pkt, weight)

• Every interval seconds: (from Floyd et al 2001)if (qavg > target) then

maxp += elseif (qavg < target) then

maxp =


S2

QoS Evaluation Setup

NS-2 Implementation

ARED/Crimson


QoS Evaluation Traffic

Throughput Sensitive=1, = 0

Delay Sensitive=.5, = .5

QoS = T / D

T is ThroughputD is Delay + = 1

PerformanceMetric


Nor

mal

ized

Q

oS(Q

oS=

)

T 0

.5

D0.

5N

orm

aliz

ed Q

oS

(Q

oS =

T 0.

5 /D

0.5 )

QoS Evaluation: Delay Sensitive Flows

CrimsonARED

Std. dev


QoS Evaluation: Throughput Sensitive Flows

Norm

aliz

ed Q

oS

(Q

oS =

T 1 /

D 0 )

CrimsonARED

Std. dev


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


Conclusions

•Diversity of Internet traffic poses challenges to AQM– Robustness - Context-aware

drops– QoS support - Protection

•Crimson’s 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


Crimson - Traffic Aware Active Queue Management

Mark Claypool

CS DepartmentWorcester Polytechnic Institute

Worcester, MA 01609

http://www.cs.wpi.edu/~claypool


Outline


•Crimson •Evaluation

– Traffic QoS – Web Traffic

•Ongoing Work •Conclusions


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


Crimson’s 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)


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 TimeResponse Time

Throughput

PerformanceMetrics


Window Size Evaluation Setup


Evaluation: Object Transmission Time


Window Size Evaluation: Improvement

February 7, 2003BU Computer Science Colloquium Crimson - Traffic Aware Active Queue Management Mark...

Documents

Transcript of February 7, 2003BU Computer Science Colloquium Crimson - Traffic Aware Active Queue Management Mark...