Yacine Boufkhad 1, Fabien Mathieu 2, Fabien de Montgoler 1, Diego Perino 2, Laurent Viennot 1

où l'on montre qu'il faut avoir un gros catalogue et bien s'en servir Yacine Boufkhad, Fabien Mathieu, Fabien de Montgoler, Diego Perino et Laurent Viennot Vidéo a la demande en Peer-to-peer intégral 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

VoD over P2P? problem statement Un modèle P2P pour la VoD Protagonistes Une organisation (FAI) souhaitant proposer un service de vidéo Des client ADSL, possédant des @µ 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

VoD over P2P? What it is not Modèle à serveur server client client client client Bande passante limitée et chère Capacités de stockage limitées et chères

VoD over P2P? What it is not Un modèle P2P pour la VoD Protagonistes Une organisation (FAI) souhaitant proposer un service de vidéo Des client ADSL, possédant des @µ Z -box ayant des capacité de stockage (disque dur) et d'upload 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

VoD over P2P? What it is not Problèmes connexes Téléchargement simple oine : délai non borné. emule, BitTorrent [Bram Cohen 2003],... Multicast Sert à diuser du contenu live Chacun regarde le même ux, au même point SplitStream [Castro et al. 2003], ZigZag [Tran et al. 2003] PPLive [Hei et al 2006] Prexstream [Gai Viennot 2006]...

VoD over P2P? What it is P2P suppléant un serveur server client client client client 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

VoD over P2P? What it is P2P pur server client client client client 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

VoD over P2P? What it is P2P pur server client client client client 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

VoD over P2P? What it is P2P pur server client client client client 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

VoD over P2P? Our goal Notre but Étant donnés les paramètres physiques du système : Taille des disques des box Upload et download des box Taille et débit des vidéos stockées en supposant le pire scénario (implique que chacun regarde un lm) et en garantissant la QoS nous voulons maximiser la taille du catalogue. O(n) borne triviale. Ω(n) atteignable?

VoD over P2P? Our goal Plan Exposé du modèle deux-temps Un résultat théorique d'optimalité cas homogène cas général Des algorithmes pratiques Des simulations

Modèle Un modèle en deux temps Peut-on vraiment se passer du serveur? 1- Déploiement Un serveur stocke des données de vidéos dans les disques des box (tâche de fond à débit lent, temps diéré) 2- Service Quand un client veut regarder une vidée, il la télécharge depuis certaines box en temps réel Nous nous intéressons à où stocker les vidéos (phase 1, centralisé) d'où télécharger les vidéos (phase 2, décentralisé, temps réel)

Modèle Stockage Sous quel forme stocker les vidéos Hypothèses 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

Modèle Stockage Dans quelles boites stocker les stripes? Réponse : allocation aléatoire Chacune des m vidéos est coupée en c stripes Chaque stripe est copiée dans k box Permutation aléatoire des mck stripes Justication On télécharge une stripe sans reconnection Pas d'hypothèse sur qui va télécherger quoi (futur inconnu) symmétrie du problème Autre raison expliquée ensuite : propriété d'expander

Résultat théorique, cas homogène Dénition Le modèle homogène Propriétés des boites n utilisateurs = n box stockage constant : d vidéos / boîte upload constant u nombre de connections entrantes constant c Propriétés des vidéos m vidéos disponibles ayant la même durée et le même débit coupées chacune en c stripes.

Résultat théorique, cas homogène Swarming Le swarming (relais entre utilisateurs) C'est quoi? La vidéo présentement regardée est mise en cache. L'utilisateur peut l'émettre vers d'autres Pourquoi? Sans cela, taille de catalogue constante! Que relayer? Tout morceau vu depuis un délai t Hypothèse de croissance régulière Pendant ce temps t arrive au plus une proportion µ de requêtes (sinon, taille de catalogue constante aussi!)

Résultat théorique, cas homogène Le théorème de Hall Le théorème de Hall Soit (X Y, E) un graphe biparti tq X = Y Un couplage parfait est M E tq M = X sans incidences entre arêtes X Y Le théorème de Hall un couplage parfait existe ssi S Y N(S) S (expansion)

Résultat théorique, cas homogène Le théorème de Hall Le théorème de Hall Soit (X Y, E) un graphe biparti tq X = Y Un couplage parfait est M E tq M = X sans incidences entre arêtes X Y S Le théorème de Hall un couplage parfait existe ssi S Y N(S) S (expansion)

Résultat théorique, cas homogène Le théorème de Hall Application du théorème de Hall le biparti des requêtes X = box Y = {y 1...y r } = requêtes = multi-ensemble de stripes arêtes E tq N(y i ) X = box pouvant satisfaire y i assignation des connections : M E tq M = r et toute requête y i touche une arête de M toute box x touche au plus b arêtes de M b=2 X Y

Résultat théorique, cas homogène Le théorème de Hall Application du théorème de Hall Théorème de Hall generalisé Une assignation existe ssi S Y N(S) S b (1/b)-expansion b = nombre de sockets d'upload. Ici constant et b = c. Modèle hétérogène : fonction b(x) de moyenne c (cf infra) b=2 X Y S

Résultat théorique, cas homogène Théorème principal Alors, est-ce possible? Théorème Une allocation par permutation aléatoire est un 1/b-expander pour tout multi-ensemble de requetes avec forte probabilité modèle homogène, pour l'instant il faut upload > download avec c (nombre de stripes) fonction de et de la vitesse de croissance max µ upload download avec O(log d) copies de chaque stripe (où d=taille de disque) Conséquence : Une taille de catalogue de Ω( dn logd ) vidéos diérentes est possible ( Θ(n) lms est l'optimum. Atteint!)

Résultat théorique, cas homogène Théorème principal Démonstration Théorème Une taille de catalogue de Ω( dn ) vidéos diérentes est possible logd Pas de reconnection : connecter les nouveaux seulement Obstruction : ens S de req tq. Upload(Box ayant S) < S c Si arrive, l'upload du swarm ne peut satisfaire la demande de dl Ratio download / upload majoré par µ/u Espérance qu'il arrive 1 obstruction(s) : O(1/n α ) avec α > 0 fonction des paramètres (d, u, µ...) mais pas de n. Point technique! Inégalité de Markov permet de conclure

Résultat théorique, cas homogène Théorème principal Les points techniques Théorème Une taille de catalogue de Ω( dn ) vidéos diérentes est possible logd Les vraies valeurs c > 2µ2 1 u 1 stripes 1 log d k 5ν log u ν = 1 c+2µ 2 1 1 uc u = 1 c uc copies d = max{d, u, exp(1)} ( ) (u 1) et nalement m = Ω 2 u+1 log 2 u 3 1 dn vidéos µ 2 log d

Résultat théorique, cas homogène Théorème principal Plus de lms ou plus de qualité? Les box ont upload u Les vidéos ont débit v P2P pur = v < u Si v est grand......la qualité est meilleure, mais......le catalogue est plus petit! m 0 en ( u v 1) 3

Résultat pour le cas hétérogène Problème! Hétérogénité : le problème Toutes les box ne sont pas créées égales... Deux sortes de box : riches (upload>seuil) et pauvres Si trop de pauvres dans le swarm plus d'upload dispo! Hypothèse d'homogénéité faible Il y a problème si les riches ont un petit disque : Intuitivement, requêtes reçues stripes stockées Mais requêtes satisfaites upload Solution : imposer une minoration de d/u (idéalement d/u = cste)

Résultat pour le cas hétérogène Solution! Hétérogénité : la solution Aecter à toute pauvre box b une box riche r(b) Réserver des slots upload pour b chez r(b) Certaines stripes requises à b sont routées par r(b) r(b) les émet donc à la place de b swarming upload r(b) b download Bien sûr certains slots d'upload de r(b) sont gâchés...

Résultat pour le cas hétérogène Conclusion de la partie théorique Conclusion de la partie théorique Nous avons montré l'existence d'un seuil : Si Si upload download upload download < 1 la taille de catalogue est constante > 1 le catalogue passe à l'échelle : taille m = Ω(n) L'algorithme d'allocation : simplement aléatoire! robustesse Boites homogènes ou hétérogènes (mais à upload majoré) disque Tous scénarios de requête (pire cas)

Algorithmes réalistes de connection 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!

Algorithmes réalistes de connection 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

Algorithmes réalistes de connection Autre idée Question : On se place dans un scénario de popularités diérentes. Chaque lm a une popularité connue. 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)

Algorithmes réalistes de connection Hypothèse d'occurrence des requêtes 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

Algorithmes réalistes de connection Simulations 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

Algorithmes réalistes de connection Simulations Simulation : insatisfaction en fonction de la réplication 0.8 0.7 0.6 SE CE DE SP20 CP20 0.5 Failure ratio 0.4 0.3 0.2 0.1 0 0 2 4 6 8 10 12 14 16 18 20 Number of copies

Algorithmes réalistes de connection Simulations 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

Algorithmes réalistes de connection Simulations Quelle valeur pour l'upload? 0.5 0.45 0.4 0.35 Failure ratio 0.3 0.25 0.2 0.15 SE CE DE SP20 CP20 0.1 0.05 0 1 1.05 1.1 1.15 1.2 1.25 1.3 1.35 1.4 1.45 1.5 Upload capacity

Algorithmes réalistes de connection Simulations Quel catalogue? (requêtes suivant popularité réaliste) 2.5 x 104 # of videos 2 1.5 1 SE CE DE SP20 CP20 0.5 0 1 1.05 1.1 1.15 1.2 1.25 1.3 1.35 1.4 1.45 1.5 upload capacity

Algorithmes réalistes de connection Simulations Quel catalogue? Scénario BlockBuster : 50% req. sur le même lm 7000 6000 5000 SE CE DE SP20 CP20 Number of videos 4000 3000 2000 1000 0 1 1.05 1.1 1.15 1.2 1.25 1.3 1.35 1.4 1.45 1.5 Upload capacity

Algorithmes réalistes de connection Simulations Insatisfaction 15000 SE CE DE SP20 Number of videos 10000 5000 0 10 6 4 1 0.6 0.4 0.1 Failure percentage

Algorithmes réalistes de connection Simulations Inuence du tracker (nombre de peers testés au max) Number of videos 6000 5000 4000 3000 2000 SE CE DE SP20 CP20 1000 0 5 10 15 20 25 30 35 40 45 50 List size

Algorithmes réalistes de connection Simulations Erreurs sur Zipf Law number of videos 2.5 x 104 SP SP10 SP20 SPr 2 CP CP10 CP20 1.5 CPr 1 0.5 0 1 1.05 1.1 1.15 1.2 1.25 1.3 1.35 1.4 1.45 1.5 upload capacity

Algorithmes réalistes de connection Simulations 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)

Algorithmes réalistes de connection conclusion Conclusion des expérimentations 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!

publications publications Boufkhad, Mathieu, Montgoler, Perino, Viennot : Achievable Catalog Size in Peer-to-Peer Video-on-Demand Systems IPTPS 2008, 7th International Workshop on Peer-to-Peer Systems, Toronto An upload bandwidth threshold for peer-to-peer Video-on-Demand scalability. IPDPS 2009, IEEE International Parallel & Distributed Processing Symposium, Rome Fine Tuning of a Distributed Video-on-Demand System ICCCN 2009, 18th International Conference on Computer Communications and Networks, San Francisco