Diusion VoD sur réseaux pair-à-pair: à propos de la taille du catalogue

Transcription

1 : à propos de la taille du catalogue Diusion VoD sur réseaux pair-à-pair: à propos de la taille du catalogue Yacine Boufkhad 1, Fabien Mathieu 2, Fabien de Montgoler 1, Diego Perino 2, Laurent Viennot 1 (1) Projet ANR Aladdin & Équipe-projet INRIA GANG & LIAFA (CNRS-Université Paris Diderot) (2) Orange Labs

2 épisode 2 : Relais ou allocation suivant la popularité? Diusion VoD sur réseaux pair-à-pair épisode 2 : Relais ou allocation suivant la popularité? Yacine Boufkhad 1, Fabien Mathieu 2, Fabien de Montgoler 1, Diego Perino 2, Laurent Viennot 1 (1) Projet ANR Aladdin & Équipe-projet INRIA GANG & LIAFA (CNRS-Université Paris Diderot) (2) Orange Labs

3 Résumé des épisodes précédents Laurent Viennot, la Rochelle 1. Un modèle P2P pour la VoD 2. Des résultats

4 Un modèle P2P pour la VoD Protagonistes Une organisation (FAI) souhaitant proposer un service de vidéo Des client ADSL, possédant Z -box Hypothèses Les clients doivent regarder leur vidéo on-demand : sans délai Bien sûr chacun demande ce qu'il veut, quand il veut Le Catalogue est l'ensemble des vidéos proposées

5 Modèle à serveur SERVER Bande passante limitée et chère Capacités de stockage limitées et chères

6 Un modèle P2P pour la VoD Protagonistes Une organisation (FAI) souhaitant proposer un service de vidéo Des client ADSL, possédant Z -box Intérêt des Åϖ -box Capacité d'upload Capacité de stockage (disque dur)

7 L'existant Téléchargement simple, oine [BitTorrent, B. Cohen 2003] multicast vidéo, pour du live (tous regardent la même chose) [SplitStream, Castro et al. 2003, ZigZag, Tran et al.... ]

8 P2P suppléant un serveur SERVER Les capacités de relais des pairs sont utiliées pour aider la distribution d'une seule vidéo [Hei et al. 2006, Annapureddy et al. 2007, Cheng et al. 2007, Huang et al. 2007,... ] Capacités de stockage du serveur toujours limitées et chères Répartition de la charge pour une vidéo mais étranglement du serveur si bcp de vidéos regardées

9 P2P pur plus de serveur Les données sont stockées sur les disques des box [Push-to-Peer, Suh et al. 2007] Croissance sans problème du système Répartition de la charge pour une vidéo

10 P2P pur plus de serveur Les données sont stockées sur les disques des box [Push-to-Peer, Suh et al. 2007] Croissance sans problème du système Répartition de la charge pour une vidéo catalogue de taille constante

11 P2P pur plus de serveur Les données sont stockées sur les disques des box [Push-to-Peer, Suh et al. 2007] Croissance sans problème du système Répartition de la charge pour une vidéo catalogue de taille constante Notre but : faire grossir le catalogue

12 Modèle Modèle n box capacités de stockage identiques ou non capacités d'émission identiques ou non nombre constant de connections m vidéos visionnables Stripping Diviser le ux video en c sous-ux c est justement le nombre de connections entrantes tolérence aux erreurs, répartition de la charge

13 Épisode 1 Si upload moyen < débit vidéo : pas bon Si upload moyen débit vidéo : catalogue constant Au-delà de 1 + ɛ : chaque lm doit être copié O(log n) fois donc le catalogue croît presque linéairement en n

14 Épisode 2 Nouvel algorithme de connection, plus réaliste Relais (swarming) Simulations (Diego Perino)

15 Allocation et requêtes Allocation aléatoire uniforme Chaque vidéo est découpée en c stripes (pour telechargement simultané) Chaque stripe est pré-chargéee k fois sur des boîtes aléatoires La taille du catalogue est donc α. n k Minimiser k Requêtes poissonniennes Ensuite, les boîte demandent à voir une vidéo. Le début du visionnage suit une loi de Poisson. Plusieurs scénarios : 1. Demandes uniformes 2. Demandes suivant une popularité en loi de Zipf

