Chapter 7: Multimedia Networking Chapter 7: Multimedia Networking

Chapter 7: Multimedia Networking
Jim Kurose, Keith Ross:
“Computer Networking: A Top-Down Approach”
3rd edition:
Addison-Wesley,
July 2004
4th edition:
Addison-Wesley,
July 2007
Slides modified (edited, reordered, reduced, extended) by
P. Imai, Ch. Tschudin, L. Yamamoto, Univ. Basel, 2007-2010
7: Multimedia Networking
7-1
Chapter 7: Multimedia Networking
Jim Kurose, Keith Ross:
“Computer Networking: A Top-Down Approach”
Slides modified (edited, reordered, reduced, extended) by
Lidia Yamamoto, Univ. Basel, June 11, 2007
(most material comes from the 3rd edition, some from other sources,
plus some gif figures from the 4th edition)
A note on the use of these ppt slides:
We’re making these slides freely available to all (faculty, students, readers).
They’re in PowerPoint form so you can add, modify, and delete slides
(including this one) and slide content to suit your needs. They obviously
represent a lot of work on our part. In return for use, we only ask the
following:
‰ If you use these slides (e.g., in a class) in substantially unaltered form,
that you mention their source (after all, we’d like people to use our book!)
‰ If you post any slides in substantially unaltered form on a www site, that
you note that they are adapted from (or perhaps identical to) our slides, and
note our copyright of this material.
Thanks and enjoy! JFK / KWR
All material copyright 1996-2008
J.F Kurose and K.W. Ross, All Rights Reserved
7: Multimedia Networking
7-2
Contents: Multimedia, QoS, CDN, P2P
ˆ Introduction


ˆ QoS
Definitions
Performance requirements
ˆ Multimedia networking

Streaming
• Client Buffering
• RTSP

Real-time Interactive
• RTP/RTCP
• SIP, SDP
• Mitigating delay and loss


Problem, lack of deployed
solutions
Net neutrality
ˆ Content Distribution
Networks (CDNs)
ˆ Peer-to-Peer (P2P)

Case study: Skype
7: Multimedia Networking
7-3
Multimedia
ˆ
Media: stimulate one of our 5 senses



ˆ
Multimedia strict definition: more than one medium
combined and synchronized together



ˆ
Sight: Text, Graphics, Images, Video
Hearing: Audio
Smell? Taste? Touch?
Web browsing or e-mail with text + images
Audio-visual communication, e.g. videoconferencing
Multimedia documents
Multimedia networking, Internet context: continuous
audio and/or video (also when single medium)


Streaming: Stored or live audio/video streaming
Real-time and/or interactive audio/video
7: Multimedia Networking
7-4
Multimedia Networking Map
Media player
Streaming multimedia:
presentation
description
media data
transmission
Streaming
presentation
control by
user
Media server
loss/delay
compensation
synchronization
across media
main direction of
information flow
7: Multimedia Networking
7-5
Multimedia Networking Map
Interactive multimedia:
user
location
Application
invite
users
interactive
session
description
call
setup
agree on
encoding
schemes
media data
transmission
loss/delay
compensation
synchronization
across media
statistics on media transmission
clock information
information for
accounting, billing
gateway
fixed or
mobile phone
networks
7: Multimedia Networking
7-6
Multimedia Networking Requirements
How to transmit audio or video over the Internet?
ˆ
Network performance requirements



ˆ
Relevant performance parameters:
delay, packet loss, bandwidth, jitter (delay variation)
File transfer, web browsing, e-mail are elastic
applications: flexible in terms of delay/bandwidth, but no
loss tolerated
Multimedia applications are typically delay-sensitive and
require some minimum bandwidth but are loss tolerant:
infrequent losses cause minor glitches
Technical challenges



