INF 5071 Performance in Distributed Systems. October 15, 2010

Transcription

1 INF 5071 Performance in Distributed Systems October 15, 2010

2 Distribution Why does distribution matter? Digital replacement of earlier methods What can be distributed?

3 Distribution Network Approaches Cable network Server ATM Server Node Distribution ADSL ATM EPON End Systems Wireless Wide-area network backbones FDM/WDM 10GB Ethernet ATM SONET Local Distribution network Wired HFC (Hybrid Fiber Coax - cable) ADSL (Asymmetric Digital Subscriber Line) EPON (Ethernet Based Passive Optical Networks) Wireless IEEE WiMax

4 Delivery Systems Developments Network

5 Delivery Systems Developments Several Programs or Timelines Network Saving network resources: Stream scheduling

6 From Broadcast to True Media-on-Demand Broadcast (No-VoD) Traditional, no control Pay-per-view (PPV) Paid specialized service Quasi Video On Demand (Q-VoD) Distinction into interest groups Temporal control by group change Near Video On Demand (N-VoD) Same media distributed in regular time intervals Simulated forward / backward True Video On Demand (T-VoD) Full control for the presentation, VCR capabilities Bi-directional connection [Little, Venkatesh 1994]

7 Optimized delivery scheduling Background/Assumption: Performing all delivery steps for each user wastes resources Scheme to reduce (network & server) load needed Terms Stream: a distinct multicast stream at the server Channel: allocated server resources for one stream Segment: non-overlapping pieces of a video Combine several user requests to one stream Mechanisms Type I: Delayed on-demand delivery Type II: Prescheduled delivery Type III: Client-side caching

8 Type I: Delayed On Demand Delivery

9 Optimized delivery scheduling Delayed On Demand Delivery Collecting requests Joining requests Batching Delayed response Collect requests for same title Batching Features Simple decision process Can consider popularity Drawbacks Obvious service delays Limited savings [Dan, Sitaram, Shahabuddin 1994] Central server multicast 1st client 2nd client 3rd client

10 Optimized delivery scheduling Delayed On Demand Delivery Collecting requests Joining requests Batching Delayed response Content Insertion E.g. advertisement loop Piggybacking Catch-up streams Display speed variations Typical Penalty on the user experience Single point of failure Central server multicast 1st client 2nd client 3rd client

11 Graphics Explained position in movie (offset) stream leaving faster than playback speed leaving slower than playback speed time Y - the current position in the movie the temporal position of data within the movie that is leaving the server X - the current actual time

12 Piggybacking [Golubchik, Lui, Muntz 1995] Save resources by joining streams Server resources Network resources Approach Exploit limited user perception Change playout speed Up to +/- 5% are considered acceptable Only minimum and maximum speed make sense i.e. playout speeds 0 +10%

13 Piggybacking position in movie (offset) slow fast time Request arrival

14 Piggybacking position in movie (offset) time

15 Adaptive Piggybacking position in movie (offset) time [Aggarwal, Wolf, Yu 1996]

16 Performance 90 [Drawing after Aggarwal, Wolf and Yu (1996)] 80 Original piggybacking Percentage of savings in BW Greedy odd-even merging Optimize for every arrival, snapshot Interarrival Time in seconds

17 Type II: Prescheduled Delivery

18 Optimized delivery scheduling Prescheduled Delivery No back-channel Non-linear transmission Client buffering and re-ordering Video segmentation Examples Staggered broadcasting, Pyramid b., Skyscraper b., Fast b., Pagoda b., Harmonic b., Typical Good theoretic performance High resource requirements Single point of failure

19 Optimized delivery scheduling Movie 1 begin broadcasting end Cut into segments Central server st client nd client Reserve channels for segments Determine a transmission schedule rd client 4 4 4

20 Prescheduled Delivery position in movie client buffer client buffer restart times time Arrivals are not relevant users can start viewing at each interval start

21 Staggered Broadcasting position in movie (offset) Jump forward Continue [Almeroth, Ammar 1996] Pause Phase offset Near Video-on-Demand Applied in real systems Limited interactivity is possible (jump, pause) Popularity can be considered change phase offset time

