Software Defined Active Queue Management

Software Defined Active Queue Management Future Networks 2014 Sebastian Meier sebastian.meier@ikr.uni-stuttgart.de 2014-09-26 Universität Stuttgart Institute of Communication Networks and Computer Engineering (IKR) Prof. Dr.-Ing. Andreas Kirstädter

Outline Motivation Queuing and queue management Queue management with southbound interfaces today Proposed programming model Dataflow approach Building blocks Conclusion & future work 2

Motivation Active Queue Management (AQM) Queuing in packet switched networks necessary when outbound interface busy typically relevant at bottlenecks interacts with end host control loops (TCP) is desirable compensate short packet bursts keep link utilization high can introduce undesired effects packet delay ("buffer bloat") burst packet loss (e.g. due to TCP global synchronization) queue management has huge impact on Quality of Service (QoS) AQM approach Improve QoS by sophisticated queue management, e.g. packet classification, queuing discipline behavior, scheduling Classifier Queues Scheduler 3

Motivation Active Queue Management (AQM) Algorithms RED BLUE, RIO, CHOKe,... (~100 more) PIE, CoDel,... 1993 2013/14 initially just targeted at breaking TCP synchronization later many scenario specific solutions today mainly targeting low delay Deployment until ~2 years no interest beyond RED recently manufacturers push to deploy PIE (Cisco) and CoDel (ALU) operators deploy low delay variants at network edge, see DOCSIS Increasing interest in influencing data plane queuing behavior Software Defined AQM Adapt queuing to changing traffic and requirements Drop Probability 1 P max 0 MinThres MaxThres Average Queue Length 4

Motivation Software Defined Networking Southbound interfaces today open APIs abstracting infrastructure configure packet forwarding neglect packet queuing & scheduling potential of SDN not fully exploited Network Operating System / Network Controller(s) Path Computation Control Plane Data Plane Topology Discovery... Northbound Interface QoS Enforcement Southbound Interface (OpenFlow, ForCES, I2RS) Our goal Device independent, adaptive control of queuing and scheduling instantiation, combination and parameterization programmability of AQM components and algorithms Data Plane Device Forwarding Data Plane Device Forwarding Queuing Port Port Port Port Port Port 5

Motivation Software Defined Networking Southbound interfaces today open APIs abstracting infrastructure configure packet forwarding neglect packet queuing & scheduling potential of SDN not fully exploited Network Operating System / Network Controller(s) Path Computation Control Plane Data Plane Topology Discovery... Northbound Interface QoS Enforcement Southbound Interface (OpenFlow, ForCES, I2RS) Our goal Device independent, adaptive control of queuing and scheduling instantiation, combination and parameterization programmability of AQM components and algorithms Data Plane Device Forwarding Data Plane Device Forwarding Queuing Port Port Port Port Port Port Classifier Queues Scheduler 6

Motivation Software Defined Networking Southbound interfaces today open APIs abstracting infrastructure configure packet forwarding neglect packet queuing & scheduling potential of SDN not fully exploited Northbound Interface Network Operating System / Network Controller(s) Path Computation Control Plane Data Plane Topology Discovery... QoS Enforcement Southbound Interface (OpenFlow, ForCES, I2RS) Our goal Device independent, adaptive control of queuing and scheduling instantiation, combination and parameterization programmability of AQM components and algorithms Data Plane Device Forwarding Data Plane Device Forwarding LINRED Dropper Buffer Port Port Port Port Port Queuing Port Classifier Queues Scheduler use P = D MAX MAX=1000 use=3 7

Towards Software Defined AQM AQM in data plane today limited choice of black box implementations/algorithms new features via software/firmware upgrade RED Vision transition from black box towards white box approach fully programmable queuing and scheduling behavior PINK Dropper use P = D MAX Buffer MAX=1000 use=3 Approach fine grained control of AQM using elementary, device independent building blocks standardized interface for building blocks instantiation and parameterization modeling approach aligned with hardware design patterns Advantages define AQM once in device independent description adapt AQM dynamically during runtime 8

Software Defined AQM Towards suitable programming model Programming Model special purpose language for implementing AQM mechanisms abstraction layer for programmable hardware Modeling challenges suitable programming model(s) for structural description (interfaces and interconnections) defining behavior (internal processing) reasonable level of abstraction for building blocks AQM Algorithm Implementation programming model? Programmable Hardware b a c + Latency Based Drop Probability Calculation Relevant practices modeling and design of AQM algorithms programmability of packet processing in hardware 9

Software Defined AQM Towards suitable programming model Modeling of AQM algorithms typically block diagrams on high level equations, formulae and rules for refinement emphasis on information flow (e.g. packets, input values, results,...) event based/reactive perspective (e.g. packet arrival, queue fill level change) Variable Attenuator (packet dropper) Output Queue Control Law Smoother Queue length monitor Source: V. Jacobson, et al. "RED in a Different Light" Source: R. Pan, et al. "PIE: A Lightweight Control Scheme to Address the Bufferbloat Problem" 10

