Introduc$on Applica$ons of MN Requirements of MN Coding and Compression 5. RTP 6. IP Mul$cast 7. IP Mul$cast (cont’d)
8. Overlay Mul$cast 9. CDN: Solu,ons 10. CDN: Case Studies 11. QoS on the Internet: Constraints 12. QoS on the Internet: Solu$ons 13. Discussion 14. Summary
#9 Mul$media Networking
2
Today’s Outline • Ways to distribute video online – Client-‐server – IP Mul$cast – P2P Media Streaming – CDN (Content Delivery Networks)
#9 Mul$media Networking
3
Content Delivery/Distribu$on Networks (CDN)
Content Distribu$on Network • challenge: how to stream content (selected from millions of videos) to hundreds of thousands of simultaneous users? • op,on 1: single, large “mega-‐server” – single point of failure – point of network conges$on – long path to distant clients – mul$ple copies of video sent over outgoing link
….quite simply: this solu$on doesn’t scale #9 Mul$media Networking
5
Content Distribu$on Network • challenge: how to stream content (selected from millions of videos) to hundreds of thousands of simultaneous users? • op,on 2: store/serve mul$ple copies of videos at mul$ple geographically distributed sites (CDN) – enter deep: push CDN servers deep into many access networks • close to users • used by Akamai, 1700 loca$ons
– bring home: smaller number (10’s) of larger clusters in POPs near (but not within) access networks • used by Limelight #9 Mul$media Networking
– Content provider (e.g., CNN) contracts with a CDN
• CDN replicates the content
CDN distribution node
– On many servers spread throughout the Internet
• Upda$ng the replicas – Updates pushed to replicas when the content changes
CDN server CDN server in S. America CDN server in Asia in Europe
#9 Mul$media Networking
7
Server Selec$on Policy • 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, repor$ng results to CDN DNS) – IP anycast
• alterna,ve: let client decide -‐ give client a list of several CDN servers – client pings servers, picks “best” – Nedlix approach #9 Mul$media Networking
8
Server Selec$on Policy Requires continuous monitoring of liveness, load, and performance
• Live server – For availability
• Lowest load – To balance load across the servers
• Closest – Nearest geographically, or in round-‐trip $me
– Fine-‐grain control – Selec$on based on client IP address
• Disadvantages – Extra round-‐trips for TCP connec$on to server – Overhead on the server #9 Mul$media Networking
10
11
Server Selec$on Mechanism • Rou$ng
• Advantages
– Anycast rou$ng
– No extra round trips – Route to nearby server
1.2.3.0/24
1.2.3.0/24
• Disadvantages – Does not consider network or server load – Different packets may go to different servers – Used only for simple request-‐response apps
#9 Mul$media Networking
11
Server Selec$on Mechanism • Naming
• Advantages
– DNS-‐based server selec$on 1.2.3.4
• Disadvantage
DNS query
1.2.3.5 local DNS server
– Avoid TCP set-‐up delay – DNS caching reduces overhead – Rela$vely fine control – Based on IP address of local DNS server – “Hidden load” effect – DNS TTL limits adapta$on
• Failed path to customer’s origin server – Route packets through an intermediate node #9 Mul$media Networking
25
Akamai Transport Op$miza$ons • Bad Internet routes – Overlay rou$ng through an intermediate server
• Packet loss – Sending redundant data over mul$ple paths
• TCP connec$on set-‐up/teardown – Pools of persistent connec$ons
• TCP conges$on window and round-‐trip $me – Es$mates based on network latency measurements #9 Mul$media Networking
26
Akamai Applica$on Op$miza$ons • Slow download of embedded objects – Prefetch when HTML page is requested
• Large objects – Content compression
• Slow applica$ons – Moving applica$ons to edge servers – E.g., content aggrega$on and transforma$on – E.g., sta$c databases (e.g., product catalogs) – E.g. batching and valida$ng input on Web forms #9 Mul$media Networking
27
Conclusion • Content distribu$on is hard – Many, diverse, changing objects – Clients distributed all over the world – Reducing latency is king
CDN: “simple” content access scenario Bob (client) requests video hrp://netcinema.com/6Y7B23V video stored in CDN at hrp://KingCDN.com/NetC6y&B23V 1. Bob gets URL for for video http://netcinema.com/6Y7B23V 2. resolve http://netcinema.com/6Y7B23V from netcinema.com web page 2 via Bob’s local DNS 1 6. request video from 5 4&5. Resolve KINGCDN server, http://KingCDN.com/NetC6y&B23 streamed via HTTP via KingCDN’s authoritative DNS, 3. netcinema’s DNS returns URL netcinema.com 4 which returns IP address of KingCDN http://KingCDN.com/NetC6y&B23V server with video 3
netcinema’s authorative DNS
KingCDN KingCDN.com #9 Mul$media Networking authoritative DNS
29
Case study: Nedlix • 30% downstream US traffic in 2011 • owns very lirle infrastructure, uses 3rd party services: – own registra$on, payment servers – Amazon (3rd party) cloud services: • Nedlix uploads studio master to Amazon cloud • create mul$ple version of movie (different endodings) in cloud • upload versions from cloud to CDNs • Cloud hosts Nedlix web pages for user browsing
– three 3rd party CDNs host/stream Nedlix content: Akamai, Limelight, Level-‐3 #9 Mul$media Networking
30
Case study: Nedlix Amazon cloud
Netflix registration, accounting servers 2. Bob browses Netflix video 2
upload copies of multiple versions of video to CDNs
3. Manifest file returned for requested video
Akamai CDN
Limelight CDN
3
1 1. Bob manages Netflix account 4. DASH streaming