22 Pyramid Broadcasting [Viswanathan, Imielinski 1996] Idea Fixed number of HIGH-bitrate channels C i with bitrate B Variable size segments a 1 a n One segment repeated per channel Segment length is growing exponentially Several movies per channel, total of m movies (constant bitrate 1) Operation Client waits for the next segment a 1 (on average ½ len (d 1) ) Receives following segments as soon as linearly possible Segment length Size of segment a i : i 1 len( ai ) = α len( a1) α is limited α>1 to build a pyramid α B/m for sequential viewing α=2.5 considered good value Drawback Client buffers more than 50% of the video Client receives all channels concurrently in the worst case

23 Pyramid Broadcasting Pyramid broadcasting with B=4, m=2, α=2 Movie a 2 3 len( a4) = α len( a3) = α len( a2) = α len( a1) time a1 a2 a3 a4 time to play a1 back at normal speed

24 Pyramid Broadcasting Pyramid broadcasting with B=4, m=2, α=2 Movie a 2 3 len( a4) = α len( a3) = α len( a2) = α len( a1) time a1 a2 a3 a4 Channels bandwidth for B normal speeds a1 Channel 1 Channel 2 Time to send a segment: len(a n )/B" a2 Sending several channels in parallel Channel 3 Channel 4 a3 a4

25 Pyramid Broadcasting Pyramid broadcasting with B=4, m=2, α=2 Movie a 2 3 len( a4) = α len( a3) = α len( a2) = α len( a1) time a1 a2 a3 a4 Channel 1 Channel 2 a1 a2 b1 b2 Segments of m different movies per channel: a & b Channel 3 a3 b3 Channel 4 a4 b4

26 Pyramid Broadcasting Pyramid broadcasting with B=4, m=2, α=2 a1 b1 Channel 1 Channel 2 a2 b2 a2 b2 a2 b2 a2 b2 a2 b2 a2 b2 a2 b2 a2 b2 a2 b2 a2 b2 Channel 3 a3 b3 a3 b3 a3 b3 a3 b3 a3 b3 Channel 4 a4 b4 a4 b4 a4 request for a arrives client starts receiving and playing a1 client starts receiving and playing a2 client starts receiving a3 client starts playing a3 client starts receiving a4 client starts playing a4

27 Pyramid Broadcasting Pyramid broadcasting with B=4, m=2, α=2 a1 b1 Channel 1 Channel 2 a2 b2 a2 b2 a2 b2 a2 b2 a2 b2 a2 b2 a2 b2 a2 b2 a2 b2 a2 b2 Channel 3 a3 b3 a3 b3 a3 b3 a3 b3 a3 b3 Channel 4 a4 b4 a4 b4 a4

28 Pyramid Broadcasting Pyramid broadcasting with B=5, m=2, α=2.5 a1 b1 Channel 1 Channel 2 Channel 3 a2 b2 a2 b2 a2 b2 a2 b2 a2 b2 a2 b2 a2 b2 a2 b2 a3 b3 a3 b3 a3 b3 Channel 4 a4 b4 In the Internet: choose m=1" Less bandwidth at the client and in multicast trees At the cost of multicast addresses

29 Skyscraper Broadcasting [Hua, Sheu 1997] Idea Fixed size segments More than one segment per channel Channel bandwidth is playback speed Segments in a channel keep order Channel allocation series 1,2,2,5,5,12,12,25,25,52,52,... Client receives at most 2 channels Client buffers at most 2 segments Operation Client waits for the next segment a1 " Receive following segments as soon as linearly possible

30 Skyscraper Broadcasting time a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 Channel 1 Channel 2 Channel 3 Channel 4 a1 a1 a1 a1 a1 a1 a1 a1 a2 a3 a2 a3 a2 a3 a2 a3 a4 a5 a4 a5 a4 a5 a4 a5 a6 a7 a8 a9 a10 a6 a7 a8 time request for a arrives a1 a2 a3 a4 a5 a6 a7 a8

31 Skyscraper Broadcasting time a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 Channel 1 Channel 2 Channel 3 Channel 4 a1 a1 a1 a1 a1 a1 a1 a1 a2 a3 a2 a3 a2 a3 a2 a3 a4 a5 a4 a5 a4 a5 a4 a5 a6 a7 a8 a9 a10 a6 a7 a8 time request for a arrives a1 a2 a3 a4 a5 a6 a7 a8

32 Other Pyramid Techniques Fast Broadcasting Many more, smaller segments Similar to previous Sequences of fixed-sized segments instead of different sized segments [Juhn, Tseng 1998] Channel allocation series Exponential series: 1,2,4,8,16,32,64,... Segments in a channel keep order Shorter client waiting time for first segment Channel bandwidth is playback speed Client must receive all channels Client must buffer 50% of all data

