The Feasibility of Supporting Large-Scale Live Streaming Applications with Dynamic Application End-Points

Transcription

1 The Feasibility of Supporting Large-Scale Live Streaming Applications with Dynamic Application End-Points Kay Sripanidkulchai, Aditya Ganjam, Bruce Maggs, and Hui Zhang Instructor: Fabian Bustamante Presented by: Mario Sanchez

2 The focus of this paper Generate new insight on the feasibility of application end-point architectures for large scale broadcast Methodology Analysis and simulation Leverage an extensive set of real-world workloads from Akamai (infrastructure-based architecture) 1/23/09 2

3 Overlay multicast architectures Router Source Application end-point 1/23/09 3

4 Infrastructure-based architecture [Akamai] + Well-provisioned Router Source Application end-point Infrastructure server 1/23/09 4

5 Application end-point architecture [End System Multicast (ESM)] + Instantly deployable + Enables ubiquitous broadcast Router Source Application end-point 1/23/09 5

6 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? 1/23/09 6

7 Large-scale groups Challenging to address these fundamental feasibility questions Little knowledge of what large-scale live streaming is like 1/23/09 7

8 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 1/23/09 8

9 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 Hosts GNP coordinates 1/23/09 9

10 Akamai live streaming infrastructure Source A A A A A A Reflectors Edge servers 1/23/09 10

11 Request volume (daily) Weekdays Number of requests Weekends Missing logs 1/23/09 11

12 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 ~ Quicktime, Real, Windows Media Player 1/23/09 12

13 Definitions Two categories of streaming (event duration) Non-stop events Short duration events Divided into 24-hour events called STREAMS Definitions Large-scale: peak group size of over 1,000 entities Entity: unique host (IP) Incarnation: entity connection to broadcast 1/23/09 13

14 Largest Event Characteristics of the traces Stream encoding bit-rate < 80kbps = audio. Overall: 71% audio vs. 7% video vs. 22 % unknown 660 large-scale streams: 605 audio, 55 video 3 encoding streams: (a) 20 kbps, audio; (b) 100 kbps, audio and video; (c) 250 kbps, audio and video 2 hour duration; all three encodings treated as one with 250 kbps requirement 1/23/09 14

15 Largest stream 75,000 x 250 kbps = 18 Gbps! 5pm 6pm 7pm 8pm 9pm 10pm 11pm 12am 1/23/09 15

16 Talk outline Akamai live streaming workload With an application end-point architecture Is there enough upstream bandwidth? Is the overlay stable enough despite dynamic participation? Are overlay structures efficient? Summary 1/23/09 16

17 Is there enough upstream bandwidth to support all hosts? Video 300 kbps DSL Upstream bandwidth only 128 kbps DSL Saturated tree DSL What if application end-points are all DSL? 1/23/09 17

18 Bandwidth Estimation Bandwidth Collection: Direct measurements alone, out of question Bandwidth Collection: Data Mining 72% of hosts: bandwidth reported by broadbandreports.com Active Measurements 7.6%: IP /24 block measurement / packet pair to estimate technology (table bellow) 1/23/09 18

19 Bandwidth Estimation Inference: 7.1%: EdgeScape IP to technology 2.2%: DNS name to technology 1.2%: Manually known domains with not-common- DNS-names to technology 90% of IP addresses with estimates 10% unknown 1/23/09 19

20 Outbound BW unit: degree vs. kbps Resources: amount of outgoing bandwidth that hosts in the system can contribute. Normalized bandwidth value by encoding bit rate: 300 kbps bandwidth, 250 kbps encoding = 300/250 = 1 degree Largest Event: 1/23/09 20

21 Metric: Resource index Ratio of the supply to the demand of upstream bandwidth; Resource index == 1 means the system is saturated Resource index == 2 means the system can support two times the current members in the system Resource Index: (3+5)/3 = 2.7 1/23/09 21

22 Metric: Resource index 10% unknown: Optimistic, Pessimistic (free-rider), Distribution Degree is dependent on the encoding bit rate, so is the Resource Index 1/23/09 22

23 Single-Tree Protocol 81 streams 1/23/09 23

24 Resource index Multiple Trees Multiple Description Coding: Video stream is encoded into k independent sub-streams and distributed across k independent trees. Fractional supply: 250 kbps encoding split into 50 kbps sub-streams = 300/250 = 1.2 degree MDC: - Increases amount of resources, - Increases the feasibility of overlay multicast 1/23/09 24

