1 / 22

Heterogeneity in Data-Driven Live Streaming: Blessing or Curse?

Heterogeneity in Data-Driven Live Streaming: Blessing or Curse?. Fabien Mathieu Hot-P2P, 04/23/2010. Roadmap. Problem statement Model Motivation Optimal broadcasting of a single chunk Many -to-one One-to-one One-to-c Towards fast broadcasting of a stream of chunks Curses

rowdy
Download Presentation

Heterogeneity in Data-Driven Live Streaming: Blessing or Curse?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Heterogeneity in Data-DrivenLive Streaming:Blessing or Curse? Fabien Mathieu Hot-P2P, 04/23/2010

  2. Roadmap • Problemstatement • Model • Motivation • Optimal broadcasting of a single chunk • Many-to-one • One-to-one • One-to-c • Towardsfastbroadcasting of a stream of chunks • Curses • Blessings

  3. The Live Streaming Problem • A live stream (streamrates) to watch… • Injected by a server of capacity • Watched by a set of N peers… • Goal #1: make it work! • Goal #2: make it fast!

  4. Chunk-based (aka data-driven) diffusion • Chunk-based: the streamis split intochunks of equal size; • Integrity-rule: onlyforwardfullyreceivedchunks; • Upload-constrained: delaycomesfromuploadbandwidth • u1¸…¸uN; • Bandwidth are expressed in chunks per second • No overlay constraints !Oversimplified model to focus on heterogeneity

  5. Optimal delay in the homogeneous case • Homogeneity allows to work in slotted time • The best way to broadcast one chunk takes • Extends to a stream of chunks by permutation of the single chunk tree

  6. Optimal delay in the heterogeneous case • Nice formula for the optimal single chunk transmission: failed • Direct link single chunk / stream of chunks: failed • Intuition: shouldbefaster (centralizationis the extreme case) • In practice: (Bonald et al., Sigmetrics, 2208) • Summary: heterogeneityis a b….

  7. Model extension: forwarding policies Authorize collaborations, or force parallelism: • Many-to-one: any set of peerswith a chunkcanforwardthatchunk in time 1/iui. • Not realisticat all, but soeasier to compute; • Will help understand the othermodels. • One-to-one (mono-source): a peeriwith a chunkcanforwardit in time 1/ui. • the genuine model; • slowerthanmany-to-one, but more realistic. • One-to-c (parallelism): a peerineedsat least c/ui to forward a chunk, up to c peerssimultaneously. • Extend the classical model; • parallelismcanavoidbandwidthwaste, but itslower.

  8. Delays under the model

  9. Example • 3 peers, s=1, n0=u1=1, u2=u3=1/2 • Exactly the bandwidthrequiredaccording to Bandwidth Conservation Law (BCL) • Equivalent homogeneous system: n0=1, u=2/3 • Streaming is the issue

  10. Single CHUNK

  11. Results for the single chunk transmission • Dm is given by a simple greedy algorithm: • Gives • Absolute, tight, lower bound for chunk transmission. • Homogeneous case:

  12. Results for the single chunk transmission • D1 is also given by a simple greedy algorithm. • No simple, closed formula. • Theorem: • Conjecture (sigh!): • Price of atomicity is • Extension to parallelism: • Price of parallelism is

  13. STREAM OF CHUNKS

  14. Streaming case: feasibility

  15. Bad case scenario • In the one-to-one model, poorpeermay affect the delay if you have to use thematsome time • This canhappeneven in overprovisionnedscenarios

  16. Good case 1: emulating homogeneity • Assume wecanfindu suchthat • (BCL of the emulated system) • (emulation condition) • Thenwe have • Poorpeers (ui<u) are neverused • Sufficient condition for u to exist: factor 2 BW provisioning for quantification

  17. Good case 2: avoiding competition

  18. Good case 2: avoiding competition • Idea: protect the early diffusion to emulate the Dr· 1 case. • Recipe: • Split the peers into E equal subsets, (E¼ Dr) • All subsets should have roughly the original BW distribution. • Round-robin the chunk injection among the subsets. • Primary goal: intra-diffusion of the chunk. • Secondary goal (when idle): broadcast to other subsets

  19. Good case 2: avoiding competition • Proper validation of the ideastill on-going • Quantification effectscanmakesome BW useless • The subset must be as similar as possible(one monsterpeer in a single subsetis hard to handle) • Lead to condition u¸ r(1+1/E)+cst, with E¼ log(N/n_0). • CorrespondingdelayalmostlikeD • For someslightlyoverprovisionnedsystems, the streamdelayisalmostlike the chunkdelay

  20. Chunk-based model and delay: summary • For homogeneoussystems, single delay=streamdelay • Collaboration for one chunktransferis not thatuseful • Parallelismis not thatscary • Heterogeneityspeeds up single delay • Somebandwidthoverprovisioningseems to berequired in the general case

  21. And then? Limits of the chunk-based model • ChunkscomesfromBitTorrent’s world • Integritypurpose • Great for unstructuredapproaches • Bigchunkreduceoverhead • Good for theory • Quantification • Delay expressed as bandwidth • But when streaming isconcerned… • Need to go down to latencytimescales • Limits of the model validity • A possible lead for future work • Do wereallyneedstrongintegritymechanisms? • Try to learnfrom the stripe world

  22. Thankyouverymany! No interactive questions, but youcan • Have a look at the paper • Email me (fabien.mathieu@orange-ftgroup.com) 22/22

More Related