Service/company landscape include
1-1
Applications (3)
 File transfer
 Remote login (telnet, rlogin, ssh)
 World Wide Web (WWW)
 Instant Messaging (Internet chat, text
messaging on cellular phones)
 Peer-to-Peer file sharing
 Internet Phone (Voice-Over-IP)
 Video-on-demand
 Distributed Games
2
Why Study Multimedia Networking?
 Exciting and fun!
 Industry-relevant research topic
 Multimedia is everywhere
 Lots of open research problems
3
4
Scalable Content Delivery
Motivation
 Use of Internet for content delivery is massive … and
becoming more so (e.g., majority of all IP traffic is
video content)
 Variety of approaches: HTTP-based Adaptive
Streaming (HAS), broadcast/multicast, batching,
replication/caching (e.g. CDNs), P2P, peer-assisted, …
 In these slides, we only provide a few high-level
examples
5
Service models
6
Client-server architecture
Client/server model has well-defined roles.
client/server
server:
 always-on host
 permanent IP address
 server farms for
scaling
clients:




communicate with server
may be intermittently
connected
may have dynamic IP
addresses
do not communicate
directly with each other
7
Pure P2P architecture
No fixed clients or servers: Each host can act as both client and
server at any time

no always-on server
 arbitrary end systems
peer-peer
directly communicate
 peers are intermittently
connected and change IP
addresses
8
Additional Multimedia Support
Content Distribution
Networks (CDNs)
origin server
in North America
 Challenging to stream large
files (e.g., video) from single
origin server in real time
 Solution: replicate content at
hundreds of servers
throughout Internet
 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 distribution node
CDN server
in S. America CDN server
in Europe
CDN server
in Asia
9
Additional Multimedia Support
Multicast/Broadcast
duplicate
duplicate
creation/transmission
R1
R1
duplicate
R2
R2
R3
R4
(a)
R3
R4
(b)
Source-duplication versus in-network duplication.
(a) source duplication, (b) in-network duplication
Also, application-layer multicast …
10
11
Multimedia Networking Applications
Classes of MM applications:
12
Multimedia Networking Applications
Classes of MM applications:
1) Streaming stored audio and video
2) Streaming live audio and video
3) Real-time interactive audio and video
13
Streaming Stored Multimedia (1/2)
1. video
recorded
2. video
sent
network
delay
3. video received,
played out at client
time
streaming: at this time, client
playing out early part of video,
while server still sending later
part of video
14
Streaming Stored Multimedia (2/2)

VCR-like functionality: client can
start, stop, pause, rewind, replay,
fast-forward, slow-motion, etc.
 10 sec initial delay OK
 1-2 sec until command effect OK
 need a separate control protocol?
 timing constraint for data that is yet to be
transmitted: must arrive in time for playback
15
Streaming Live Multimedia
Examples:
 Internet radio talk show
 Live sporting event
Streaming
 playback buffer
 playback can lag tens of seconds after
transmission
 still have timing constraint
Interactivity
 fast-forward is not possible
 rewind and pause possible!
16
Interactive, Real-time Multimedia
 applications: IP telephony, video conference,
distributed interactive worlds
 end-end delay requirements:
 audio:
< 150 msec good, < 400 msec OK
• includes application-layer (packetization) and network delays
• higher delays noticeable, impair interactivity
 session initialization

callee must advertise its IP address, port number,
frame rate, encoding algorithms
17
18
Multimedia Networking Applications
Fundamental characteristics:
19
Multimedia Networking Applications
Fundamental characteristics:
 Inherent frame rate
 Typically delay-sensitive


end-to-end delay
delay jitter
 But loss-tolerant: infrequent losses cause
minor transient glitches
 Unlike data apps, which are often delaytolerant but loss-sensitive.
20
Multimedia Networking Applications
Fundamental characteristics:
 Inherent frame rate
 Typically delay-sensitive


end-to-end delay
delay jitter
 But loss-tolerant: infrequent losses cause
minor transient glitches
 Unlike data apps, which are often delaytolerant but loss-sensitive.
