Telematics

Chapter 11: Multimedia Networking

Beispielbild
User Server
watching with video
video clip clips

Application Layer Application Layer

Univ.-Prof. Dr.-Ing. Jochen H. Schiller Presentation Layer Presentation Layer

Computer Systems and Telematics (CST) Session Layer Session Layer

Institute of Computer Science Transport Layer Transport Layer

Network Layer Network Layer Network Layer

Freie Universität Berlin
Data Link Layer Data Link Layer Data Link Layer
[Link]
Physical Layer Physical Layer Physical Layer
Contents
● Design issues
● Multimedia networking applications
● Streaming stored audio and video
● Making the best out of best effort service
● Protocols for real-time interactive applications
● Providing multiple classes of service
● Providing QoS guarantees

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.2
Design Issues
● Two kinds of applications
● Non-real-time applications OSI Reference Model
● Email, FTP, Application Layer
● Real-time applications
Presentation Layer
● Audio, video
● Principles Session Layer
● Classify multimedia applications
Transport Layer
● Identify network services
applications need
Network Layer
● Making the best of the best effort
service Data Link Layer
● Protocols and Architectures
Physical Layer
● Specific protocols for best-effort
● Mechanisms for providing QoS
● Architectures for QoS

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.3
Multimedia and Quality of Service: What is it?

Multimedia applications:
Network audio and video
(“continuous media”)

QoS
Network provides
application with level of
performance needed for
application to function.

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.4
Quality of Service in the Internet
● Problem today:
● IP is packet switched, therefore no guarantees on transmission is given
● Throughput, transmission delay, …
● The Internet transmits data at best effort
● But: many applications need a certain Quality of Service (QoS)

Application Reliability Delay Jitter Throughput

E-Mail high low low low
File Transfer high low low medium
Web Access high medium low medium
Remote Login high medium medium low
Audio on Demand low low high medium
Video on Demand low low high high
IP Telephony low high high low
Video Conference low high high high

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.5
QoS Parameters
● Throughput [bit/s]
● Which minimum/maximum/average data rate is necessary?
● Transmission delay [s]
● Which maximum delay is tolerable?
● Jitter [s]
● Which fluctuations in the transmission delay are tolerable?
● Availability [%]
● With which probability the communication service is available?

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.6
 Multimedia networking applications

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.7
MM Networking Applications
● Classes of MM applications: A B
● Stored streaming t1
● Live streaming t2
● Interactive, real-time t3 t‘1
t4 t‘2
t‘3
● Fundamental characteristics:
t‘4
● Typically delay sensitive
● End-to-end delay
● Delay jitter
Time
● Loss tolerant: infrequent losses di = t‘i – ti
cause minor glitches ji = di+1 – di
● Antithesis of data, which are loss
intolerant but delay tolerant

Jitter ji is the variability of packet

delays within the same packet stream
Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.8
Streaming Stored Multimedia

● Stored streaming:
● Media stored at source
● Transmitted to client
● Streaming: client play out begins
before all data has arrived
● Timing constraint for still-to-be
transmitted data: in time for play out

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.9
Streaming Stored 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

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.10
Streaming Stored Multimedia: Interactivity

● VCR-like functionality:
● Client can
● pause, rewind, FF, push slider bar
● Delay restrictions
● 10 sec initial delay OK
● 1-2 sec until command effect OK
● Timing constraint for still-to-be
transmitted data: in time for play
out

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.11
Streaming Live Multimedia
● Examples:
● Internet radio talk show
● Live sporting event
● Streaming (as with streaming stored multimedia)
● Playback buffer
● Playback can lag tens of seconds after transmission
● Still have timing constraint
● Interactivity
● Fast forward impossible
● Rewind, pause possible!

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.12
Real-Time Interactive Multimedia
● Applications
● IP telephony, video conference
● Distributed interactive worlds
● End-to-end delay requirements
● Audio: <150 msec good, <400 msec OK
● Includes application-level (packetization)
and network delays
● Higher delays noticeable, impair
interactivity
● Session initialization
● How does callee advertise its IP address,
port number, encoding algorithms?

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.13
Multimedia Over Today’s Internet
● TCP/UDP/IP: “best-effort service”
● No guarantees on delay, loss

? ? ?
? ? ?
But you said multimedia apps require ?
QoS and level of performance to be
? ? effective! ? ?

Today’s Internet multimedia applications

use application-level techniques to mitigate
(as best possible) effects of delay, loss

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.14
How should the Internet evolve to better
support multimedia?
● Integrated services philosophy
● Fundamental changes in Internet so that apps can reserve end-to-end bandwidth
● Requires new, complex software in hosts & routers

● Laissez-faire
● No major changes
● More bandwidth when needed
● Content distribution, application-layer multicast
● Application layer

What’s your opinion?

● Differentiated services philosophy
● Fewer changes to Internet infrastructure
● Provide small number of service classes (maybe two)

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.15
How should the Internet evolve to better
support multimedia?
Approach Unit of Guarantee Deployment Complexity Mechanisms
allocation to date
Making the best of None None or soft Everywhere Minimal Application-layer
best-effort service support, CDN,
over-provisioning
Differential QoS Classes of None or soft Some Medium Policing,
flows scheduling
Guaranteed QoS Individual Soft or hard, Little High Policing,
flows once a flow is scheduling, call
admitted admission and
signaling

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.16
 Multimedia networking applications