33 Fast Broadcasting time a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 Channel 1 Channel 2 Channel 3 Channel 4 time a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a2 a3 a2 a3 a2 a3 a2 a3 a2 a3 a2 a3 a2 a3 a2 a3 a4 a5 a6 a7 a4 a5 a6 a7 a4 a5 a6 a7 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a8 a9 a10 a11 a12 a13 a14 a15 request for a arrives a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15

34 Fast Broadcasting time a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 Channel 1 Channel 2 Channel 3 Channel 4 time a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a2 a3 a2 a3 a2 a3 a2 a3 a2 a3 a2 a3 a2 a3 a2 a3 a4 a5 a6 a7 a4 a5 a6 a7 a4 a5 a6 a7 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a8 a9 a10 a11 a12 a13 a14 a15 request for a arrives a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15

35 Pagoda Broadcasting Pagoda Broadcasting Channel allocation series 1,3,5,15,25,75,125 Segments are not broadcast linearly Consecutive segments appear on pairs of channels Client must receive up to 7 channels For more channels, a different series is needed! Client must buffer 45% of all data Based on the following Segment 1 needed every round Segment 2 needed at least every 2 nd round Segment 3 needed at least every 3 rd round Segment 4 needed at least every 4 th round [Paris, Carter, Long 1999]

36 Pagoda Broadcasting a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 time a16 a17 a18 a19 C 1 C 2 C 3 C 4 time a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a2 a4 a2 a5 a2 a4 a2 a5 a2 a4 a2 a5 a2 a4 a2 a5 a3 a6 a12 a3 a7 a13 a3 a6 a14 a3 a7 a15 a3 a6 a12 a3 a8 a9 a10 a11 a16 a17 a18 a19 a8 a9 a10 a11 a16 a17 a18 a19 request for a arrives a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19

37 Pagoda Broadcasting time a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19 C 1 C 2 C 3 C 4 time a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a2 a4 a2 a5 a2 a4 a2 a5 a2 a4 a2 a5 a2 a4 a2 a5 a3 a6 a12 a3 a7 a13 a3 a6 a14 a3 a7 a15 a3 a6 a12 a3 a8 a9 a10 a11 a16 a17 a18 a19 a8 a9 a10 a11 a16 a17 a18 a19 request for a arrives a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18

38 Harmonic Broadcasting Idea Fixed size segments One segment repeated per channel Later segments can be sent at lower bitrates Receive all other segments concurrently Harmonic series determines bitrates Bitrate(a i ) = Playout-rate(a i )/i" Bitrates 1/1, 1/2, 1/3, 1/4, 1/5, 1/6, " [Juhn, Tseng 1997] Consideration Size of a 1 determines client start-up delay Growing number of segments allows smaller a 1" Required server bitrate grows very slowly with number of segments Drawback Client buffers about 37% of the video for >=20 channels (Client must re-order small video portions) Complex memory cache for disk access necessary

39 Harmonic Broadcasting time a1 a2 a3 a4 a5 C 1 C 2 C 3 C 4 C 5 a1 a1 a1 a1 a1 a1 a1 a1 a2 a2 a2 a2 a3 a4 a5 a3 a4 request for a arrives a1 a2 a3 a4 a5

40 Harmonic Broadcasting time a1 a2 a3 a4 a5 C 1 C 2 C 3 C 4 C 5 a1 a1 a1 a1 a1 a1 a1 a1 a2 a2 a2 a2 a3 a4 ERROR a5 a3 a4 request for a arrives a1 a2 a3 a4 a5

41 Harmonic Broadcasting time a1 a2 a3 a4 a5 C 1 C 2 C 3 C 4 C 5 a1 a1 a1 a1 a1 a1 a1 a1 a2 a2 a2 a2 a3 a4 request for a arrives a5 a3 a4 Read a1 and consume concurrently Read rest of a2 and consume concurrently a1 a2 a3 a4 a5 Consumes 1 st segment faster than it is received!!!

42 Harmonic Broadcasting: Bugfix Delayed Harmonic Broadcasting Wait until a 1 is fully buffered All segments will be completely cached before playout Fixes the bug in Harmonic Broadcasting [By Paris, Long, ] or Cautious Harmonic Broadcasting Wait an additional a 1 time Starts the harmonic series with a 2 instead of a 1 Fixes the bug in Harmonic Broadcasting

