13PIT101

Multimedia Communication & Networks

UNIT - III

Dr.A.Kathirvel

Professor & Head/IT - VCEW

UNIT - III

Best Effort service model – Scheduling and Dropping policies

– Network Performance Parameters – Quality of Service and

metrics – WFQ and its variants – Random Early Detection –

QoS aware Routing – Admission Control – Resource

Reservation – RSVP - Traffic Shaping Algorithms – Caching –

Laissez Faire Approach - Possible Architectures – An

Overview of QoS Architectures

Quality of Service

• MM systems consist of set of services

• To provide generic MM services, services get parameterized with so called Quality of Service

• Examples of QoS parameters:

– QoS for Audio service:

• Sample rate – 8000 samples/second

• Sample resolution – 8 bits per sample

– QoS for network service:

• Throughput – 100 Mbps

• Connection setup time – 50 ms

QoS (cont.)

• QoS concept comes from networking service and was introduced for specification how good the offered network services are

• Services are performed on different objects

– Media sources

– Media sinks

– Connections

• QoS specification characterizes the service objects

Layered Model for QoS

Application QoS Parameters

System QoS Parameters

Network QoS Parameters

QoS Classes

• Guaranteed Service Class

– QoS guarantees are provided based on deterministic and statistical QoS

parameters

• Predictive Service Class

– QoS parameter values are estimated and based on the past behavior of

the service

• Best Effort Service Class

– There are no guarantees or only partial guarantees are provided

QoS Classes (cont.) QoS Class determines: (a) reliability of offered QoS, (b) utilization of resources

• Single Value: QoS1 – average (QoSave), contractual value, threshold

value, target value

• Pair Value: <QoS1, QoS2> with

QoS1 – required value; QoS2 – desired value

Example: <QoSavg,QoSpeak>; <QoSmin, QoSmax>

Deterministic QoS Parameters

Deterministic QoS Parameter Values

• Triple of Values <QoS1, QoS2, QoS3>

– QoS1 – best value

– QoS2 – average value

– QoS3 – worst value

• Example:

– <QoSpeak, QoSavg, QoSmin>, where QoS is network

bandwidth

Guaranteed QoS

• We need to provide 100% guarantees for QoS values (hard guarantees) or

very close to 100% (soft guarantees)

• Current QoS calculation and resource allocation are based on:

1. Hard upper bounds for imposed workloads

2. Worst case assumptions about system behavior

1. Advantages: QoS guarantees are satisfied even in the worst case case

(high reliability in guarantees)

2. Disadvantage: Over-reservation of resources, hence needless rejection

of requests

Predictive QoS Parameters

• We utilize QoS values (QoS1, ..QoSi) and compute average

– QoSbound step at K>i is QoSK = 1/i*∑jQoSj

• We utilize QoS values (QoS1, , QoSi) and compute maximum

value

– QoSK = max j=1,…i (QoSj)

• We utilize QoS values (QoS1, , QoSi) and compute minimum

value

– QoSK = min j=1,…i (QoSj)

Best Effort QoS

• No QoS bounds or possible very weak QoS bounds

• Advantages: resource capacities can be statistically

multiplexed, hence more processing requests can be granted

• Disadvantages: QoS may be temporally violated

Quality-aware Service Model

• Quality-aware Autonomous Single Service

– Consists of a set of functions

– Accepts input data with QoS level QoSin

• QoSin=[q1in,..qn

in]

– Generates output data with QoS level QoSout

• QoSout=[q1out,..qn

out]

• Example: Video player service

– Input QoS: [Recorded Video Frame Rate, Recorded Frame Size, Recorded Pixel Precision]

– QoSin=[30fps, 640x480 pixels, 24 bits per pixel]

– Output QoS: [Playback Video Frame Rate, Playback Frame Size, Playback Pixel Precision]

– QoSout=[20fps, 320x240pixels, 24bits per pixel]

Quality-aware Service Model • Quality-aware Composite Service

– Consists of set of autonomous services that are connected into a

directed acyclic graph, called service graph

– Is correct if the inter-service satisfied the following relation:

• QoSout of Service K ‘satisfies ‘QoSin of Service M iff

• qKjout = qMl

in for qMlin being single QoS value

• qKjout is in qMl

in for qMlin being a range of QoS value

• Example:

– Video-on-demand service, consists of two services: retrieval service

and playback service

• Output quality of the retrieval service needs to correspond to input

quality of playback service, or at least falls into the range of input

quality of playback service

Scheduling And Policing Mechanisms

• scheduling: choose next packet to send on link; allocate link capacity and output

queue buffers to each connection (or connections aggregated into classes)

• FIFO (first in first out) scheduling: send in order of arrival to queue

– 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

Need for a Scheduling Discipline

• Why do we need a non-trivial scheduling discipline?

• Per-connection delay, bandwidth, and loss are determined by the scheduling

discipline

– The NE can allocate different mean delays to different connections by its

choice of service order

– it can allocate different bandwidths to connections by serving at least a

certain number of packets from a particular connection in a given time

interval

– Finally, it can allocate different loss rates to connections by giving them

more or fewer buffers

FIFO Scheduling

• Disadvantage with strict FIFO scheduling is that the scheduler cannot

differentiate among connections -- it cannot explicitly allocate some

connections lower mean delays than others

• A more sophisticated scheduling discipline can achieve this objective (but

at a cost)

• The conservation law

– “the sum of the mean queueing delays received by the set of

multiplexed connections, weighted by their fair share of the link’s load,

is independent of the scheduling discipline”

Requirements

• A scheduling discipline must satisfy four requirements:

– Ease of implementation -- pick a packet every few microsecs; a scheduler that takes O(1) and not O(N) time

– Fairness and Protection (for best-effort connections) -- FIFO does not offer any protection because a misbehaving connection can increase the mean delay of all other connections. Round-robin scheduling?

– Performance bounds -- deterministic or statistical; common performance parameters: bandwidth, delay (worst-case, average), delay-jitter, loss

– Ease and efficiency of admission control -- to decide given the current set of connections and the descriptor for a new connection, whether it is possible to meet the new connection’s performance bounds without jeopardizing the performance of existing connections

Designing a scheduling discipline

• Four principal degrees of freedom:

– the number of priority levels

– whether each level is work-conserving or non-work-conserving

– the degree of aggregation of connections within a level

– service order within a level

• Each feature comes at some cost

– for a small LAN switch -- a single priority FCFS scheduler or at most

2-priority scheduler may be sufficient

– for a heavily loaded wide-area public switch with possibly

noncooperative users, a more sophisticated scheduling discipline may

be required.

Work conserving and non-work

conserving disciplines

• A work-conserving scheduler is idle only when there is no packet awaiting

service

• A non-work-conserving scheduler may be idle even if it has packets to

serve

– makes the traffic arriving at downstream switches more predictable

– reduces buffer size necessary at output queues and the delay jitter

experienced by a connection

– allows the switch to send a packet only when the packet is eligible

– for example, if the (k+1)th packet on connection A becomes eligible for

service only i seconds after the service of the kth packet, the

downstream swicth receives packets on A no faster than one every i

secs.

Eligibility times

• By choosing eligibility times carefully, the output from a switch can be mode more predictable (so that bursts won’t build up in the n/w)

• Two approaches: rate-jitter and delay-jitter

• rate-jitter: peak rate guarantee for a connection – E(1) = A(1); E(k+1) = max(E(k) + Xmin, A(k+1)) where Xmin

is the time taken to serve a fixed-sized packet at peak rate)

• delay-jitter: at every switch, the input arrival pattern is fully reconstructed – E(0,k) = A (0,k); E(i+1, k) = E(i,k) + D + L where D is the

delay bound at the previous switch and L is the largest possible delay on the link between switch i and i+1

Pros and Cons

• Reduces delay jitter: Con -- we can remove jitter at endpoints with an

elasticity buffer; Pro--reduces buffers(expensive) at the switches

• Increases mean delay, problem?: pro--for playback applications, which

delay packets until the delay-jitter bound, increasing mean delay does not

affect the perceived performance

• Wasted bandwidth, problem?: pro--It can serve best-effort packets when

there are no eligible packets to serve

• Needs accurate source descriptors -- no rebuttal from the non-work

conserving camp

Priority Scheduling

transmit highest priority queued packet

• multiple classes, with different priorities

– class may depend on marking or other header info, e.g. IP

source/dest, port numbers, etc..

Priority Scheduling

• The scheduler serves a packet from priority level k only if

