February 7, 2003BU Computer Science Colloquium Crimson - Traffic Aware Active Queue Management Mark Claypool CS Department Worcester Polytechnic Institute Worcester, MA

February 7, 2003BU Computer Science Colloquium 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

February 7, 2003BU Computer Science Colloquium 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 Routing Table Packet queue 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

February 7, 2003BU Computer Science Colloquium 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?”

February 7, 2003BU Computer Science Colloquium 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)

February 7, 2003BU Computer Science Colloquium 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

February 7, 2003BU Computer Science Colloquium 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)

February 7, 2003BU Computer Science Colloquium AQM Challenge (4) Diverse application delay and throughput (QoS) requirements Delay Sensitivity Throughput Sensitivity FTP, Web Browsing Interactive Multimedia (Large queues) (Medium queues) (Small queues)

February 7, 2003BU Computer Science Colloquium Meeting the Challenges: Crimson 1)Wide range of traffic conditions “Analysis of Active Queue Management”, TR )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 )Unresponsive flows 4)Diverse application QoS requirements “ Traffic Sensitive Active Queue Management for Improved Multimedia Streaming”, QoS-IP 2003

February 7, 2003BU Computer Science Colloquium Outline Introduction  Related Work  Crimson Evaluation Ongoing Work Conclusions

February 7, 2003BU Computer Science Colloquium Related Work - AQM Support for QoS

February 7, 2003BU Computer Science Colloquium Outline Introduction  Related Work  Crimson  Evaluation Ongoing Work Conclusions

February 7, 2003BU Computer Science Colloquium The Crimson Approach Source Edge Core Edge Core Source provides content-aware “hints” Edge monitors flow hints for cheating Core makes per-packet decisions using rate-based AQM

February 7, 2003BU Computer Science Colloquium 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

February 7, 2003BU Computer Science Colloquium 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 ( W i ) and RTT ( T i ) –Edge monitors arrival rate of each flow ( R i ) –if R i > ((W i x mtu) / T i ) then modify source hint or impose rate limit or … Note, that Crimson’s delay hint doesn’t need monitoring!

February 7, 2003BU Computer Science Colloquium Crimson Active Queue Management Congestion Controller Packet queue 10 Mbps 5 Mbps p p’ Router = QoS Controller (hint) q + q’ = + q + Rate +

February 7, 2003BU Computer Science Colloquium Outline Introduction  Related Work  Crimson  Evaluation –Delay Hints  Ongoing Work Conclusions

February 7, 2003BU Computer Science Colloquium Using Delay Hints – An Example T1 link H.261 Videoconference

February 7, 2003BU Computer Science Colloquium Using Delay Hints – An Example T1 link H.261 Videoconference

February 7, 2003BU Computer Science Colloquium Using Delay Hints – An Example T1 link H.261 Videoconference

February 7, 2003BU Computer Science Colloquium Target Queue Typical AQM FTPMM 8032 Crimson’s Moving Target Typical AQM Typical AQM (Delay Hints, in ms)

February 7, 2003BU Computer Science Colloquium Average Queue Crimson’s Weighted Insert FTPMM 8032 t0t weight = arrival_time + pkt.delay p’ = p  (delay avg /pkt.delay) (Starting Delay Hints, in ms)

February 7, 2003BU Computer Science Colloquium Crimson’s QoS AQM On receiving packet pkt: target = AdjustTarget(target, pkt.delay) if (q avg >= max th ) then dropPacket(pkt, 1) elseif (q avg >= min th ) then p = calcDropP(q avg, min th, max th, max p ) p’ = p  (delay avg /pkt.delay) if (!dropPacket(pkt,p’)) then weight = arrival_time + pkt.delay insertPacket(pkt, weight) Every interval seconds: (from Floyd et al 2001) if (q avg > target) then max p +=  elseif (q avg < target) then max p  = 

February 7, 2003BU Computer Science Colloquium QoS Evaluation Setup NS-2 Implementation ARED/Crimson

February 7, 2003BU Computer Science Colloquium QoS Evaluation Traffic Throughput Sensitive  =1,  = 0 Delay Sensitive  =.5,  =.5 QoS = T  / D  T is Throughput D is Delay  +  = 1 Performance Metric

February 7, 2003BU Computer Science Colloquium Normalized QoS (QoS = T 0.5 /D 0.5 ) QoS Evaluation: Delay Sensitive Flows Crimson ARED Std. dev

February 7, 2003BU Computer Science Colloquium QoS Evaluation: Throughput Sensitive Flows Normalized QoS (QoS = T 1 /D 0 ) Crimson ARED Std. dev

February 7, 2003BU Computer Science Colloquium 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

February 7, 2003BU Computer Science Colloquium 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

February 7, 2003BU Computer Science Colloquium Crimson - Traffic Aware Active Queue Management Mark Claypool CS Department Worcester Polytechnic Institute Worcester, MA

February 7, 2003BU Computer Science Colloquium Outline Introduction  Related Work  Crimson  Evaluation –Traffic QoS  –Web Traffic  Ongoing Work Conclusions

February 7, 2003BU Computer Science Colloquium 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

February 7, 2003BU Computer Science Colloquium Crimson’s Window Size AQM min th_mod = min th + (max th – min th ) x (1 – pkt.cwnd / cwnd avg ) max p_mod = max p x (max th – min th_mod ) / (max th – min th ) p’ = max p_mod x (q avg – min th_mod ) / (max th - min th_mod )

February 7, 2003BU Computer Science Colloquium 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

February 7, 2003BU Computer Science Colloquium Window Size Evaluation Setup

February 7, 2003BU Computer Science Colloquium Evaluation: Object Transmission Time

February 7, 2003BU Computer Science Colloquium Window Size Evaluation: Improvement