Network Support for QoS – DiffServ and IntServ Hongli Luo CEIT, IPFW

Topics r Providing Multiple Classes of Service m DiffServ r Providing QoS guarantees m InteServ and RSVP

Providing Multiple Classes of Service r thus far: making the best of best effort service m one-size fits all service model r alternative: multiple classes of service m partition traffic into classes m network treats different classes of traffic differently (analogy: VIP service vs regular service) 0111 r granularity: differential service among multiple classes, not among individual connections r history: (Type-of-service) ToS bits in IPv4 header

Multiple classes of service: scenario R1 R2 H1 H2 H3 H4 1.5 Mbps link R1 output interface queue

Scenario 1: mixed FTP and audio r Example: 1Mbps IP phone, FTP share 1.5 Mbps link. m bursts of FTP can congest router, cause audio loss m want to give priority to audio over FTP packet marking (packet classification) needed for router to distinguish between different classes; and new router policy to treat packets accordingly Principle 1 R1 R2

Principles for QOS Guarantees (more) r what if applications misbehave (audio sends higher than declared rate) m policing: force source adherence to bandwidth allocations r marking and policing at network edge: provide protection (isolation) for one class from others Principle 2 R1 R2 1.5 Mbps link 1 Mbps phone packet marking and policing

Principles for QOS Guarantees (more) r Isolation m Isolation among classes of traffic m Isolation among flows within the same traffic class to protect one flow from another flow. r In practice m Packets within a class are treated the same at routers within the network core m At the edge of the network, packets within a given flow may be monitored to ensure that the aggregate rate of an individual flow does not exceed a given value r It is desirable to provide an isolation among traffic classes and among flows m One class or flow is not adversely affected by misbehaving flow

Principles for QOS Guarantees (more) r Allocating fixed (non-sharable) bandwidth to flow: inefficient use of bandwidth if flows doesn’t use its allocation While providing isolation, it is desirable to use resources as efficiently as possible Principle 3 R1 R2 1.5 Mbps link 1 Mbps phone 1 Mbps logical link 0.5 Mbps logical link

Principles for QOS Guarantees (more) r To provide isolation among traffic classes or flows m Policing Ensure that a traffic class or flow meet certain criteria For misbehaving application, policing mechanism takes actions (drop or delay packets) to make sure the traffic actually entering the network conforms to the criteria Packet classification, marking, and policing can be located at the edge of the network –In the end system or at an edge router leaky bucket m Link-level packet-scheduling Explicitly allocate a fixed amount of link bandwidth to each class or flow

Scheduling And Policing Mechanisms r scheduling: choose next packet to send on link r FIFO (first in first out) scheduling: send in order of arrival to queue m discard policy: if packet arrives to full queue: who to discard? Tail drop: drop arriving packet priority: drop/remove on priority basis random: drop/remove randomly

Scheduling Policies: more Priority scheduling: transmit highest priority queued packet r multiple classes, with different priorities m class may depend on marking or other header info, e.g. IP source/dest, port numbers, etc.. m Each priority class has its own queue

Scheduling Policies: still more round robin scheduling: r multiple classes, alternates service among classes r cyclically scan class queues, serving one from each class (if available)

Scheduling Policies: still more Weighted Fair Queuing: r generalized Round Robin r each class gets weighted amount of service in each cycle r Plays a central role in QoS architecture. r Available in today’s router products. r Class i receives a throughput

Policing Mechanisms Policing : regulation of the rate at which a class or a flow is allowed to inject packets into the network Goal: limit traffic to not exceed declared parameters Three common-used criteria: r (Long term) Average Rate: how many pkts can be sent per unit time (in the long run) m crucial question: what is the interval length: 100 packets per sec or 6000 packets per min have same average! r Peak Rate: e.g., 6000 pkts per min. (ppm) avg.; 1500 pkts per second peak rate r (Max.) Burst Size: max. number of pkts sent consecutively over an extremely short interval of time (with no intervening idle)

Policing Mechanisms Token Bucket: limit input to specified Burst Size and Average Rate. r Before a packet is transmitted into the network, it must first remove a token from the token bucket. r bucket can hold b tokens r tokens generated at rate r token/sec unless bucket full r Maximum burst size for a leaky-bucket-policed flow is b packets r over interval of length t: number of packets admitted less than or equal to (r t + b). r limits the long-term average rate at which packets can enter the network

