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
 Deterministic QoS Parameters

• 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 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,..qnin]
– Generates output data with QoS level QoSout
• QoSout=[q1out,..qnout]
• 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 = qMlin for qMlin being single QoS value
• qKjout is in qMlin 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)
 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

#32
 Diffserv Architecture
Edge router: marking
- per-flow traffic management r scheduling
- marks packets as in-profile and out-
profile b ..
.
Core router:
- per class traffic management
- buffering and scheduling
based on marking at edge
- preference given to in-profile
packets

QoS #33
 Edge-router Packet Marking
• profile: pre-negotiated rate A, and token bucket size B
• packet marking at edge based on per-flow profile

Rate A

User packets

Possible usage of marking:

• class-based marking: packets of different classes marked differently
• intra-class marking: conforming portion of flow marked differently than
non-conforming one

QoS #34
 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 #35
 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 #36
 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 #37
 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 #38
 DiffServ Routers
DiffServ
Edge
Router
Classifier Marker Meter Policer

DiffServ PHB
Select PHB PHB Local
Core PHB
PHB conditions
Router
Extract Packet
DSCP treatment

QoS #39
 IntServ vs. DiffServ

IntServ
network
DiffServ
network

"Call blocking" "Prioritization"

approach approach
QoS #40
Comparison of Intserv & Diffserv
Architectures
Intserv Diffserv
Granularity of service Individual Flow Aggregate of
differentiation flows
State in routers(e.g. Per Flow Per Aggregate
scheduling, buffer
management)
Traffic Classification Several header fields DS Field
Basis
Type of service Deterministic or Absolute or
differentiation statistical guarantees relative
assurance
Admission Control Required Required for
absolute
differentiation
Signaling Protocol Required(RSVP) Not required for
relative schemes

QoS #41
Comparison of Intserv & Diffserv
Architectures
Intserv Diffserv
Coordination for End-to-End Local (Per-Hop)
service differentiation
Scope of Service A Unicast or Multicast Anywhere in a
Differentiation path Network or in
specific paths
Scalabilty Limited by the number Limited by the
of flows number of classes
of service
Network Accounting Based on flow Based on class
characteristics and QoS usage
requirement
Network Management Similar to Circuit Similar to existing
Switching networks IP networks
Interdomain Multilateral Bilateral
deployment Agreements Agreements

QoS #42
 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!

arriving token rate, r

traffic

bucket size, b
per-flow
rate, R
WFQ

D = b/R
max
 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

request/
reply

 QoS-sensitive
scheduling (e.g.,
WFQ)
 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: Controlled load service:
• worst case traffic arrival: leaky-bucket-  "a quality of service closely
policed source approximating the QoS that same
• simple (mathematically provable) flow would receive from an unloaded
bound on delay [Parekh 1992, Cruz network element."
1988]

arriving token rate, r

traffic

bucket size, b
per-flow
rate, R
WFQ

D = b/R
max
 Multimedia in Networks
Fundamental characteristics:
• Typically delay sensitive Classes of MM applications:
delay. • Streaming stored audio and
• But loss tolerant: infrequent video
losses cause minor glitches • Streaming live audio and
that can be concealed. video
• Antithesis of data • Real-time interactive video
(programs, banking info,
etc.), which are loss
intolerant but delay tolerant.
• Multimedia is also called
“continuous media”
 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” • We can send redundant packets to
Internet, we can: mitigate the effects of packet loss.
• Use UDP to avoid TCP and its
slow-start phase…  We will discuss all these “tricks”.
• 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
 How should the Internet evolve to better
support multimedia?
Integrated services philosophy:
• Change Internet protocols so that Differentiated services philosophy:
applications can reserve end-to- • Fewer changes to Internet
end bandwidth infrastructure, yet provide 1st and
– Need to deploy protocol that 2nd class service.
reserves bandwidth • Datagrams are marked.
– Must modify scheduling • User pays more to send/receive
policies in routers to honor 1st class packets.
reservations
• ISPs pay more to backbones to
– Application must provide the send/receive 1st class packets.
network with a description of
its traffic, and must further
abide to this description.
• Requires new, complex software
in hosts & routers
 How should the Internet evolve to better
support multimedia? (cont.)
Laissez-faire philosophy Virtual private networks (VPNs)
• No reservations, no datagram • Reserve permanent blocks of
marking bandwidth for enterprises.
• As demand increases, provision • Routers distinguish VPN traffic
more bandwidth using IP addresses
• Place stored content at edge of • Routers use special scheduling
network: policies to provide reserved
– ISPs & backbones add caches bandwidth.
– Content providers put content
in CDN nodes
– P2P: choose nearby peer with
content
 QoS Architectures

Host A Host B

Application Application
QoS-enabled
Presentation Presentation
Top-to-Bottom QoS

Application
Session Session QoS API

Transport Transport RSVP

Network Network DiffServ

Data Link Data Link SBM

Physical Physical

SBM

RSVP DiffServ and MPLS RSVP

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)
DiffServ applied at network ingress appropriate to RSVP service
x x
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