Audio and Video Compression

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.17
A few words about audio compression
● Analog signal sampled at constant ● Example:
rate ● 8,000 samples/sec, 256 quantized
● Telephone: 8,000 samples/sec values  64,000 bps
● CD music: 44,100 samples/sec ● Receiver converts bits back to
analog signal
● Each sample quantized, i.e.,
● Some quality reduction
rounded
● 28=256 possible quantized values
● Each quantized value represented ● Example rates
by bits ● CD: 1.411 Mbps (stereo)
● 8 bits for 256 values ● MP3: 96, 128, 160 kbps
● GSM: 13 kbps
● Internet telephony
● G.729: 8 kbps
● G.723.3: 5.3 kbps and 6.4 kbps

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.18
A few words about video compression
● Video: sequence of images ● Examples:
displayed at constant rate ● MPEG1 (CD-ROM) 1.5 Mbps
● Frame rate 24 images/sec ● MPEG2 (DVD) 3-6 Mbps
● Digital image: array of pixels ● MPEG4 <1 Mbps
● Each pixel represented by bits ● Often used in Internet
● Redundancy ● Research: layered (scalable)
● Spatial (within image) video
● Temporal (from one image to next) ● Adapt layers to available bandwidth

● Example
● Single image of 1024 * 768 pixels
● Each pixel encoded into 24 bits
2.25 Mbyte without compression
Compression ratio 10:1 results in <
250 kbyte

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.19
 Streaming stored audio and video

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.20
Streaming Stored Multimedia
● Application-level streaming techniques for making the best out of best
effort service:
● Client-side buffering
● Use of UDP versus TCP
● Multiple encodings of multimedia

● Media Player
● Jitter removal
● Decompression
● Error concealment
● Graphical user interface
with controls for interactivity

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.21
Internet multimedia: Simplest approach
● Audio or video stored in file
● Files transferred as HTTP object
● Received in entirety at client
● Then passed to player
Web
browser
Web
server
● Audio, video not streamed: with audio
Media files
● No, “pipelining,” long delays until Player
play out!

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.22
Internet multimedia: Streaming approach

Web
browser
Web
(2) Meta file
server
with audio
Media files
Player

● Browser gets metafile

● Browser launches player, passing metafile
● Player contacts server
● Server streams audio/video to player
Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.23
Streaming from a streaming server

(1) HTTP request/response for

Web
Web presentation description file
server
browser
(2) presentation
description file
(3) Audio/video file
Media requested and sent Streaming
Player server

● Allows for non-HTTP protocol between server and media player

● UDP or TCP for step (3)

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.24
Streaming Multimedia: Client Buffering

constant bit
rate video client video constant bit
transmission reception rate video
playout at client
variable
network

buffered
video
delay

client playout time

delay

● Client-side buffering, play out delay compensate for network-

added delay, delay jitter

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.25
Streaming Multimedia: Client Buffering

Client buffer

Variable fill Constant

rate = x(t) drain rate = d To
From decompression
network and playout

Buffered
video

● Client-side buffering, play out delay compensate for network-

added delay, delay jitter

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.26
Streaming Multimedia: UDP or TCP?
● UDP
● Server sends at rate appropriate for client (oblivious to network congestion !)
● Often send rate = encoding rate = constant rate
Fill rate = constant rate - packet loss
● Short play out delay (2-5 seconds) to remove network jitter
● Error recover: time permitting

● TCP
● Send at maximum possible rate under TCP
● Fill rate fluctuates due to TCP congestion control
● Larger play out delay: smooth TCP delivery rate
● HTTP/TCP passes more easily through firewalls

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.27
Streaming Multimedia: Client rate(s)

1.5 Mbps encoding

28.8 kbps encoding

● Q: How to handle different client receive rate capabilities?

● 28.8 kbps dialup
● 100 Mbps Ethernet
● A: Server stores, transmits multiple copies of video, encoded at different
rates
Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.28
 Streaming stored audio and video
RTSP

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.29
User Control of Streaming Media: RTSP
● HTTP ● What it does not do:
● Does not target multimedia content ● Does not define compression
● No commands for fast forward, etc. schemes
● Does not define how audio/video is
encapsulated for streaming over
● RTSP: RFC2326 network
● Client-server application layer ● Does not restrict how streamed
protocol media is transported (UDP or TCP
● User control possible)
● rewind ● Does not specify how media player
● fast forward buffers audio/video
● pause, resume
● repositioning, etc.

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.30
RTSP: Out of band control
● FTP uses an “out-of-band” control ● RTSP messages also sent out-of-
channel: band:
● File transferred over one TCP ● RTSP control messages use
connection. different port numbers than media
● Control info (directory changes, file stream: out-of-band
deletion, rename) sent over ● Port 554
separate TCP connection ● Media stream is considered “in-
● “Out-of-band”, “in-band” channels band”
use different port numbers

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.31
RTSP Example
● Scenario:
● Metafile communicated to web browser
● Browser launches player
● Player sets up an RTSP control connection, data connection to streaming server
● Metafile example
<title>Twister</title>
<session>
<group language=en lipsync>
<switch>
<track type=audio
e="PCMU/8000/1"
src = "rtsp://[Link]/twister/[Link]/lofi">
<track type=audio
e="DVI4/16000/2" pt="90 DVI4/8000/1"
src="rtsp://[Link]/twister/[Link]/hifi">
</switch>
<track type="video/jpeg“ src="rtsp://[Link]/twister/video">
</group>
</session>

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.32
RTSP Operation