16 Trois algorithmes de connection 1 Connection simple (S) Le visonneur se connecte à l'une des k boîtes stockant son lm. Quand plus d'émission dispo dans aucune des k boîtes : échec! 2 Connection avec cache et relais (C) Chaque visonneur a un cache de la vidéo regardée. Un nouveau visonneur se connecte a un des k pairs stockant le lm ou à un des l pairs le visonnant. Quand plus d'émission dispo dans aucune des k + l boîtes : échec!

17 Trois algorithmes de connection 3 Connection dynamique avec relais (D) Un pair serveur peut déconnecter un pair client (qui devra se reconnecter) Règle de priorité serveur : Préférer le relais au stockage : déconnecter si besoin Mais réserver une connection de stockage! Règle de priorité client : Requerir seulement des relais (connus par tracker) Cependant pour un swarm petit, requêtes faites dans relais+stockage

18 Théorème d'ecacité Théorème Une allocation de Ω( dn log(d) ) vidéos par permutation aléatoire des stripes permet de répondre à une séquence quelconque de requêtes avec forte probabilité.

19 Idée de la preuve Min-cut Max-ow Un couplage de connexion satisfaisant les requêtes existe si et seulement si pour tout ensemble de requêtes de stripes X, l'upload total des boites contenant les stripes des X est au moins X /c. (Généralisation du théorème de Hall). Expander Autrement dit, les graphe biparti d'allocations stripes/boîtes est un 1 -Expander (Pour tout ensemble de sommets X, N(X ), l'ensemble uc des sommets est voisin est tel que N(X ) X /(uc)).

20 Idée de la preuve Permutation aléatoire Une allocation par permutation aléatoire des stripes répliqués O(log(d)) fois chacune est un 1 -Expander avec forte probabilité. uc Preuve L'espérance du nombre d'ensembles d'obstructions, c'est à dire, les ensembles de stripes tels que N(X ) < X /(uc) est O(1/n α ) (α > 0). L'inégalité de Markov permet de conclure.

21 Autre idée Question : On se place dans un scénario de popularités diérentes. Vaut-il mieux pré-charger les lms selon la popularité, on tous autant et utiliser le cache? Pré-chargement suivant la popularité Chaque vidéo est découpée en c stripes (pour telechargement simultané) Chaque stripe est pré-chargéee max(1,α.popu(lm)) fois sur des boîtes aléatoires La taille du catalogue est toujours O(n) (réplication moyenne constante)

22 Simulations Hypothèses 1000 peers, 25 lms par boîte. Arrivées réalistes avec burst max 27/5 sec, loi de Poisson modié, moyenne 17/5 sec Répartition réaliste en Zipf Law des requêtes de paramètre 0.4 Quelles courbes? 3 algorithmes de requêtes : Simple, Cache, Dynanique 2 allocations lms sur boîtes : Equiréparti ou Power law

23 Simulation : insatisfaction en fonction de la réplication SE CE DE SP20 CP Failure ratio Number of copies

24 Simulations Quelles courbes? 3 algorithmes de requêtes : Simple, Cache, Dynanique 2 allocations lms sur boîtes : Equiréparti ou Power law Quel résultat? Abscisse : un paramètre varie Ordonnée : on lit les échecs ou la taille du catalogue

25 Quelle valeur pour l'upload? Failure ratio SE CE DE SP20 CP Upload capacity

26 Quel catalogue? (requêtes suivant popularité réaliste) 2.5 x 104 # of videos SE CE DE SP20 CP upload capacity

27 Quel catalogue? Scénario BlockBuster : 50% req. sur le même lm SE CE DE SP20 CP20 Number of videos Upload capacity

28 Insatisfaction SE CE DE SP20 Number of videos Failure percentage

29 Inuence du tracker (nombre de peers testés au max) Number of videos SE CE DE SP20 CP List size

30 Erreurs sur Zipf Law number of videos 2.5 x 104 SP SP10 SP20 SPr 2 CP CP10 CP CPr upload capacity

31 Paramètres et leurs valeurs par défaut du simulateur n Nombre de boites (1000) m Nombre de vidéos. nd = km (5 ou variable) d Nombre de lms par boîte (25) u upload d'une boîte (1.2 débit video) c Nombre de connections entrantes = nombre de stripes (10) x Pairs demandés au tracker (30)

32 Conclusion Le relais avec connection dynamique est robuste Un pair trouvera à se connecter dans le swarm si réplication logarithmique (théorème) voire constante (simulations) La réplication par popularité sans relais est fragile La moindre erreur sur la réplication est lourde Reconnection dynamique? Utile sur les gros swarms! Work in progress En cours : hétérogénéité, hypothèses nes du théorème,...

33 Game over Game over