Multimedia

Lecture IX
Quality of Service Issues in MM
Applications

Dr. George Karraz, Ph. D.

 Outline

• Review of IPTV main services

• Characteristics of multimedia applications
• The constraints of QoS
• Quality of Service (QoS) management
• network support for multimedia

2
 Learning Objectives

Upon completion of this lecture, you will be able to:

• Understand QoS Constraints (IPTV case study)
• Understand the nature of multimedia data and the scheduling
and resource issues associated with it.
• Understand the nature of Quality of Service and the system
support that it requires.

3
 What is IPTV

• IPTV: Internet Protocol Television

• Television through Internet Protocol
• Digital television, transmitting over IP networks

4
 IPTV

• Internet Protocol Television (IPTV) has been a

hot topic in recent years.
• IPTV can deliver broadcast TV and other
multimedia services over secure, managed
broadband IP based networks with a required
level of quality of service.
• It can provide bundled service offerings that
encompass Internet access, audio/video/data
5
and interactive services, as well as mobile
services.
 IPTV definition

The definition formulated by the ITU-T focus

group on IPTV:

• IPTV is multimedia services of delivering

television/audio/text/graphics/data over IP based
networks managed to provide the required level of
Quality of Service (QoS)/Quality of Experience
(QoE), security, interactivity and reliability.”
6
 Main features of IPTV
• Triple play
• voice, video and Internet services
• Interactive TV
• Time shifting
• Personalization
• Accessible on multiple devices
• Quality of Service/Experience
• Security, data protection and IP right

7
 Triple Play of Services

• Offer three services

• IPTV provides one facet of the so-called "triple play"
of services: voice, data, and video. The triple-play
vision is that consumers can subscribe to one service
that provides voice, data (Internet and other online
services), and video (live broadcast and on-demand) -
all three brought into the home or office over one
line or feed, and by one service provider 8
Quad play

9
 IPTV vs. Internet TV
• IPTV offers broadcast quality video services, while Internet TV
usually offers low resolution quality video services  No QoS

10
Technologies enabling video over IP

• Advances in video compression

• Compression technologies have rapidly evolved from MPEG-1 to
H.264 (MPEG-4 part 10).

• Growth in IP network capacity

• Broadband access networks such as xDSL, GigabitEthernet,
FTTx, Cable Modem, WiFi/Wimax

11
Characteristics of multimedia applications

• Large quantities of continuous data

• Timely and smooth delivery is critical

• deadlines
• throughput and response time guarantees

• Interactive MM applications require low round-trip delays

End-to-end delay (transmission, processing, queuing delays in routers; propagation
delays in the links; end-system processing delays) for interactive applications < 400 ms
• Resources required:
• Processor cycles in workstations
and servers At the right time
• Network bandwidth (+ latency)
and in the right quantities
• Dedicated memory
• Disk bandwidth (for stored media)
12
Streaming Multimedia: What is it?

2. video
sent
1. video 3. video received,
recorded network played out at client
delay
time
streaming: at this time, client
playing out early part of video,
while server still sending later
part of video
13
 Real-Time Interactive Multimedia

o applications: IP telephony, video

conference, distributed
interactive worlds
o end-end delay requirements:
 audio: < 150 msec good, < 400 msec OK
• includes application-level (packetization) and network
delays
• higher delays noticeable, impair interactivity
o session initialization
 how does callee advertise its IP address, port number,
encoding algorithms?
Parameters that affect directly QoS in IPTV
systems

• The most important parameters:

• Bandwidth
• Packet Loss
• Delay
• Jitter

15
 Bandwidth requirements
• Bandwidth is the most important parameter for offering
services with high QoS.
• Thus, in order to manage bandwidth usage we should use
some compression techniques.
• There are different MPEG compression methods for
offering IPTV service. The most common methods used in
IPTV systems are MPEG2 and MPEG4.

16
 Bandwidth requirements
