International audienceNous proposons Phosphite, un mécanisme d'incitation qui vise à assurer que les pairs d'un système de vidéo à la demande dédient une partie de leur bande passante à du téléchargement dans le désordre. Sans incitation, les pairs égoïstes vont tenter de maximiser leur bénéfice en téléchargeant le contenu dans l'ordre, ce qui va à l'encontre de l'intérêt général. Les derniers blocs téléchargeables ayant alors tendance à disparaître du système, le serveur devra souvent réintroduire ces derniers blocs. Phosphite permet de s'assurer que les pairs dédient une partie de leur bande passante à du téléchargement dans le désordre au bénéfice de la communauté. Ainsi, tous les blocs restent disponibles avec une probabilité supérieure à 98% alors que sans incitation les derniers blocs sont disponibles avec une probabilité inférieure à 50%

Champel, Mary-Luc

Kermarrec, Anne-Marie

Le Scouarnec, Nicolas

INRIA a CCSD electronic archive server

HAL Id: inria-00383172https://hal.inria.fr/inria-00383172Submitted on 12 May 2009HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.Phosphite : Incitation à la collaboration pour la vidéo àla demande en P2PMary-Luc Champel, Anne-Marie Kermarrec, Nicolas Le ScouarnecTo cite this version:Mary-Luc Champel, Anne-Marie Kermarrec, Nicolas Le Scouarnec. Phosphite : Incitation à la collab-oration pour la vidéo à la demande en P2P. AlgoTel, 2009, Carry-Le-Rouet, France. ￿inria-00383172￿Phosphite : Incitation à la collaboration pour lavidéo à la demande en P2PMary-Luc Champel1, Anne-Marie Kermarrec2 et Nicolas Le Scouarnec11Thomson R&D France , 1 avenue de Belle-Fontaine, 35576, Cesson-Sevigné, France2INRIA Rennes / Bretagne-Atlantique, campus de Beaulieu, 35042, Rennes, FranceNous proposons Phosphite, un mécanisme d’incitation qui vise à assurer que les pairs d’un système de vidéo à lademande dédient une partie de leur bande passante à du téléchargement dans le désordre. Sans incitation, les pairségoı̈stes vont tenter de maximiser leur bénéfice en téléchargeant le contenu dans l’ordre, ce qui va à l’encontre del’intérêt général. Les derniers blocs téléchargeables ayant alors tendance à disparaı̂tre du système, le serveur devrasouvent réintroduire ces derniers blocs. Phosphite permet de s’assurer que les pairs dédient une partie de leur bandepassante à du téléchargement dans le désordre au bénéfice de la communauté. Ainsi, tous les blocs restent disponiblesavec une probabilité supérieure à 98% alors que sans incitation les derniers blocs sont disponibles avec une probabilitéinférieure à 50%.Keywords: pair-à-pair, incitation, vidéo à la demande1 IntroductionDans les systèmes de vidéo à la demande, les utilisateurs choisissent un contenu et le regardent quandils le souhaitent. Les utilisateurs ne sont pas synchronisés, ce qui rend impossible l’utilisation de multicastpour réduire les besoins en ressources au niveau du serveur. Ainsi, le déploiement de solutions P2P (pair àpair) limite la charge du serveur en permettant aux pairs d’échanger du contenu entre eux.Les systèmes de vidéo à la demande s’appuyant sur des technologies P2P utilisent en général une variantedu protocole Bittorrent [Coh03]. Le contenu à télécharger est divisé en blocs. La copie initiale des blocs estfournie par le serveur. Par la suite, les pairs, agissant à la fois comme clients et comme relais, échangentdes blocs jusqu’à avoir obtenu l’ensemble du contenu. Ainsi, un pair ne s’adresse au serveur que si le blocsouhaité n’est pas disponible auprès d’un de ses voisins. Les recours au serveur sont coûteux et doiventrester exceptionnels.Bittorrent [Coh03] est régi par quelques règles qui assurent son bon fonctionnement. D’une part, afin defavoriser la collaboration, les pairs sont servis proportionnellement à leur contribution via un mécanismede réciprocation. D’autre part, afin d’assurer une diversité suffisante entre les pairs, le bloc qui doit êtretéléchargé est choisi selon une politique LRF (Local Rarest First). Cette politique indique que le blocà télécharger en priorité est celui qui est le plus rare localement (estimation réalisée selon les cartes dedisponibilités fournies par les voisins). La diversité assurée par cette seconde règle est cruciale puisqu’ellepermet le bon fonctionnement du mécanisme de réciprocation et qu’elle assure qu’aucun bloc ne devientrare, rendant le système résistant au dynamisme. En effet, l’absence de blocs rares permet de garantir queles pairs pourront télécharger l’ensemble des blocs même si un nombre important de pairs quitte le système.Les systèmes de vidéo à la demande [PWMC08, CE07, CSDP07] qui s’appuient sur Bittorrent identifientla politique LRF comme une composante essentielle du protocole Bittorrent. Néanmoins, la politique LRFconduit à un téléchargement dans le désordre qui ne permet pas la réalisation d’un système de vidéo à lademande dans lequel l’utilisateur commence à lire le contenu alors qu’il n’en a téléchargé qu’une petitepartie. Ainsi, la politique de choix des blocs utilisée dans de tels systèmes combine une part importante detéléchargement dans l’ordre à une petite part de téléchargement dans le désordre.La nature distribuée des réseaux P2P les rend sensibles aux comportements égoı̈stes. En effet, chaque pairest indépendant et libre de modifier son comportement en s’appuyant sur une variante du protocole, ce quiMary-Luc Champel, Anne-Marie Kermarrec et Nicolas Le ScouarnecRequête du bloc 5Envoi du XOR du bloc 5 et du bloc 8Je dois télécharger le bloc8 afin de pouvoir décoderet utiliser le bloc 5Bloc pas encore téléchargé Bloc téléchargé Bloc en cours de lecture1 12 1 12Je choisis d'encoder avecla probabilité pe et je choisisd'encoder avec le bloc 8 avecla probabilité pcFIGURE 1: Illustration d’un échange entre deux pairs. Le second pair répond à la requête du premier tout en luiimposant de télécharger le bloc 8 avant de pouvoir utiliser le bloc 5.aura un impact important sur le reste du système. Ainsi, un comportement égoı̈ste apparaı̂tra dès lors que lepair arrête de servir l’intérêt général pour se concentrer sur son propre intérêt. À ce titre, Bittorrent inclutdéjà un mécanisme de réciprocation pour s’assurer que les pairs collaborent bien en fournissant du contenuaux autre pairs. Cependant, aucun mécanisme ne s’assure que le pair effectue bien un téléchargement dansle désordre, Bittorrent reposant entièrement sur la bonne volonté des pairs pour ce point.Nous nous intéressons au cas où les pairs téléchargent le contenu dans l’ordre. Dans un système de vidéoà la demande, chaque pair à intérêt à télécharger le contenu dans l’ordre puisqu’il téléchargera en premierle contenu qu’il utilisera en premier. Une telle stratégie permet de s’assurer que le contenu est disponible aumoment de l’afficher à l’écran. Ainsi, les pairs ont individuellement intérêt à ne faire que du téléchargementdans l’ordre, ce qui est malheureusement contraire à l’intérêt général.Les comportements égoı̈stes ont un impact réel sur les réseaux P2P. En effet, l’anonymat des utilisa-teurs ne les incite pas à contribuer. Ainsi, GNutella, un des premiers réseau P2P, comportait plus de 80%de free-riders qui utilisaient le système sans contribuer, ce qui dégradait les performances pour les utili-sateurs légitimes. Bittorrent a supplanté ce réseau puisqu’il assure la contribution en récompensant,par demeilleures performances , les pairs qui contribuent. De plus, un comportement égoı̈ste qui conduirait lespairs à télécharger dans l’ordre semble possible. En effet, afin de permettre aux utilisateurs de visualiser unaperçu du contenu en cours de téléchargement, certains clients Bittorrent (Bittornado, G3 Torrent, uTorrent)incluent une option, fortement déconseillée, permettant de télécharger les blocs dans l’ordre.Phosphite, le mécanisme que nous proposons, permet de s’assurer qu’un pair dédie bien une partie (10%)de sa bande passante à du téléchargement dans le désordre. Le but est d’assurer que chaque pair participeraà un tâche commune assurant la persistance des données. Nous nous concentrons sur le respect de l’ordre detéléchargement. En effet, la collaboration peut-être assurée par les mécanismes classiques de réciprocationdéjà présents dans Bittorrent. Dans la suite de l’article, nous présentons Phosphite et nous abordons lamanière de structurer les paquets pour assurer la robustesse du mécanisme. Enfin, nous évaluons l’effet dumécanisme d’incitation.2 Phosphite, Préserver le téléchargement Out-Of-OrderPhosphite est une extension d’un protocole de vidéo à la demande s’inspirant de Bittorrent. Cette ex-tension permet de s’assurer qu’un pair dédiera une partie de sa bande passante à du téléchargement dans ledésordre. Cette obligation est imposée à un pair par les pairs qui lui fournissent des données. En effet, le pairqui demande à télécharger un premier bloc est parfois forcé d’en télécharger un second avant de pouvoirutiliser le premier. Phosphite ne s’appuie ni sur des protocoles d’audit, ni sur des mécanismes de cryptogra-phie complexes à déployer. Au final, on répond au pair en lui envoyant le bloc mais en conditionnant sonutilisation à la possession d’un autre bloc grâce à un petit challenge informatique.Phosphite est relativement simple. Un pair qui reçoit une requête choisit d’imposer le téléchargementd’un autre bloc avec une probabilité pe(x). S’il a choisi d’imposer le téléchargement, il choisit un blocy > x selon une loi définie par pc(x,y). Le challenge est construit à partir du code correcteur d’erreurs(x,y,x⊕ y). Le pair envoie x⊕ y †. Cela impose au second pair de télécharger y pour pouvoir décoder et†. Dans la suite de cet article, x⊕ y désignera l’opération calculant le ou-exclusif bit à bit entre x et y.Phosphite: Incitation pour la vidéo à la demande en pair à pair11010010000 100 200 300 400 500pe = 0.1 (LRF)pe = 0.25 (Uniforme)pe = 0.1 (Uniforme)Sans incitationLimite pour la disponibilite a 98%Limite pour la disponibilite a 90%Limite pour la disponibilite a 75%Limite pour la disponibilite a 50%(a) Nombre de réplicats (ordonnée) par bloc (abscisse).024681012pe=0.1(LRF)pe=0.1(Uniforme)pe=0.25(Uniforme)Sansincitation(b) Charge moyenne du serveurFIGURE 2: Comparaison des variantes de Phosphite avec un système sans Phosphiteutiliser x. La procédure se répète récursivement puisque, quand le pair émet une requête pour y, il peutrecevoir y⊕ z avec une probabilité pe(y). La figure 1 présente un échange entre deux pairs.Ce même challenge peut aussi être construit à partir du chiffrement symétrique de Vernam qui permet dechiffrer x avec une clé k au moins aussi longue que x en calculant x⊕ k. Avant de transmettre des données,x est chiffré avec la clé y. Le pair qui reçoit x⊕ y doit télécharger y avant de pouvoir déchiffrer x.Phosphite s’appuie sur deux paramètres pe(x), qui est la probabilité d’envoyer un bloc encodé, et pc(x,y),qui définit comment choisir y quand un pair a décidé d’encoder. Ces deux paramètres définissent entièrementle mécanisme d’incitation. Ainsi, comme le pair qui envoie une requête ne peut pas mentir sur le bloc x qu’ilsouhaite et comme Phosphite ne s’appuie que sur cette information, le mécanisme d’incitation laisse peude place aux attaques.La probabilité d’encoder pe(x) peut prendre une forme quelconque. Cependant, nous nous limiteronsau cas où pe(x) = c est constant puisque cette forme simple donne d’excellents résultats alors que desformes plus compliquées (croissantes, décroissantes, triangulaires) présentent des effets indésirables. Ence qui concerne la loi pc(x,y) définissant le choix du bloc avec lequel encoder, deux alternatives sontintéressantes. D’une part, le bloc y peut être choisi aléatoirement et uniformément parmi les blocs z > x dis-ponibles. D’autre part, le bloc y peut-être choisi comme étant le bloc z > x disponible le plus rare localement(estimation réalisée selon les cartes de contenus des voisins du pair qui répond à la requête). Cette méthode,inspirée de la politique LRF de Bittorrent, permet d’éviter l’apparition de blocs rares. Puisque y > x, le pairacquiert obligatoirement une nouvelle donnée à chaque bloc reçu. Ainsi, il n’y a pas de surcoût en terme debande passante consommée.Puisque le mécanisme n’offre pas d’avantages aux nouveaux arrivants et aux pairs qui déclarent coopérerentre eux, les attaques classiques (attaque sibylline et collusion) ne présentent pas d’intérêt. Néanmoins, lemécanisme d’incitation reste sensible à des attaques où un pair tente de déterminer si le contenu est encodépour fermer la connexion et annuler le téléchargement si c’est le cas.Afin de prévenir ce type d’attaque, les entêtes du paquet doivent être ajoutés à la fin du paquet et non audébut. De plus, les données doivent être chiffré symétriquement, avec une clé aléatoire qui sera ajoutée àla fin du paquet. En effet, si le contenu n’est pas chiffré, un échantillon des données permet à un pair dese faire une idée de la nature du contenu. Si un pair télécharge la même donnée depuis trois pairs et qu’aumoins deux d’entre eux lui envoient un contenu dont les premiers octets sont identiques, alors il sait queces pairs envoient du contenu non-encodé. Il choisira donc de télécharger depuis l’un de ces deux pairs.Pour prévenir cette attaque, le contenu ne doit être exploitable qu’une fois que l’intégralité du bloc a ététéléchargée.3 ÉvaluationNous effectuons une simulation par cycle d’un système où les pairs sont indépendants. Le système esthomogène : tous les pairs sont identiques. Les pairs téléchargent dans l’ordre les différents blocs d’un filmMary-Luc Champel, Anne-Marie Kermarrec et Nicolas Le Scouarnec(a) pe = 0 (b) pe = 0.10, (Uniforme) (c) pe = 0.25, (Uniforme) (d) pe = 0.10, (LRF)FIGURE 3: Disponibilité des blocs suivant les pairs. Chaque ligne représente un bloc et chaque colonne représente unpair. Si un bloc est disponible, un point noir apparaı̂t.en anticipant jusqu’à 20 blocs par rapport à la lecture. Après une période de pré-chargement de 60 cycles,le système commence à lire les 512 blocs. Les 20 derniers blocs correspondent au générique du film. Lesutilisateurs restent regarder le film qu’ils ont acheté mais quittent le système rapidement à l’issue du film.Pendant le film, ils partent selon une loi exponentielle, en moyenne au bout de 200 cycles. Pendant legénérique, ils partent en moyenne au bout de 10 cycles. Une fois la lecture du film terminée, ils partent enmoyenne au bout de 2 cycles.La figure 2(b) présente le nombre moyen de blocs fournit par le serveur par cycle. L’utilisation dumécanisme d’incitation utilisant pe = 0.1 et une politique LRF permet de diviser par 4 la charge du ser-veur. La diffusion entre pairs est plus efficace.La figure 2(a) présente le nombre de réplicats pour chaque bloc. Les lignes horizontales indiquent desbornes à ne pas franchir pour que le contenu soit disponible sur au moins un voisin avec une certaineprobabilité. Le mécanisme d’incitation, avec la politique LRF, assure que les différents blocs restent dispo-nibles avec plus de 98% de chances alors qu’en l’absence d’incitation, les derniers blocs ne sont même pasdisponibles à 50%. Ainsi, le mécanisme d’incitation permet de réduire la dépendance au serveur.La figure 3 affiche une carte du contenu disponible sur chaque pair. Conformément aux figures 2(b) et2(a), la politique LRF permet de placer judicieusement des réplicats supplémentaires sur les derniers blocs.La politique uniforme est moins efficace et nécessite de forcer plus souvent les pairs à télécharger pourobtenir une réplication aussi efficace.4 ConclusionsPhosphite est un mécanisme d’incitation au téléchargement dans le désordre à la fois simple et puissant.Il ne présente pas de failles permettant de le contourner et reste simple à mettre en oeuvre. Sa simplicitélui permet de s’intégrer facilement dans des systèmes existants et de s’interfacer simplement avec desmécanisme de réciprocation (assurant la participation).Phosphite s’appuie sur la construction de codes correcteur d’erreurs (ou sur le chiffrement de Vernam)afin de construire un challenge informatique qui permet d’assurer que les pairs téléchargent une partie desblocs dans le désordre.Phosphite permet ainsi d’assurer que tous les blocs sont disponibles avec plus de 98% de chances quandl’absence de mécanisme d’incitation conduit à ne même pas pouvoir garantir 50% de chances pour lesderniers blocs.Références[CE07] Niklas Carlsson and Derek L. Eager. Peer-assisted on demand streaming of stored media usingbittorrent-like protocols. In IFIP/Networking, 2007.[Coh03] Bram Cohen. Incentives build robustness in bittorrent. In P2PEcon, June 2003.[CSDP07] Yung Ryn Choe, Derek L. Schuff, Jagadeesh M. Dyaberi, and Vijay S. Pai. Improving vodserver efficiency with bittorrent. In MM, 2007.[PWMC08] Khandoker Parvez, Carey Williamson, Anirban Mahanti, and Niklas Carlsson. Analysis ofbittorrent-like protocols for on-demand stored media streaming. In SIGMETRICS, 2008.