Jitter is the variability
of packet delays within
the same packet stream
21
Streaming Multimedia: Client
Buffering
variable
network
delay
client video
reception
constant bit
rate video
playout at client
buffered
video
constant bit
rate video
transmission
client playout
delay
time
 Client-side buffering, playout delay compensate
for network-added delay, delay jitter
22
Streaming Multimedia: Client
Buffering
constant
drain
rate, d
variable fill
rate, x(t)
buffered
video
 Client-side buffering, playout delay compensate
for network-added delay, delay jitter
23
24
Streaming Multimedia: UDP or TCP?
UDP
 server sends at rate appropriate for client
(oblivious to network congestion !)
 often send rate = encoding rate = constant rate
 then, fill rate = constant rate - packet loss
 short playout delay (2-5 seconds) to compensate
for network delay jitter
 error recover: time permitting
TCP
 send at maximum possible rate under TCP
 fill rate fluctuates due to TCP congestion control
 larger playout delay: smooth TCP delivery rate
 HTTP/TCP passes more easily through firewalls
25
26
User Control of Streaming
Media: RTSP
RTSP: RFC 2326
 client-server application
layer protocol
 user control: rewind,
fast forward, pause,
resume, repositioning,
etc.
What it doesn’t do:
 doesn’t define how
audio/video is
encapsulated for
streaming over network
 doesn’t restrict how
streamed media is
transported (UDP or
TCP possible)
 doesn’t specify how
media player buffers
audio/video
27
A protocol family for streaming
 RTSP
 RTP
 RTCP
28
RTSP: out-of-band control
FTP uses an “out-ofband” control channel:
 file transferred over
one TCP connection.
 control info (directory
changes, file deletion,
rename) sent over
separate TCP
connection
 “out-of-band”, “inband” channels use
different port
numbers
RTSP messages (also)
sent out-of-band:
 RTSP control
messages use
different port
numbers than media
stream: out-of-band.
 port 554
 media stream is
considered “in-band”.
29
RTSP Example
Scenario:
 metafile communicated to web browser
 browser launches player
 player sets up an RTSP control connection,
data connection to streaming server
30
Metafile Example
<title>Twister</title>
<session>
<group language=en lipsync>
<switch>
<track type=audio
e="PCMU/8000/1"
src = "rtsp://audio.example.com/twister/audio.en/lofi">
<track type=audio
e="DVI4/16000/2" pt="90 DVI4/8000/1"
src="rtsp://audio.example.com/twister/audio.en/hifi">
</switch>
<track type="video/jpeg"
src="rtsp://video.example.com/twister/video">
</group>
</session>
31
RTSP Operation
32
RTSP Exchange Example
C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0
Transport: rtp/udp; compression; port=3056; mode=PLAY
S: RTSP/1.0 200 1 OK
Session 4231
C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
Range: npt=0C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
Range: npt=37
C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
S: 200 3 OK
33
Real-Time Protocol (RTP)
 RTP specifies packet
structure for packets
carrying audio, video
data
 RFC 3550
 RTP runs in end systems
 RTP packets
encapsulated in UDP
segments
34
Real-Time Protocol (RTP)
 RTP specifies packet
structure for packets
carrying audio, video
data
 RFC 3550
 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 able
to work together
35
RTP runs on top of UDP
RTP libraries provide transport-layer interface
that extends UDP:
• port numbers, IP addresses
• payload type identification
• packet sequence numbering
• time-stamping
36
RTP Example
 consider sending 64
kbps PCM-encoded
voice over RTP.
 application collects
encoded data in
chunks, e.g., every 20
msec = 160 bytes in a
chunk.
 audio chunk + RTP
header form RTP
packet, which is
encapsulated in UDP
segment
 RTP header indicates
type of audio encoding
in each packet

sender can change
encoding during
conference.
 RTP header also
contains sequence
numbers, timestamps.
37
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.
38
RTP Header
Payload Type (7 bits): 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 mu-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.
39
RTP Header (2)

Timestamp field (32 bytes 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 usecs for 8 KHz
sampling clock)
if application generates chunks of 160 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 t RTP
stream. Each stream in RTP session should have
distinct SSRC.
40
Real-Time Control Protocol (RTCP)
 works in conjunction
with RTP.
 each participant in RTP
session periodically
transmits RTCP control
packets to all other
participants.
 each RTCP packet