43 Prescheduled Delivery Evaluation Techniques Video segmentation Varying transmission speeds Re-ordering of data Client buffering Advantage Achieves server resource reduction Problems Tends to require complex client processing May require large client buffers Is incapable (or not proven) of working with user interactivity Current research to work with VCR controls Guaranteed bandwidth required

44 Type III: Client Side Caching

45 Optimized delivery scheduling Client Side Caching On-demand delivery Client buffering Multicast complete movie Unicast start of movie for latecomers (patch) Examples Stream Tapping, Patching, Hierarchical Streaming Merging, Typical Considerable client resources Single point of failure

46 Optimized delivery scheduling Patching [Hua, Cai, Sheu 1998, also as Stream Tapping Carter, Long 1997] Central server Join! Unicast patch stream 1st client multicast cyclic buffer 2nd client Server resource optimization is possible

47 Optimized delivery scheduling position in movie (offset) full stream patch stream request arrival time (patch) window size restart time of full stream

48 Optimized delivery scheduling position in movie (offset) full stream interdeparture time interarrival time time

49 Optimized delivery scheduling position in movie (offset) Number of concurrent streams Concurrent full streams Concurrent patch streams time Total number of concurrent streams The average number of patch streams is constant if the arrival process is a Poisson process

50 Optimized delivery scheduling position in movie (offset) Number of concurrent streams Compare the numbers of streams time Shown patch streams are just examples But always: patch end times on the edge of a triangle

51 Optimized delivery scheduling position in movie (offset) Number of concurrent streams time

54 Optimized delivery scheduling Minimization of server load Minimum average number of concurrent streams Depends on F movie length Δ U expected interarrival time Δ Μ patching window size C U cost of unicast stream at server C M cost of multicast stream at server S U setup cost of unicast stream at server S M setup cost of multicast stream at server

55 Optimized delivery scheduling Optimal patching window size For identical multicast and unicast setup costs For different multicast and unicast setup costs + C C Δ = 2 F Δ M M M U ΔM = 2 ΔU S U F Servers can estimate Δ U Movie length And achieve massive saving Patching window size Unicast 7445 Mio $ Interarrival Greedy time 3722 Mio $ patching λ-patching 375 Mio $ Based on prices by Deutsche Telekom, IBM and Real Networks from 1997

56 Pull-Patching playout time Combination adaptive segmented HTTP streaming patching quality Pull-Patching

57 Pull-Patching Experiment client joins 100 segments into the stream 4 video layers Results if enough resources (8 Mbps) 8 Mbps bandwidth

58 Pull-Patching Experiment client joins 100 segments into the stream 4 video layers Results if enough resources bandwidth limitations 2 Mbps bandwidth 4 Mbps bandwidth 8 Mbps bandwidth

59 Pull-Patching Experiment client joins 100 segments into the stream 4 video layers Results if enough resources bandwidth limitations loss ( delay and jitter) Pull-Patching works client side decisions overcomes traditional patching limitations dynamic adaption loss and delay handling patch server scalability 8 Mbps bandwidth, 3 % loss 8 Mbps bandwidth, 1 % loss 8 Mbps bandwidth

60 HMSM [Eager, Vernon, Zahorjan 2001] Hierarchical Multicast Stream Merging Key ideas Each data transmission uses multicast Clients accumulate data faster than their playout rate multiple streams accelerated streams Clients are merged in large multicast groups Merged clients continue to listen to the same stream to the end Combines Dynamic skyscraper Piggybacking Patching

61 HMSM Always join the closest neighbour HMSM(n,1) Clients can receive up to n streams in parallel HMSM(n,e) Clients can receive up to n full-bandwidth streams in parallel but streams are delivered at speeds of e, where e «1 Basically HMSM(n,1) is another recursive application of patching

62 HMSM(2,1) HMSM(2,1): max 2 streams, 1 playout speed each position in movie (offset) playout determine patch size time request arrival

63 HMSM(2,1) HMSM(2,1): max 2 streams, 1 playout speed each position in movie (offset) determine patch size closest neighbor first time request arrival

64 HMSM(2,1) HMSM(2,1): max 2 streams, 1 playout speed each position in movie (offset) patch extension patch extension closest neighbor first time request arrival

65 Client Side Caching Evaluation Techniques Video segmentation Parallel reception of streams Client buffering Advantage Achieves server resource reduction Achieves True VoD behaviour Problems Optimum can not be achieved on average case Needs combination with prescheduled technique for high-popularity titles May require large client buffers Are incapable (or not proven) to work with user interactivity Guaranteed bandwidth required

