The document discusses quality of service (QoS) in multimedia communication networks, including QoS parameters and classes, deterministic and predictive QoS parameters, guaranteed and best effort QoS, QoS-aware service models, scheduling and policing mechanisms like priority scheduling and weighted fair queueing, and QoS architectures like Integrated Services and Differentiated Services.

1. 13PIT101
Multimedia Communication & Networks
UNIT - III
Dr.A.Kathirvel
Professor & Head/IT - VCEW

2. 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

3. 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

4. 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

5. Layered Model for QoS

6. Application QoS Parameters

7. System QoS Parameters

8. Network QoS Parameters

9. 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

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

11. 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>

12. 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

13. 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

14. 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)

15. 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

16. 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]

17. 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

18. 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

19. 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

20. 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”

21. 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

22. 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.

23. 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.

24. 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

25. 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

26. 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..

27. 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

28. 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)

29. 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

30. Weighted Fair Queueing
• generalized Round Robin (offers differential service to
each connection/class)
• each class gets weighted amount of service in each cycle

31. 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
#32

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

34. 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
B
User packets
Possible usage of marking:
•
•
QoS
class-based marking: packets of different classes marked differently
intra-class marking: conforming portion of flow marked differently than
non-conforming one
#34

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
#35

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
#36

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
#37

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
#38

39. DiffServ Routers
DiffServ
Edge
Router
Classifier
DiffServ
Core
Router
Marker
Select PHB
Meter
PHB
PHB
PHB
PHB
Extract
DSCP
QoS
Local
conditions
Packet
treatment
#39
Policer

40. IntServ vs. DiffServ
IntServ
network
DiffServ
network
"Call blocking"
approach
QoS
"Prioritization"
approach
#40

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

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

43. Traffic Regulators
• Leaky bucket controllers
• Token bucket controllers

44. 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).

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

46. 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?

47. 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)

48. 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

49. 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

50. 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

51. 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

52. 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

53. Intserv QoS: Service models [rfc2211, rfc 2212]
Controlled load service:
Guaranteed service:
•
•
worst case traffic arrival: leaky-bucketpoliced source
simple (mathematically provable)
bound on delay [Parekh 1992, Cruz
1988]
arriving
traffic
 "a quality of service closely
token rate, r
bucket size, b
per-flow
rate, R
WFQ
D = b/R
max
approximating the QoS that same
flow would receive from an unloaded
network element."

54. 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

55. 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

56. Multimedia in networks (3): challenges
• TCP/UDP/IP suite provides besteffort, 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.

57. 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”.

58. How should the Internet evolve to better
support multimedia?
Integrated services philosophy:
• Change Internet protocols so that
applications can reserve end-toend 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.

59. 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.

60. QoS Architectures
Host B
Application
Top-to-Bottom QoS
Host A
Application
Presentation
Presentation
Session
Session
Transport
Transport
RSVP
Network
Network
DiffServ
Data Link
Data Link
SBM
Physical
Physical
SBM
RSVP
DiffServ and MPLS
End-to-End QoS
RSVP
QoS-enabled
Application
QoS API

61. Protocol Comparison
QoS
most
Net App Description
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
x
least
DiffServ applied at network core ingress
Fair queuing applied by network elements (e.g. WFQ, RED)
Best effort service

62. 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

63. 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

64. Queries