there are no packets awaiting service in levels k+1, k+2, …, n

• at least 3 levels of priority in an integrated services network?

• Starvation? Appropriate admission control and policing to

restrict service rates from all but the lowest priority level

• Simple implementation

Round Robin Scheduling

• multiple classes

• cyclically scan class queues, serving one from each class (if available)

• provides protection against misbehaving sources (also guarantees a

minimum bandwidth to every connection)

Max-Min Fair Share

• Fair Resource allocation to best-effort connections?

• Fair share allocates a user with a “small” demand what it wants, and evenly distributes unused resources to the “big” users.

• Maximize the minimum share of a source whose demand is not fully

satisfied.

– Resources are allocated in order of increasing demand

– no source gets a resource share larger than its demand

– sources with unsatisfied demand s get an equal share of resource

• A Generalized Processor Sharing (GPS) server will implement max-min

fair share

Weighted Fair Queueing

• generalized Round Robin (offers differential service to

each connection/class)

• each class gets weighted amount of service in each cycle

Policing Mechanisms

Goal: limit traffic to not exceed declared parameters

Three common-used criteria:

• (Long term) Average Rate: how many pkts can be sent per unit time (in the

long run)

– crucial question: what is the interval length: 100 packets per sec or

6000 packets per min have same average!

• Peak Rate: e.g., 6000 pkts per min. (ppm) avg.; 1500 ppm peak rate

• (Max.) Burst Size: max. number of pkts sent consecutively (with no

intervening idle)

#32

IETF Differentiated Services

Concerns with Intserv:

• Scalability: signaling, maintaining per-flow router state difficult with large

number of flows

• Flexible Service Models: Intserv has only two classes. Also want “qualitative” service classes

– “behaves like a wire”

– relative service distinction: Platinum, Gold, Silver

Diffserv approach:

• simple functions in network core, relatively complex functions at edge routers

(or hosts)

• Don’t define service classes, provide functional components to build service classes

QoS #33

Diffserv Architecture

Edge router:

- per-flow traffic management

- marks packets as in-profile and out-

profile

Core router:

- per class traffic management

- buffering and scheduling

based on marking at edge

- preference given to in-profile

packets

scheduling

. . .

r

b

marking

QoS #34

Edge-router Packet Marking

• class-based marking: packets of different classes marked differently

• intra-class marking: conforming portion of flow marked differently than

non-conforming one

• profile: pre-negotiated rate A, and token bucket size B

• packet marking at edge based on per-flow profile

Possible usage of marking:

User packets

Rate A

B

QoS #35

Classification and Conditioning

• Packet is marked in the Type of Service (TOS) in IPv4, and

Traffic Class in IPv6

• 6 bits used for Differentiated Service Code Point (DSCP)

and determine PHB that the packet will receive

• 2 bits are currently unused

QoS #36

Classification and Conditioning

• It may be desirable to limit traffic injection rate of some class;

user declares traffic profile (eg, rate and burst size); traffic is

metered and shaped if non-conforming

QoS #37

Forwarding (PHB)

• Per Hop Behavior (PHB) result in a different observable

(measurable) forwarding performance behavior

• PHB does not specify what mechanisms to use to ensure

required PHB performance behavior

• Examples:

– Class A gets x% of outgoing link bandwidth over time

intervals of a specified length

– Class A packets leave first before packets from class B

QoS #38

Forwarding (PHB)

PHBs being developed:

• Expedited Forwarding: pkt departure rate of a class equals or exceeds

specified rate

– logical link with a minimum guaranteed rate

• Premium service

– DSCP = 101110 (46)

• Assured Forwarding: 4 classes of traffic

– each guaranteed minimum amount of bandwidth

– each with three drop preference partitions

• Gold, silver, bronze

QoS #39

DiffServ Routers

Classifier Meter Policer Marker

DiffServ Edge Router

Extract DSCP

Local conditions

PHB PHB PHB PHB

Select PHB

Packet treatment

DiffServ

Core

Router

QoS #40

IntServ vs. DiffServ

IntServ network

DiffServ network

"Call blocking" approach

"Prioritization" approach

QoS #41

Comparison of Intserv & Diffserv

Architectures

Intserv DiffservGranularity of service

differentiation

Individual Flow Aggregate of

flows

State in routers(e.g.

scheduling, buffermanagement)

