M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for - PowerPoint PPT Presentation

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming R. Bernardini ∗ and R. Rinaldo ∗ and A. Vitali † ∗ DIEGM – University of Udine, Udine, Italy † ST microelectronics, Agate Brianza, Italy

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Outline • Introduction – Why P2P live streaming? – Problems • Our proposal • Conclusions 1

Introduction

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Our objective A peer-to-peer architecture for video live streaming 2

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Applicative context Live Event Sub−source #1 Root Source User 2 H Contact user group #1 i n e w u s e r , w e l c o m e Dispatcher t 3 o g r Hi, some music, please o u p # 1 1 Sub−source #2 Sub−source #4 Sub−source #3 User New User User group #2 User group #4 group #3 3

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Why peer-to-peer? Bandwidth With the centralized approach the bandwidth required to each server grows linearly with the number of users With the P2P approach, each new user is also a new server ⇒ enhanced scalability # Users 4

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Obstacles to P2P live streaming 5

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Obstacles to P2P live streaming (2) Evanescence Server • Peers can leave at any time • Nodes can remain isolated Peer Peer Peer ⇒ quality drop Bye... • Solution: Peer Peer Peer Peer Peer – Network structure ? ? – Cross-packet FEC Peer Peer Peer 6

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Obstacles to P2P live streaming (3) Asymmetric bandwidth Home users have enough download bandwidth to Download receive streaming data, . . . but . . . they have not enough upload bandwidth to act as streaming servers Upload Clipart courtesy FCIT http://etc.usf.edu/clipart 7

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Obstacles to P2P live streaming (4) Asymmetric bandwidth: the chunky solution File Chunk 1 Chunk 2 Chunk 3 Chunk 4 Typical P2P approach: the file is partitioned into chunks, different Peer 1 Peer 3 peers send me different chunks. Me Peer 2 Peer 4 8

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Obstacles to P2P live streaming (5) Drawbacks of chunky • The chunky solution works fine for “normal” files, but. . . . . . it is not much useful with live streaming because – Future chunks do not exist yet – Past chunks are useless • Possibile solution: buffering ⇒ long start-up times 9

Proposed solution Description

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming The problem • We want to break the original stream into smaller pieces (called crumbs ) such that – The bandwidth required by a crumb is N times smaller than the band- width required by the original stream – It is possible to recover the original stream from any combination of N different crumbs Crumb New crumb Recovered packet Me 10

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming The solution ( . . . and secret sharing let it be. . . ) • Work at packet level • A packet can be though as vector c = [ c 1 , c 2 ,..., c K ] t , c i ∈ GF ( 2 n ) • Vector c is organized as an N -row matrix and left r : reduction vector multiplied by vector r ( b ) : = [ 1 , b ,..., b N − 1 ] N : reduction factor u : reduced vector   ··· c 1 c N + 1 ··· c 2 c N + 2   u : = r ( b ) C = r ( b )   . . . . . .   ··· c N c 2 N • b and u are sent to other peers 11

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Reconstruction HOWTO • Original packet can be reconstructed as soon as N crumbs are received. • Reconstruction is carried out by solving linear system      = r 1 C − 1 u 1  r 1 u 1     = r 2 C u 2 r 2 u 2     C = − →  .   .  . = . . . . . . . . . . . .        r N u N  = r N C  u N � �� � � �� � R − 1 U 12

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Reconstruction HOWTO (2) • The matrix of reduction vectors     b N − 1 b 2 ··· 1 b 1 r 1 1 1  b N − 1  b 2 r 2 1 b 2 ···     R =  = 2 2   . . . . . .   . . . . . . . . .    b N − 1 b 2 r N ··· 1 b N N N is a Wandermonde matrix ⇒ Invertibility is granted as soon as b i � = b j for every i � = j 13

Proposed solution Remarks

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Characteristics of proposed solution Independent on the P2P structure Independent on the multimedia format. It can be used with – Scalable streams – Multiple description – Encrypted format 14

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Choosing the reduction vector • The reduction vector is chosen as r ( b ) = [ 1 , b , b 2 , ..., b N − 1 ] where b is a random non-null element of GF ( 2 n ) . • Random choice ⇒ simpler structure ⇒ R maybe non full-rank 15

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Choosing the reduction vector (2) Probability of non-full-rank R 0 10 F 2 8 F 2 16 −2 F 2 32 10 −4 10 Prob. −6 10 −8 10 −10 10 0 10 20 30 40 50 N Birthday problem 16

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Failure probability • To combact evenescence we can contact M > N peers. • The number P of currently available peers can be modeled as a queue with M servers and capacity M • We experience “ failure ” (we are unable to reconstruct the signal) if P < N State Number of connected peers T conn /T find ρ= 1/T find New peer found 0 1 2 n n+1 N−1 N N+1 M Peer leaves (n+1)/T conn BAD GOOD 17

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Failure probability (2) α =M/N=1.10 ρ =400.0 0 0 10 10 −2 −2 10 10 −4 −4 10 10 P F P F −6 −6 10 10 ρ =50 α =1.1 ρ =100 α =1.2 −8 −8 10 10 ρ =200 α =1.3 ρ =400 α =1.5 ρ =800 α =2.0 −10 −10 10 10 0 0.2 0.4 0.6 0.8 1 1.2 1.4 0.6 0.7 0.8 0.9 1 1.1 1.2 M/ ρ M/ ρ 18

Extensions

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Unequal reduction Glossary • The multimedia content (e.g., a soccer Analog Analog Analog Analog match) is a colletion one or more streams Base ... Binary Binary Binary Binary Layer (e.g., audio/video, different SVC layers, dif- Analog Analog Analog Analog ferent descriptions, . . . ) Packet Packet Packet Packet • Each stream is a sequence of multimedia Stream packets (e.g., data relative to a slice). Analog Analog Analog Analog Detail ... Binary Binary Binary Binary Layer • Each multimedia packet can further di- Analog Analog Analog Analog vided into different components (e.g., Packet Packet Packet Packet motion vectors, DCT coefficients, head- Stream ers. . . ). Multimedia content Reduction is done at the component level 19

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Unequal reduction (2) Crumb creation Component 1 Reduced 1 Reduction Component 1 Component 2 Reduced 1 Reduced 2 Component 2 Reduction Reduced 2 Reduced 3 Component 3 Crumb Packet Component 3 Reduced 3 Reduction 20

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Digital Right Management • In some context, only authorized users should be able to access the multi- media content • A possible solution is encrypting the data stream • For increased security, decryption should be done inside the player, not in- side the P2P software Encryption must be transparent to the P2P software 21

M EDUSA : a Reliable Chunkless Peer-to-Peer Architecture for Multimedia Streaming Seeder with cryptography • For every content the seeder generates a content Binary/Analog Reducer key Components To the peers • The content key is used Parser Encryption Reducer to encrypt the analog/binary components Video Content Reducer archive Key • When a new node joins the network it gives to the Encryption seeder the public key of its player To/from user P2P • The seeder encrypts the Module content key with the pub- Public user key lic key and sends the result back to the user 22