Software Defined Active Queue Management

Universität Stuttgart

Institute of Communication Networks and Computer Engineering (IKR)

Software Defined

Active Queue Management

Future Networks 2014

Sebastian Meier

[email protected] 2014-09-26

Outline

Motivation

Queuing and queue management

Queue management with southbound interfaces today

Proposed programming model

Dataflow approach Building blocks

Motivation

Active Queue Management (AQM)

• 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

Motivation

Active Queue Management (AQM)

• 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

1993 2013/14

RED BLUE, RIO, CHOKe, ... (~100 more) PIE, CoDel, ...

Dr o p P rob ab ility 0 1 MinThres MaxThres Average Queue Length P_max

Motivation

Software Defined Networking

• open APIs abstracting infrastructure • configure packet forwarding

• neglect packet queuing & scheduling

→ potential of SDN not fully exploited

Our goal

Device independent, adaptive control of queuing and scheduling • instantiation, combination and parameterization

• programmability of AQM components and algorithms

Network Operating System / Network Controller(s) Northbound Interface

Southbound Interface

(OpenFlow, ForCES, I2RS)

Path

Computation DiscoveryTopology ... EnforcementQoS

Data Plane Control Plane

Forwarding Data Plane Device

Port Port Port

Forwarding Data Plane Device

Port Port Port Queuing

Motivation

Software Defined Networking

• open APIs abstracting infrastructure • configure packet forwarding

• neglect packet queuing & scheduling

→ potential of SDN not fully exploited

Our goal

Device independent, adaptive control of queuing and scheduling • instantiation, combination and parameterization

• programmability of AQM components and algorithms

Network Operating System / Network Controller(s) Northbound Interface

Southbound Interface

(OpenFlow, ForCES, I2RS)

Path

Computation DiscoveryTopology ... EnforcementQoS

Data Plane Control Plane

Forwarding Data Plane Device

Port Port Port

Forwarding Data Plane Device

Port Port Port Queuing

Motivation

Software Defined Networking

• open APIs abstracting infrastructure • configure packet forwarding

• neglect packet queuing & scheduling

→ potential of SDN not fully exploited

Our goal

Device independent, adaptive control of queuing and scheduling • instantiation, combination and parameterization

• programmability of AQM components and algorithms

Network Operating System / Network Controller(s) Northbound Interface

Southbound Interface

(OpenFlow, ForCES, I2RS)

Path

Computation DiscoveryTopology ... EnforcementQoS

Data Plane Control Plane

Forwarding Data Plane Device

Port Port Port

Forwarding Data Plane Device

Port Port Port Queuing

Classifier Queues Scheduler

Buffer MAX=1000 Dropper P = use=3 use MAX D LINRED

Towards Software Defined AQM

AQM in data plane today

• limited choice of black box implementations/algorithms • new features via software/firmware upgrade

Vision

• transition from black box towards white box approach • fully programmable queuing and scheduling behavior

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

RED

Software Defined AQM

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

Relevant practices

• modeling and design of AQM algorithms

• programmability of packet processing in hardware

a b c Programmable Hardware AQM Algorithm Implementation programming model? Latency Based Drop Probability Calculation

+

Software Defined AQM

Towards suitable programming model

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

Source: R. Pan, et al. "PIE: A Lightweight Control Scheme to Address the Bufferbloat Problem"

∫ Queuelength monitor Output Queue Smoother Control Law Variable Attenuator (packet dropper)

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

Digital Logic Design Dataflow oriented

AQM Design Dataflow oriented

Implementation procedural

Software Defined AQM

Dataflow Programming Model

• 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

Software Defined AQM

Dataflow Programming Model

• 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

Software Defined AQM

Dataflow Programming Model

• 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

Software Defined AQM

Dataflow Programming Model

• 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

+

->

CMP removeElement isEmpty addEvent removeEvent addElement fillLevel isRejecting capacity remainingCapacity

Software Defined AQM

Dataflow Programming Model

• 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

Add Metadata

meta p_in

pout push pop Strip

Metadata hi->lo ref valCMP Time Reference ts p_in meta pout o i -5ms Deterministic Dropper p_in pout doDrop Periodic Timer

start stop expired

drop control

lo->hi current time current time

packet +TS packet TS packet delay high delay low delay sustained high delay goodQ. badQ. packet packet doDrop period packet +TS interval doDrop drop interval

Software Defined AQM

Current State

• dataflow programming model

– token capacity of interconnections – execution model

– token pushing vs. pulling

• overall architecture

– integration with controller

– interface for instantiation and parameterization

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

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

State of the art

OpenFlow

• 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

Queue ate ate ength Port ogical h

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

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

! " # # $ % $ & ' ( ) *) * + , * -*. ( ) *) * / 0 . 12 2 *. Sc 3 edu ler source: RFC 5812

Register Transfer Level