• Bandwidth requirements for offering one TV channel with
MPEG-2 compression are:
• MPEG-2: SDTV ~ 4 Mbps  HDTV ~ 16 Mbps (Not used)
• Bandwidth requirements for offering one TV channel with
MPEG-4 compression are:
• MPEG-4: SDTV ~ 2 Mbps  HDTV ~ 8 Mbps
• These requirements for broadband dictate the needs for using
broadband access technology. The best case is using FTTH. In
rural areas this wireline technology is very expensive, so in these
areas it is more appropriate to use wireless technology WiMAX

17
Video compression technologies

18
 Packet Loss and Delay
• network loss: IP datagram lost due to network congestion
(router buffer overflow)
• delay loss: IP datagram arrives too late for playout at receiver
• delays: processing, queueing in network; end-system (sender, receiver)
delays
• typical maximum tolerable delay: 400 ms

19
 Packet Loss Constraints
• Packet Loss Ratio (PLR) is the most critical constraint
• A low packet loss causes a significant degradation in QoE
• Ranging from pixel artifacts to screen freeze (loss of I frame)
• PLR  from loss distance and loss duration
• Loss Distance measures spacing between consecutive packet loss
• [ADSL forum TR.126] Loss Distance should be limited to at most one
per 60 minutes for SD and one for 4 hours for HD
• Loss duration is the duration of a loss
• [ADSL forum TR.126] specifications indicate a 16 ms maximum duration
of a single error for SD / HD / MPEG-2 / MPEG-4

20
Packet Loss

21
MPEG Error Retention

22
 MPEG over IP
• The I, B and P-frames are carried across the network in 188 byte
MPEG Transport Stream (TS) packets which are encapsulated in
IP packets.
• A single IP packet is capable of containing approximately seven
TS.
• MPEG-TS over UDP: typically 7 MPEG-TS packets in one UDP
packet 7x188B = 1316B payloads

23
 Delay Jitter
constant bit
rate client constant bit
transmission reception rate playout
at client
variable
network

buffered
data
delay
(jitter)

client playout time

delay

• consider end-to-end delays of two consecutive packets: difference

can be more or less than 20 msec (transmission time difference)
Time relationship

25
 Jitter

• Jitter is introduced in real-time data by the delay between packets

26
 Timestamp

• To prevent jitter, we can time-stamp the packets and separate the arrival
27
time from the playback time
 QoS mechanisms can be implemented at
different levels

• At the network level it includes traffic management mechanisms

such as buffering and scheduling employed to differentiate
between traffics belong to different applications.
• At levels other levels than the transport include loss concealment,
Forward Error Correction (FEC)

28
 QoS Mechanisms & handling level
Checking that application resource are
Admission control
available before serving the user

Forward Error
At application level Adding redundancy to data for FEC
Correction

RTP Retransmission Retransmitting lost data

Traffic prioritization
DiffServ
At network level
Checking that network resource are
Admission control available before serving the user

29
 QoS and QoE
Network Impairments
Content Impairments

• Freeze
• Bandwidth
• Blur
• Packet Loss
• Noise
• Delay
• Color
• Jitter
• Channel Change Time

End-user’s Quality of Experience

Human vision System Modeling

30
Network support for multimedia

31
 Dimensioning best effort networks

• approach: deploy enough link capacity so that congestion

doesn’t occur, multimedia traffic flows without delay or
loss
• low complexity of network mechanisms (use current “best
effort” network)
• high bandwidth costs
• challenges:
• network dimensioning: how much bandwidth is “enough?”
• estimating network traffic demand: needed to determine how much
bandwidth is “enough” (for that much traffic)

32
 Providing multiple classes of service
• thus far: making the best of best effort service
• one-size fits all service model
• alternative: multiple classes of service
• partition traffic into classes
• network treats different classes of traffic differently (analogy: VIP service
versus regular service)
 granularity: differential
service among multiple
classes, not among
individual connections
 history: ToS bits
Providing multiple classes of service
o thus far: making the best of best effort service
 one-size fits all service model
o alternative: multiple classes of service
 partition traffic into classes
 network treats different classes of traffic differently (analogy:
VIP service versus regular service)
o granularity: differential
service among multiple
classes, not among 0111

individual connections
o history: ToS bits
Competing audio and HTTP applications
Multiple classes of service: scenario

H3
H1
R1 R2