25 Multiple-Trees Protocol 1/23/09 25

26 Large-scale video streams A few streams are in trouble or close. 1/3 of the streams are in trouble. Most streams have sufficient upstream bandwidth. 1/23/09 26

27 Talk outline Akamai live streaming workload With an application end-point architecture Is there enough upstream bandwidth? Is the overlay stable enough despite dynamic participation? Are overlay structures efficient? Summary 1/23/09 27

28 When is a tree stable? Not stable X Interruptions Time Ancestor leaves More stable Stable nodes X Less stable X nodes Departing hosts have no descendants Stable nodes at the top of the tree 1/23/09 28

29 Extreme group dynamics 45% stay less than 2 minutes! 15% stay longer than 30 minutes (heavy-tailed) 1/23/09 29

30 Stability evaluation: simulation Hosts construct an overlay amongst themselves using a single-tree protocol 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 1/23/09 30

31 Overlay Protocol Simulation: Join IP1 IP2... Join 1/23/09 31

32 Probe and select parent IP 1 IP 2 IP 1 IP /23/09 32

33 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) 1/23/09 33

34 Parent leave X Host leaves 1/23/09 34

35 Parent leave Host leaves All descendants are disconnected? 1/23/09 35

36 Find new parent Host leaves All descendants are disconnected All descendants probe to find new parents 1/23/09 36

37 Stability metrics Mean interval between ancestor change Interruptions Number of descendants of a departing host X Time Ancestor leaves 1/23/09 37

38 Stability of largest stream Longest-first Random Min depth Oracle: there is stability! 1/23/09 38

39 Is longest-first giving poor predictions? Oracle, ~100% no descendants Longest-first, 91% Min depth, 82% Random, 72% 1/23/09 39

40 Percentage of sessions with interval between ancestor change < 5 minutes Stability of 50 large-scale streams Random Longest-first Oracle There is stability! Of the practical algorithms, min depth performs the best. 1/23/09 40 Min depth

41 There is inherent stability Given future knowledge, stable trees can be constructed In many scenarios, practical algorithms can construct stable trees Minimum depth is robust Predicting stability (longest-first) is not always robust; when wrong, the penalty is severe Mechanisms to cope with interrupts are useful Multiple trees 1/23/09 41

42 Stability Multiple Trees Poor stability = being disconnected from at least 25% of the trees 1/23/09 42

43 There is inherent stability Multiple trees can increase the perceived quality of the streams but improved performance comes at a cost of more frequent disconnects, more protocol overhead and more complex protocol. 1/23/09 43

44 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 1/23/09 44

45 Efficient Overlay Efficient overlay: one in which the overlay structure closely reflects the underlying IP network. The Challenge: to enable hosts to discover other nearby hosts that may be used as parents. Large number of hosts: prohibitive to know everyone else. Solution: partition end-points into clusters. 1/23/09 45

46 Cluster Membership Membership server: One member of each cluster is designated as the cluster head. Hosts in the same cluster maintain knowledge about one another. 1/23/09 46

47 Cluster Membership Handling host join: obtain list of member servers from rendezvous point Creating Membership servers: rendezvous point create servers on-demand as needed Recovering from membership server dynamics: before leaving a membership server looks to promote host inside cluster State maintenance: servers exchange state with the rendezvous point; among themselves and random set of hosts inside cluster. 1/23/09 47

48 Cluster policies Naïve clustering, 3 policies: Random, delaybased clustering, geographic clustering. Two critical requirements: Cluster size (redirection, new cluster creation) Resources within cluster (redirect free-riders) Cluster Quality Proximity Data, GNP: network delay, geographic distance 1/23/09 48

49 Relative Delay Penalty (RDP) How well does the overlay structure match the underlying network topology? RDP = Overlay distance Direct unicast distance US US 50ms 20ms US 50ms Europe US 50ms Europe Results are more promising than previous studies using synthetic workloads and topologies. 1/23/09 49

50 Summary Indications of the feasibility of application end-point architectures The overlay can be stable despite dynamic participation There often is enough upstream bandwidth Overlay structures can be efficient These findings can be generalized to other protocols Thank you! 1/23/09 50