HTTP Get
Web
Web server
browser Presentation description file

Setup
Media Streaming
Player Play
server

Media stream

Pause

Teardown

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.33
RTSP Exchange Example
C: SETUP rtsp://[Link]/twister/audio RTSP/1.0
Transport: rtp/udp; compression; port=3056; mode=PLAY
Difference to HTTP
S: RTSP/1.0 200 1 OK
RTSP tracks session and
Session 4231 state of the client

C: PLAY rtsp://[Link]/twister/[Link]/lofi RTSP/1.0

Session: 4231
Range: npt=0-

C: PAUSE rtsp://[Link]/twister/[Link]/lofi RTSP/1.0

Session: 4231
Range: npt=37

C: TEARDOWN rtsp://[Link]/twister/[Link]/lofi RTSP/1.0

Session: 4231

S: 200 3 OK

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.34
 Making the best out of best-effort service
Removing Jitter at the Receiver

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.35
Interactive Multimedia: Internet Phone
● Look at a PC-2-PC Internet phone example in detail
● Speaker’s audio: alternating talk spurts and silent periods
● 64 kbps during talk spurt
● Packets generated only during talk spurts
● 20 msec chunks at 8000 byte/sec  1 chunk = 160 byte data
● Application-layer header added to each chunk
● Chunk+header encapsulated into UDP segment
● Application sends UDP segment into socket every 20 msec during talkspurt

Talk Silence

Time

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.36
Internet Phone: Packet Loss and Delay
● Network loss: IP datagram lost due to network congestion
● Router buffer overflow
● Delay loss: IP datagram arrives too late for play out at receiver
● Delays:
● Processing
● Queuing in network
● End-system (sender, receiver) delays
● Typical maximum tolerable delay: 400 ms
● Loss tolerance
● Depending on voice encoding, losses concealed, packet loss rates between 1%
and 10% can be tolerated

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.37
Delay Jitter
constant bit
rate client constant bit
transmission reception rate playout
at client
variable
network

buffered
delay

data
(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)

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.38
Internet Phone: Fixed Playout Delay
● Receiver attempts to play out each chunk exactly q msecs after chunk was
generated.
● Chunk has time stamp t: play out chunk at t+q
● Chunk arrives after t+q  data arrives too late for play out, data “lost”
● Tradeoff in choosing q:
● Large q: less packet loss
● Small q: better interactive experience

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.39
Fixed Playout Delay
● Sender generates packets every 20 msec during talk spurt
● First packet received at time r
● First playout schedule: begins at p
● Second playout schedule: begins at p’
packets

packets loss
generated
packets
playout schedule
received
p' - r

playout schedule
p-r

time

r
p p'

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.40
Adaptive Playout Delay (1)
● Goal: minimize playout delay, keeping late loss rate low
● Approach: adaptive playout delay adjustment:
● Estimate network delay, adjust playout delay at beginning of each talk spurt
● Silent periods compressed and elongated
● Chunks still played out every 20 msec during talk spurt

ti  timestamp of the i - th packet

ri  the time packet i is received by receiver
pi  the time packet i is played at receiver
ri  ti  network delay for i - th packet
d i  estimate of average network delay after receiving i - th packet

● Dynamic estimate of average delay at receiver: di  (1  u)di 1  u(ri  ti )

● where u is a fixed constant (e.g., u = 0.01).

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.41
Adaptive playout delay (2)
● Also useful to estimate average deviation of delay vi :
vi  (1  u)vi 1  u | ri  ti  di |

● Estimates di , vi calculated for every received packet, but used only at start
of talk spurt

● For first packet in talk spurt, playout time is:

pi  ti  di  Kvi
● where K is positive constant, e.g., K=4

● Remaining packets in talkspurt are played out periodically

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.42
Adaptive Playout (3)
● Q: How does receiver determine whether packet is first in a talkspurt?

● If no loss, receiver looks at successive timestamps.

● Difference of successive stamps > 20 msec talk spurt begins.

● With loss possible, receiver must look at both time stamps and sequence
numbers.
● Difference of successive stamps > 20 msec and
sequence numbers without gaps  talk spurt begins.

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.43
 Making the best out of best effort service
Recovery from packet loss

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.44
Recovery from packet loss (1)
● Forward Error Correction (FEC): ● Playout delay: enough time to
simple scheme receive all n+1 packets
● For every group of n chunks create ● Tradeoff:
redundant chunk by exclusive or- ● Increase n, less bandwidth waste
ing n original chunks ● Increase n, longer playout delay
● Send out n+1 chunks, increasing ● Increase n, higher probability that 2
bandwidth by factor 1/n. or more chunks will be lost
● Can reconstruct original n chunks if
at most one lost chunk from n+1
chunks RTP Header (12 octets or more)
FEC Header (10 octets)
FEC Level 0 Header
FEC Level 0 Payload
FEC Level 1 Header
FEC Level 1 Payload
Cont.
FEC Packet Structure RFC5109

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.45
Recovery from packet loss (1): FEC
● The FEC header is 10 octets RTP Header (12 octets or more)
● Extension flag (E bit) FEC Header (10 octets)
● Long-mask flag (L bit) FEC Level 0 Header
● P recovery field FEC Level 0 Payload
● X recovery field FEC Level 1 Header

