1 / 37

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

zachary-carter
Télécharger la présentation

CSE 124 Networked Services Fall 2009

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSE 124 Networked ServicesFall 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. CSE 124 Networked Services Fall 2009

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

  3. Application layer protocols for Multimedia services CSE 124 Networked Services Fall 2009

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

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

  6. 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) (1) HTTP Get for media file Web Browser Web Server (2) HTTP Redirect (303) (3) HTTP Get for media file Media player Streaming Server (YouTube, or CDN) (4) Streamed flash media CSE 124 Networked Services Fall 2009

  7. client video reception constant bit rate video playout at client variable network delay buffered video client playout delay Streaming Multimedia: Client Buffering constant bit rate video transmission • client-side buffering, playout delay compensate for network-added delay, delay jitter Cumulative data time CSE 124 Networked Services Fall 2009

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

  9. 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 Real Time Streaming Protocol: User Control of Streaming Media CSE 124 Networked Services Fall 2009

  10. 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”. RTSP: out of band control CSE 124 Networked Services Fall 2009

  11. RTSP Example Scenario: • metafile communicated to the web browser • browser launches player • player sets up an RTSP control connection, data connection to streaming server CSE 124 Networked Services Fall 2009

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

  13. RTSP Operation CSE 124 Networked Services Fall 2009

  14. 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 request CSE 124 Networked Services Fall 2009

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

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

  17. Soft service failures • Duration Violation • A session s is considered as facing duration violation if • Data Size Violation • Re-buffering Quality violation 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 N – Number of individual probes/sessions Di – Startup/Setup Delay for ith probe P – Penalty for the re-buffering incident (includes the re-buffering time) Ri – No. of re-buffering incidents for ith session Qthresh – Re-buffering Quality threshold (0< Qthresh ≤1) CSE 124 Networked Services Fall 2009

  18. 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. Keynote’s agents’ location Source: Keynote, Inc. CSE 124 Networked Services Fall 2009

  19. 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 oninterruptions • 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 Connect Time Buffer Time Play Time Re-Buffer Play Time Re-Buffer 1.2s 0.9s 1.2s 0.9s 3.2s 2.6s 35s Frustration Time = 2.1s Frustration Time = 2.1s+(2+3.2)+(2+2.6)= 11.9s CSE 124 Networked Services Fall 2009

  20. 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) CSE 124 Networked Services Fall 2009

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

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

  23. YouTube stream statistics (Measurements from a network) CSE 124 Networked Services Fall 2009

  24. 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) CSE 124 Networked Services Fall 2009

  25. 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 Real-Time Protocol (RTP) CSE 124 Networked Services Fall 2009

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

  27. 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 Example CSE 124 Networked Services Fall 2009

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

  29. 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; intd = transit - s->transit; s->transit = transit; if (d < 0) d = -d; s->jitter += (1./16.) * ((double)d - s->jitter); Source: RFC 3550 CSE 124 Networked Services Fall 2009

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

  31. 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. RTP Header (2) CSE 124 Networked Services Fall 2009

  32. 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 Real-Time Control Protocol (RTCP) CSE 124 Networked Services Fall 2009

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

  34. 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: e-mail address of sender, sender's name, SSRC of associated RTP stream provide mapping between the SSRC and the user/host name RTCP Packets CSE 124 Networked Services Fall 2009

  35. 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 Synchronization of Streams CSE 124 Networked Services Fall 2009

  36. 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 RTCP Bandwidth Scaling Tsender = (No. Senders x Avg Packet size)/(0.25x0.05xSession bandwidth) Treceiver = (No. Senders x Avg Packet size)/(0.75x0.05xSession bandwidth)

  37. 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, KyoungwonSuh, 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. • BeomjooSeo, Michele Covell, MirjanaSpasojevic, Sumit Roy, Roger Zimmermann, LeonidasKontothanassis 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. CSE 124 Networked Services Fall 2009

More Related