Per Flow Per Aggregate

Traffic ClassificationBasis

Several header fields DS Field

Type of servicedifferentiation

Deterministic orstatistical guarantees

Absolute orrelative

assurance

Admission Control Required Required for

absolutedifferentiation

Signaling Protocol Required(RSVP) Not required forrelative schemes

QoS #42

Comparison of Intserv & Diffserv

Architectures

Intserv Diffserv Coordination for

service differentiation

End-to-End Local (Per-Hop)

Scope of Service

Differentiation

A Unicast or Multicast

path

Anywhere in a

Network or in specific paths

Scalabilty Limited by the number of flows

Limited by the number of classes

of service

Network Accounting Based on flow

characteristics and QoS

requirement

Based on class

usage

Network Management Similar to Circuit

Switching networks

Similar to existing

IP networks

Interdomain deployment

Multilateral Agreements

Bilateral Agreements

Traffic Regulators

• Leaky bucket controllers

• Token bucket controllers

Policing Mechanisms

Token Bucket: limit input to specified Burst Size and Average Rate.

• bucket can hold b tokens

• tokens generated at rate r token/sec unless bucket full

• over interval of length t: number of packets admitted less than or equal to (r t + b).

Policing Mechanisms (more)

• 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 Integrated Services

• architecture for providing QOS guarantees in IP networks for individual application sessions

• resource reservation: routers maintain state info (a la VC) of allocated resources, QoS req’s

• admit/deny new call setup requests:

Question: can newly arriving flow be admitted

with performance guarantees while not violating

QoS guarantees made to already admitted flows?

Intserv: QoS guarantee scenario

• Resource reservation

– call setup, signaling (RSVP)

– traffic, QoS declaration

– per-element admission control

QoS-sensitive

scheduling (e.g.,

WFQ)

request/

reply

RSVP

• Multipoint Multicast connections

• Soft state

• Receiver initiated reservations

• identifies a session using a combination of dest. Address, transport-layer protocol type, dest. Port number

• each RSVP operation applies only to packets of a particular session

• not a routing protocol; merely used to reserve resources along the existing route set up by whichever underlying routing protocol

RSVP Messages

• Path message originating from the traffic sender

– to install reverse routing state in each router along the path

– to provide recceivers with information about the characteristics of the sender traffic and end-to-end path so that they can make appropriate reservation requests

• Resv message originating from the receivers

– to carry reservation requests to the routers along the distribution tree between receivers and senders

• PathTear, ResvTear, ResvErr, PathErr

PATH Message

• Phop: the address of the last RSVP-capable node to forward this path message.

• Sender template: filter specification identifying the sender

• Sender Tspec: defines sender traffic characteristics

• Optional Adspec: info about the end-to-end path used by the receivers to compute the level of resources that must be reserved

RESV Message

• Rspec: reservation specification comprising the value R of bandwidth to be reserved in each router, and a slack term about end-to-end delay

• reservation style, FF, WF, SE

• Filterspec to identify the senders

• Flowspec comprising the Rspec and traffic specification (set equal to Sender Tspec)

• optional ResvConf

Call Admission

Arriving session must :

• declare its QOS requirement

– R-spec: defines the QOS being requested

• characterize traffic it will send into network

– T-spec: defines traffic characteristics

• signaling protocol: needed to carry R-spec and T-spec to routers (where reservation is required)

– RSVP

Intserv QoS: Service models [rfc2211, rfc 2212]

Guaranteed service:

• worst case traffic arrival: leaky-bucket-

policed source

• simple (mathematically provable)

bound on delay [Parekh 1992, Cruz

1988]

Controlled load service:

"a quality of service closely

approximating the QoS that same

flow would receive from an unloaded

network element."

WFQ

token rate, r

bucket size, b

per-flow

rate, R

D = b/R max

arriving

traffic

Multimedia in Networks Fundamental characteristics:

• Typically delay sensitive delay.

• But loss tolerant: infrequent losses cause minor glitches that can be concealed.

• Antithesis of data (programs, banking info, etc.), which are loss intolerant but delay tolerant.

• Multimedia is also called “continuous media”

Classes of MM applications:

• Streaming stored audio and

video

• Streaming live audio and

video

• Real-time interactive video

Multimedia in networks (2)

Streaming stored MM

• Clients request audio/video files from servers and pipeline reception over the network and display