● CC recovery field FEC Level 1 Payload

● M recovery field Cont.

FEC Packet Structure RFC5109
● PT recovery field
● SN base field
● TS recovery field From RTP header

● Length recovery field

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.46
Recovery from packet loss (2)
● 2nd FEC scheme
● “Piggyback lower
quality stream”
● send lower resolution
audio stream as
redundant information
● e.g., nominal
stream PCM at 64 kbps
and redundant stream
GSM at 13 kbps.
● Whenever there is non-
consecutive loss,
receiver can conceal the loss.
● Can also append (n-1)-st and
(n-2)-nd low-bit rate chunk

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.47
Recovery from packet loss (3)

Interleaving
● Chunks divided into smaller units ● If packet lost, still have most of
every chunk
● For example, four 5 msec units per
chunk ● No redundancy overhead, but
increases playout delay
● Packet contains small units from
different chunks

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.48
 Making the best out of best-effort-service
Content Distribution Networks (CDN)

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.49
Content distribution networks (CDNs)
● Content replication Origin server
● Challenging to stream large files in North America
(e.g., Video) from single origin
server in real time
● Solution: replicate content at
hundreds of servers throughout
internet CDN distribution node
● Content downloaded to CDN servers
ahead of time
● Placing content “close” to user avoids
impairments (loss, delay) of sending
content over long paths
● CDN server typically in edge/access
network
CDN server
CDN server CDN server
in Asia
in S. America in Europe

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.50
Content distribution networks (CDNs)
● Content replication Origin server
● CDN (e.g., Akamai) customer is the in North America
content provider (e.g., CNN)
● CDN replicates customers’ content
in CDN servers.
● when provider updates content,
CDN updates servers CDN distribution node

CDN server
CDN server CDN server
in Asia
in S. America in Europe

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.51
CDN example
● Origin server ([Link]) ● CDN company ([Link])
● Distributes HTML ● Distributes gif files
● Replaces: ● Uses its authoritative DNS server to
[Link] route redirect requests
with
[Link]

HTTP request for

[Link]/sports/[Link]
origin server
1
DNS query for
2 [Link]
CDN’s authoritative
Client DNS server
3

HTTP request for

[Link]/[Link]/sports/[Link]
CDN server near client
Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.52
More about CDNs
● Routing requests
● CDN creates a “map”, indicating distances from leaf ISPs and CDN nodes
● When query arrives at authoritative DNS server:
● Server determines ISP from which query originates
● Uses “map” to determine best CDN server
● CDN nodes create application-layer overlay network

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.53
Summary: Internet Multimedia / Bag of tricks
● Use UDP to avoid TCP congestion control (delays) for time-sensitive traffic
● Client-side adaptive playout delay: to compensate for delay
● Server side matches stream bandwidth to available client-to-server path
bandwidth
● Chose among pre-encoded stream rates
● Dynamic server encoding rate
● Error recovery (on top of UDP)
● FEC, interleaving, error concealment
● Retransmissions, time permitting
● CDN: bring content closer to clients

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.54
 Protocols for real-time interactive
applications
RTP, RTCP, SIP

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.55
Real-Time Protocol (RTP)
● RTP specifies packet structure for
packets carrying audio and video data
● RTP packet provides
● Payload type identification
● Packet sequence numbering
● Time stamping
● RTP runs in end systems
● RTP packets encapsulated in UDP
segments
● Interoperability: if two Internet phone
applications run RTP, then they may be RFC6222
able to work together
RFC5761

RFC6051

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.56
RTP runs on top of UDP
● RTP libraries provide transport-
layer interface that extends UDP
● Port numbers, IP addresses Applicaton
● Payload type identification Transport RTP
● Packet sequence numbering Layer UDP
● Time-stamping IP
Data Link
Physical

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.57
RTP Example
● Consider sending 64 kbps PCM- ● RTP header indicates type of
encoded voice over RTP. audio encoding in each packet
● Application collects encoded data ● Sender can change encoding
in chunks, e.g., during conference.
every 20 msec = 160 bytes ● RTP header also contains
in a chunk. sequence numbers, timestamps.
● Audio chunk + RTP header form
RTP packet, which is
encapsulated in UDP segment

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.58
RTP and QoS
● RTP does not provide any mechanism to ensure timely data delivery or
other QoS guarantees.
● RTP encapsulation is only seen at end systems (not) by intermediate
routers.
● Routers providing best-effort service, making no special effort to ensure that RTP
packets arrive at destination in timely matter.

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.59
RTP Header
● Version (V): This field identifies the version of RTP
● Padding (P): If P is set, the packet contains one or more additional padding octets
● Extension (X): If X is set, the fixed header MUST be followed by exactly one extension
● CSRC count (CC): number of CSRC identifiers that follow the fixed header
● Marker (M): interpretation of the marker is defined by a profile
● Payload Type (PT): identifies the format of the RTP payload
● Sequence Number: increments by one for each RTP data packet sent
● Timestamp: reflects the sampling instant of the first octet in the RTP data packet
● SSRC: field identifies the synchronization source
● CSRC list: 0 to 15 items. The CSRC list identifies the contributing sources for the
payload contained in this packet.

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.60
RTP Header
● Payload Type: Indicates type of encoding currently being used
● If sender changes encoding in middle of conference, sender informs
receiver via payload type field.
● Payload type 0: PCM µ-law, 64 kbps
● Payload type 3: GSM, 13 kbps
● Payload type 7: LPC, 2.4 kbps
● Payload type 26: Motion JPEG
● Payload type 31: H.261
● Payload type 33: MPEG2 video
● Sequence Number (16 bits): Increments by one for each RTP packet sent,
and may be used to detect packet loss and to restore packet sequence.