Currently all packets receive equal, best effort service
Except for TCP reliability (loss=0) guarantee, no other
performance guarantees are available
Scalability: one to many, many to many transmissions
7: Multimedia Networking
7-7
Multimedia Networking Requirements
elastic applications
File
transfer
delay-sensitive, loss tolerant
Streaming
Real-time
multimedia
multimedia
Web
browsing
E-mail
No loss
(max loss = 0)
Min
bandwidth
Max loss
Max delay,
jitter
performance requirements
Available
transport
protocols
TCP
?
?
UDP
?
IP Network Layer: Best Effort Delivery Service
7: Multimedia Networking
7-8
Multimedia Networking: Solutions
ˆ
A) Add performance guarantees to the Internet
stack



ˆ
Quality of Service (QoS), e.g. Intserv, Diffserv
IP Multicast
Several attempts, no real success so far
B) Adaptive applications: make the best of best
effort



Streaming and (semi-)real-time support over UDP and
even TCP
Application-layer solutions: CDNs, P2P, Application-layer
multicast,…
Increasingly successful
7: Multimedia Networking
7-9
Contents: Multimedia, QoS, CDN, P2P
ˆ Introduction


Definitions
Performance requirements
ˆ Multimedia networking

Streaming
• Client Buffering
• RTSP

ˆ QoS

Intserv, Diffserv
ˆ Content Distribution
Networks (CDNs)
ˆ Peer-to-Peer (P2P)

Case study: Skype
Real-time Interactive
• RTP/RTCP
• SIP, SDP, H.323
• Mitigating delay and loss
7: Multimedia Networking
7-10
Streaming Stored Multimedia
Media server
media
data
client
control
file transmission
ˆ client playout begins as soon as possible
(i.e. before whole file is transmitted)
ˆ control:VCR or DVD-like: pause, move
forwards, backwards,…
ˆ time constraint: media data should
arrive in time for playout
ˆ
7: Multimedia Networking
7-11
Streaming Live Multimedia
Internet
“broadcast
station”
ˆ
client
control
examples


ˆ
media
data
Internet radio talk show
Live sports event
playout buffer instead of file transmission

store a few tens of seconds before playback: cope with jitter
no fast-forwarding possible!
ˆ time constraint same as stored streaming
ˆ
7: Multimedia Networking
7-12
constant bit
rate video
transmission
variable
network
delay
client video
reception
constant bit
rate video
playout at client
buffered
video
Cumulative data
Streaming Multimedia: Client Buffering
time
client playout
delay
ˆ
Client-side buffering with playout delay to
compensate for network-added delay and jitter
7: Multimedia Networking
7-13
Streaming Multimedia: Client Buffering
constant
drain
rate, s
variable fill
rate, r(t)
playout delay: d
buffered
video
ˆ
ˆ
ˆ
ˆ
Buffer size: b > s*d
If large buffer (~file size) possible then avg(r(t)) > s allowed
Small buffer requires avg(r(t)) = s
If avg(r(t)) < s: starvation
7: Multimedia Networking
7-14
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 (a few seconds) to compensate for jitter
ˆ error recovery if time permits
TCP
ˆ send at maximum possible rate under TCP
ˆ buffer fill rate fluctuates due to TCP congestion control
ˆ larger playout delay in order to smooth TCP delivery rate
ˆ popular: HTTP/TCP passes more easily through firewalls
7: Multimedia Networking
7-15
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
7: Multimedia Networking
7-16
Multimedia Networking: Partial Map
Media player
Streaming multimedia:
presentation
description
media data
transmission
Media server
RTSP
Streaming
presentation
control by
user
main direction of
information flow
7: Multimedia Networking
7-17
Real Time Streaming Protocol (RTSP)
ˆ IETF RFC 2326
ˆ www.rtsp.org
ˆ User control of streaming media: VCR-like

rewind, fast forward, pause, resume, repositioning, etc…
ˆ Client-server application-layer protocol

request-response: requests from player to server; each request
confirmed with a response message from server
ˆ Syntax and operation intentionally similar to HTTP
7: Multimedia Networking
7-18
RTSP Operation
ˆ
ˆ
Web
browser
HTTP GET
presentation desc.
Web
server
SETUP
ˆ
ˆ
PLAY
media
player
media stream
media
server
PAUSE
ˆ
TEARDOWN
client
server
ˆ
Client (browser) requests page
containing multimedia presentation
Client obtains XML metafile: a
description of the multimedia
presentation, which can consist of
several media streams.
Link to each media stream: rtsp://
The browser invokes corresponding
media player (helper application)
based on the content type of the
presentation description.
Each player sets up an RTSP control
connection, and a data connection to
the streaming server
RTSP: (out-of band) control protocol