• Interactive: user can control operation (similar to VCR: pause, resume, fast forward, rewind, etc.)

• Delay: from client request until display start can be 1 to 10 seconds

Unidirectional Real-Time:

• similar to existing TV and radio

stations, but delivery over the

Internet

• Non-interactive, just listen/view

Interactive Real-Time :

• Phone or video conference

• More stringent delay requirement

than Streaming & Unidirectional

because of real-time nature

• Video: < 150 msec acceptable

• Audio: < 150 msec good, <400

msec acceptable

Multimedia in networks (3): challenges

• TCP/UDP/IP suite provides best-

effort, no guarantees on delay or

delay variation.

– Streaming apps with initial

delay of 5-10 seconds are now

commonplace, but

performance deteriorates if

links are congested

(transoceanic)

– Real-Time Interactive apps

have rigid requirements for

packet delay and jitter.

– Jitter is the variability of

packet delays within the same

packet stream.

• Design for multimedia apps

would be easier if there were

some 1st and 2nd class services.

– But in the public Internet, all

packets receive equal service.

– Packets containing real-time

interactive audio and video

stand in line, like everyone

else.

• There have been, and continue to

be, efforts to provide

differentiated service.

Multimedia in networks (4):

making the best of best effort

To mitigate impact of “best-effort” Internet, we can:

• Use UDP to avoid TCP and its

slow-start phase…

• Buffer content at client and

control playback to remedy jitter

• We can timestamp packets, so that

receiver knows when the packets

should be played back.

• Adapt compression level to

available bandwidth

• We can send redundant packets to

mitigate the effects of packet loss.

We will discuss all these “tricks”.

How should the Internet evolve to better

support multimedia? Integrated services philosophy:

• Change Internet protocols so that

applications can reserve end-to-

end bandwidth

– Need to deploy protocol that

reserves bandwidth

– Must modify scheduling

policies in routers to honor

reservations

– Application must provide the

network with a description of

its traffic, and must further

abide to this description.

• Requires new, complex software

in hosts & routers

Differentiated services philosophy:

• Fewer changes to Internet

infrastructure, yet provide 1st and

2nd class service.

• Datagrams are marked.

• User pays more to send/receive

1st class packets.

• ISPs pay more to backbones to

send/receive 1st class packets.

How should the Internet evolve to better

support multimedia? (cont.) Laissez-faire philosophy

• No reservations, no datagram

marking

• As demand increases, provision

more bandwidth

• Place stored content at edge of

network:

– ISPs & backbones add caches

– Content providers put content

in CDN nodes

– P2P: choose nearby peer with

content

Virtual private networks (VPNs)

• Reserve permanent blocks of

bandwidth for enterprises.

• Routers distinguish VPN traffic

using IP addresses

• Routers use special scheduling

policies to provide reserved

bandwidth.

QoS Architectures

Application

Physical

Data Link

Network

Transport

Session

Presentation

To

p-t

o-B

otto

m Q

oS

Host A

Application

Physical

Data Link

Network

Transport

Session

Presentation

Host B

RSVP

DiffServ

SBM

QoS-enabled

Application

QoS API

SBM

RSVP RSVPDiffServ and MPLS

End-to-End QoS

Protocol Comparison

QoS Net App Description

most x Provisioned resources end-to-end (leased lines)

x x RSVP Guaranteed (provides feedback to application)

x x RSVP Controlled Load (provides feedback to application)

x MPLS (Multi-Protocol Label Switching)

x x DiffServ applied at network ingress appropriate to RSVP service level for that flow

x x DiffServ or SBM applied on per-flow basis by source application

x DiffServ applied at network core ingress

x Fair queuing applied by network elements (e.g. WFQ, RED)

least Best effort service

Multicast Environments

• RSVP

– Heterogeneous receivership makes reservation merging a difficult task

• DiffServ

– Its relative simplicity makes it a better fit for multicast support

• MPLS

– Work is underway, no standards have emerged yet

• SBM

– Explicit support for multicast

Conclusions

• Complexity at the edges – simple network core

– Limit RSVP’s use on the backbone

– Instead use the DiffServ

• DiffServ is a perfect complement for RSVP

• ToDo :

– Performance attributes for each class still missing

– Interworking solution for mapping IP CoS to ATM QoS

Queries