contains sender and/or
receiver reports

report statistics useful
to application: #
packets sent, # packets
lost, interarrival jitter,
etc.
 feedback can be used
to control
performance

sender may modify its
transmissions based on
feedback
41
Real-time Control Protocol (RTCP)
Receiver report packets:
 fraction of packets
lost, last sequence
number, average
interarrival jitter
Sender report packets:
 SSRC of RTP stream,
current time, number of
packets sent, number of
bytes sent
 RTCP attempts to limit its
traffic to 5% of session
bandwidth
42
Real-time Control Protocol (RTCP)
 RTCP attempts to limit its
traffic to 5% of session
bandwidth
each RTP session: typically a single multicast address; all RTP /RTCP packets
belonging to session use multicast address.


RTP, RTCP packets distinguished from each other via distinct port numbers.
to limit traffic, each participant reduces RTCP traffic as number of
conference participants increases

43
RTCP Packets
Receiver report packets:
 fraction of packets
lost, last sequence
number, average
interarrival jitter
Sender report packets:
 SSRC of RTP stream,
current time, number of
packets sent, number of
bytes sent
Source description
packets:
 e-mail address of
sender, sender's name,
SSRC of associated
RTP stream
 provide mapping
between the SSRC and
the user/host name
44
Synchronization of Streams
 RTCP can synchronize
different media streams
within a RTP session
 consider videoconferencing
app for which each sender
generates one RTP stream
for video, one for audio.
 timestamps in RTP packets
tied to the video, audio
sampling clocks
 not tied to wall-clock
time
 each RTCP sender-report
packet contains (for most
recently generated packet
in associated RTP stream):


timestamp of RTP packet
wall-clock time for when
packet was created.
 receivers uses association
to synchronize playout of
audio, video
45
RTCP Bandwidth Scaling
 RTCP attempts to limit its
traffic to 5% of session
bandwidth.
Example
 Suppose one sender,
sending video at 2 Mbps.
Then RTCP attempts to
limit its traffic to 100
Kbps.
 RTCP gives 75% of rate to
receivers; remaining 25%
to sender
 75 kbps is equally shared
among receivers:

with R receivers, each
receiver gets to send RTCP
traffic at 75/R kbps.
 sender gets to send RTCP
traffic at 25 kbps.
 participant determines RTCP
packet transmission period by
calculating avg RTCP packet
size (across entire session)
and dividing by allocated rate
46
47
HTTP-based streaming
 HTTP-based streaming
 Allows easy caching, NAT/firewall traversal, etc.
 Use of TCP provides natural bandwidth adaptation
 Split into fragments, download sequentially
 Some support for interactive VoD
4
HTTP-based adaptive streaming (HAS)
 HTTP-based adaptive streaming
 Multiple encodings of each fragment (defined in
manifest file)
 Clients adapt quality encoding based on (buffer and
network) conditions
4
Chunk-based streaming
 Chunks begin with keyframe so independent of other chunks
 Playing chunks in sequence gives seamless video
 Hybrid of streaming and progressive download:


Stream-like: sequence of small chunks requested as needed
Progressive download-like: HTTP transfer mechanism, stateless
servers
50
Example
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
Client
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
Server
51
Example
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
Client
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
Server
52
Example
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
Client
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
Server
53
Example
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
Client
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
Server
54
Example
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
Client
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
Server
55
Example
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
Client
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
Server
56
Example
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
Client
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
Server
57
Example
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
Client
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
Server
58
HTTP-based Adaptive
Streaming (HAS)
 Other terms for similar concepts: Adaptive Streaming,
Smooth Streaming, HTTP Chunking
 Probably most important is return to stateless server and
TCP basis of 1st generation
 Actually a series of small progressive downloads of chunks
(or range requests)
 No standard protocol ...
59
HTTP-based Adaptive
Streaming (HAS)
 Other terms for similar concepts: Adaptive Streaming,
Smooth Streaming, HTTP Chunking
 Probably most important is return to stateless server and
TCP basis of 1st generation
 Actually a series of small progressive downloads of chunks
(or range requests)
 No standard protocol ...