request-response
RTSP SETUP, PLAY, PAUSE,
TEARDOWN
7: Multimedia Networking
7-19
XML 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>
7: Multimedia Networking
7-20
RTSP Exchange Example
C: SETUP rtsp://audio.example.com/twister/audio.en/lofi 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
7: Multimedia Networking
7-21
Multimedia Networking: Protocol Map
Streaming multimedia:
presentation
description
e
XML metafil
RTP/UDP,
TCP
media data
transmission
RTSP
Media server
Media player
Streaming
presentation
control by
user
loss/delay
compensation
main direction of
information flow
synchronization
across media
7: Multimedia Networking
7-22
Contents: Multimedia, QoS, CDN, P2P
ˆ Introduction


Definitions
Performance requirements
ˆ Multimedia networking

Streaming
• Client Buffering
• RTSP

ˆ QoS

Intserv, Diffserv
ˆ Content Distribution
Networks (CDNs)
ˆ Peer-to-Peer (P2P)

Case study: Skype
Real-time Interactive
• RTP/RTCP
• SIP, SDP, H.323
• Mitigating delay and loss
7: Multimedia Networking
7-23
Interactive, Real-Time Multimedia
applications: VoIP, IP
telephony, video conference,
distributed interactive worlds
ˆ end-end delay requirements:
 audio: < 150 msec good, < 400 msec OK
ˆ loss tolerance:
 1% to 20% depending on encoding and application
ˆ session initialization
 locate participants, agree on encoding formats, etc.
ˆ
7: Multimedia Networking
7-24
Multimedia Networking: Partial Map
Interactive multimedia: data transmission and control
Application
media data
transmission
loss/delay
compensation
RTP/UDP
statistics on media transmission
clock information
RTCP
synchronization
across media
7: Multimedia Networking
7-25
RTP (and RTCP)
RTP (Real-Time Transport Protocol): RFC 3550
ˆ Transport-level packet format to carry
monomedia data (video, audio, animations,…).
Payload contains:
ˆ

Payload type, sequence number, timestamp, source
identifier(s), media samples
Multimedia via multiple synchronized RTP sessions
ˆ Support for multipoint, bidirectional flows,
translators and mixers
ˆ Generally runs over UDP: unicast or multicast
ˆ Companion Control Protocol: RTCP:
ˆ


Clock timestamp for media synchronization
Periodic sender/receiver statistics
7: Multimedia Networking
7-26
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
7: Multimedia Networking
7-28
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.
7: Multimedia Networking
7-29
RTP Header
ˆ
Payload Type (7 bits): type of encoding, e.g.:



0 = PCM mu-law, 64 kbps
3 = GSM, 13 kbps
33 = MPEG2 video
Sequence Number (16 bits) of RTP packet
ˆ Timestamp (32 bits): sample number
ˆ

incremented by one for each sample (not real-time clock)
even if source inactive
SSRC (32 bits): synchronization source identifier
ˆ CSRC (32 bits): contributing source id (e.g. mixing)
ˆ
cod.
Seq. no.
type
Timestamp
SSRC
CSRC1 CSRC2 Samples…
7: Multimedia Networking
7-38
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.
ˆ
7: Multimedia Networking
7-39
Multimedia Networking: Partial Map
Interactive multimedia: “call setup”
Application
user
location
interactive
session
description
SIP
invite
users
call
setup
agree on
encoding
schemes
SDP
loss/delay
compensation
synchronization
across media
7: Multimedia Networking
7-40
Session Initiation Protocol (SIP)
IETF RFC 3261
ˆ Creation and management of multimedia sessions
ˆ




ˆ
SIP user identity