Sequence Synchronization Miscellaneous

Payload Type Timestamp
Number Source Identifier Fields
RTP Header
Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.61
RTP Header (2)
● Timestamp field (32 bits long): sampling instant of first byte in this RTP
data packet
● For audio, timestamp clock typically increments by one for each sampling period
(for example, each 125 µs for 8 kHz sampling clock)
● If application generates chunks of 160 byte encoded samples, then timestamp
increases by 160 for each RTP packet when source is active. Timestamp clock
continues to increase at constant rate when source is inactive.

● SSRC field (32 bits long): identifies source of the RTP stream. Each stream
in RTP session should have distinct SSRC.

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.62
 Protocols for real-time interactive
applications
RTCP

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.63
Real-Time Control Protocol (RTCP)
● Works in conjunction with RTP ● Feedback can be used to control
● Each participant in RTP session performance
periodically transmits RTCP ● Sender may modify its
control packets to all other transmissions based on feedback
participants.
● Each RTCP packet contains
sender and/or receiver reports
● Report statistics useful to
application
● Number of packets sent
● Number of packets lost
● Interarrival jitter, etc.

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.64
RTCP - Continued
● Each RTP session: typically a
single multicast address
● All RTP/RTCP packets belonging to
RTP
session use multicast address.
RTCP
● RTP and RTCP packets are
distinguished from each other via
distinct port numbers
● RTCP Port = RTP Port + 1 Internet
● To limit traffic, each participant
reduces RTCP traffic as number
of conference participants RTCP RTCP

increases

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.65
RTCP Packets
● Receiver report packets: ● Source description packets:
● Fraction of packets lost, ● E-mail address of sender
● Last sequence number ● Sender's name
● Average interarrival jitter ● SSRC of associated RTP stream
● Sender report packets: ● Provide mapping between the SSRC
● SSRC of RTP stream and the user/host name
● Current time
● Number of packets sent
● Number of bytes sent

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.66
Synchronization of Streams
● RTCP can synchronize different ● Each RTCP sender-report packet
media streams within a RTP contains (for most recently
session generated packet in associated
● Consider videoconferencing app RTP stream):
for which each sender generates ● Timestamp of RTP packet
one RTP stream for video, one for ● Wall-clock time for when packet
audio. was created.
● Timestamps in RTP packets tied ● Receivers uses association to
to the video, audio sampling synchronize playout of audio,
clocks video
● not tied to wall-clock time

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.67
RTCP Bandwidth Scaling
● RTCP attempts to limit its traffic ● 75 kbps is equally shared among
to 5% of session bandwidth. receivers:
● Example ● With R receivers, each receiver
● Suppose one sender, sending video gets to send RTCP traffic at 75/R
at 2 Mbps. Then RTCP attempts to kbps.
limit its traffic to 100 kbps. ● Sender gets to send RTCP traffic
● RTCP gives 75% of rate to at 25 kbps.
receivers; remaining 25% to sender ● Participant determines RTCP
packet transmission period by
calculating avg RTCP packet size
(across entire session) and
dividing by allocated rate

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.68
 Protocols for real-time interactive
applications
Session Initiation Protocol (SIP)

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.69
SIP: Session Initiation Protocol [RFC 3261]
● SIP long-term vision:
● All telephone calls, video conference calls take place over Internet
● People are identified by names or e-mail addresses, rather than by phone
numbers
● You can reach callee, no matter where callee roams, no matter what IP device
callee is currently using

RFC5922 RFC5954 RFC6026 RFC6141

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.70
SIP Services
● Setting up a call, SIP provides ● Determine current IP address of
mechanisms .. callee:
● For caller to let callee know she ● Maps mnemonic identifier to
wants to establish a call current IP address
● So caller and callee can agree on ● Call management:
media type, encoding ● Add new media streams during call
● To end call ● Change encoding during call
● Invite others
● Transfer, hold calls

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.71
Setting up a call to known IP address
● Alice’s SIP invite message
indicates her port number, IP
address, encoding she prefers to
receive (PCM µlaw)
● Bob’s 200 OK message indicates
his port number, IP address,
preferred encoding (GSM)
● SIP messages can be sent over
TCP or UDP; here sent over
RTP/UDP.
● Default SIP port number is 5060.

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.72
Setting up a call (more)
● Codec negotiation: ● Rejecting a call
● Suppose bob doesn’t have PCM ● Bob can reject with replies
µlaw encoder. ● “busy”
● Bob will instead reply with 606 not ● “gone”
acceptable reply, listing his ● “payment required”
encoders Alice can then send new ● “forbidden”
invite message, advertising
different encoder
● Media can be sent over RTP or
some other protocol

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.73
Example of SIP message
 Here we don’t know
