CSE 124 Networked Services Fall 2009 B. S. Manoj, Ph.D 10/13/20091CSE 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 23 rd October Week-2 Homework – Due on 15 th October First Paper Discussion – Discussion on 29 th October – Write-up due on: 28 th October – Papers will be online soon 10/13/2009CSE 124 Networked Services Fall 20092

Application layer protocols for Multimedia services 10/13/2009CSE 124 Networked Services Fall 20093

Streaming stored video over HTTP browser GETs metafile browser launches player, passing metafile player contacts server server streams audio/video to player 10/13/20094CSE 124 Networked Services Fall 2009

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 video transmission Cumulative data time variable network delay client video reception constant bit rate video playout at client client playout delay buffered video Streaming Multimedia: Client Buffering client-side buffering, playout delay compensate for network-added delay, delay jitter 10/13/20097CSE 124 Networked Services Fall 2009

Streaming Multimedia: Client Buffering client-side buffering, playout delay compensate for network-added delay, delay jitter buffered video variable fill rate, x(t) constant drain rate, d 10/13/20098CSE 124 Networked Services Fall 2009

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… 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 10/13/20099CSE 124 Networked Services Fall 2009

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 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”. 10/13/200910CSE 124 Networked Services Fall 2009

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

Metafile/Description Example Twister <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"> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> 10/13/200912CSE 124 Networked Services Fall 2009

RTSP Operation 10/13/200913CSE 124 Networked Services Fall 2009

RTSP Exchange Example C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/ 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: OK Normal play time (NPT) indicates the stream absolute position relative to the beginning of the presentation. OK message is used for every Client request 10/13/200914CSE 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 10/13/2009CSE 124 Networked Services Fall

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

Soft service failures Duration Violation – A session s is considered as facing duration violation if Data Size Violation Re-buffering Quality violation 10/13/2009CSE 124 Networked Services Fall T sm -- Measured session duration T se – Expected session duration D thresh (0<D thresh ≤1) – acceptable threshold of duration requirement. B sm -- Measured Data Bytes (B sm < B se ) B se – Expected Data Byates B thresh (0<B thresh ≤1) – acceptable threshold of Data Bytes N – Number of individual probes/sessions D i – Startup/Setup Delay for i th probe P – Penalty for the re-buffering incident (includes the re-buffering time) R i – No. of re-buffering incidents for i th session Q thresh – Re-buffering Quality threshold (0< Q thresh ≤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/2009CSE 124 Networked Services Fall Source: Keynote, Inc. Keynote’s agents’ location

Streaming Performance Metrics Performance metrics for streaming are still evolving Some proprietary metrics such as StreamQ TM 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. 10/13/2009CSE 124 Networked Services Fall Connect Time Buffer Time Play Time 1.2s0.9s 35s Frustration Time = 2.1s Connect Time Buffer Time Play Time 1.2s3.2s Re- Buffer Play Time Re- Buffer 0.9s2.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) 10/13/2009CSE 124 Networked Services Fall

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 minutes, 350MB movie 10/13/2009CSE 124 Networked Services Fall

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/2009CSE 124 Networked Services Fall N=27

10/13/2009CSE 124 Networked Services Fall YouTube stream statistics (Measurements from a network)

Statistics of YouTube-like models Global to local correlation is very small ( ) – For clients in the range: 2127, 2480, and 1547) 10/13/2009CSE 124 Networked Services Fall

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 10/13/200925CSE 124 Networked Services Fall 2009

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 2610/13/2009CSE 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. 10/13/200927CSE 124 Networked Services Fall 2009

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

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 /13/200929CSE 124 Networked Services Fall 2009

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/200930CSE 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. 10/13/200931CSE 124 Networked Services Fall 2009

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 10/13/200932CSE 124 Networked Services Fall 2009

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

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: address of sender, sender's name, SSRC of associated RTP stream provide mapping between the SSRC and the user/host name 10/13/200934CSE 124 Networked Services Fall 2009

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 10/13/200935CSE 124 Networked Services Fall 2009

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 videopeer-to-peer – 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 – 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 , May – 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 , October /13/2009CSE 124 Networked Services Fall