ˆ
Establish, modify, terminate sessions
Invite new participants to existing sessions
Add or remove media
User location for personal mobility (name mapping and
redirection)
URI = Universal Resource Identifier: locationindependent, e.g. sip:bob@biloxi.com,
sip:alice@atlanta.com
Address, e.g. sip:bob@193.64.210.89
Multimedia session descriptions in SIP (mainly):

SDP = Session Description Protocol (RFC 2327)
7: Multimedia Networking
7-41
Important Role of SIP
ˆ
Mostly known for VoIP (voice over IP), or
videoconferencing
ˆ
In general: to signal digital media transfer,
e.g. Fax, but also any binary app data
ˆ
Added value of SIP (over FTP etc):





Terminal capability negotiation (codecs to use)
Personal mobility
Caller and callee authentication
Call transfer
Extensions: session mobility (switch device on the fly)
7: Multimedia Networking
7-42
SIP Call Set Up: Known IP Address
ˆ
Alice’s SIP invite message
contains SDP session
description


…..
SDP
ˆ
C= protocol (IPv4) & IP
address.
M= media (audio), port
number (38060), preferred
encoding (“RTP/AVP 0” =
PCM ulaw) to receive audio
Bob’s SIP “200 OK” message
contains his own SDP descr.:

IP address, port &
preferred encoding to recv.
(“RTP/AVP 3” = GSM)
ˆ
SIP messages can be sent
over TCP or UDP; here sent
over RTP/UDP.
ˆ
Default SIP port number is
5060.
7: Multimedia Networking
7-43
SIP Call Set Up: Location-independent URI
6
sip:alice@atlanta.com
INVITE
sip:bob@biloxi.com
sip:bob@biloxi.com
SIP
Proxy
biloxi.com
2
5
4
3
1
SIP
Registrar
Biloxi.com
Location
database
SIP
Proxy
atlanta.com
•SIP Registrar: registers SIP user locations into database
•SIP Proxy: informs clients about locations, routes calls
(both functions may be combined into the same machine)
Call routing via SIP proxy servers
7: Multimedia Networking
7-44
SIP Call Set Up: Location-independent URI
sip:bob@biloxi.com
sip:alice@atlanta.com
INVITE
sip:bob@biloxi.com
SIP
Proxy
atlanta.com
4
1
SIP
Proxy
biloxi.com
SIP
Registrar
Biloxi.com
2
5
REDIRECT
6
unibas.ch
7
Location
database
SIP
Proxy
unibas.ch
REGISTER
3
8
Call routing via SIP proxy servers
7: Multimedia Networking
7-45
Another Example
Keith
(home)
SIP registrar
upenn.edu
Caller jim@umass.edu
places a call to keith@upenn.edu
SIP
registrar
eurecom.fr
2
(1) Jim sends INVITE
message to umass SIP
proxy. (2) Proxy forwards
request to upenn
registrar server.
(3) upenn server returns
redirect response,
indicating that it should
try keith@eurecom.fr
SIP proxy
umass.edu
3
1
4
5
7
8
Jim
6
9
SIP client
217.123.56.89
Keith
(now)
SIP client
197.87.54.21
(4) umass proxy sends INVITE to eurecom registrar. (5) eurecom
registrar forwards INVITE to 197.87.54.21, which is running keith’s SIP
client. (6-8) SIP response sent back (9) media sent directly
between clients.
Note: also a SIP ack message, which is not shown.
7: Multimedia Networking
7-46
Important Role of SIP
ˆ
Mostly known for VoIP (voice over IP), or
videoconferencing
ˆ
In general: to signal digital media transfer,
e.g. Fax, but also any binary app data
ˆ
Added value of SIP (over FTP etc):





Terminal capability negotiation (codecs to use)
Personal mobility
Caller and callee authentication
Call transfer
Extensions: session mobility (switch device on the fly)
7: Multimedia Networking
7-47
Codecs
ˆ
Wasteful to transmit raw multimedia data:
ˆ
Shannon‘s separation theorem:
quite some redundancy (consecutive images)
or little content (pauses in a phone conversation)
two possible levels of compression, both can be
treated independently


Source coding (compression at application level)
Channel coding (compression at physical level)
/
ˆ Codec = COding/DECoding, or COmpression/DECompression
ˆ