INVITE sip:bob@[Link] SIP/2.0 Bob’s IP address.
Via: SIP/2.0/UDP [Link] Intermediate SIP
From: sip:alice@[Link] servers needed.
To: sip:bob@[Link]
Call-ID: a2e3a@[Link]
 Alice sends, receives
Content-Type: application/sdp
Content-Length: 885 SIP messages using
SIP default port 506

 Alice specifies in Via:

c=IN IP4 [Link]
m=audio 38060 RTP/AVP 0 header that SIP client
sends, receives SIP
messages over UDP
Notes:
● HTTP message syntax
● SDP = session description protocol
● Call-ID is unique for every call.
Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.74
Name translation and user locataion
● Caller wants to call callee, but ● Result can be based on:
only has callee’s name or e-mail ● Time of day (work, home)
address. ● Caller (don’t want boss to call you
● Need to get IP address of callee’s at home)
current host: ● Status of callee (calls sent to
● User moves around voicemail when callee is already
talking to someone)
● DHCP protocol
● User has different IP devices (PC, ● Service provided by SIP servers:
PDA, car device) ● SIP registrar server
● SIP proxy server

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.75
SIP Registrar

 When Bob starts SIP client, client sends SIP REGISTER

message to Bob’s registrar server
(similar function needed by Instant Messaging)

Register Message:
REGISTER sip:[Link] SIP/2.0
Via: SIP/2.0/UDP [Link]
From: sip:bob@[Link]
To: sip:bob@[Link]
Expires: 3600

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.76
SIP Proxy
● Alice sends invite message to her proxy server
● Contains address sip:bob@[Link]
● Proxy responsible for routing SIP messages to callee
● Possibly through multiple proxies.
● Callee sends response back through the same set of proxies.
● Proxy returns sip response message to Alice
● Contains bob’s IP address
● Proxy analogous to local DNS server

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.77
Example
● Caller jim@[Link] who places a
call to keith@[Link] SIP registrar
[Link]

1) Jim sends INVITE message to umass SIP proxy 2

SIP registrar
SIP proxy. [Link] 3
[Link]
2) Proxy forwards request to upenn 4
registrar server.
1 7
3) upenn server returns redirect 5
response, indicating that it should try 8 6
keith@[Link] 9
4) umass proxy sends INVITE to
eurecom registrar. SIP client SIP client
5) eurecom registrar forwards INVITE [Link] [Link]
to [Link], which is running
keith’s SIP client.
6-8) SIP response sent back
9) media sent directly between clients.
Note: there is also a SIP ack message,
which is not shown.

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.78
 Protocols for real-time interactive
applications
H.323

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.79
Alternative to SIP: H.323

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.80
Alternative to SIP: H.323

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.81
Comparison: SIP vs. H.323
● H.323 is another signaling ● H.323 comes from the ITU
protocol for real-time, interactive (telephony)
● H.323 is a complete, vertically ● SIP comes from IETF:
integrated suite of protocols for ● Borrows much of its concepts from
multimedia conferencing: HTTP
● Signaling ● SIP has Web flavor, whereas H.323
● Registration has telephony flavor
● Admission control ● SIP uses the KISS principle
● Transport ● Keep it simple stupid.
● Codecs
● SIP is a single component
● Works with RTP, but does not
mandate it
● Can be combined with other
protocols, services

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.82
 Providing multiple classes of service

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.83
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 vs regular service
● Granularity: differential service among multiple classes, not among individual
connections
● History:
● Type of Service (TOS) bits
in IPv4

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.84
Multiple classes of service: Scenario

H3
H1
R1 R2

H4
H2 1.5 Mbps link

R1 output
interface
queue

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.85
Scenario: Mixed FTP and Audio
● Example: 1Mbps IP phone and FTP share 1.5 Mbps link
● Bursts of FTP can congest router  cause audio loss
● Want to give priority to audio over FTP

H1 H3
R1 R2

H4
H2

Principle 1
Packet marking needed for router to distinguish between different classes;
and new router policy to treat packets accordingly

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.86
Principles for QOS Guarantees
● What if applications misbehave (audio sends higher than declared rate)
● Policing: force source adherence to bandwidth allocations
● Marking and policing at network edge:
● Similar to ATM UNI (user network interface)

H1 H3
R1 R2
1 Mbps 1.5 Mbps link
phone

H4
H2
packet marking
and policing

Principle 2
Provide protection (isolation) for one class from others

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.87
Principles for QOS Guarantees
● Allocating fixed (non-sharable) bandwidth to flow: inefficient use
of bandwidth if a flow does not use its allocation

R1 1 Mbps logical link

H1 H3
R2

H4
H2
0.5 Mbps logical link

Principle 3
While providing isolation, it is desirable to use resources as efficiently as
possible
Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.88
 Providing multiple classes of service
