Transcript Lecture-6 on 10/13/2009

CSE 124
Networked Services
Fall 2009
B. S. Manoj, Ph.D
http://cseweb.ucsd.edu/classes/fa09/cse124
Some of these slides are adapted from various sources/individuals including but not limited to
the slides from the text books by Kurose and Ross and IEEE/ACM digital libraries.
Use of these slides other than for pedagogical purpose for CSE 124, may require explicit
permissions from the respective sources.
10/13/2009
CSE 124 Networked Services Fall 2009
1
Announcements
• Programming Assignment 1
– Due on 23rd October
• Week-2 Homework
– Due on 15th October
• First Paper Discussion
– Discussion on 29th October
– Write-up due on: 28th October
– Papers will be online soon
10/13/2009
CSE 124 Networked Services Fall 2009
2
Application layer protocols for
Multimedia services
10/13/2009
CSE 124 Networked Services Fall 2009
3
Streaming stored video over HTTP
• browser GETs metafile
• browser launches player, passing metafile
• player contacts server
• server streams audio/video to player
10/13/2009
CSE 124 Networked Services Fall 2009
4
Streaming from a streaming server
• allows for non-HTTP protocol between server, media player
• UDP or TCP for step (3)
CSE 124 Networked Services Fall 2009
Streaming from a streaming server
(1) HTTP Get for media file
(2) HTTP Redirect (303)
Web Server
Web Browser
Media
player
(3) HTTP Get for media file
(4) Streamed flash media
Streaming
Server
(YouTube, or
CDN)
• YouTube-like popular streaming services do it using HTTP redirect
• Web server provides a redirect message using Location field.
• Browser connects to the Streaming server (YouTube or Google) or
CDN server (Limelight)
CSE 124 Networked Services Fall 2009
Streaming Multimedia: Client
Buffering
constant bit
rate video
transmission
variable
network
delay
constant bit
rate video
playout at client
buffered
video
client video
reception
client playout
delay
time
• client-side buffering, playout delay compensate for
network-added delay, delay jitter
10/13/2009
CSE 124 Networked Services Fall 2009
7
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
10/13/2009
CSE 124 Networked Services Fall 2009
8
Real Time Streaming Protocol: User
Control of Streaming Media
HTTP
• does not target multimedia
content
• no commands for fast
forward, etc.
RTSP: RFC 2326
• client-server application
layer protocol
• user control: rewind, fast
forward, pause, resume,
repositioning, etc…
10/13/2009
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
CSE 124 Networked Services Fall 2009
9
RTSP: out of band control
FTP uses an “out-of-band”
control channel:
• file transferred over one
TCP connection.
• control info (directory
changes, file deletion,
rename) sent over
separate TCP connection
• “out-of-band”, “in-band”
channels use different
port numbers
10/13/2009
RTSP messages also sent outof-band:
• RTSP control messages
use different port
numbers than media
stream: out-of-band.
– port 544
• media stream is
considered “in-band”.
CSE 124 Networked Services Fall 2009
10
RTSP Example
Scenario:
• metafile communicated to the web browser
• browser launches player
• player sets up an RTSP control connection, data
connection to streaming server
10/13/2009
CSE 124 Networked Services Fall 2009
11
Metafile/Description 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>
10/13/2009
CSE 124 Networked Services Fall 2009
12
RTSP Operation
10/13/2009
CSE 124 Networked Services Fall 2009
13
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
•Normal play time (NPT) indicates the stream
absolute position relative to the beginning of the
S: 200 3 OK
presentation.
10/13/2009
message
used
CSE 124 •OK
Networked
Services Fallis
2009
for every Client request14
Performance measure of large
scale streaming services
• Performance is key to retaining users for any large scale
streaming service
• Traditional methods of performance measure may not work
– Performance is influenced by the relative location of clients and
streaming servers
– Internal measurements are of limited value
– New distributed measurements are emerging
• Distributed Streaming Performance measurement
companies exist
– e.g Keynote, Inc.
– Measurement agents are setup around the world
– Agents are measurement software that are pseudo media
10/13/2009 players
CSE 124 Networked Services Fall 2009
15
Other performance metrics for
streaming services
• When a streaming server is overloaded
– It starts behaving erratically
– New requests may be rejected
– Existing sessions may be poorly served
• Two kinds of service failures
– Hard service failure
– Soft service failure
• Hard service failure
– New session request rejection
– Existing session termination
• Soft service failure
– Duration violation
– Size violation
– Re-buffering violation
10/13/2009
CSE 124 Networked Services Fall 2009
16
Soft service failures
• Duration Violation
– A session s is considered as facing duration violation if
Tsm
1
 Dthresh