Either analog-to-digital (and back), or digital-to-digital
7: Multimedia Networking
7-48
Compression „tricks“
ˆ
Minimum sampling
ˆ
Lossless vs lossy compression
ˆ
Sort data according to importance:
only extract what is really needed to reconstruct signal
ears and eye tolerate incomplete information,
some information is masked anyway (too quick movements,
too low volume)


Voice more important than image
Periodic reference (inter-) frames, subsequent frames
to reuse data from previous ones
I
B B P
B B P B B P B B
I
7: Multimedia Networking
7-49
Example Sampling and Compression
ˆ
Speech frequency range: 200 Hz – 8 KHz
Sampling theorem (Nyquist): need to sample at
least at twice the max frequence
ˆ „linear PCM (pulse code modulation)“ for phone:
only at 8KHz, with 8 bits per sample: 64 kbps
ˆ Using vocal tract model: down to 2-4 Kbps
ˆ
ˆ
Music (40 Hz – 22 KHz)
sampling used for CDs: 44.1 KHz, 16 bits per value,
results in 1.4112 Mbps for stereo stream !
ˆ Using psycho-acustic model: MP3 typically
compresses by a factor of 10 or 12
7: Multimedia Networking
7-50
Codec Acronym Soup
ˆ
MP3, JPEG, MPEG, MPEG layers, u-law, H.264
etc
7: Multimedia Networking
7-51
Typical data rates
2-16 kbps (Highly) compressed speech
64 kpbs Uncompressed phone (ISDN rate)
128 kbps Compressed music (e.g. MP3)
N * 64 kbps Video conferencing (small image)
0.5 Mbps youtube
1 Mbps HD youtube
8-16 Mbps HD TV
20 Mbps DVD download in less than 1h
7: Multimedia Networking
7-52
Codec Wars (status 2010)
ˆ
ˆ
ˆ
ˆ
ˆ
ˆ
There was a stack war (Internet vs OSI), a
browser war (Netscape vs IE), and now we have
codec wars: mpeg, wmv, flash (most popular today),
divx, xvid, realvideo, theora ogg, V8 etc
Today, codecs need plugins in the web browsers;
in the future, native support preferred
H.264 (part of MPEG4): Apple wants to kill
Adobe‘s Flash, pushes H.264 and bans flash
H.264 most prominent candidate for HTML5
Patent doubts over open source codec Theora Ogg
Google bought company producing V8, could open
source it
7: Multimedia Networking
7-53
Multimedia Networking: Protocol Map
Interactive multimedia:
SIP
user
location
Application
invite
users
interactive
session
description
call
setup
synchronization
across media
H.264
SDP
media data
transmission
loss/delay
compensation
agree on
encoding
schemes
RTP/UDP
statistics on media transmission
clock information
information for
accounting, billing
RTCP
gateway
fixed or
mobile phone
networks
7: Multimedia Networking
7-56
Interactive, Real-Time Multimedia
Mitigating the impact of loss and delay
ˆ Example: Internet Phone
ˆ Mitigating loss



Forward error correction (FEC)
Interleaving
Loss concealment
7: Multimedia Networking
7-57
Mitigating loss: Forward Error Correction
(FEC) with Redundant Packets
Redundant packet
(inserted one every n packets)
A
B
C
R
R = A xor B xor C
Lost packet
A
B
C
R
Recovery:
B = A xor C xor R
+ : simple, valid for any media
-: consumes 1/n more bandwidth
-: increases playout delay
7: Multimedia Networking
7-59
Mitigating loss: Forward Error Correction
(FEC) with Redundant Streams
Nominal stream
(higher quality,
e.g. PCM)
Redundant stream
(lower quality,
e.g. GSM)
7: Multimedia Networking
7-60
Mitigating loss: Interleaving
Small
gaps
7: Multimedia Networking
7-61
Interleaving
Used in GSM
ˆ Pros:
+ : significantly improves perceived quality
+ : low overhead
+ : does not increase bandwidth usage
+ : can handle lost bursts
ˆ Cons:
- : increases playout delay
ˆ
7: Multimedia Networking
7-62
Loss concealment
No concealment:
sent
A
received
A
played
A
Repetition:
B
C
B
sent
A
received
A
B
C
C
played
A
A
C
packet
repetition
Interpolation:
A
B
C
C
(silence)
sent
B
C
received
A
B
C
played
A
B’
C
A
decoded
signal
B’
C
time
B’ = f(A, C)
7: Multimedia Networking
7-63
Contents: Multimedia, QoS, CDN, P2P
ˆ Introduction