Scheduling and Policing Mechanisms

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.89
Scheduling and Policing Mechanisms
● Scheduling: choose next packet to send on link
● FIFO (first in first out) scheduling: send in order of arrival to queue
● Real-world example?
● 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

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.90
Scheduling Policies: Priority based
● 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.
● Real world example?

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.91
Scheduling Policies: Round Robin
● Round robin scheduling:
● Multiple classes
● Cyclically scan class queues, serving one from each class (if available)
● Class 1, Class 2, Class 1, ...
● Real world example?

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.92
Scheduling Policies: Weighted Fair Queuing (WFQ)
● Weighted fair queuing
● Generalized round robin
wi
● Each class gets weighted amount of service in each cycle Wi  N

● For a link with transmission rate R, class i will get a w

j 1
j

throughput of Ri=R×Wi
● Real-world example?

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.93
Policing Mechanisms
● Goal: Limit traffic to not exceed declared parameters

● Three common-used criteria:

● Average Rate: how many packets can be sent per unit time (in the long run)
● Long term criteria
● Crucial question: What is the interval length?

100 packets per sec or 6000 packets per min have same average!

● Peak Rate: restriction of number of packets for a short time, e.g.,

● Average rate: 6000 packets/min
● Peak rate: 500 packets/sec

● Burst Size: max. number of packets sent consecutively (with no intervening idle)

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.94
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 ≤ (r t + b)

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.95
Policing Mechanisms
● Combine Token Bucket and WFQ to provide guaranteed upper bound on
delay, i.e., QoS guarantee!
● n flows with leaky buckets of parameters ri and bi
● Each flow receives a share Ri of the bandwidth R
w
Ri  R N i
 wj j 1

● Maximum delay of flow i is dmax

bi
d max 
R Nwi
wj
j 1

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.96
 Providing multiple classes of service