Tse
• Data Size Violation
Bsm
1
 Bthresh
Bse
Tsm -- Measured session duration
Tse – Expected session duration
Dthresh (0<Dthresh ≤1) – acceptable
threshold of duration requirement.
Bsm -- Measured Data Bytes (Bsm < Bse)
Bse – Expected Data Byates
Bthresh (0<Bthresh ≤1) – acceptable
threshold of Data Bytes
• Re-buffering Quality violation N – Number of individual probes/sessions
N
 D  P  R 
i 1
10/13/2009
i

i
N
T
i 1 i
Di – Startup/Setup Delay for ith probe
P – Penalty for the re-buffering incident
 Qthresh (includes the re-buffering time)
Ri – No. of re-buffering incidents for ith session
Qthresh
– Re-buffering
Quality threshold (0< 17
Qthresh ≤
CSE 124 Networked
Services
Fall 2009
Distributed performance measurement
of streaming services
• Agents attempt connection to a streaming
server at 10 times/hour
• Attempt playing media files (e.g for 60s)
• Agents measure the following
Keynote’s agents’ location
– Network parameters
• DNS time, end-to-end delay using traceroute,
packet statistics, and player statistics
– Streaming statistics
• connection success rate, bit rate, connection setup
/buffer/rebuffer time
– Server statistics
• server type, serving platform, streaming protocol
– Presentation statistics
CSE 124 Networked Services Fall 2009
• frame rate, metafiles,
urls, player errors etc.
10/13/2009
Source: Keynote, Inc.
18
Streaming Performance Metrics
• Performance metrics for streaming are still evolving
• Some proprietary metrics such as StreamQTM from Keynote, Inc.
exist
• StreamQ rates streaming servers A+ to F
•
•
•
•
Connect Buffer
Time
Time
1.2s
0.9s
Based on Frustration Time (FT)
Frustration Time defines the time spent by a media client on interruptions
StreamQ rating is based on the ratio of Frustration Time to playing time
FT < 6s: A+, 6s < FT < 9s: A, 9s < FT < 12s: B+ etc.
Play Time
35s
Frustration Time = 2.1s
10/13/2009
Connect Buffer Play
RePlay
ReTime
Time Time Buffer Time Buffer
1.2s
0.9s
3.2s
2.6s
Frustration Time = 2.1s+(2+3.2)+(2+2.6)= 11.9s
CSE 124 Networked Services Fall 2009
19
User behavior on Large Scale VoD
services over the Internet
• What is the content access pattern in large scale systems
– Hard to study using simulations or analysis
– Need real data, network, and users
– Mostly proprietary and confidential, so limited real data is available
• Here we discuss the empirical observations spanning
– 150,000 users in a chinese city
– 219 days in 2004
– Based on the PowerInfo Video-on-Demand (VoD) system of China
Telecom
• Similar to ComCast or NetFlix model
• Free value added service to the paying China Telecom customers
• Video on Demand service covering 20 cities (1.5 million unique users)
10/13/2009
CSE 124 Networked Services Fall 2009
20
• User Distribution and Hour
of day
– During the peak loaded
week
– Highest during Noon-2pm
or 6-10pm
• Distribution of Session
Lengths
– ~70% users spend less than
20 minutes
– A typical file is 100-120
minutes, 350MB movie
10/13/2009
CSE 124 Networked Services Fall 2009
21
• Average 5 users/s or 15 per
5 sec
– A very small prob. for large
number of users
• User arrival rate is different
from Poisson
– Shifted poisson
• Deviation from Pareto
Principle
– 10% of objects account for
60% access
– 23% of objects account for
80% access
N=27
10/13/2009
CSE 124 Networked Services Fall 2009
22
YouTube stream statistics
(Measurements from a network)
10/13/2009
CSE 124 Networked Services Fall 2009
23
Statistics of YouTube-like models
• Global to local correlation is very small (0.040.06)
– For clients in the range: 2127, 2480, and 1547)
10/13/2009
CSE 124 Networked Services Fall 2009
24
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
10/13/2009
• 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
CSE 124 Networked Services Fall 2009
25
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
10/13/2009
CSE 124 Networked Services Fall 2009
26
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
10/13/2009
• RTP header indicates type
of audio encoding in each
packet
– sender can change encoding
during conference.
• RTP header also contains
sequence numbers,
timestamps.
CSE 124 Networked Services Fall 2009
27
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.
• However, the End systems can utilize the information
in the header for better QoS
– For example, the jitter estimation
10/13/2009
CSE 124 Networked Services Fall 2009
28
Estimate of the statistical variance
of the RTP data interarrival time
• The inputs are
• r->ts: the timestamp from the incoming packet
• arrival: the current time in the same units
• s->transit: holds the relative transit time for the previous
packet
• s->jitter : holds the estimated jitter
• As each data packet arrives, the jitter estimate is
updated:
int transit = arrival - r->ts;
int d = transit - s->transit;
s->transit = transit;
if (d < 0) d = -d;
s->jitter += (1./16.) * ((double)d - s->jitter);
10/13/2009
CSE 124 Networked Services Fall 2009
Source: RFC 3550
29
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.
10/13/2009
CSE 124 Networked Services Fall 2009
30
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 the RTP stream.
– Each stream in RTP session should have distinct SSRC.
10/13/2009
CSE 124 Networked Services Fall 2009
31
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
• feedback can be used to
control performance
– sender may modify its
transmissions based on
feedback
– report statistics useful to
application: # packets sent, #
packets lost, interarrival jitter,
etc.
10/13/2009
CSE 124 Networked Services Fall 2009
32
RTCP - Continued

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
10/13/2009
CSE 124 Networked Services Fall 2009
33
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
10/13/2009
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
CSE 124 Networked Services Fall 2009
34
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
10/13/2009
• 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
CSE 124 Networked Services Fall 2009
35
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
gets to send RTCP traffic at 75/R
• Suppose one sender, sending
kbps.
video at 2 Mbps. Then RTCP
attempts to limit its traffic to
• sender gets to send RTCP traffic at
100 Kbps.
25 kbps.
• RTCP gives 75% of rate to
• participant determines RTCP packet
receivers; remaining 25% to
transmission period by calculating
sender
avg RTCP packet size (across entire
session) and dividing by allocated
rate
Tsender = (No. Senders x Avg Packet size)/(0.25x0.05xSession bandwidth)
Treceiver = (No. Senders x Avg Packet size)/(0.75x0.05xSession bandwidth)
To conclude
•
By 2012, nearly 90% of all consumer IP traffic is expected to consist of
–
–
–
–
video on demand,
IP peer-to-peer video
Internet video
IP phone traffic
•
Read through SIP protocol from Chapter 7, Kurose and Ross
•
References:
– Michael Zink, Kyoungwon Suh, Yu Gu, and Jim Kurose, “Characteristics of YouTube network
traffic at a campus network – Measurements, models, and implications,” Elsevier Computer
Networks, vol. 53, no. 4, pp. 501–514, March 2009.
– Beomjoo Seo, Michele Covell, Mirjana Spasojevic, Sumit Roy, Roger Zimmermann,
Leonidas Kontothanassis and Nina Bhatti, ``Evaluating Server Capacity for Streaming Media
Services,” Proceedings of the 8th International Conference (ICEIS) 2006, pp. 112-131, May
2006.
– H. Yu, D. Zheng, B. Y. Zhao, and W. Zheng, “Understanding user behavior in large-scale videoon-demand systems,” Proceedings of the EuroSys 2006 conference Vol. 40 , No. 4, pp. 333344, October 2006.
10/13/2009
CSE 124 Networked Services Fall 2009
37