Apple HLS: HTTP Live Streaming
Microsoft IIS Smooth Streaming: part of Silverlight
Adobe: Flash Dynamic Streaming
DASH: Dynamic Adaptive Streaming over HTTP
60
Example players
Player
Container
Type
Microsoft
Smooth
Streaming
Silverlight
Chunk
Netflix
player
Silverlight
Range
Apple HLS
QuickTime
Chunk
Adobe HDS
Flash
Chunk
Open
Source
61
Problem: Proxyassisted HAS
Slides from: V. Krishnamoorthi et al.
"Helping Hand or Hidden Hurdle:
Proxy-assisted HTTP-based Adaptive
Streaming Performance",
Proc. IEEE MASCOTS, 2013
Clients’ want
 High playback quality
 Small stall times
 Few buffer
interruptions
 Few quality switches
62
Problem: Proxyassisted HAS
Clients’ want
 High playback quality
 Small stall times
 Few buffer
interruptions
 Few quality switches
Slides from: V. Krishnamoorthi et al.
"Helping Hand or Hidden Hurdle:
Proxy-assisted HTTP-based Adaptive
Streaming Performance",
Proc. IEEE MASCOTS, 2013
HAS is increasingly responsible
for larger traffic volumes
Network and service providers
may consider integrating HASaware proxy policies
63
Problem: Proxyassisted HAS
Clients’ want
 High playback quality
Slides from: V. Krishnamoorthi et al.
"Helping Hand or Hidden Hurdle:
Proxy-assisted HTTP-based Adaptive
Streaming Performance",
Proc. IEEE MASCOTS, 2013
Network providers’ want
• High QoE of customers/clients
 Small stall times
 Few buffer
interruptions
 Few quality switches
64
Problem: Proxyassisted HAS
Clients’ want
Network providers’ want
 High playback quality
• High QoE of customers/clients
 Small stall times
• Low bandwidth usage
 Few buffer
• High hit rate
interruptions
 Few quality switches
65
Problem: Proxyassisted HAS
Clients’ want
Network providers’ want
 High playback quality
• High QoE of customers/clients
 Small stall times
• Low bandwidth usage
 Few buffer
• High hit rate
interruptions
 Few quality switches
66
Problem: Proxyassisted HAS
In this paper …
 Evaluation of proxy-assisted HAS
policies
67
Problem: Proxyassisted HAS
In this paper …
 Evaluation of proxy-assisted HAS
policies
68
Problem: Proxyassisted HAS
In this paper …
 Evaluation of proxy-assisted HAS
policies
69
Problem: Proxyassisted HAS
In this paper …
 Evaluation of proxy-assisted HAS
policies
70
Problem: Proxyassisted HAS
In this paper …
 Evaluation of proxy-assisted HAS
policies
71
Example: Default
“best-effort”
72
Example: Default
“best-effort”
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
Client
5,4
5,3
5,2
5,1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
Proxy
73
Example: Default
“best-effort”
1,4
2,4
1,3
2,3
1,2
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
Client 1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
Proxy before
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4 5,4
4,3 5,3
4,2 5,2
4,1 5,1
Proxy
6,4 7,4
6,3 7,3
6,2 7,2
6,1 7,1
after
74
Example: Default
“best-effort”
1,4
2,4
1,3
2,3
1,2
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
Client 1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
Proxy before
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4 5,4
4,3 5,3
4,2 5,2
4,1 5,1
Proxy
6,4 7,4
6,3 7,3
6,2 7,2
6,1 7,1
after
75
Example: Default
“best-effort”
1,4
2,4
1,3
2,3
1,2
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
Client 2
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
Proxy before
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4 5,4
4,3 5,3
4,2 5,2
4,1 5,1
Proxy
6,4 7,4
6,3 7,3
6,2 7,2
6,1 7,1
after
76
Example: Default
“best-effort”
1,4
2,4
1,3
2,3
1,2
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
Client 2
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
Proxy before
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4 5,4
4,3 5,3
4,2 5,2
4,1 5,1
Proxy
6,4 7,4
6,3 7,3
6,2 7,2
6,1 7,1
after
77
Example: Default
“best-effort”
1,4
2,4
1,3
2,3
1,2
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
Client 3
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
Proxy before
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4 5,4
4,3 5,3
4,2 5,2
4,1 5,1
Proxy
6,4 7,4
6,3 7,3
6,2 7,2
6,1 7,1
after
78
Example: Default
“best-effort”
1,4
2,4
1,3
2,3
1,2
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
Client 3
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4
4,3
4,2
4,1
5,4
5,3
5,2
5,1
6,4
6,3
6,2
6,1
7,4
7,3
7,2
7,1
Proxy before
1,4
2,4
1,3
2,3
1,2
1,1
2,2
2,1
3,4
3,3
3,2
3,1
4,4 5,4
4,3 5,3
4,2 5,2
4,1 5,1
Proxy
6,4 7,4
6,3 7,3
6,2 7,2
6,1 7,1
after
79
80
Multimedia Over “Best Effort”
Internet
 TCP/UDP/IP:
?
no guarantees on delay, loss
?
?
?
?
?
But you said multimedia apps requires ?
QoS and level of performance to be
?
? effective!
?
?
Today’s multimedia applications implement
functionality at the app. layer to mitigate
(as best possible) effects of delay, loss
81
Packet Loss
 network loss: IP datagram lost due to
network congestion (router buffer
overflow) or losses at wireless link(s)
 delay loss: IP datagram arrives too late for
playout at receiver (effectively the same
as if it was lost)
delays: processing, queueing in network; endsystem (sender, receiver) delays
 Tolerable delay depends on the application

 How can packet loss be handled?

We will discuss this next …
82
Receiver-based Packet Loss
Recovery
 Generate replacement packet
 Packet repetition
 Interpolation
 Other sophisticated schemes
 Works when audio/video streams exhibit
short-term correlations (e.g., self-similarity)
 Works for relatively low loss rates (e.g., < 5%)
 Typically, breaks down on “bursty” losses
83
Forward Error Correction (FEC)
 For every group of n actual media packets, generate k





additional redundant packets
Send out n+k packets, which increases the bandwidth
consumption by factor k/n.
Receiver can reconstruct the original n media packets
provided at most k packets are lost from the group
Works well at high loss rates (for a proper choice of k)
Handles “bursty” packet losses
Cost: increase in transmission cost (bandwidth)
84
Another FEC Example
• “piggyback lower
quality stream”
• Example: send lower
resolution audio stream as
the redundant
information
•
• Whenever there is non-consecutive loss, the
receiver can conceal the loss.
• Can also append (n-1)st and (n-2)nd low-bit rate
chunk
85
Interleaving: Recovery from packet loss
Interleaving
 Intentionally alter the sequence of packets before transmission
 Better robustness against “burst” losses of packets
 Results in increased playout delay from inter-leaving
86
Summary:
Internet MM “tricks of the trade”
 UDP vs TCP
 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) at the app layer
 FEC, interleaving
 retransmissions, time permitting
 conceal errors: repeat nearby data
87
88
More slides …
89
Some more on QoS:
Real-time traffic support
 Hard real-time
 Soft real-time
 Guarantee bounded delay
 Guarantee delay jitter
 End-to-end delay = queuing delays +
transmission delays + processing times +
propagation delay (and any potential retransmission delays at lower layers)
90
How to provide better support for
Multimedia? (1/4)
Integrated Services (IntServ) philosophy:
 architecture for providing QoS guarantees in IP
networks for individual flows
 requires fundamental changes in Internet design
so that apps can reserve end-to-end bandwidth
 Components of this architecture are





Reservation protocol (e.g., RSVP)
Admission control
Routing protocol (e.g., QoS-aware)
Packet classifier and route selection
Packet scheduler (e.g., priority, deadline-based)
91
How to provide better support for
Multimedia? (2/4)
Concerns with IntServ:
 Scalability: signaling, maintaining per-flow router
state difficult with thousands/millions of flows
 Flexible Service Models: IntServ has only two
classes. Desire “qualitative” service classes
 E.g., Courier, ExpressPost, and normal mail
 E.g., First, business, and economy class
Differentiated Services (DiffServ) approach:
 simple functions in network core, relatively
complex functions at edge routers (or hosts)
 Don’t define the service classes, just provide
functional components to build service classes
92