Mul$media Networking
#9 CDN Solu$ons
Semester Ganjil 2012
Today’s Outline
•
Ways to distribute video online
– Client-‐server
– IP Mul$cast
– P2P Media Streaming
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
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
Content Distribu$on Network
throughout the Internet•
Upda$ng the replicas
– Updates pushed to replicas when the content changes
origin server in North America
CDN distribution node
CDN server
in S. America CDN server in Europe
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”
Server Selec$on Policy
•
Live server
– For availability
•
Lowest load
– To balance load across the servers
•
Closest
– Nearest geographically, or in round-‐trip $me
•
Best performance
– Throughput, latency, …
•
Cheapest bandwidth, electricity, …
Server Selec$on Mechanism
•
Applica$on
– HTTP redirec$on
•
Advantages
– Fine-‐grain control – Selec$on based on
client IP address
•
Disadvantages
– Extra round-‐trips for TCP connec$on to server
– Overhead on the server
10
GET
Redirect
GET
Server Selec$on Mechanism
•
Rou$ng
– Anycast rou$ng
•
Advantages
– No extra round trips – Route to nearby server
•
Disadvantages
– Does not consider
network or server load – Different packets may
go to different servers – Used only for simple
request-‐response apps
11
1.2.3.0/24
Server Selec$on Mechanism
Akamai Sta$s$cs
•
Distributed servers
–
Servers: ~61,000
–
Networks: ~1,000
–
Countries: ~70
•
Many customers
–
Apple, BBC, FOX, GM
IBM, MTV, NASA,
NBC, …
•
Client requests
–
Hundreds of
billions per day
–
Half in the top
45 networks
HTTP
How Akamai Uses DNS
cnn.com (content provider) DNS root server
1 2
HTTP
How Akamai Uses DNS
cnn.com (content provider) DNS root server
1 2
HTTP
How Akamai Uses DNS
cnn.com (content provider) DNS root server
1 2
HTTP
How Akamai Uses DNS
cnn.com (content provider) DNS root server
1 2
HTTP
How Akamai Uses DNS
cnn.com (content provider) DNS root server
1 2
HTTP
How Akamai Uses DNS
cnn.com (content provider) DNS root server
1 2
HTTP
How Akamai Uses DNS
cnn.com (content provider) DNS root server
1 2
How Akamai Works: Cache Hit
cnn.com (content provider) DNS root server Akamai server
1 2
Akamai high-level DNS server
Mapping System
•
Equivalence classes of IP addresses
– IP addresses experiencing similar performance – Quan$fy how well they connect to each other
•
Collect and combine measurements
– Ping, traceroute, BGP routes, server logs
• E.g., over 100 TB of logs per days
– Network latency, loss, and connec$vity
Mapping System
•
Map each IP class to a preferred server cluster
– Based on performance, cluster health, etc. – Updated roughly every minute
•
Map client request to a server in the cluster
Adap$ng to Failures
•
Failing hard drive on a server
– Suspends aqer finishing “in progress” requests
•
Failed server
– Another server takes over for the IP address – Low-‐level map updated quickly
•
Failed cluster
– High-‐level map updated quickly
•
Failed path to customer
’
s origin server
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
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)
Conclusion
•
Content distribu$on is hard
– Many, diverse, changing objects
– Clients distributed all over the world – Reducing latency is king
•
Contribu$on distribu$on solu$ons
– Reac$ve caching
CDN: “simple” content access scenario
Bob (client) requests video hrp://netcinema.com/6Y7B23V
video stored in CDN at hrp://KingCDN.com/NetC6y&B23V 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&B23V 4
4&5. Resolve
http://KingCDN.com/NetC6y&B23
via KingCDN’s authoritative DNS, which returns IP address of KingCDN server with video
5
6. request video from KINGCDN server, streamed via HTTP
Case study: Nedlix
•
30% downstream US traffic in 2011
•
owns very lirle infrastructure, uses 3
rdparty
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:
Case study: Nedlix
Limelight CDN
Level-3 CDN
2
2. Bob browses Netflix video
3
3. Manifest file returned for requested video
4. DASH streaming