H4
H2 R1 output 1.5 Mbps link
interface
queue
Scenario 1: mixed HTTP and VoIP
 example: 1Mbps VoIP, HTTP share 1.5 Mbps link.
 HTTP bursts can congest router, cause audio loss
 want to give priority to audio over HTTP

R1
R2

Principle 1
packet marking needed for router to distinguish between
different classes; and new router policy to treat packets
accordingly
Principles for QOS guarantees (more)
 what if applications misbehave (VoIP sends higher
than declared rate)
 policing: force source adherence to bandwidth allocations
 marking, policing at network edge
1 Mbps
phone
R1 R2

1.5 Mbps link

packet marking and policing

Principle 2
provide protection (isolation) for one class from others
Principles for QOS guarantees (more)
 allocating fixed (non-sharable) bandwidth to flow:
inefficient use of bandwidth if flows doesn’t use its
allocation
1 Mbps 1 Mbps logical link
phone R1
R2

1.5 Mbps link

0.5 Mbps logical link

Principle 3
while providing isolation, it is desirable to use
resources as efficiently as possible
• scheduling: choose next packet to send on link
Scheduling Mechanisms
• 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

40
 Scheduling policies: priority
high priority queue
(waiting area)
priority scheduling: send highest
priority queued packet arrivals departures

• multiple classes, with classify link

different priorities low priority queue
(server)

• class may depend on (waiting area)

marking or other header 2

1 3 4 5
info, e.g. IP source/dest,
arrivals
port numbers, etc.
packet in
• real world example? service 1 3 2 4 5

departures
1 3 2 4 5
 Scheduling policies: still more
Round Robin (RR) scheduling:
• multiple classes
• cyclically scan class queues, sending one complete packet from
each class (if available)
2
1 3 4 5
arrivals

packet in
service 1 3 2 4 5

departures
1 3 3 4 5

42
 Scheduling policies: still more

Weighted Fair Queuing (WFQ):

• generalized Round Robin
• each class gets weighted amount of service in each cycle
• real-world example?

43
 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)

44
 Policing mechanisms:
implementation

token bucket: limit input to specified burst size and average

rate

45

• bucket can hold b tokens

• token bucket, WFQ combine to provide guaranteed upper bound
Policing and QoS guarantees
on delay, i.e., QoS guarantee!

arriving token rate, r

traffic

bucket size, b
per-flow
rate, R
WFQ

arriving
D = b/R
max
traffic 46
 Differentiated services
• want “qualitative” service classes
• “behaves like a wire”
• relative service distinction: Platinum, Gold, Silver
• scalability: placing only simple functionality within the
network core, with more complex control operations
being implemented at edge routers (or hosts)
• signaling, maintaining per-flow router state difficult with large
number of flows
• don’t define service classes, provide functional
components to build service classes
47
 Diffserv architecture marking
r
edge router:
b scheduling
 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 over out-of-profile
packets
 Edge-router packet marking
• profile: pre-negotiated rate r, bucket size b
rate r
• packet marking at edge based on per-flow profile

user packets

possible use of marking:

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

49
 Diffserv packet marking: details
• 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)
• determine PHB that the packet will receive
• 2 bits currently unused

DSCP unused

50
 Classification, conditioning
may be desirable to limit traffic injection rate of some class:
• user declares traffic profile (e.g., rate, burst size)
• traffic metered, shaped if non-conforming

51
Forwarding Per-hop Behavior (PHB)
• 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

52
 Forwarding PHB

PHBs proposed:
• expedited forwarding: pkt departure rate of a class equals or
exceeds specified rate
• logical link with a minimum guaranteed rate
• assured forwarding: 4 classes of traffic
• each guaranteed minimum amount of bandwidth
• each with three drop preference partitions

53
• basic fact of life: can not support traffic demands beyond link capacity
Per-connection QOS guarantees
• consider two 1 Mbps audio applications transmitting their packets over
the 1.5 Mbps link
1 Mbps
phone R1 R2

1 Mbps 1.5 Mbps link

phone

Principle
call admission: flow declares its needs, network may
block call (e.g., busy signal) if it cannot meet needs 54
 Thank you!

Next: Protocols for real-time streaming

55