Definitions
Performance requirements
ˆ Multimedia networking

Streaming
• Client Buffering
• RTSP

ˆ QoS

Intserv, Diffserv
ˆ Content Distribution
Networks (CDNs)
ˆ Peer-to-Peer (P2P)

Case study: Skype
Real-time Interactive
• RTP/RTCP
• SIP, SDP, H.323
• Mitigating delay and loss
7: Multimedia Networking
7-64
Multimedia Networking Requirements
elastic applications
File
transfer
delay-sensitive, loss tolerant
Streaming
Real-time
multimedia
multimedia
Web
browsing
E-mail
No loss
(max loss = 0)
Min
bandwidth
Max loss
Max delay,
jitter
performance requirements
Available
transport
protocols
TCP
?
?
UDP
?
IP Network Layer: Best Effort Delivery Service
7: Multimedia Networking
7-65
Multimedia Quality of Service (QoS)
Multimedia applications:
network audio and video
(“continuous media”)
QoS
network provides
application with level of
performance needed for
application to function.
7: Multimedia Networking
7-66
Quality of Service (QoS), Net Neutrality
Internet currently offers only best effort service
ˆ A lot of research, conferences on “Quality of
Service”, some standards were developped
(Internet “IntServ”, “DiffServ”),
but it never took off
ˆ
ˆ
Carriers’ interest:


ˆ
Unhappy to sell only raw IP packet stream, little revenue
Want to sell “premium service”
(and limit those users occupying too much resources)
Politico-technical debate: Net neutrality
Google in favor, carriers+some tech folk against
7: Multimedia Networking
7-67
Summary
Many limitations of current networked multimedia
applications are due to network constraints
ˆ Main problems with both Intserv and Diffserv
ˆ



Complexity, deployment & management cost/effort
Crossing legacy best-effort portions of the Internet
Socio-economic barriers: who uses ≠ who pays
Current “winner” solution is “laissez-faire” with
over-provisioning
ˆ Research directions
ˆ


Autonomic, self-organizing networks: self-deploying
services, including QoS
Adaptive functionality, not only at application layer, also
at transport and network layer
7: Multimedia Networking
7-72
Contents: Multimedia, QoS, CDN, P2P
ˆ Introduction


Definitions
Performance requirements
ˆ Multimedia networking

Streaming
• Client Buffering
• RTSP

ˆ QoS

Intserv, Diffserv
ˆ Content Distribution
Networks (CDNs)
ˆ Peer-to-Peer (P2P)

Case study: Skype
Real-time Interactive
• RTP/RTCP
• SIP, SDP, H.323
• Mitigating delay and loss
7: Multimedia Networking
7-73
Content Distribution Networks (CDNs)
ˆ
Problem: Streaming stored multimedia: large and
very popular files (e.g. video from TV broadcast)
from single origin server in real time


ˆ
Not a solution:


ˆ
Bottleneck at server
Delay, loss
Multicast: not everyone asks content at the same time
Web caching: content pulled on demand, fresh
information (e.g. news) not cached
Solution: CDN



Content pushed in advance to servers located as close as
possible to potential users
New business: CDN company
Clients: large corporations, e.g. tv/movie industry
7: Multimedia Networking
7-74
CDN: Proactive Content Replication
ˆ CDN company (e.g., Akamai):
customers are large content
providers (e.g. CNN)
ˆ CDN replicates customers’
content in CDN servers.
ˆ Content downloaded to CDN
servers ahead of time
ˆ Placing content “close” to user


