CSE 124 Networked Services Fall 2009

CSE 124 Networked Services

Fall 2009B. S. Manoj, Ph.D

http://cseweb.ucsd.edu/classes/fa09/cse124

10/13/2009 1CSE 124 Networked Services Fall 2009

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.

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


Streaming stored video over HTTP

• browser GETs metafile• browser launches player, passing metafile• player contacts server• server streams audio/video to player


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

• 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)

Web Browser

Web Server

Streaming Server

(YouTube, or CDN)

(1) HTTP Get for media file

(2) HTTP Redirect (303)

(3) HTTP Get for media file

(4) Streamed flash media

Media player

CSE 124 Networked Services Fall 2009

constant bit rate videotransmission

Cum

ulat

ive

data

time

variablenetwork

delay

client videoreception

constant bit rate video playout at client

client playoutdelay

buff

ered

vide

o

Streaming Multimedia: Client Buffering

• client-side buffering, playout delay compensate for network-added delay, delay jitter


Streaming Multimedia: Client Buffering

• client-side buffering, playout delay compensate for network-added delay, delay jitter

bufferedvideo

variable fillrate, x(t)

constant drainrate, d


Real Time Streaming Protocol: User Control of Streaming MediaHTTP• 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…

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


RTSP: out of band controlFTP 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

RTSP messages also sent out-of-band:

• RTSP control messages use different port numbers than media stream: out-of-band.– port 544

• media stream is considered “in-band”.


RTSP ExampleScenario:• metafile communicated to the web browser

• browser launches player

• player sets up an RTSP control connection, data connection to streaming server


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>


RTSP Operation


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=0-

C: 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

•Normal play time (NPT) indicates the stream absolute position relative to the beginning of the presentation.

•OK message is used for every Client request10/13/2009 14CSE 124 Networked Services Fall 2009

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 players


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


Soft service failures• Duration Violation

– A session s is considered as facing duration violation if

• Data Size Violation

• Re-buffering Quality violation


threshse

sm DT

T1

Tsm -- Measured session durationTse – Expected session durationDthresh (0<Dthresh ≤1) – acceptablethreshold of duration requirement.

threshse

sm BB

B1

Bsm -- Measured Data Bytes (Bsm < Bse)Bse – Expected Data ByatesBthresh (0<Bthresh ≤1) – acceptablethreshold of Data Bytes

threshN

i i

N

iii

QT

RPD

1

1

N – Number of individual probes/sessionsDi – Startup/Setup Delay for ith probeP – Penalty for the re-buffering incident (includes the re-buffering time)Ri – No. of re-buffering incidents for ith sessionQthresh – Re-buffering Quality threshold (0< Qthresh ≤1)

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– 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

• frame rate, metafiles, urls, player errors etc.10/13/2009 CSE 124 Networked Services Fall 2009 18

Source: Keynote, Inc.

Keynote’s agents’ location

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 • 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.


Connect Time

Buffer Time Play Time

1.2s 0.9s 35s

Frustration Time = 2.1s

Connect Time

Buffer Time

Play Time

1.2s 3.2s

Re-Buffer

Play Time

Re-Buffer

0.9s 2.6s

Frustration Time = 2.1s+(2+3.2)+(2+2.6)= 11.9s

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)


• 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


• 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

10/13/2009 CSE 124 Networked Services Fall 2009 22N=27


YouTube stream statistics (Measurements from a network)

Statistics of YouTube-like models

• Global to local correlation is very small (0.04-0.06)– For clients in the range: 2127, 2480, and 1547)


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


RTP runs on top of UDPRTP libraries provide transport-layer interface that extends UDP:

• port numbers, IP addresses• payload type identification• packet sequence numbering• time-stamping

2610/13/2009 CSE 124 Networked Services Fall 2009

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.


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


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);

Source: RFC 3550


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 30CSE 124 Networked Services Fall 2009

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.


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


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


RTCP PacketsReceiver report packets:• fraction of packets lost, • last sequence number,

average interarrival jitterSender 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


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


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

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 video-on-demand systems,” Proceedings of the EuroSys 2006 conference Vol. 40 , No. 4, pp. 333-344, October 2006.


http://www.techweb.com/encyclopedia/defineterm.jhtml?term=peer-to-peer&x=&y=

CSE 124 Networked Services Fall 2009

Documents

popular streaming services

networked servicesfall

streaming serveryoutube

streaming stored video

streamed media

band control channel

playout delay

real time streaming