580 likes | 782 Views
CPS 214 Computer Networks and Distributed Systems. “Live” Video and Audio Streaming End System Multicast Analysis of Akamai Workload. Presentations. Monday, April 21 Abhinav, Risi Bi, Jie Jason, Michael Martin, Matt Amre, Kareem Wednesday, April 23 Ben, Kyle Jayan, Michael
E N D
CPS 214Computer Networks and Distributed Systems • “Live” Video and Audio Streaming • End System Multicast • Analysis of Akamai Workload
Presentations • Monday, April 21 • Abhinav, Risi • Bi, Jie • Jason, Michael • Martin, Matt • Amre, Kareem • Wednesday, April 23 • Ben, Kyle • Jayan, Michael • Kshipra, Peng • Xuhan, Yang
The Feasibility of Supporting Large-Scale Live Streaming Applications with Dynamic Application End-Points Kay Sripanidkulchai, Aditya Ganjam, Bruce Maggs*, and Hui Zhang Carnegie Mellon University * and Akamai Technologies
Motivation • Ubiquitous Internet broadcast • Anyone can broadcast • Anyone can tune in
Overlay multicast architectures Router Source Application end-point
Infrastructure-based architecture[Akamai] + Well-provisioned Router Source Application end-point Infrastructure server
Application end-point architecture[End System Multicast (ESM)] + Instantly deployable + Enables ubiquitous broadcast Router Source Application end-point
W Waypoint architecture [ESM] + Waypoints as insurance Router Source Application end-point Waypoint W
Feasibility of supporting large-scale groups with an application end-point architecture? • Is the overlay stable enough despite dynamic participation? • Is there enough upstream bandwidth? • Are overlay structures efficient?
Large-scale groups • Challenging to address these fundamental feasibility questions • Little knowledge of what large-scale live streaming is like
Publishers with compelling content need proof that the system works. System has not attracted large-scale groups due to lack of compelling content. Chicken and egg problem
The focus of this paper • Generate new insight on the feasibility of application end-point architectures for large scale broadcast • Our methodology to break the cycle • Analysis and simulation • Leverage an extensive set of real-world workloads from Akamai (infrastructure-based architecture)
Talk outline • Akamai live streaming workload • With an application end-point architecture • Is the overlay stable enough despite dynamic participation? • Is there enough upstream bandwidth? • Are overlay structures efficient? • Summary
Measurements used in this study • Akamai live streaming traces • Trace format for a request [IP, Stream URL, Session start time, Session duration] • Additional measurements collected • Hosts’ upstream bandwidth
An Analysis of Live Streaming Workloads on the Internet Kunwadee Sripanidkulchai, Bruce Maggs*, Hui Zhang Carnegie Mellon University and *Akamai Technologies
A A A A A A Akamai live streaming infrastructure Source Reflectors Edge servers
Extensive traces • 1,000,000 daily requests • 200,000 daily client IP addresses from over 200 countries • 1,000 daily streams • 1,000 edge servers • Everyday, over a 3-month period
Largest stream 75,000 x 250 kbps = 18 Gbps!
Highlight of findings • Popularity of events [Bimodal Zipf] • Session arrivals [Exponential for short time-scales, time-of-day and time-zone-correlated behavior, LOTS of flash crowds] • Session durations [Heavy-tailed] • Transport protocol usage [TCP rivals UDP] • Client lifetime • Client diversity
Request volume (daily) Weekdays Number of requests Weekends Missing logs
Audio vs. video Video 7% Most streams are audio. Audio 71% Unknown 22%
Stream types • Non-stop (76%) vs. short duration (24%) • All video streams have short duration • Smooth arrivals (50%) vs. flash crowds (50%) • Flash crowds are common
Client lifetime • Motivating questions • Should servers maintain “persistent” state about clients (for content customization)? • Should clients maintain server history (for server selection problems)? • Want to know • Are new clients tuning in to an event? • What is the lifetime of a client?
Analysis methodology • Windows media format • Player ID field to identify distinct users • Birth rate = Number of new distinct users Total number of distinct users
Weekends Xmas Weekdays Daily new client birth rate • New client birth rate is 10-100% across all events. • For these 2 events, birth rate is 10-30%.
One-timers: tune in for only 1 day In almost all events, 50% of clients are one-timers!
Client lifetime (excluding one-timers) y = 3x y = x For most events, average client lifetime is at least 1/3 of the event duration.
Client lifetime • Motivating questions • Should servers maintain “persistent” state about clients (for content customization)? Any state should time-out quickly because most clients are one-timers. • Should clients maintain server history (for server selection problems)? Yes, recurring clients tend to hang around for a while.
Where are clients from? Number of IP Addresses Countries Clients are from over 200 countries. Most clients are from the US and Europe.
Analysis methodology • Map client IP to location using Akamai’s EdgeScape tool • Definitions • Diversity index = Number of distinct ‘locations’ that a stream reaches • Large streams are streams that have a peak group size of more than 1,000 clients
Many small streams reach more than half the world! Almost all large streams reach more than half the world. Time zone diversity
Client diversity • Motivating questions • Where should streaming servers be placed in the network? Clients are tuning in from many different locations. • How should clients be mapped to servers? For small streams which happen to have a diverse set of clients, it may be too wasteful for a CDN to map every client to the nearest server.
Summary • Publishers are using the Internet to reach a wider audience than traditional radio and TV • Interesting observations • Lots of audio traffic • Lots of flash crowds (content-driven behavior) • Lots of one-timers • Lots of diversity amongst clients, even for small streams
Nice pictures…see paper for details Percentage of requests Quicktime Real Windows media
Talk outline • Akamai live streaming workload • With an application end-point architecture • Is the overlay stable enough despite dynamic participation? • Is there enough upstream bandwidth? • Are overlay structures efficient? • Summary
Not stable More stable Departing hosts have no descendants Stable nodes at the top of the tree X When is a tree stable? Stable nodes X Less stable nodes X Interruptions Time Ancestor leaves
15% stay longer than 30 minutes (heavy-tailed) 45% stay less than 2 minutes! Extreme group dynamics
Stability evaluation: simulation • Hosts construct an overlay amongst themselves using a single-tree protocol • Skeleton protocol of the one presented in the ESM Usenix ’04 paper • Findings are applicable to many protocols • Goal: construct a stable tree • Parent selection is key • Group dynamics from Akamai traces (join/leave) • Honor upstream bandwidth constraints • Assign degree based on bandwidth estimation
Join Join IP1 IP2 ...
Probe and select parent IP2 IP1 IP2 ... IP1
Probe and select parent Parent selection algorithms • Oracle: pick a parent who will leave after me • Random • Minimum depth (select one out of 100 random) • Longest-first (select one out of 100 random)
Parent leave X Host leaves
Parent leave ? Host leaves All descendants are disconnected
Find new parent Host leaves All descendants are disconnected All descendants probe to find new parents
Mean interval between ancestor change Number of descendants of a departing host Stability metrics Interruptions X Time Ancestor leaves
Stability of largest stream Longest-first Random Min depth Oracle: there is stability!
Is longest-first giving poor predictions? Oracle, ~100% no descendants Longest-first, 91% Min depth, 82% Random, 72%
Stability of 50 large-scale streams Longest-first Percentage of sessions with interval between ancestor change < 5 minutes Random Min depth Oracle There is stability! Of the practical algorithms, min depth performs the best.