Differentiated Services

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.97
IETF Differentiated Services
● Want “qualitative” service classes
● “Behaves like a wire”
● Relative service distinction: platinum, gold, silver
● Scalability: simple functions in network core, relatively complex functions
at edge routers (or hosts)
● Signaling
● Maintaining per-flow router state
● Difficult with large number of flows
● Do not define service classes, provide functional components to build
service classes

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.98
Diffserv Architecture
● Edge router: ● Core router:
● Per-flow traffic management ● Per class traffic management
● Marks packets as in-profile and out- ● Buffering and scheduling based on
profile marking at edge
● Preference given to in-profile
packets

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.99
Classification and 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

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.100
Per Hop Behavior (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

● Two PHBs are defined

● Expedited forwarding behavior EF-PHB
● Assured forwarding behavior AF-PHB

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.101
Expedited Forwarding
● Idea with Expedited Forwarding:
● There are “regular” and “expedited” packets.
● Expedited packets are forwarded to guarantee a minimum data transmission rate
● Routers can manage two separated queues for these packet types (Weighted
Fair Queuing).
● Possible: low loss rate/delay/jitter as well as a guaranteed data transmission rate

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.102
Assured Forwarding
● Improves differentiation: Definition of 4 priority classes with own
resources (at the moment; there also is room for more classes)
● For each class, 3 drop probabilities are defined: low, medium, high
● Thus: altogether 12 different service classes
● Principle:
● The priority class determines the portion of the transmission capacity of the
routers
● During high load, packets of lower priority would be discarded completely
● Fairness: packets of each priority class should have chances to survive
● Therefore definition of the probabilities for each class: by suitable selection of
the probabilities, a small part of the lowest priority level still is still forwarded,
while packets of higher priority classes are already discarded.

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.103
Assured Forwarding

1. Classification of the
packets in service
classes 4. Weighted Fair Queuing in
2. Appropriate choice of
DSCP tags accordance to priority
classes

3. Bring the data streams in a form according to their flow

specification. Exceeding the specifications leads to
discarding data. If thereafter still too much data are
present, discarding of packets in accordance with their
probability

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.104
Application of DiffServ with IP
● Use of the Type of Service field in IPv4 for the classification (DSCP –
Differentiated Service Code Point). The DSCP value defines the per-hop
behavior of the packet from one router to the next one.

Type of
Version IHL Total Length
Service
DM
Identification FF
Fragment Offset Prece-
D T R free
dence
Time to Live Protocol Header Checksum

Source Address
DSCP free
Destination Address

The code point defines the transmission class, which informs a router, how it
has to treat the packet in forwarding.

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.105
 Providing QoS guarantees

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.106
Principles for QoS Guarantees
● Basic fact of life: can not support traffic demands beyond link capacity

● Required for QoS

● Resource reservation
● Call admission

Principle 4
Call Admission: flow declares its needs, network may block call (e.g., busy
signal) if it cannot meet needs
Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.107
Principles for QoS Guarantees: Call Admission
● Call admission
● Traffic characterization and specification of the desired QoS
● Signaling for call setup
● Per-element call admission

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.108
Principles for QoS Guarantees: Call Admission
● Call admission ● Arriving session must
● Traffic characterization and ● declare its QoS requirement
specification of the desired QoS ● R-spec: defines the QoS being
● Signaling for call setup requested (RFC 2215)
● Per-element call admission ● Characterize traffic it will send
● T-spec: defines traffic characteristics
● Signaling protocol: needed to carry
R-spec and T-spec to routers
● RSVP

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.109
 Providing multiple classes of service
Integrated Services

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.110
QoS in the Internet: Integrated Services
● 1995-1997 standardized by the IETF as an architecture for the
transmission of multimedia streams
● Integrated Services (IntServ) uses RSVP for signaling of flow specifications
as well as reservations and provides QoS for each data flow individually

● Thus the principle adds a connection-orientation to IP

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.111
Integrated Services
● Classes of QoS
● Guaranteed: Data rate, delay and reliability are guaranteed. Deviations do not
occur, packets are not discarded. Suitable for intolerant real-time applications.
● Controlled Load: “weak” guarantees, small deviations are possible.
● Principle: for data streams of this class the network behaves as best effort for an
unloaded network. No guarantees are given, suitable for tolerant real-time
applications.
● Best Effort: as good as possible, normal Internet traffic.
● Problems
● Scalability: for each data flow a router has to maintain own flow specifications
● How can authorization and priority be treated for a reservation request?
● The QoS classes are not sufficient to differentiate reasonably between different
types of data streams.
● Possible: use IntServ only “at the edge” of large networks, where only few
data flows are present

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.112
Signaling in the Internet

connectionless no network
(stateless) forwarding best effort signaling protocols
by IP routers + service = in initial IP design

● New requirement: reserve resources along end-to-end path (end system,

routers) for QoS for multimedia applications
● RSVP: Resource Reservation Protocol [RFC 2205]
● “ … allow users to communicate requirements to network in robust and efficient
way.” i.e., signaling !
● Earlier Internet Signaling protocol: ST-II [RFC 1819]

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.113
RSVP Design Goals
● Accommodate heterogeneous receivers (different bandwidth along paths)
● Accommodate different applications with different resource requirements
● Make multicast a first class service, with adaptation to multicast group
membership
● Leverage existing multicast/unicast routing, with adaptation to changes in
underlying unicast, multicast routes
● Control protocol overhead to grow (at worst) linear in number receivers
● Modular design for heterogeneous underlying technologies

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.114
RSVP: does not…
● Specify how resources are to be reserved
● Rather: a mechanism for communicating needs
● Determine routes packets will take
● That’s the job of routing protocols
● Signaling decoupled from routing
● Interact with forwarding of packets
● Separation of control (signaling) and data (forwarding) planes

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.115
RSVP: Overview of operation
● Senders, receiver join a multicast group
● Done outside of RSVP
● Senders need not join group
● Sender-to-network signaling
● Path message: make sender presence known to routers
● Path teardown: delete sender’s path state from routers
● Receiver-to-network signaling
● Reservation message: reserve resources from sender(s) to receiver
● Reservation teardown: remove receiver reservations
● Network-to-end-system signaling
● Path error
● Reservation error

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.116
Guaranteeing Delay: Resource Reservation
● Establish a path through the network and reserve fixed amounts of
network capacity, buffer capacity and CPU time with the routers.
● Standardized by the IETF as Resource Reservation Protocol (RSVP)

● RSVP is not a routing protocol, but only an “addition” to such one.

● A description of the requirements of the receiver in form of a flow specification
(Level of the QoS) is needed.

● Categories of flow specification are

1. Best Effort: Take all free resources you can get
2. Rate Sensitive: a guaranteed (minimal) data transmission rate is necessary
3. Delay Sensitive: a guaranteed (maximal) delay is necessary

● RSVP can be used for Unicast and for Multicast

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.117
RSVP
● Procedure of RSVP
● The sender sends a RSVP Path Message to the receiver. Information about the
routers on the network path are being collected and communicated to the
receiver.
● Additionally, also flow specifications for the receiver are provided.
● The receiver sends back RSVP Reservation Messages along the collected path,
which contain its flow specification. Every router on the path reserves resources
accordingly.
● If a reservation is not possible with a router, an error message is sent back.
● As soon as the RSVP Reservation Message reaches the sender, the complete
path is reserved, the sender begins to send its data.
● To delete outdated reservations, timeouts are defined. If the receiver does not
refresh its reservation before expiration of the timer, it is deleted.

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.118
IntServ Router
RSVP signaling RSVP signaling
Reservation
Routing Setup Agent Policy
Agent (RSVP) Control

Admission
Control
Packet
Data Classifier Data
Packet
Scheduler

• Packet Classifier: classifies incoming • Routing Agent: instructs classifier

packets regarding QoS class about routes for data streams
• Packet Scheduler: sorts packets • Policy Control: checks the permission
regarding basing on QoS class for resource reservations
• Reservation Setup Agent: configures • Admission Control: decides if a new
Packet Classifier and Scheduler for reservation can be accepted based on
new connections resources already used

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.119
RSVP with Multicast

(a) A path from receiver 3 to sender 1

(b) A second path for sender 2, because both data streams are independent
(c) For multicast, already existing reservations can be used

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.120
Summary
● Principles
● Classify multimedia applications
● Identify network services applications need
● Making the best of best effort service
● Protocols and architectures
● Specific protocols for best-effort
● Mechanisms for providing qos
● Architectures for qos
● Multiple classes of service
● QoS guarantees, admission control

Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ [Link] ▪ Telematics ▪ Chapter 11: Multimedia Networking 11.121