CSE 679 Qo S Infrastructure to Support Multimedia

  • Slides: 33
Download presentation
CSE 679: Qo. S Infrastructure to Support Multimedia Communications r Principles r Policing r

CSE 679: Qo. S Infrastructure to Support Multimedia Communications r Principles r Policing r Scheduling r RSVP r Integrated and Differentiated Services

Improving QOS in IP Networks r IETF groups are working on proposals to provide

Improving QOS in IP Networks r IETF groups are working on proposals to provide better QOS control in IP networks, i. e. , going beyond best effort to provide some assurance for QOS r Work in Progress includes RSVP, Integrated Services, and Differentiated Services r Simple model for sharing and congestion studies:

How to provide Qo. S?

How to provide Qo. S?

Principles for QOS Guarantees r Consider a phone application at 1 Mbps and an

Principles for QOS Guarantees r Consider a phone application at 1 Mbps and an FTP application sharing a 1. 5 Mbps link. m m bursts of FTP can congest the router and cause audio packets to be dropped. want to give priority to audio over FTP r PRINCIPLE 1: Marking of packets is needed for router to distinguish between different classes; and new router policy to treat packets accordingly

Principles for QOS Guarantees (more) r Applications misbehave (audio sends packets at a rate

Principles for QOS Guarantees (more) r Applications misbehave (audio sends packets at a rate higher than 1 Mbps assumed above); r PRINCIPLE 2: provide protection (isolation) for one class from other classes r Require Policing Mechanisms to ensure sources adhere to bandwidth requirements; Marking and Policing need to be done at the edges:

Principles for QOS Guarantees (more) r Alternative to Marking and Policing: allocate a set

Principles for QOS Guarantees (more) r Alternative to Marking and Policing: allocate a set portion of bandwidth to each application flow; can lead to inefficient use of bandwidth if one of the flows does not use its allocation r PRINCIPLE 3: While providing isolation, it is desirable to use resources as efficiently as possible

Principles for QOS Guarantees (more) r Cannot support traffic beyond link capacity r PRINCIPLE

Principles for QOS Guarantees (more) r Cannot support traffic beyond link capacity r PRINCIPLE 4: Need a Call Admission Process; application flow declares its needs, network may block call if it cannot satisfy the needs

Policing Mechanisms r Three criteria: m (Long term) Average Rate (100 packets per sec

Policing Mechanisms r Three criteria: m (Long term) Average Rate (100 packets per sec or 6000 packets per min? ? ), crucial aspect is the interval length m Peak Rate: e. g. , 6000 p p minute Avg and 1500 p p sec Peak m (Max. ) Burst Size: Max. number of packets sent consecutively, ie over a short period of time

Policing Mechanisms r Token Bucket mechanism, provides a means for limiting input to specified

Policing Mechanisms r Token Bucket mechanism, provides a means for limiting input to specified Burst Size and Average Rate.

Policing Mechanisms (more) r Bucket can hold b tokens; token are generated at a

Policing Mechanisms (more) r Bucket can hold b tokens; token are generated at a rate of r token/sec unless bucket is full of tokens. r Over an interval of length t, the number of packets that are admitted is less than or equal to (r t + b).

Scheduling Mechanisms r Scheduling: choosing the next packet for transmission on a link can

Scheduling Mechanisms r Scheduling: choosing the next packet for transmission on a link can be done following a number of policies; r FIFO: in order of arrival to the queue; packets that arrive to a full buffer are either discarded, or a discard policy is used to determine which packet to discard among the arrival and those already queued

Scheduling Policies r Priority Queuing: classes have different priorities; class may depend on explicit

Scheduling Policies r Priority Queuing: classes have different priorities; class may depend on explicit marking or other header info, eg IP source or destination, TCP Port numbers, etc. r Transmit a packet from the highest priority class with a nonempty queue r Preemptive and non-preemptive versions

Scheduling r Scheduling: m FIFO m Priority Scheduling (static priority) m Round Robin m

Scheduling r Scheduling: m FIFO m Priority Scheduling (static priority) m Round Robin m Weight Fair Queuing (WFQ)

Priority-driven Scheduler r packets are transmitted according to their priorities; within the same priority,

Priority-driven Scheduler r packets are transmitted according to their priorities; within the same priority, packets are served in FIFO order. r Complex in terms of no provable bounded delay due to no flow isolation r Simple in terms of no per-flow management: SP make it possible to decouple Qo. S control from the core-router. D = ? ? max

Round Robin r Round Robin: scan class queues serving one from each class that

Round Robin r Round Robin: scan class queues serving one from each class that has a non-empty queue

WFQ r Weighted Fair Queuing: is a generalized Round Robin in which an attempt

WFQ r Weighted Fair Queuing: is a generalized Round Robin in which an attempt is made to provide a class with a differentiated amount of service over a given period of time

Resource Configuration r Traffic engineering m Qo. S routing m Resource provisioning r Network

Resource Configuration r Traffic engineering m Qo. S routing m Resource provisioning r Network planning m Network design

Admission Control r Session must first declare its QOS requirement and characterize the traffic

Admission Control r Session must first declare its QOS requirement and characterize the traffic it will send through the network r R-spec: defines the QOS being requested r T-spec: defines the traffic characteristics r A signaling protocol is needed to carry the R-spec and T-spec to the routers where reservation is required; RSVP is a leading candidate for such signaling protocol

Admission Control r Call Admission: routers will admit calls based on their R-spec and

Admission Control r Call Admission: routers will admit calls based on their R-spec and T-spec and base on the current resource allocated at the routers to other calls.

Reservation Protocol: RSVP Upper layer protocols and applications IP service interface IP ICMP IGMP

Reservation Protocol: RSVP Upper layer protocols and applications IP service interface IP ICMP IGMP RSVP Link layer service interface Link layer modules

RSVP r Used on connectionless networks r Relies on soft state: reservations must be

RSVP r Used on connectionless networks r Relies on soft state: reservations must be refreshed and do not have to be explicitly deleted r Aims to support multicast as effectively as unicast flows - mcast apps good candidates for real-time, and are heterogeneous r Receiver-oriented approach

Basic Message Types r PATH message r RESV message r CONFIRMATION message m generated

Basic Message Types r PATH message r RESV message r CONFIRMATION message m generated only upon request m unicast to receiver when RESV reaches node with established state r TEARDOWN message r ERROR message (if path or RESV fails)

Making A Reservation r Receivers make reservation r Before making a reservation, receiver must

Making A Reservation r Receivers make reservation r Before making a reservation, receiver must know: m type of traffic sender will send (Tspec) m path the sender’s packets will follow r Both can be accomplished by sending PATH messages

PATH Messages r PATH messages carry sender’s Tspec r Routers note the direction PATH

PATH Messages r PATH messages carry sender’s Tspec r Routers note the direction PATH messages arrived and set up reverse path to sender r Receivers send RESV messages that follow reverse path and setup reservations r If reservation cannot be made, user gets an error

PATH and RESV messages Sender 1 Sender 2 PATH RESV (merged) RESV R R

PATH and RESV messages Sender 1 Sender 2 PATH RESV (merged) RESV R R R receiver 1 RESV receiver 2

Soft State r Routing protocol makes routing changes, RSVP adjusts reservation state r In

Soft State r Routing protocol makes routing changes, RSVP adjusts reservation state r In absence of route or membership changes, periodic PATH and RESV msgs refresh established reservation state r When change, new PATH msgs follow new path, new RESV msgs set reservation r Non-refreshed state times out automatically

Router handling of RESV messages r If new request rejected, send error message r

Router handling of RESV messages r If new request rejected, send error message r If admitted: m install packet filter into forwarding dbase m pass flow parameters to scheduler m activate packet policing if needed m forward RESV msg upstream

Two Qo. S Planes r Control-Plane m Call management (setup, signaling (RSVP) and tear-down)

Two Qo. S Planes r Control-Plane m Call management (setup, signaling (RSVP) and tear-down) m Admission control (delay computation etc) m and resource provisioning (off-line), path determination (shortest-path routing, MPLS) etc. r Data-Plane: m Packet forwarding (controlled by schedulers, such as rate -based schedulers, e. g. WFQ and priority-based schedulers, e. g. Static Priority)

Integrated Services (Int-Serv) r An architecture for providing QOS guarantees in IP networks for

Integrated Services (Int-Serv) r An architecture for providing QOS guarantees in IP networks for individual application sessions r relies on resource reservation, and routers need to maintain state info (Virtual Circuit? ? ), maintaining records of allocated resources and responding to new Call setup requests on that basis

Differentiated Services (Diff-Serv) Model q Basic Idea o Services classification o Flow aggregation q

Differentiated Services (Diff-Serv) Model q Basic Idea o Services classification o Flow aggregation q Relative Differentiated Services o provide per-hop, per-class relative services q Absolute Differentiated Services: o provide Int. Serv-type end-to-end absolute performance o guarantees without per-flow state in the network core

Differentiated Services r Intended to address the following difficulties with Intserv and RSVP; r

Differentiated Services r Intended to address the following difficulties with Intserv and RSVP; r Scalability: maintaining states by routers in high speed networks is difficult sue to the very large number of flows r Flexible Service Models: Intserv has only two classes; want to provide ‘relative’ service distinction (Platinum, Gold, Silver, …) r Simpler signaling: (than RSVP) many applications and users may only want to specify a more qualitative notion of service

Differentiated Services r Approach: m Only simple functions in the core, and relatively complex

Differentiated Services r Approach: m Only simple functions in the core, and relatively complex functions at edge routers (or hosts) m Do not define service classes, instead provides functional components with which service classes can be built

Edge Functions r At DS-capable host or first DS-capable router r Classification: edge node

Edge Functions r At DS-capable host or first DS-capable router r Classification: edge node marks packets according to classification rules to be specified (manually by admin, or by some TBD protocol) r Traffic Conditioning: edge node may delay and then forward or may discard