* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Lecture-6 on 10/13/2009
Survey
Document related concepts
TCP congestion control wikipedia , lookup
Asynchronous Transfer Mode wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Remote Desktop Services wikipedia , lookup
TV Everywhere wikipedia , lookup
Video on demand wikipedia , lookup
Serial digital interface wikipedia , lookup
Quality of service wikipedia , lookup
Deep packet inspection wikipedia , lookup
Lifecasting (video stream) wikipedia , lookup
Transcript
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