Title: Transport of Real-Time Traffic over the Internet
1Transport of Real-Time Trafficover the Internet
- Bernd Girod
- Information Systems Laboratory
- Stanford University
2THE MEANING OF FREE SPEECH The acquisition by
eBay of Skype is a helpful reminder to the
world's trillion-dollar telecoms industry that
all phone calls will eventually be free . . . .
. . Ultimatelyperhaps by 2010voice may become a
free internet application, with operators making
money from related internet applications like
IPTV . . .
Economist, September 2005
3IPTV Rollout
Verizon 10M householdsby 2009
IPTV SBC18M households by 2007
IEEE Spectrum, Jan. 2005
4Why Is Real-Time Transport Hard?
Internet is a best-effort network . . .
Congestion Insufficient rate to
communicate Packet loss Impairs perceptual
quality Delay Impairs interactivity of
services Telephony one way delay lt 150 ms
ITU-T Rec. G.114 Delay
jitter Obstructs continuous media playout
5Outline of the Talk
- QoS vs. best effort
- Resource allocation for IPTV
- Rate-distortion optimized streaming
- Multi-path routing
- P2P multicasting of live video streams
6How 1B Users Share the Internet
Rate r
TCP Throughput
maximum transfer unit
Growing congestion
data rate
packet loss rate
p
round trip time
0.001
0.0001
0.1
0.01
- Mahdavi, Floyd, 1997
- Floyd, Handley, Padhye, Widmer, 2000
7QoS vs. Best Effort
- Reservation-ism
- Voice and video need guaranteed QoS (bandwidth,
loss, delay) - Implement admission control Busy tone when
network is full - Best effort is fine for data applications
- Best Effort-ism
- Best Effort good enough for all applications
- Real-time applications can be made adaptive to
cope with any level of service - Overprovisioning always solves the problem, and
its cheaper than QoS guarantees
8Simple Model of A Shared Link
- Link of capacity C is shared among k flows
- Fair sharing each flow uses data rate C/k
- Homogeneous flows with same utility function u(.)
- Total utility
C
Breslau, Shenker, 1998
9Rigid Applications
u
- Utility u0 below of minimum bit-rate B
- Maximum total utility Uk is achieved by
admitting at most k flows
1
C/k
B
Breslau, Shenker, 1998
10Rigid Applications (cont.)
- Expected loss in total utility w/o admission
control - Gap DU is substantial when number of admissable
flows k is small - Gap DU usually disappears with growing capacity
C? Overprovisioning can solve the problem!
Breslau, Shenker, 1998
11Elastic Applications
- Elastic applications utility function u(k), such
that total utility U(k)ku(C/k) increases with k - Example u(C/k)1-aC/k
- All flows should be admitted best effort!
u
C/k
12Video Compression
- H.264 video coding for 2 different testsequences
- Video is elastic application
- Rate must be adapted to network throughput
- How to achieve rate control for stored content or
multicasting? - Utility function depends on content should use
unequal rate allocation
Good picture quality
Foreman Mobile
Bad picture quality
13Different Utility Functions
- Example uk(rk)1-akrk
- With rkgt0 ? Karush-Kuhn-Tucker conditions
(reverse water-filling) - Better than utility-oblivious fair sharing
Equal-slope Pareto condition
uk
Vilfredo Pareto 1848-1923
rk
14Distribution of IPTV over WLAN
5 Mbps
11 Mbps
2 Mbps
Home Media Gateway
courtesy van Beek, 2004
15Video Streaming Over Shared Channel
Transcoder
Decoder
0
0
Transcoder
Decoder
1
1
Receiver
Transcoder
Decoder
(Multi-Channel)
2
2
Transcoder
Decoder
3
3
Controller
Kalman, van Beek, Girod 2005
16Tx Backlog for 4 Video Streams 85 WLAN
Utilization
Kalman, van Beek, Girod 2005
17Streaming of Stored Content
Media files are already compressed How can we
nevertheless adapt to network?
100s to 1000ssimultaneous streams
DSL
Cable
wireless
Server
Network
Client
18Not All Packets are Equally Important
I
I
P
P
I
B
B
B
P
P
P
I
B
B
B
P
A
A
19Not All Packets are Equally Important
I
I
P
B
P
P
I
B
B
P
P
I
B
B
B
P
A
A
20Distortion-Aware Packet Dropping
Good Picture quality
Distortionaware
Packet dropping No retransmissions QCIF
Carphone I-P-P-P-P-P- . . .
Bad picture quality
Oblivious
Percentage of Packets Retained
Chakareski, Girod, ICME 2004
21Rate-DistortionOptimized (RaDiO) Streaming
- Decide which packets to send (and when) to
maximize picture quality while not exceeding an
average rate 2001
Server
Client
Network
22A Brief History of Media Streaming
- Media streaming w/o congestion avoidance
reckless driving 1995 - TCP-friendly rate control Limit average rate
for fair sharing with TCP 1997 - Rate-distortion optimized packet scheduling
(RaDiO) Decide which packets to send (and
when) to maximize picture quality while not
exceeding an average rate 2001 - Congestion-distortion-optimized
scheduling/routing (CoDiO) Decide which
packets to send (and when) to maximize picture
quality while minimizing network congestion.
2004
23Congestion vs. Rate
- Congestion queuing delay that packets experience
- weighted by size of the packet
- averaged over all packets in the network
- Congestion increases nonlinearly with link
bit-rate
Rmax
24Video Distortion with Self Congestion
Good Picture quality
Bad picture quality
Bit-Rate kbps
25Streaming with Last Hop Bottleneck
Random cross traffic
High bandwidth links
Video traffic
Low bandwidth last hop
Acknowledgments
26Delay distribution
- Overall delay distribution
- Queue length determines delay of last hop
pdf
delay
C
27Comparison RaDiO vs. CoDiO
50
PSNR dB
PSNR dB
Rate kbps
End-to-end delay ms
Simulations using H.263 Rate 10 fps Sequence
Foreman (32kbps,32kbps) Sequence length
60s Playout deadline 600ms
28How To Avoid Traffic Jams?
- Avoid congested times . . .
- ?Congestion-aware packet scheduling
- Avoid congested roads . . .
- ?Congestion-aware routing
29Multipath Routing for Minimum Congestion
- Mesh network, fully connected
- Streaming 100 kbps from Node 1 to Node 5
- Random cross traffic
30Multipath Video Streaming
Good Picture quality
6 dB
Sequence Foreman QCIF, 250
frames, 30 fps Codec H.26L TML 8.5 Playout
deadline 500 ms Packetization 1
frame/packet Traffic model CBR No. of
realizations 400
Bad picture quality
Bit-Rate kbps
31Multipath Video Streaming
3 paths 187 kbps, PSNR 36.2 dB
1 path 80 kbps, PSNR 32.5 dB
32Distribution of Live Streams via
Pseudo-Multicast
- Example
- AOL webcast of Live 8 concert
- July 2, 2005
Content delivery network
Media server
. . .
Splitter servers
1500 servers in 90 locations
50 Gbps
. . .
. . .
. . .
. . .
. . .
175,000 simultaneous viewers
8M unique viewers
33Distribution of Live Streams via
Pseudo-Multicast
- Example
- AOL webcast of Live 8 concert
- July 2, 2005
300 kbps
175,000 simultaneous viewers
8M unique viewers
34P2P Multicast over 1 Tree
35P2P Multicast over 2 Trees
36P2P Ungraceful Parent Leave
Parent leave is detected
Retransmissions requested
New parent is selected
Parent of yellow tree is down
Yellow tree is recovered
3 trees
Hello, Yellow Tree Parent?
37Experimental Set-up
- Network/protocol simulation in ns-2
- 1000 nodes
- 300 active peers
- Random peer arrival/departure ON (5 min)/OFF
(30 s) - Over-provisioned backbone
- Typical access bandwidth distribution
- Delay 5 ms/link congestion
- Video streaming
- Compression H.264 at 220 kbps
- 15 minute live multicast
Setton, Noh, Girod, ACM MM 2005
38Join and Rejoin Latencies
Setton, Noh, Girod, ACM MM 2005
39Congestion-DistortionOptimized P2P Live Streaming
Without CoDiO
peersconnected to 4/4 trees
With CoDiO
peersconnected to 4/4 trees
Setton, Noh, Girod, ACM MM 2005
40P2P Video Multicast 64 out of 300 Peers
Congestion-distortion optimized (CoDiO) streaming
Without CoDiO
H.264 _at_ 220 kbps2 sec latency for all streams
41Concluding Remarks
- Over-provisioning makes QoS superfluous
- Elastic applications dont need QoS
- Joint rate control for access bottlenecks (e.g.
IPTV, WLAN) - Media-aware congestion control (e.g. CoDiO)
- Multipath routing to mitigate congestion
- P2P viable alternative for content delivery
networks - Client-server ? edge-based ? P2P
42The End
- http//www.stanford.edu/bgirod/publications.html