Phosphite : Incitation à la collaboration pour la vidéo à la demande en P2P

HAL-Rennes 1

Phosphite : Incitation a` la collaboration pour la vide´o a`la demande en P2PMary-Luc Champel, Anne-Marie Kermarrec, Nicolas Le ScouarnecTo cite this version:Mary-Luc Champel, Anne-Marie Kermarrec, Nicolas Le Scouarnec. Phosphite : Incitationa` la collaboration pour la vide´o a` la demande en P2P. Chaintreau, Augustin and Magnien,Clemence. AlgoTel, 2009, Carry-Le-Rouet, France. 2009. <inria-00383172>HAL Id: inria-00383172https://hal.inria.fr/inria-00383172Submitted on 12 May 2009HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.L’archive ouverte pluridisciplinaire HAL, estdestine´e au de´poˆt et a` la diffusion de documentsscientifiques de niveau recherche, publie´s ou non,e´manant des e´tablissements d’enseignement et derecherche franc¸ais ou e´trangers, des laboratoirespublics ou prive´s.Phosphite : Incitation a` la collaboration pour lavide´o a` la demande en P2PMary-Luc Champel1, Anne-Marie Kermarrec2 et Nicolas Le Scouarnec11Thomson R&D France , 1 avenue de Belle-Fontaine, 35576, Cesson-Sevigne´, France2INRIA Rennes / Bretagne-Atlantique, campus de Beaulieu, 35042, Rennes, FranceNous proposons Phosphite, un me´canisme d’incitation qui vise a` assurer que les pairs d’un syste`me de vide´o a` lademande de´dient une partie de leur bande passante a` du te´le´chargement dans le de´sordre. Sans incitation, les pairse´goı¨stes vont tenter de maximiser leur be´ne´fice en te´le´chargeant le contenu dans l’ordre, ce qui va a` l’encontre del’inte´reˆt ge´ne´ral. Les derniers blocs te´le´chargeables ayant alors tendance a` disparaıˆtre du syste`me, le serveur devrasouvent re´introduire ces derniers blocs. Phosphite permet de s’assurer que les pairs de´dient une partie de leur bandepassante a` du te´le´chargement dans le de´sordre au be´ne´fice de la communaute´. Ainsi, tous les blocs restent disponiblesavec une probabilite´ supe´rieure a` 98% alors que sans incitation les derniers blocs sont disponibles avec une probabilite´infe´rieure a` 50%.Keywords: pair-a`-pair, incitation, vide´o a` la demande1 IntroductionDans les syste`mes de vide´o a` la demande, les utilisateurs choisissent un contenu et le regardent quandils le souhaitent. Les utilisateurs ne sont pas synchronise´s, ce qui rend impossible l’utilisation de multicastpour re´duire les besoins en ressources au niveau du serveur. Ainsi, le de´ploiement de solutions P2P (pair a`pair) limite la charge du serveur en permettant aux pairs d’e´changer du contenu entre eux.Les syste`mes de vide´o a` la demande s’appuyant sur des technologies P2P utilisent en ge´ne´ral une variantedu protocole Bittorrent [Coh03]. Le contenu a` te´le´charger est divise´ en blocs. La copie initiale des blocs estfournie par le serveur. Par la suite, les pairs, agissant a` la fois comme clients et comme relais, e´changentdes blocs jusqu’a` avoir obtenu l’ensemble du contenu. Ainsi, un pair ne s’adresse au serveur que si le blocsouhaite´ n’est pas disponible aupre`s d’un de ses voisins. Les recours au serveur sont couˆteux et doiventrester exceptionnels.Bittorrent [Coh03] est re´gi par quelques re`gles qui assurent son bon fonctionnement. D’une part, afin defavoriser la collaboration, les pairs sont servis proportionnellement a` leur contribution via un me´canismede re´ciprocation. D’autre part, afin d’assurer une diversite´ suffisante entre les pairs, le bloc qui doit eˆtrete´le´charge´ est choisi selon une politique LRF (Local Rarest First). Cette politique indique que le bloca` te´le´charger en priorite´ est celui qui est le plus rare localement (estimation re´alise´e selon les cartes dedisponibilite´s fournies par les voisins). La diversite´ assure´e par cette seconde re`gle est cruciale puisqu’ellepermet le bon fonctionnement du me´canisme de re´ciprocation et qu’elle assure qu’aucun bloc ne devientrare, rendant le syste`me re´sistant au dynamisme. En effet, l’absence de blocs rares permet de garantir queles pairs pourront te´le´charger l’ensemble des blocs meˆme si un nombre important de pairs quitte le syste`me.Les syste`mes de vide´o a` la demande [PWMC08, CE07, CSDP07] qui s’appuient sur Bittorrent identifientla politique LRF comme une composante essentielle du protocole Bittorrent. Ne´anmoins, la politique LRFconduit a` un te´le´chargement dans le de´sordre qui ne permet pas la re´alisation d’un syste`me de vide´o a` lademande dans lequel l’utilisateur commence a` lire le contenu alors qu’il n’en a te´le´charge´ qu’une petitepartie. Ainsi, la politique de choix des blocs utilise´e dans de tels syste`mes combine une part importante dete´le´chargement dans l’ordre a` une petite part de te´le´chargement dans le de´sordre.La nature distribue´e des re´seaux P2P les rend sensibles aux comportements e´goı¨stes. En effet, chaque pairest inde´pendant et libre de modifier son comportement en s’appuyant sur une variante du protocole, ce quiMary-Luc Champel, Anne-Marie Kermarrec et Nicolas Le ScouarnecRequête du bloc 5Envoi du XOR du bloc 5 et du bloc 8Je dois télécharger le bloc8 afin de pouvoir décoderet utiliser le bloc 5Bloc pas encore téléchargé Bloc téléchargé Bloc en cours de lecture1 12 1 12Je choisis d'encoder avecla probabilité pe et je choisisd'encoder avec le bloc 8 avecla probabilité pcFIGURE 1: Illustration d’un e´change entre deux pairs. Le second pair re´pond a` la requeˆte du premier tout en luiimposant de te´le´charger le bloc 8 avant de pouvoir utiliser le bloc 5.aura un impact important sur le reste du syste`me. Ainsi, un comportement e´goı¨ste apparaıˆtra de`s lors que lepair arreˆte de servir l’inte´reˆt ge´ne´ral pour se concentrer sur son propre inte´reˆt. `A ce titre, Bittorrent inclutde´ja` un me´canisme de re´ciprocation pour s’assurer que les pairs collaborent bien en fournissant du contenuaux autre pairs. Cependant, aucun me´canisme ne s’assure que le pair effectue bien un te´le´chargement dansle de´sordre, Bittorrent reposant entie`rement sur la bonne volonte´ des pairs pour ce point.Nous nous inte´ressons au cas ou` les pairs te´le´chargent le contenu dans l’ordre. Dans un syste`me de vide´oa` la demande, chaque pair a` inte´reˆt a` te´le´charger le contenu dans l’ordre puisqu’il te´le´chargera en premierle contenu qu’il utilisera en premier. Une telle strate´gie permet de s’assurer que le contenu est disponible aumoment de l’afficher a` l’e´cran. Ainsi, les pairs ont individuellement inte´reˆt a` ne faire que du te´le´chargementdans l’ordre, ce qui est malheureusement contraire a` l’inte´reˆt ge´ne´ral.Les comportements e´goı¨stes ont un impact re´el sur les re´seaux P2P. En effet, l’anonymat des utilisa-teurs ne les incite pas a` contribuer. Ainsi, GNutella, un des premiers re´seau P2P, comportait plus de 80%de free-riders qui utilisaient le syste`me sans contribuer, ce qui de´gradait les performances pour les utili-sateurs le´gitimes. Bittorrent a supplante´ ce re´seau puisqu’il assure la contribution en re´compensant,par demeilleures performances , les pairs qui contribuent. De plus, un comportement e´goı¨ste qui conduirait lespairs a` te´le´charger dans l’ordre semble possible. En effet, afin de permettre aux utilisateurs de visualiser unaperc¸u du contenu en cours de te´le´chargement, certains clients Bittorrent (Bittornado, G3 Torrent, uTorrent)incluent une option, fortement de´conseille´e, permettant de te´le´charger les blocs dans l’ordre.Phosphite, le me´canisme que nous proposons, permet de s’assurer qu’un pair de´die bien une partie (10%)de sa bande passante a` du te´le´chargement dans le de´sordre. Le but est d’assurer que chaque pair participeraa` un taˆche commune assurant la persistance des donne´es. Nous nous concentrons sur le respect de l’ordre dete´le´chargement. En effet, la collaboration peut-eˆtre assure´e par les me´canismes classiques de re´ciprocationde´ja` pre´sents dans Bittorrent. Dans la suite de l’article, nous pre´sentons Phosphite et nous abordons lamanie`re de structurer les paquets pour assurer la robustesse du me´canisme. Enfin, nous e´valuons l’effet dume´canisme d’incitation.2 Phosphite, Pre´server le te´le´chargement Out-Of-OrderPhosphite est une extension d’un protocole de vide´o a` la demande s’inspirant de Bittorrent. Cette ex-tension permet de s’assurer qu’un pair de´diera une partie de sa bande passante a` du te´le´chargement dans lede´sordre. Cette obligation est impose´e a` un pair par les pairs qui lui fournissent des donne´es. En effet, le pairqui demande a` te´le´charger un premier bloc est parfois force´ d’en te´le´charger un second avant de pouvoirutiliser le premier. Phosphite ne s’appuie ni sur des protocoles d’audit, ni sur des me´canismes de cryptogra-phie complexes a` de´ployer. Au final, on re´pond au pair en lui envoyant le bloc mais en conditionnant sonutilisation a` la possession d’un autre bloc graˆce a` un petit challenge informatique.Phosphite est relativement simple. Un pair qui rec¸oit une requeˆte choisit d’imposer le te´le´chargementd’un autre bloc avec une probabilite´ pe(x). S’il a choisi d’imposer le te´le´chargement, il choisit un blocy > x selon une loi de´finie par pc(x,y). Le challenge est construit a` partir du code correcteur d’erreurs(x,y,x⊕ y). Le pair envoie x⊕ y †. Cela impose au second pair de te´le´charger y pour pouvoir de´coder et†. Dans la suite de cet article, x⊕ y de´signera l’ope´ration calculant le ou-exclusif bit a` bit entre x et y.Phosphite: Incitation pour la vide´o a` la demande en pair a` pair11010010000 100 200 300 400 500pe = 0.1 (LRF)pe = 0.25 (Uniforme)pe = 0.1 (Uniforme)Sans incitationLimite pour la disponibilite a 98%Limite pour la disponibilite a 90%Limite pour la disponibilite a 75%Limite pour la disponibilite a 50%(a) Nombre de re´plicats (ordonne´e) par bloc (abscisse).024681012p e=0.1(LRF)p e=0.1(Uniforme)p e=0.25(Uniforme)Sansincitation(b) Charge moyenne du serveurFIGURE 2: Comparaison des variantes de Phosphite avec un syste`me sans Phosphiteutiliser x. La proce´dure se re´pe`te re´cursivement puisque, quand le pair e´met une requeˆte pour y, il peutrecevoir y⊕ z avec une probabilite´ pe(y). La figure 1 pre´sente un e´change entre deux pairs.Ce meˆme challenge peut aussi eˆtre construit a` partir du chiffrement syme´trique de Vernam qui permet dechiffrer x avec une cle´ k au moins aussi longue que x en calculant x⊕ k. Avant de transmettre des donne´es,x est chiffre´ avec la cle´ y. Le pair qui rec¸oit x⊕ y doit te´le´charger y avant de pouvoir de´chiffrer x.Phosphite s’appuie sur deux parame`tres pe(x), qui est la probabilite´ d’envoyer un bloc encode´, et pc(x,y),qui de´finit comment choisir y quand un pair a de´cide´ d’encoder. Ces deux parame`tres de´finissent entie`rementle me´canisme d’incitation. Ainsi, comme le pair qui envoie une requeˆte ne peut pas mentir sur le bloc x qu’ilsouhaite et comme Phosphite ne s’appuie que sur cette information, le me´canisme d’incitation laisse peude place aux attaques.La probabilite´ d’encoder pe(x) peut prendre une forme quelconque. Cependant, nous nous limiteronsau cas ou` pe(x) = c est constant puisque cette forme simple donne d’excellents re´sultats alors que desformes plus complique´es (croissantes, de´croissantes, triangulaires) pre´sentent des effets inde´sirables. Ence qui concerne la loi pc(x,y) de´finissant le choix du bloc avec lequel encoder, deux alternatives sontinte´ressantes. D’une part, le bloc y peut eˆtre choisi ale´atoirement et uniforme´ment parmi les blocs z > x dis-ponibles. D’autre part, le bloc y peut-eˆtre choisi comme e´tant le bloc z > x disponible le plus rare localement(estimation re´alise´e selon les cartes de contenus des voisins du pair qui re´pond a` la requeˆte). Cette me´thode,inspire´e de la politique LRF de Bittorrent, permet d’e´viter l’apparition de blocs rares. Puisque y > x, le pairacquiert obligatoirement une nouvelle donne´e a` chaque bloc rec¸u. Ainsi, il n’y a pas de surcouˆt en terme debande passante consomme´e.Puisque le me´canisme n’offre pas d’avantages aux nouveaux arrivants et aux pairs qui de´clarent coope´rerentre eux, les attaques classiques (attaque sibylline et collusion) ne pre´sentent pas d’inte´reˆt. Ne´anmoins, leme´canisme d’incitation reste sensible a` des attaques ou` un pair tente de de´terminer si le contenu est encode´pour fermer la connexion et annuler le te´le´chargement si c’est le cas.Afin de pre´venir ce type d’attaque, les enteˆtes du paquet doivent eˆtre ajoute´s a` la fin du paquet et non aude´but. De plus, les donne´es doivent eˆtre chiffre´ syme´triquement, avec une cle´ ale´atoire qui sera ajoute´e a`la fin du paquet. En effet, si le contenu n’est pas chiffre´, un e´chantillon des donne´es permet a` un pair dese faire une ide´e de la nature du contenu. Si un pair te´le´charge la meˆme donne´e depuis trois pairs et qu’aumoins deux d’entre eux lui envoient un contenu dont les premiers octets sont identiques, alors il sait queces pairs envoient du contenu non-encode´. Il choisira donc de te´le´charger depuis l’un de ces deux pairs.Pour pre´venir cette attaque, le contenu ne doit eˆtre exploitable qu’une fois que l’inte´gralite´ du bloc a e´te´te´le´charge´e.3 ´EvaluationNous effectuons une simulation par cycle d’un syste`me ou` les pairs sont inde´pendants. Le syste`me esthomoge`ne : tous les pairs sont identiques. Les pairs te´le´chargent dans l’ordre les diffe´rents blocs d’un filmMary-Luc Champel, Anne-Marie Kermarrec et Nicolas Le Scouarnec(a) pe = 0 (b) pe = 0.10, (Uniforme) (c) pe = 0.25, (Uniforme) (d) pe = 0.10, (LRF)FIGURE 3: Disponibilite´ des blocs suivant les pairs. Chaque ligne repre´sente un bloc et chaque colonne repre´sente unpair. Si un bloc est disponible, un point noir apparaıˆt.en anticipant jusqu’a` 20 blocs par rapport a` la lecture. Apre`s une pe´riode de pre´-chargement de 60 cycles,le syste`me commence a` lire les 512 blocs. Les 20 derniers blocs correspondent au ge´ne´rique du film. Lesutilisateurs restent regarder le film qu’ils ont achete´ mais quittent le syste`me rapidement a` l’issue du film.Pendant le film, ils partent selon une loi exponentielle, en moyenne au bout de 200 cycles. Pendant lege´ne´rique, ils partent en moyenne au bout de 10 cycles. Une fois la lecture du film termine´e, ils partent enmoyenne au bout de 2 cycles.La figure 2(b) pre´sente le nombre moyen de blocs fournit par le serveur par cycle. L’utilisation dume´canisme d’incitation utilisant pe = 0.1 et une politique LRF permet de diviser par 4 la charge du ser-veur. La diffusion entre pairs est plus efficace.La figure 2(a) pre´sente le nombre de re´plicats pour chaque bloc. Les lignes horizontales indiquent desbornes a` ne pas franchir pour que le contenu soit disponible sur au moins un voisin avec une certaineprobabilite´. Le me´canisme d’incitation, avec la politique LRF, assure que les diffe´rents blocs restent dispo-nibles avec plus de 98% de chances alors qu’en l’absence d’incitation, les derniers blocs ne sont meˆme pasdisponibles a` 50%. Ainsi, le me´canisme d’incitation permet de re´duire la de´pendance au serveur.La figure 3 affiche une carte du contenu disponible sur chaque pair. Conforme´ment aux figures 2(b) et2(a), la politique LRF permet de placer judicieusement des re´plicats supple´mentaires sur les derniers blocs.La politique uniforme est moins efficace et ne´cessite de forcer plus souvent les pairs a` te´le´charger pourobtenir une re´plication aussi efficace.4 ConclusionsPhosphite est un me´canisme d’incitation au te´le´chargement dans le de´sordre a` la fois simple et puissant.Il ne pre´sente pas de failles permettant de le contourner et reste simple a` mettre en oeuvre. Sa simplicite´lui permet de s’inte´grer facilement dans des syste`mes existants et de s’interfacer simplement avec desme´canisme de re´ciprocation (assurant la participation).Phosphite s’appuie sur la construction de codes correcteur d’erreurs (ou sur le chiffrement de Vernam)afin de construire un challenge informatique qui permet d’assurer que les pairs te´le´chargent une partie desblocs dans le de´sordre.Phosphite permet ainsi d’assurer que tous les blocs sont disponibles avec plus de 98% de chances quandl’absence de me´canisme d’incitation conduit a` ne meˆme pas pouvoir garantir 50% de chances pour lesderniers blocs.Re´fe´rences[CE07] Niklas Carlsson and Derek L. Eager. Peer-assisted on demand streaming of stored media usingbittorrent-like protocols. In IFIP/Networking, 2007.[Coh03] Bram Cohen. Incentives build robustness in bittorrent. In P2PEcon, June 2003.[CSDP07] Yung Ryn Choe, Derek L. Schuff, Jagadeesh M. Dyaberi, and Vijay S. Pai. Improving vodserver efficiency with bittorrent. In MM, 2007.[PWMC08] Khandoker Parvez, Carey Williamson, Anirban Mahanti, and Niklas Carlsson. Analysis ofbittorrent-like protocols for on-demand stored media streaming. In SIGMETRICS, 2008.

HAL-CentraleSupelec

https://hal.inria.fr/inria-00383172/document

Phosphite : Incitation à la collaboration pour la vidéo à la demande en P2P

Abstract

Similar works

Full text

Available Versions

INRIA a CCSD electronic archive server

HAL-Rennes 1

HAL-CentraleSupelec