alleviates load at origin server
avoids impairments (loss, delay)
of sending content over long
paths
ˆ CDN server typically in
edge/access network
origin server
in North America
CDN distribution node
CDN server
in S. America CDN server
in Europe
CDN server
in Asia
7: Multimedia Networking
7-75
An Akamaized Website (Wikipedia)
origin
server
Akamai
CDN
server
7: Multimedia Networking
7-76
CDN Redirection Mechanism
client
4
1
Origin
server
2
3
1
CDNs authoritative
DNS server
Nearby
CDN server
CDN
network
2
3
Content
Provider’s
network
www.ocpn.com
HTTP request for
www.ocpn.com/sports/sports.html
HTML page containing
link to www.cdn.com/www.ocpn.com/video.mpg2
DNS query for www.cdn.com
Answer from map to determine nearest server
4 HTTP request for
www.cdn.com/www.ocpn.com/video.mpg2
www.cdn.com
7: Multimedia Networking
7-77
CDN status
ˆ
Content Deliver Networks is big business
- content providers pay to keep customers happy
ˆ
Google does it itself (server replication etc)
ˆ
Look at fast data delivery as a service. Once the
infrastructure is in place, one can add more
„services“:


ˆ
location awar services
Personalized service
This has already started:
Google replies differ, according to location+person
7: Multimedia Networking
7-79
Contents: Multimedia, QoS, CDN, P2P
ˆ Introduction


ˆ QoS
Definitions
Performance requirements
ˆ Multimedia networking

Streaming
• Client Buffering
• RTSP


Intserv, Diffserv
ˆ Content Distribution
Networks (CDNs)
ˆ Peer-to-Peer (P2P)

Case study: Skype
Real-time Interactive
• RTP/RTCP
• SIP, SDP, H.323
• Mitigating delay and loss
7: Multimedia Networking
7-80
Client-server architecture
Server:
client




content provider
always-on host
permanent IP address
server farms for scaling
Clients:


server
client



content consumer
communicate with server
may be intermittently
connected
may have dynamic IP
addresses
do not communicate directly
with each other
7: Multimedia Networking
7-81
P2P architecture
ˆ Peer: both content provider and
ˆ
ˆ
ˆ
ˆ
consumer
Motivation: share information,
e.g. files
End systems communicate
directly (no 3rd party servers)
Decentralized, scalable
Issues:






content dissemination, search
and retrieval
intermittent connectivity
dynamic IP addresses
NAT/firewall traversal
non-cooperative nodes
security
7: Multimedia Networking
7-82
Hybrid
ˆ Centralized index
e.g. original “Napster”
1) when peer connects, it informs
central server:


Bob
centralized
index server
1
peers
IP address
content, e.g. song titles
2) Alice queries index for song, index
returns Bob’s address
3) Alice requests and obtains song file
from Bob directly
ˆ Centralized access control
e.g. Skype: register/authenticate with
central server, rest P2P (search
for users, media exchange)
1
3
1
2
1
Alice
7: Multimedia Networking
7-83
P2P Case Study: Skype
Supernode structure:
login
server
7: Multimedia Networking
7-84
P2P Case Study: Skype
ˆ
ˆ
ˆ
ˆ
ˆ
P2P VoIP software, encrypted calls
NAT and firewall traversal
Gateways to mobile/fixed phone networks
Proprietary protocols over TCP and UDP
Supernode structure (precursor: KaZaA)

Supernode peer must be fully reachable (not behind NAT)
among other criteria: Firewall/NAT traversal via
supernodes
Media data: direct communication between peers
when possible; when not (e.g. firewall) then relay via
supernode
ˆ Codecs in the range ~16kbps-128kbps with loss
concealment
ˆ
7: Multimedia Networking
7-85
CDN+P2P Summary
ˆ CDN increasingly popular
ˆ Can P2P win over CDN?
Technically, it is elegant and convincing!



Skype’s new Joost service: TV on demand
Zattoo
Bittorrent for sharing large files (including videos, software)
ˆ Legal issues


Copyright infringement
(Zattoo negotiates with each content provider)
Dissemination of offensive content, malicious programs (e.g.
spyware, adware, viruses), spam (new: VoIP spam!)
7: Multimedia Networking
7-86