Policing Mechanisms (more) r token bucket, WFQ combine to provide guaranteed upper bound on delay, i.e., QoS guarantee! WFQ token rate, r bucket size, b per-flow rate, R D = b/R max arriving traffic

IETF Differentiated Services r Goal: provide service differentiation in a scalable and flexible manner. r scalability: simple functions in network core, relatively complex functions at edge routers (or hosts) m signaling, maintaining per-flow router state difficult with large number of flows r Flexibility: m Does not define specific service or service classes, m provide functional components to build service classes

Edge functions:  At host or edge router  Packet classification and traffic conditioning  per-flow traffic management  Packet mark identifies the class of traffic Core functions:  Core router  forwarding  per class traffic management  per-hop behavior: buffering and bandwidth sharing based on marking at edge Diffserv Architecture scheduling... r b marking

Edge-router Packet Marking r class-based marking: packets of different classes marked differently r intra-class marking: conforming portion of flow marked differently than non-conforming one r profile: pre-negotiated rate A, bucket size B r packet marking at edge based on per-flow profile Possible usage of marking: User packets Rate A B

Classification and Conditioning r Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6 r 6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive r 2 bits are currently unused

Classification and Conditioning at the Edge Router may be desirable to limit traffic injection rate of some class: r user declares traffic profile (e.g., rate, burst size) r traffic metered, shaped if non-conforming

Forwarding (PHB) r Per-hop behaviors (PHB) r PHB result in a different observable (measurable) forwarding performance behavior r PHB does not specify what mechanisms to use to ensure required PHB performance behavior r Examples: m Class A gets x% of outgoing link bandwidth over time intervals of a specified length m Class A packets leave first before packets from class B

Forwarding (PHB) PHBs being developed: r Expedited Forwarding: pkt departure rate of a class equals or exceeds specified rate m logical link with a minimum guaranteed rate r Assured Forwarding: 4 classes of traffic m each guaranteed minimum amount of bandwidth m each with three drop preference partitions

Principles for QOS Guarantees (more) r Basic fact of life: can not support traffic demands beyond link capacity Call Admission: flow declares its needs, network may block call (e.g., busy signal) if it cannot meet needs Principle 4 R1 R2 1.5 Mbps link 1 Mbps phone 1 Mbps phone

QoS guarantee scenario r Resource reservation m call setup, signaling (RSVP) m traffic, QoS declaration m per-element admission control m QoS-sensitive scheduling (e.g., WFQ) request/ reply

IETF Integrated Services (InteServ) r architecture for providing QoS guarantees in IP networks for individual application sessions r resource reservation: routers maintain state info of allocated resources, QoS req’s r admit/deny new call setup requests: Question: can newly arriving flow be admitted with performance guarantees while not violated QoS guarantees made to already admitted flows?

Call Admission Arriving session must : r declare its QOS requirement m R-spec: defines the QOS being requested r characterize traffic it will send into network m T-spec: defines traffic characteristics r signaling protocol: needed to carry R-spec and T- spec to routers (where reservation is required) m RSVP

Signaling in the Internet connectionless (stateless) forwarding by IP routers best effort service no network signaling protocols in initial IP design + = r New requirement: reserve resources along end-to-end path (end system, routers) for QoS for multimedia applications r RSVP m Resource Reservation Protocol [RFC 2205] m An Internet Signaling protocol perform the call setup signaling needed by IntServ. m Allows applications to reserve bandwidth for their data flows.

RSVP Design Goals 1. Used by host to request a specific amount of bandwidth from the network. 2. Used by the routers to forward bandwidth reservation requests. 3. Receiver-oriented: 1. accommodate heterogeneous receivers (different bandwidth along paths) 2. accommodate different applications with different resource requirements 4. Provides reservation for bandwidth in multicast trees 5. control protocol overhead to grow (at worst) linear in # receivers 6. modular design for heterogeneous underlying technologies

RSVP: does not… r specify how resources are to be reserved r rather: a mechanism for communicating needs r determine routes packets will take r that’s the job of routing protocols r signaling decoupled from routing r interact with forwarding of packets r separation of control (signaling) and data (forwarding) planes