Software Defined AQM Towards suitable programming model High performance packet processing in hardware traditionally ASICs (not programmable) recently programmable FPGAs (e.g. Juniper MS-PIC) programmable network processors (e.g. CISCO npower X1) not directly programmable (e.g. using VHDL) programmable via vendor specific frameworks (e.g. Junos SDK) typically procedural implementation Observation AQM and digital logic design: reactive, concurrent, dataflow oriented different programming model for implementation potentially obstructs algorithm (focus on sequence of procedures, not data flow) source for inefficiencies and errors (no implicit concurrency) more suitable programming model for AQM algorithms desirable AQM Design Dataflow oriented Implementation procedural Digital Logic Design Dataflow oriented 11

Software Defined AQM Dataflow Programming Model Dataflow programming declarative programming paradigm first languages in 1966, MIT Concepts self-contained functional blocks ports for reading and writing of data scheduled, as soon as all inputs have input data (reactive behavior) exchange of data via lightweight message passing (tokens) no locking interconnection of blocks specified separately no "A <has> B" relations Token 12

Software Defined AQM Dataflow Programming Model Dataflow programming declarative programming paradigm first languages in 1966, MIT Concepts self-contained functional blocks ports for reading and writing of data scheduled, as soon as all inputs have input data (reactive behavior) exchange of data via lightweight message passing (tokens) no locking interconnection of blocks specified separately no "A <has> B" relations 13

Software Defined AQM Dataflow Programming Model Advantages implementation approach closely resembles AQM design approach digital logic design on register-transfer level reactive approach fits queuing behavior (reaction on packet enqueue, dequeue) loose coupling facilitates component oriented modeling encourages design of reusable functional blocks potential for hardware optimizations for common functional blocks inherently parallel, supports pipelining Drawbacks non-deterministic execution (in absence of fixed schedule) debugging challenging due to parallelism 14

Software Defined AQM Dataflow Programming Model Level of abstraction very fine grained modeling may be cumbersome and confusing coarse grained modeling may limit reusability + - > Current approach model functions commonly utilized in AQM as blocks, e.g. buffer, dropper, time reference & timer, RNG, moving average, threshold observer increase reusability by making components configurable capacity removeelement isempty - #consecutive samples - hold off time addelement isrejecting addevent removeevent filllevel remainingcapacity ref val CMP above below lo->hi hi->lo 15

Software Defined AQM Dataflow Programming Model Example CoDel algorithm (simplified) algorithm modeled with < 10 elementary building blocks only one simple customized building block: drop control Good Queue: count = 1, interval => 100 Bad Queue: count++, interval => 100 / sqrt(count), dodrop => 1 packet current time Time Reference ts meta p packet in Add pout push pop Metadata +TS current time packet +TS TS i o meta p Strip in p Metadata out - packet delay 5ms ref val CMP lo->hi hi->lo high delay period Periodic Timer start stop expired packet low delay drop interval sustained high delay badq. interval drop goodq. control dodrop dodrop p dodrop in Deterministic packet Dropper p out 16

Software Defined AQM Current State Ongoing research dataflow programming model token capacity of interconnections execution model token pushing vs. pulling overall architecture integration with controller interface for instantiation and parameterization Token Implementation Java implementation for proof of concept & functional evaluation ForkJoin scheduler for lightweight block scheduling unsuitable for performance evaluation (user space packet processing) Intel DPDK (Data Plane Development Kit) implementation work in progress, no performance measurements yet hardware implementation future work 17

Conclusion & Future Work Conclusion AQM has huge impact on QoS limited support for controlling queuing behavior in today s southbound interfaces control interface for adaptive operation needed proposing dataflow programming model for software defined AQM Future work refinement of programming model performance evaluation and comparison with Linux queuing framework control protocol development signaling towards data plane device feedback from data plane to control plane 18

Bonus Slides 19

State of the art OpenFlow Queuing model OF-Config associate ports, queues with logical switch set minimum and maximum data rate of queue OpenFlow flow based rate limiting with meter bands flow based output queue assignment Evaluation QoS and queuing focused on rate limiting instantiation of ports and queues out of scope model is incomplete, lacks information regarding queue properties discipline, feedback strategy,... scheduling queue priorities, scheduling algorithm,... Current OpenFlow protocols insufficient for queue management ogical h Port Queue ate ength ate 20

-*. State of the art ForCES Queuing model device capabilities modeled by coarse-grained Logical Functional Blocks (LFBs) well-defined interfaces for LFB interaction and configuration (e.g. queue depth) can model hardware restrictions (e.g. #max instances/element, LFB order) does not provide many details about LFB internals ()*)* /0.122*. 3 ()*)* +,* &' $%$ ##"! eduler Sc source: RFC 5812 Evaluation good approach for black box modeling of AQM configuration no detailed specifications for queuing related LFBs (except RR scheduler) ForCES LFB abstraction level too coarse grained for our purpose 21

Register Transfer Level R1 E1 R0 E0 #0 #0 S3,S2 S1,S0 C out X Y M0 + / C in AC 22