66 Overall Evaluation Advantage Achieves server resource reduction Problems May require large client buffers Incapable (or not proven) to work with user interactivity Guaranteed bandwidth required Fixes Introduce loss-resistant codecs and partial retransmission Introduce proxies to handle buffering Choose computationally simple variations

67 Zipf-distribution The typical way or modeling access probability

68 Zipf distribution and features Popularity Estimate the popularity of movies (or any kind of product) Frequently used: Zipf distribution /1 /x ility b a b r o p e tiv la r e probability z(i) = C i ς N 1 C =1/ n ς n=1 100,000 req 1,000,000 req Zipf Objects movie sorted rank (out by of 500) popularity Danger 0.1 /% c e n r e ife d e tiv la r e Zipf-distribution of a process can only be applied 100,000 req while popularity 1,000,000 req doesn t change is only an observed property a subset of a Zipfdistributed dataset is no longer Zipf-distributed movie rank (out of 500)

69 Optimized delivery scheduling Optimum depends on popularity Estimate the popularity of movies Frequently used: Zipf distribution z( i) = C i, C = 1/ N l= 1 1 l 0.16 /1 /x ility b a b r o p e tiv la r e movie rank (out of 500)

70 Optimized delivery scheduling Problem Being Zipf-distributed is only an observed property /1 y /x ilit b a b ro p e tiv la re probability ,000 req 1,000,000 req Zipf movie rank (out of 500) 0.1 /% c e n re ife d e tiv la re frequency 100,000 req 1,000,000 req movie rank (out of 500)

71 Optimized delivery scheduling Density function of the Zipf distribution Compared to real-world data ility a b b ro p l r e n ta probability curves for 250 movie titles /3/ z(i) /6/ movie index

72 Optimized delivery scheduling Conclusion Major optimizations possible Independent optimizations don t work Centralized systems problems Scalability is limited Minimum latency through distance Single point of failure Look at distributed systems Clusters Distribution Architectures

73 Some References 1. Thomas D.C. Little and Dinesh Venkatesh: "Prospects for Interactive Video-on-Demand", IEEE Multimedia 1(3), 1994, pp " 2. Asit Dan and Dinkar Sitaram and Perwez Shahabuddin: "Scheduling Policies for an On-Demand Video Server with Batching", IBM TR RC 19381, 1993" 3. Rajesh Krishnan and Dinesh Venkatesh and Thomas D. C. Little: "A Failure and Overload Tolerance Mechanism for Continuous Media Servers", ACM Multimedia Conference, November 1997, pp " 4. Leana Golubchik and John C. S. Lui and Richard R. Muntz: "Adaptive Piggybacking: A Novel Technique for Data Sharing in Video-on-Demand Storage Servers", Multimedia Systems Journal 4(3), 1996, pp " 5. Charu Aggarwal, Joel Wolf and Philipp S. Yu: On Optimal Piggyback Merging Policies for Video-on- Demand Systems, ACM SIGMETRICS Conference, Philadelphia, USA, 1996, pp " 6. Kevin Almeroth and Mustafa Ammar: "On the Use of Multicast Delivery to Provide a Scalable and Interactive Video-on-Demand Service", IEEE JSAC 14(6), 1996, pp " 7. S. Viswanathan and T. Imielinski: "Metropolitan Area Video-on-Demand Service using Pyramid Broadcasting", Multimedia Systems Journal 4(4), 1996, pp " 8. Kien A. Hua and Simon Sheu: "Skyscraper Broadcasting: A New Broadcasting Scheme for" 9. Metropolitan Video-on-Demand Systems", ACM SIGCOMM Conference, Cannes, France, 1997, pp " 10. L. Juhn and L. Tsend: "Harmonic Broadcasting for Video-on-Demand Service", IEEE Transactions on Broadcasting 43(3), 1997, pp " 11. Carsten Griwodz and Michael Liepert and Michael Zink and Ralf Steinmetz: "Tune to Lambda Patching", ACM Performance Evaluation Review 27(4), 2000, pp " 12. Kien A. Hua and Yin Cai and Simon Sheu: "Patching: A Multicast Technique for True Video-on Demand Services", ACM Multimedia Conference, Bristol, UK, 1998, pp " 13. Derek Eager and Mary Vernon and John Zahorjan: "Minimizing Bandwidth Requirements for On-Demand Data Delivery", Multimedia Information Systems Conference 1999" 14. Jehan-Francois Paris: