1. Chapter 7 Multimedia Networking Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you see the animations; and can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following:  If you use these slides (e.g., in a class) that you mention their source (after all, we’d like people to use our book!)  If you post any slides on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Thanks and enjoy! JFK/KWR All material copyright 1996-2012 J.F Kurose and K.W. Ross, All Rights Reserved Multmedia Networking7-1 The course notes are adapted for CSCI 363 at Bucknell Spring 2014, Xiannong Meng

2. Multimedia networking: outline 7.1 multimedia networking applications 7.2 streaming stored video 7.3 voice-over-IP 7.4 protocols for real-time conversational applications 7.5 network support for multimedia Multmedia Networking7-2

3. Multimedia: audio Multmedia Networking7-3  analog audio signal sampled at constant rate  telephone: 8,000 samples/sec  music CD : 44,100 samples/sec  each sample quantized, i.e., rounded  e.g., 2 8 =256 possible quantized values  each quantized value represented by bits, e.g., 8 bits for 256 values time audio signal amplitude analog signal quantized value of analog value quantization error sampling rate (N sample/sec)

4. Multimedia: audio Multmedia Networking7-4  example: 8,000 samples/sec, 256 quantized values: 64,000 bps  receiver converts bits back to analog signal:  some quality reduction example rates  CD: 1.411 Mbps (44,100 samples/s, 16 bit/s or 705.6 kbps for mono, 32bit/s or 1.411mbps for stereo)  MP3: 96, 128, 160 kbps  Internet telephony: 5.3 kbps and up time audio signal amplitude analog signal quantized value of analog value quantization error sampling rate (N sample/sec)

5.  video: sequence of images displayed at constant rate  e.g., 24 images/sec  digital image: array of pixels  each pixel represented by bits  coding: use redundancy within and between images to decrease # bits used to encode image  spatial (within image)  temporal (from one image to next) Multmedia Networking7-5 Multimedia: video ……………………...… spatial coding example: instead of sending N values of same color (all purple), send only two values: color value (purple) and number of repeated values (N) ……………………...… frame i frame i+1 temporal coding example: instead of sending complete frame at i+1, send only differences from frame i

6. Multmedia Networking7-6 Multimedia: video ……………………...… spatial coding example: instead of sending N values of same color (all purple), send only two values: color value (purple) and number of repeated values (N) ……………………...… frame i frame i+1 temporal coding example: instead of sending complete frame at i+1, send only differences from frame i  CBR: (constant bit rate): video encoding rate fixed  VBR: (variable bit rate): video encoding rate changes as amount of spatial, temporal coding changes  examples:  MPEG 1 (CD-ROM) 1.5 Mbps  MPEG2 (DVD) 3-6 Mbps  MPEG4 (often used in Internet, < 1 Mbps)

7. Multimedia networking: 3 application types Multmedia Networking7-7  streaming, stored audio, video  streaming: can begin playout before downloading entire file  stored (at server): can transmit faster than audio/video will be rendered (implies storing/buffering at client)  e.g., YouTube, Netflix, Hulu  conversational (interactive) voice/video over IP  interactive nature of human-to-human conversation limits delay tolerance  e.g., Skype  streaming live audio, video  e.g., live sporting event (futbol)

8. Multimedia networking: outline 7.1 multimedia networking applications 7.2 streaming stored video 7.3 voice-over-IP 7.4 protocols for real-time conversational applications 7.5 network support for multimedia Multmedia Networking7-8

9. Streaming stored video: 1.video recorded (e.g., 30 frames/sec) 2. video sent Cumulative data streaming: at this time, client playing out early part of video, while server still sending later part of video network delay (fixed in this example) time Multmedia Networking7-9 3. video received, played out at client (30 frames/sec)

10. Streaming stored video: challenges  continuous playout constraint: once client playout begins, playback must match original timing  … but network delays are variable (jitter), so will need client-side buffer to match playout requirements  other challenges:  client interactivity: pause, fast-forward, rewind, jump through video  video packets may be lost, retransmitted Multmedia Networking7-10

11. 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  client-side buffering and playout delay: compensate for network-added delay, delay jitter Multmedia Networking7-11 Streaming stored video: revisted

12. Client-side buffering, playout Multmedia Networking7-12 variable fill rate, x(t) client application buffer, size B playout rate, e.g., CBR r buffer fill level, Q(t) video server client

13. Client-side buffering, playout Multmedia Networking7-13 variable fill rate, x(t) client application buffer, size B playout rate, e.g., CBR r buffer fill level, Q(t) video server client 1. Initial fill of buffer until playout begins at t p 2. playout begins at t p, 3. buffer fill level varies over time as fill rate x(t) varies and playout rate r is constant

14. playout buffering: average fill rate (~x), playout rate (r):  ~x < r : buffer eventually empties (causing freezing of video playout until buffer again fills)  ~x > r: buffer will not empty, provided initial playout delay is large enough to absorb variability in x(t)  initial playout delay tradeoff: buffer starvation less likely with larger delay, but larger delay until user begins watching Multmedia Networking7-14 variable fill rate, x(t) client application buffer, size B playout rate, e.g., CBR r buffer fill level, Q(t) video server Client-side buffering, playout

15. Streaming multimedia: UDP  server sends at rate appropriate for client  often: send rate = encoding rate = constant rate  transmission rate can be oblivious to congestion levels  short playout delay (2-5 seconds) to remove network jitter  error recovery: application-level, timeipermitting  RTP [RFC 2326]: multimedia payload types  UDP may not go through firewalls Multmedia Networking7-15

16. UDP stream example and issues  Video consumption rate: 2 Mbps (given)  Then the server would transmit one UDP packet full of data every (8000 bits)/(2 Mbps) = 4 ms  Some issues:  UDP doesn’t handle variable network bandwidth well  UDP streaming requires a media control server (e.g., RTSP server) to process client-server interaction, and to track client state  Many firewalls are designed to block UDP traffic Multmedia Networking7-16

17. Streaming multimedia: HTTP  multimedia file retrieved via HTTP GET  send at maximum possible rate under TCP  fill rate fluctuates due to TCP congestion control, retransmissions (in-order delivery)  larger playout delay: smooth TCP delivery rate  HTTP/TCP passes more easily through firewalls Multmedia Networking7-17 variable rate, x(t) TCP send buffer video file TCP receive buffer application playout buffer server client

18. Streaming multimedia: DASH  DASH: Dynamic, Adaptive Streaming over HTTP  server:  divides video file into multiple chunks  each chunk stored, encoded at different rates  manifest file: provides URLs for different chunks  client:  periodically measures server-to-client bandwidth  consulting manifest, requests one chunk at a time chooses maximum coding rate sustainable given current bandwidth can choose different coding rates at different points in time (depending on available bandwidth at time) Multmedia Networking7-18

19. Streaming multimedia: DASH  DASH: Dynamic, Adaptive Streaming over HTTP (a.k.a. MPEG-DASH)  “intelligence” at client: client determines  when to request chunk (so that buffer starvation, or overflow does not occur)  what encoding rate to request (higher quality when more bandwidth available)  where to request chunk (can request from URL server that is “close” to client or has high available bandwidth) Multmedia Networking7-19

20. MPEG-DASH structure Multmedia Networking7-20 http://dashif.org/mpeg-dash/

21. Content distribution networks  challenge: how to stream content (selected from millions of videos) to hundreds of thousands of simultaneous users?  option 1: single, large “mega-server”  single point of failure  point of network congestion  long path to distant clients  multiple copies of video sent over outgoing link ….quite simply: this solution doesn’t scale Multmedia Networking7-21

22. Content distribution networks  challenge: how to stream content (selected from millions of videos) to hundreds of thousands of simultaneous users?  option 2: store/serve multiple copies of videos at multiple geographically distributed sites (CDN)  enter deep: push CDN servers deep into many access networks close to users used by Akamai, 1700 locations  bring home: smaller number (10’s) of larger clusters in POPs near (but not within) access networks used by Limelight Multmedia Networking7-22

23. CDN: “simple” content access scenario Multmedia Networking7-23 Bob (client) requests video http://netcinema.com /6Y7B23V  video stored in CDN at http://KingCDN.com/NetC6y&B 23V netcinema.com KingCDN.com 1 1. Bob gets URL for for video http://netcinema.com/6Y7B23V from netcinema.com web page 2 2. resolve http://netcinema.com/6Y7B23V via Bob’s local DNS netcinema’s authorative DNS 3 3. netcinema’s DNS returns URL http://KingCDN.com/NetC6y&B 23V 4 4&5. Resolve http://KingCDN.com/NetC6y&B23 via KingCDN’s authoritative DNS, which returns IP address of KIingCDN server with video 5 6. request video from KINGCDN server, streamed via HTTP KingCDN authoritative DNS

24. CDN cluster selection strategy  challenge: how does CDN DNS select “good” CDN node to stream to client  pick CDN node geographically closest to client  pick CDN node with shortest delay (or min # hops) to client (CDN nodes periodically ping access ISPs, reporting results to CDN DNS)  IP anycast  alternative: let client decide - give client a list of several CDN servers  client pings servers, picks “best”  Netflix approach Multmedia Networking7-24

25. Case study: Netflix  30% downstream US traffic in 2011  owns very little infrastructure, uses 3 rd party services:  own registration, payment servers  Amazon (3 rd party) cloud services: Netflix uploads studio master to Amazon cloud create multiple version of movie (different encodings) in cloud upload versions from cloud to CDNs Cloud hosts Netflix web pages for user browsing  three 3 rd party CDNs host/stream Netflix content: Akamai, Limelight, Level-3 Multmedia Networking7-25

26. Case study: Netflix Multmedia Networking7-26 1 1. Bob manages Netflix account Netflix registration, accounting servers Amazon cloud Akamai CDN Limelight CDN Level-3 CDN 2 2. Bob browses Netflix video 3 3. Manifest file returned for requested video 4. DASH streaming upload copies of multiple versions of video to CDNs