THESE DOCTEUR DE L INSTITUT NATIONAL POLYTECHNIQUE DE TOULOUSE

Transcription

1 N d ordre : THESE présentée pour obtenir le titre de : DOCTEUR DE L INSTITUT NATIONAL POLYTECHNIQUE DE TOULOUSE Ecole doctorale : INFORMATIQUE ET TELECOMMUNICATIONS Spécialité : Réseaux et télécommunications Par M. Laurent Lancerica ETUDE DE LA REPLICATION DE CONTENUS MULTIMEDIA POUR LE SUPPORT DE LA QUALITE DE SERVICE DANS LES RESEAUX Soutenue le devant le jury composé de : M. Eric Horlait Président & Rapporteur M. Richard Castanet Rapporteur Mme. Isabelle Buret Examinateur M. Nicolas Douchin Examinateur M. Christian Fraboul Directeur de thèse M. Laurent Dairaine Co-Directeur de thèse

2

3 Remerciements Les travaux présentés dans ce mémoire ont été réalisés à l Ecole Nationale Supérieure d Ingénieurs de Construction Aéronautiques (ENSICA) et au laboratoire de Télécommunication Spatiale et Aéronautique (TéSA). En premier lieu, je tiens à exprimer mes sincères remerciements à Laurent Dairaine, enseignant chercheur à l ENSICA, pour le soutien sans faille et l encadrement de très grande qualité qu il m a fourni pendant toute la durée de ces travaux. Je souhaite exprimer ma profonde gratitude à Christian Fraboul, responsable du département réseaux et télécommunication de l Ecole Nationale Supérieure d Electronique, Electrotechnique, Informatique, Hydraulique et Télécommunication (ENSEEIHT), pour avoir accepté de diriger mes recherches et pour ses conseils avisés. Je suis également reconnaissant à : Monsieur Eric Horlait, professeur des universités à l université Paris 6 Monsieur Richard Castanet, professeur des universités à l ENSEIRB Monsieur Nicolas Douchin, ingénieur d affaires chez CRIL TECHNOLOGY Madame Isabelle Buret, responsable secteur d étude à ALCATEL Space Industrie Pour l honneur qu il m ont fait en participant à mon jury de thèse. Je tiens à remercier en particulier Messieurs Eric Horlait et Richard Castanet pour avoir accepté de rapporter mes travaux. Je tiens aussi à exprimer mes sincères remerciements à toute l équipe d enseignantschercheurs du département informatique de l ENSICA : Yves Caumel, Fabrice Frances, Patrick Sénac, Tanguy Pérennou, Jérôme Lacan et Pierre de Saquis-Sannes. Je remercie également les doctorants et plus particulièrement Luis, Ernesto, Romain, Mathieu, Emmanuel, Jérôme, Florestan, Hervé, Tarek et Ludovic avec qui j ai pu partagé mon bureau ou mes expériences. Je remercie aussi René Espourteau et Bernard Jarlan pour leur disponibilité et leurs capacités à résoudre les problèmes. Je remercie aussi les membres de TéSA et en particulier Emmanuel Chaput, Julien Fasson et Sylvie Eichen pour la bonne ambiance qu ils apportaient tout au long de mes séjours à TéSA. Un grand merci aussi à tous mes amis qui m ont soutenu et encouragé pendant ces années. Mes derniers remerciements sont pour l ensemble de ma famille et de mon entourage. Tout d abord pour mes parents sans qui je ne serais pas arrivé jusque là, ma tante, mon oncle et mes cousines qui sont pour moi comme une deuxième famille. Enfin pour ma moitié Fatima pour son soutien, sa confiance et sa patience pendant les moments de désespoirs, mais aussi surtout pour toute la cheikhbellitude qu elle me fait partager.

4

5 Table des matières Chapitre Introduction GENERALE Contexte La problématique de la qualité de service Contributions Organisation du document Chapitre La qualité de service dans l Internet Introduction La structure de l Internet Le réseau de cœur de l Internet (Internet Backbone) Les différents types de domaine L interconnexion de domaine La notion de qualité de service dans l Internet Le service «Au mieux» (Best Effort) Les besoins en terme de qualité de service Les différentes composantes pour le support de la QoS dans l Internet Gestion de la QoS au niveau de la composante réseau Intserv Services intégrés Diffserv Services différentiés La commutation de label, MPLS - Multiprocotol Label Switching Le routage contraint ou basé sur la QoS - QoS Routing et Constraint based routing L Ingénierie de Trafic Le surdimensionnement Gestion de la QoS au niveau de la composante transport Le Protocole UDP Le Protocole TCP RTP/RTCP SCTP DCCP Autres approches Conclusion du Chapitre Chapitre La réplication de contenu comme support de la qualité de service Introduction La réplication comme alternative aux approches transport et réseau Les réseaux de distribution de contenus (Content Delivery Network CDN) Les motivations et évolutions du transport de contenus Evolution des architectures de réplication Techniques de caching pour le transport de contenus Web Le transport de contenus sur le Web, protocole HTTP Terminologie Architecture de caching Protocoles de caching et réplication Techniques de caching pour le transport de flux vidéo (Streaming) Streaming Streaming live... 43

6 Du caching à la distribution de contenus Principe de Redirection Discussion Les réseaux de peer-to-peer Généralités Architecture et fonctionnement Architecture Algorithme de recherche Partage de données et algorithme de référencement Discussion Modélisation des réseaux de recouvrement Conclusion du Chapitre Chapitre Gestion de la replication de contenus dans les structures de recouvrement Introduction Gestion de la réplication dans un système de peer-to-peer Caractérisation PeerFecT : un système de peer-to-peer utilisant une technique de FEC Les codes à effacements (erasures codes) Principes de PeerFecT Etude de performances Modélisation du cas séquentiel Modélisation du cas parallèle Simulation Résultats dans le cas de téléchargements séquentiels Résultats dans le cas de téléchargements parallèles Discussion Evaluation de la qualité de service dans un réseau de peer-to-peer Simulation Evaluation de la QoS Discussion et application Réplication partielle de contenus dans un CDN Caractérisation Gestion des contenus Etude préliminaire Etude de performances de la réplication partielle Modélisation de l architecture Résultats Discussion Conclusion du Chapitre Chapitre Proposition d une Architecture de replication à gestion de garantie de qualité de service Introduction Description de contenu Définition Description de contenus Aspects liés à la distribution Aspects liés à la réplication Représentation des paramètres Description de l architecture Architecture physique... 97

7 Architecture logicielle Types de services et garanties Paramètres de contrat de service Les types de services Service déterministe Service moyen Service combiné Service orienté coût Service «Au mieux» Conclusion sur les types de services Protocole et fonctionnement Fonctionnement général Protocoles, API Algorithmes Calcul du nombre de répliquas Fonctionnement du module décisionnel Accès aux contenus Conclusion du Chapitre Chapitre MITV : Un système de télévision Multicast Interactive basée sur la réplication Introduction Le système MITV Contexte de l étude Fonctionnement général de MITv Architecture du système MITv Unité de Production Système de communication de MITv Système utilisateur Implémentation et test Discussion Conclusion du Chapitre Chapitre Conclusion Générale Rappels des contributions Perspectives Acronymes Bibliographie Bibliographie de l auteur

8

9 CHAPITRE CONTEXTE INTRODUCTION GENERALE La notion de qualité de service soulève un fort intérêt dans le contexte des réseaux de communication et en particulier de l Internet. L Internet est passé en quelques années de l état d un simple réseau dédié à l enseignement et à la recherche à l état d un réseau très grand public, industriel et commercial. Cette évolution a engendré de nouveaux besoins en termes de qualité de service pour faire face aux contraintes d applications novatrice et aux attentes des utilisateurs finaux. Cette mutation a engendré une augmentation de volume des débits d informations transitant par le réseau, accroissant notablement les problèmes de congestion et, par suite, dégradant la qualité de service (QoS, Quality of Service). Certaines applications, qualifiées d élastiques, comme l , le transfert de fichier, voire même le Web, ne sont que peu affectées par ces manques temporaires de ressources. D autres applications, plus récemment introduites sur le réseau Internet et qualifiées d applications à contraintes temporelles (applications multimédia, temps réel), se satisfont beaucoup moins bien des variations de qualité de service et nécessitent un minimum de ressources de communication pour fonctionner. Les approches classiques pour résoudre ces problèmes sont d une part de réaliser un traitement de bout en bout pour offrir un service de communication en adéquation avec le besoin des applications et d autre part de gérer les ressources de communication au sein du réseau de manière différentiée LA PROBLEMATIQUE DE LA QUALITE DE SERVICE De nombreux travaux de recherche ont mis l accent sur la prise en charge de certains paramètres de qualité de service au niveau des protocoles de transport et du réseau, afin de faire converger le service du système de communication vers un support capable de répondre aux demandes des applications temps réels, multimédia, interactive, tout en continuant à répondre aux demandes des applications informatiques plus traditionnelles. Le protocole TCP est un exemple de telle adaptation, rendant un service fiable et ordonné sur la base du service du réseau IP sans garantie. Cependant, l adaptation de service au niveau transport est limitée à certains paramètres tels que la fiabilité et l ordre. Certaines applications demandent d autres caractéristiques de service, par exemple des performances minimales en terme de délai de bout en bout ou de débit auxquelles d autres approches protocolaires, (par exemple, rtp/rtcp, sctp, etc.), essayent de faire face en adaptant «au mieux» le service réseau disponible. Cependant, comme ces approches se basent sur un service de communication sans garantie, elles ne prémunissent pas l utilisateur du manque de ressources. L autre approche, plus récemment développée dans le contexte Internet, implique très fortement le cœur de l architecture réseau. Elle consiste à gérer de manière différentiée l utilisation des ressources de communication par la couche IP de manière à lui adjoindre des alternatives au traditionnel service sans garantie (best effort) du réseau Internet. Ces approches proposent la gestion différentiée des ressources du réseau. Cependant le déploiement et la mise à l échelle de telles solutions sont des facteurs compliquant notablement la gestion de QoS au niveau réseau. De telles approches peuvent être mises en place dans des environnements réseau restreint tels que des domaines privés. Cependant, des difficultés supplémentaires, d ordre technique et extra technique apparaissent dès qu il s agit d assurer des garanties de bout en bout dans un contexte multi domaines. D autre part, gérer et maintenir des garanties de QoS sur des paramètres tels que le délai de bout en bout, la gigue ou le débit, peut être considérés comme trop coûteux pour certaines applications traditionnelles comme le Web.

10 Dans le contexte actuel, le déploiement global du support de la qualité de service dans l Internet n a toujours pas été opéré. Des solutions «ad hoc» ont consisté à diminuer la charge dans le cœur du réseau, en augmentant, voire en surdimensionnant les capacités des liens. Cependant, ce type d approche ne résout pas tous les problèmes et des dégradations de performances en termes de délai et de gigue peuvent néanmoins apparaître s il existe des points de concentration dans le réseau. Ces situations ont notamment lieu au niveau des points d échange entre les réseaux d opérateurs (peering point), voire au niveau des réseaux d accès. De plus, l augmentation constante des volumes de trafic induisent une course au débit nécessitant une continuelle remise en question du dimensionnement des infrastructures CONTRIBUTIONS L objectif de ce mémoire est de présenter une solution alternative mais aussi complémentaire aux approches traditionnelles de gestion de la qualité de service qui se situent généralement au niveau du réseau ou des protocoles de transport. Au terme de ce travail, quatre points caractérisent les contributions de ce mémoire. Etude de la réplication comme une composante de gestion de la qualité de service Nous avons étudié la réplication comme une solution alternative aux approches traditionnelles de gestion de la qualité de service au niveau du réseau et des protocoles de transport. Cette solution, adaptée uniquement à certains types d applications, est basée sur le stockage distribué du contenu à différents points du réseau, au plus proche des utilisateurs finaux. Cette technique générale de réplication est employée notamment dans le cadre du «caching», ou des réseaux de réplication de contenus (Content Delivery Network, CDN). Dans ces systèmes, des unités de stockage distribuées conservent une copie d un contenu initialement disponible sur un serveur centralisé. Ce contenu est déployé dans une unité de réplication à l initiative d un client placé en aval dans les systèmes de cache ou à priori de leur utilisation, sur toutes les unités de réplication dans les CDN. Cette copie peut alors être substituée au contenu d origine tant que sa validité est assurée. Cette approche conduit à diminuer le trafic dans le cœur du réseau : dans la situation idéale, le cœur du réseau est uniquement sollicité pour la mise à jour des contenus déployés sur les unités de stockage. De la même façon, la réplication de contenus est aussi présente dans les réseaux d homologues à homologues ou de Peer-to-Peer (P2P) qui permettent aux utilisateurs, les «peers», de partager des ressources ou des contenus en s affranchissant du modèle classique client/serveur. Dans le cadre des applications Peer-to-Peer de partage de fichiers, la réplication apparaît comme un résultat de la popularité des contenus téléchargés, plus le contenu est téléchargé plus celui-ci est alors accessible et disponible pour l ensemble des utilisateurs. Il s en suit une meilleure QoS d accès pour ces contenus. Cette technique constitue ainsi une manière de mieux satisfaire les besoins des applications et donc finalement d améliorer la qualité de service rendue aux utilisateurs finaux. Traditionnellement, la technique de réplication est utilisée dans des architectures déployées à grandes échelles dans l Internet. Ce type de structure logique, structure de recouvrement (structure Overlay), repose sur les services offerts par des hôtes IP interconnectés par l architecture réseau. Conséquence du fonctionnement dans les architectures de «caching», la réplication est utilisée dans les CDN de façons à améliorer les performances des utilisateurs finaux, sans pour autant avoir quantifié et défini les impacts de cette réplication en terme de qualité de service. Dans la perspective d une telle étude, nous proposons un modèle qui permet de caractériser les structures de recouvrement de façon à pouvoir y étudier les impacts de la réplication sur la qualité de service offerte à l utilisateur final.

11 Proposition d amélioration de la gestion de la réplication dans des structures de recouvrement Notre deuxième contribution concerne l amélioration et la quantification de l utilisation de la réplication dans les structures de recouvrement. En s appuyant sur les caractéristiques propres à chacune des deux structures de recouvrement (i.e. réseaux de Peerto-Peer et CDN), des solutions pour améliorer les performances d accès aux contenus, mais aussi permettant de quantifier la qualité de service sont proposées. Dans le cadre des réseaux de Peer-to-Peer, cette approche repose sur l utilisation de codes à effacement (notamment utilisés dans les techniques FEC, Forward Error Correction) et permet ici d augmenter la disponibilité d un contenu. L augmentation de cette disponibilité pour tous les «peers» du réseau est étudiée afin de déterminer les gains par rapport aux approches traditionnelles des systèmes de Peer-to-Peer classiques. Dans le cadre des architectures de CDN, une proposition d évolution concernant la gestion des entités de réplication est présentée, en se basant sur le déploiement effectif nécessaire pour obtenir un certain type de garantie. En gérant le nombre de répliquas ainsi que leur placement au sein du réseau de recouvrement selon les besoins réels associés aux contenus, nous montrons qu il est possible de contrôler statistiquement la qualité du service offerte aux utilisateurs tout en optimisant l utilisation de la capacité de stockage répartie offerte par le CDN. Les gains apportés par cette gestion différentiée de la réplication peuvent alors être mis à profit pour le déploiement éventuel d autres contenus. Définition d une architecture de réplication à garantie de qualité de service Notre troisième contribution est la proposition d architecture de réplication gérant la qualité de service. En tirant profit des améliorations obtenues pour chacune des deux types de structures de recouvrement, cette architecture de réplication vient faire l union des résultats obtenus pour les CDN et les réseaux de Peer-to-Peer. Dans ce cadre, la notion de contenu est définie afin de les caractériser et de déterminer quels types sont à même de bénéficier des avantages de la réplication. Pour cela, un modèle de description des contenus utilisant le langage XML est proposé. Les différents modes de communication entre les unités de réplication dans les diverses phases de fonctionnement - configuration, réplication, et distribution - permettent de caractériser complètement cette architecture de réplication à gérant la qualité de service. Etude d une mise en œuvre possible d une architecture de réplication Enfin, une mise en œuvre d une telle architecture de réplication est menée dans le cadre d une étude de cas concernant l utilisation d un service multipoint par satellite pour une application de télévision interactive. Cette étude de cas est issue du projet RNRT DIPCAST. Ce système baptisé MITv, pour Multicast Interactive Television, repose sur le couplage des services traditionnels de diffusion télévisuelle et des services de communication multipoint d un système satellite intégrant une technologie multispot et la commutation embarquée. Plus précisément, l objectif de MITv est de fournir un accès à haute qualité de service aux contenus interactifs associés aux émissions télévisées, tout en minimisant le stockage nécessaire de ces contenus ainsi que les ressources de communication. Ces objectifs sont atteints par l exploitation du service de communication multipoint par satellite afin de déployer les contenus dans les entités de réplication, au plus proche des utilisateurs finaux. Une généralisation de l environnement réseau et la définition d un système communication pour le système MITv a permis de proposer une solution de déploiement d un système de télévision interactive indépendante du réseau de diffusion télévisuelle et compatible avec les architectures réseaux actuellement en place. Une maquette fonctionnelle de ce système a été réalisée et évaluée sur un émulateur réseau reproduisant en temps réel les conditions de fonctionnement du service IP Multicast utilisant la technologie DVB-S/DVB-RCS par

12 satellite. Le fonctionnement global du système MITv et l intérêt de l architecture de réplication ont ainsi été validés et mesurés ORGANISATION DU DOCUMENT Le Chapitre 2 est constitué d un état de l art des méthodes traditionnelles de gestions de la qualité de service dans l Internet. La réplication, solution alternative et complémentaire aux approches basées sur les protocoles de transport et la gestion des ressources réseaux, est par la suite exposée, puis détaillée dans le cadre des architectures de recouvrement de type CDN et réseaux de Peer-to-Peer dans le Chapitre 3. Ceci est complété par la proposition d un modèle qui caractérise les systèmes de recouvrement afin d y étudier la réplication. Ce modèle est ensuite instancié dans le Chapitre 4 pour les systèmes CDN et Peer-to-Peer. Des propositions d amélioration de gestion de la réplication sont détaillées dans le cadre des deux types d architecture de recouvrement et permettent d obtenir des garanties statistiques de QoS. Une architecture de réplication à garantie de qualité de service est définie dans le Chapitre 5, comme l union des résultats d amélioration obtenus pour les CDN et les réseaux de Peer-to-Peer. Le Chapitre 6 propose une étude de cas possible de déploiement d une architecture de réplication dans le cadre d un système satellite couplant les services traditionnels de diffusion télévisuelles et un service IP multipoint. Le chapitre se termine par une discussion générale sur les gains potentiels des architectures réplication en fonction du déploiement géographique de cette dernière. Finalement, la conclusion présente une synthèse de nos différentes contributions, puis expose les perspectives de nos travaux.

13 CHAPITRE 2. LA QUALITE DE SERVICE DANS L INTERNET Résumé Ce chapitre introduit la notion de qualité de service dans l Internet. Dans un premier temps, une description de la structure de l Internet est effectuée pour mettre en évidence les problèmes induits par cette structure. La notion de qualité de service dans l Internet est alors introduite en se basant sur les services actuellement disponibles. Les besoins des applications en terme de qualité de service ainsi que les attentes des utilisateurs finaux, ont conduit à la nécessité de gérer cette qualité de service. Les approches classiques développées dans le cadre de l IETF (Internet Engineering Task Force) et des fournisseurs de services réseaux reposant sur la gestion de la couche réseau sont alors détaillées. Les approches étudiant la gestion de la qualité de service au niveau de la couche transport sont étudiées en s intéressant tout d abord aux protocoles de transport traditionnels de l Internet avant de présenter des solutions protocolaires plus récentes répondant à de nouveaux besoins INTRODUCTION La notion de qualité de service (QoS) soulève un intérêt grandissant dans le contexte de l Internet pour la Recherche comme pour les fournisseurs de service Internet. De nombreux travaux de recherche ont mis l accent sur la gestion de la QoS au niveau des protocoles de transport et du réseau, afin de faire converger le réseau vers un support capable de supporter et gérer les demandes des applications temps réels, multimédia, interactive et les demandes des applications de données plus traditionnelles, comme le transfert de fichier ou l . Cependant la mise en œuvre d une QoS de bout en bout peut paraître complexe à la vue même de la structure sous-jacente de l Internet. La description de cette structure fera l objet du début de ce chapitre. La section suivante définira la notion de QoS dans l Internet et les différents moyens mis en œuvre au niveau des approches réseau et transport pour garantir une QoS de bout en bout avant de conclure sur leurs limitations LA STRUCTURE DE L INTERNET L Internet est constitué des milliers de réseaux interconnectés capables d échanger du trafic de données à l aide du protocole IP. Chaque réseau ayant une autonomie technique et de fonctionnement est nommé «domaine». Les domaines sont interconnectés les uns les autres par des liaisons inter domaines au niveau de points d interconnexion, les «peering point». Pour obtenir un accès à l Internet, un domaine a besoin d un point d interconnexion avec un autre domaine déjà connecté à l Internet Le réseau de cœur de l Internet (Internet Backbone) La structure de l Internet est considérée par la plupart des utilisateurs connectés par un fournisseur d accès à Internet (IAP Internet Access Provider) comme une boîte noire ou un vaste nuage où il est possible de se connecter. En effet, cette structure n est pas une entité définie de façon hiérarchique et fixée, mais est plutôt une structure qui a du évoluer avec les mutations du réseau. L infrastructure sous-jacente qui a permis de connecter les utilisateurs à l «Internet Global» est le réseau de cœur, (Internet backbone ou Core Internet). Sa structure et ses capacités ont radicalement changé durant les années pour passer d une capacité de 56Kbps en 1969 avec le réseau ARPANET, à plusieurs Gigabits par seconde aujourd hui avec l Internet actuel. Le réseau de cœur de l Internet est constitué en majorité par les NAP

14 (Network Access Point) et les NSP (Network Service Provider), les NAP étant des endroits publics où de nombreux domaines échangent leurs trafics et les NSP étant des opérateurs privés qui acheminent et interconnectent les domaines et qui sont connectés à au moins 3 NAP. La topologie de ce réseau de cœur a évolué avec la décision de rendre le réseau Internet public est ouvert au commerce, le faisant passer d une interconnexion de 4 réseaux en 1969 avec ARPANET à une interconnexion de milliers de réseaux regroupés en domaine Les différents types de domaine Ces domaines peuvent être classifiés en fonction de leur taille dans l Internet. Un domaine est généralement constitué par un réseau local (LAN) qui peut être constitué d une seule machine dans le cas d un utilisateur particulier ou d un utilisateur mobile jusqu à plusieurs milliers de machines pour des grandes entreprises ou collectivités. Les réseaux d utilisateur sont connectés à l Internet par l intermédiaire de réseaux d accès. Les technologies disponibles et utilisées pour les réseaux d accès sont nombreuses, par exemple le réseau téléphonique commuté, le RNIS (Réseau Numérique à Intégration de Service), les technologies xdsl (x Digital Suscriber Line), le câble, le GPRS (General Packet Radio Service), voire même des solutions dédiées comme des connexions Frame Relay, ATM (Asynchronous Transfert Mode), souvent nommées liaisons spécialisées. Les Fournisseurs de Service Internet (ISP Internet Service Provider) sont les points de références pour tous les domaines et fournissent tous les types de services possibles pour les utilisateurs particuliers ou entreprises. Ces services vont de l interconnexion basique à l Internet jusqu à la distribution spécifique de contenu. Les ISP les plus classiques peuvent être classés selon les catégories suivantes [2] : ASP (Prestataires de service d application, Application Service Provider) : Les fournisseurs de service d applications qui offrent l accès aux utilisateurs à des applications et au support relatif, par exemple le e-business, l ou même les services de jeux. HSP (Prestataires de service d hébergement, Hosting Service Provider) : Les fournisseurs de service d hébergement, qui offrent des espaces de stockages et les services de publications pour les contenus web des utilisateurs. SSP (Prestataires de service de stockage, Storage Service Provider) : Les fournisseurs de service de stockage sont des xsps qui offrent aux sociétés des solutions de stockage et de connexion permettant d externaliser leurs données et la gestion. WSP (Prestataires de services sans-fil, Wireless Service Provider) : Les fournisseurs de service sans-fil qui offrent un accès sans-fil a l Internet pour les utilisateurs nomades par l intermédiaire de leurs téléphones cellulaires ou de leurs LapTop. NSP (Prestataires de services réseaux, Network Service Provider) : Les fournisseurs de service réseaux, ils sont le compromis entre des sociétés de télécommunications et des sociétés de transports de données. Ils interconnectent les autres types de prestataires. Les fournisseurs de service Internet peuvent aussi être classés en «Tiers» en fonction de la taille de leur réseau et du nombre d abonnés. Ce type de classement est très utilisé aux Etat-Unis. Aussi avec cette vision il existe 3 types d ISP : Tier-1 (mondial ou national) : Ils sont de très grands fournisseurs, ils possèdent des réseaux d envergure nationale ou internationale avec plus d 1 million d abonnés. Il n y a par exemple qu une dizaine de Tier-1 aux Etat-Unis [3]. Le

15 concept de Tier-1 est similaire au concept de NSP bien que ces derniers ne possèdent pas leurs propres abonnés. L ISP Tier-1 possède un accès à l Internet mondial et n a pas besoin d acheter une connexion à un NSP. Tier-2 (régional) : Les ISP Tier-2 possèdent des réseaux d envergure régionale avec un capacité maximale autour de abonnés. Interconnectés à un ISP Tier-1 ils peuvent offrir des services nationaux à leurs abonnés. Tier-3 (local) : Ce sont les ISP les plus modestes, ils offrent des services locaux basiques L interconnexion de domaine Afin de remplir sa fonction de connectivité pour ses utilisateurs, un domaine doit être connecté à d autres domaines. Cette interconnexion de domaine est la topologie même de l Internet. La topologie de l Internet global est loin d être simple car celle-ci est constituée par le maillage assez désorganisé des domaines nationaux, régionaux et locaux. Dans la plupart des cas être connecté à un domaine qui est déjà connecté par un seul point à l Internet suffit pour obtenir la connectivité avec les autres domaines. Cependant dans un souci de fiabilité, de robustesse et de performances certains domaines peuvent posséder plusieurs points de connexion avec différents domaines. Le modèle le plus simple d interconnexion pour représenter la structure de l Internet est un modèle purement hiérarchique comme le montre la Figure Dans ce modèle, les ISP Tier-3 sont connectés aux ISP Tier-2 qui sont connectés au ISP nationaux Tier-1 qui sont eux-mêmes directement interconnectés. Trois scénarii sont alors représentés sur la Figure 2.1. Les utilisateurs E et F sont abonnés au même ISP Local. Lors d une communication entre ces deux hôtes le trafic généré reste donc un trafic local à l ISP. Les utilisateurs A et B sont des abonnés de 2 différents ISP locaux qui sont interconnectés par un ISP régional. Lors d une communication ente A et B le trafic généré traverse donc une zone plus importante et doit ainsi être routé par un nombre plus important de routeurs. Enfin le cas le plus complexe, des utilisateurs C et D qui sont abonnés à des ISP locaux différents où le trafic doit être routé jusqu aux ISP nationaux avant de pouvoir être expédié à l hôte de destination par l intermédiaire de l ISP régional et local correspondant. Dans ce cas même si les deux utilisateurs habitent dans la même ville, le trafic entre eux peut parcourir des milliers de kilomètres. Figure Interconnexion hiérarchique des ISP dans l'internet

16 Le problème principal avec ce modèle d interconnexion hiérarchique est la mauvaise utilisation des ressources entre les ISPs. Le chemin le plus court est celui qui utilise le moins de ressources. En d autres termes, les chemins les plus courts sont les plus efficaces et les moins chers, aussi il faut éviter au maximum les chemins longs. Ces longs chemins nuisent aussi à la qualité de service perçue par les utilisateurs, le trafic étant soumis à des retards et des pertes plus importants et par conséquent des débits plus faibles. Aussi l interconnexion directe des ISP nationaux et des ISP régionaux est de plus en plus commune, comme le montre les lignes en pointillés sur la Figure De la même façon les ISP locaux et les réseaux d entreprise multiplient les connexions à l Internet dans un but d optimisation. L interconnexion de deux domaines implique un provisionnement de bande passante pour chacune des deux parties qui peut être réalisé de deux façons [4]. La première approche repose sur un échange, «Exchange-based interconnection». Cette solution est mise en œuvre par la création d un point d échange ou chaque ISP place un routeur lié à son réseau par un lien dédié. Ces deux routeurs sont alors connectés au niveau liaison, (par un lien Ethernet par exemple), pour faciliter les échanges de paquets. La seconde approche repose sur un modèle d interconnexion directe, «direct circuit connection». Cette méthode est simple à mettre en oeuvre puisqu elle ne nécessite pas l existence d un point d échange par lequel va transiter le trafic. La connexion directe est généralement réalisée par une connexion point à point entre les deux ISP en utilisant une liaison spécialisée louée à un opérateur de télécommunication, par exemple une connexion T1, T3, ATM ou connexion fibre. La plupart des ISP nationaux possèdent aujourd hui plusieurs interconnexions directes avec les autres ISP afin de limiter les risques de congestions. Les accords économiques liés à ses relations entre ISP s apparentent à des relations d échange équitable ou relation de «Peering». Les ISPs offrent l accès à leurs utilisateurs. Ces accords d échanges ne sont bâtis sur la base de la réciprocité, car les ISPs en rapport sont de tailles équivalentes et leurs échanges doivent être à priori équitables en terme de volume de données échangées. L interconnexion de domaine reste encore un sujet ouvert aujourd hui et engendre son lot de problèmes. Les solutions d interconnexion équitable semblaient être une solution pour éviter les NAP et donc les points de congestions, mais ce sont ces dernières qui sont souvent la cause de ces congestions, le trafic essayant de suivre le chemin le plus court, le problème s est déplacé. Les problèmes les plus courants avec l interconnexion de domaines sont les suivants [5][6][7] : Le manque de motivations financières : Le manque d intérêt pour augmenter la capacité d un lien d échange entre deux ISP. Comme l ISP «peer» est potentiellement un concurrent, augmenter la capacité de ce lien d interconnexion peut augmenter les capacités et la qualité du réseau du concurrent. Aussi ces liens sont souvent considérés comme une des sources principales de congestions de l Internet, cependant ceci est difficilement vérifiable car les ISP ne donnent quasiment aucune statistique concernant ces liens d interconnexion. Routage inefficace : Comme les plus importants ISP de niveau 1 ne payent pas pour s interconnecter les uns les autres, la majorité du trafic pour eux n est pas facturée. Aussi afin de minimiser les dépenses associées à l augmentation des capacités de leurs réseaux, les administrateurs de ces domaines ont mis en place des politique de routage de type «patates chaudes», «hot potatoes», visant à ce débarrasser au plus vite du trafic transitant dans leur réseau. Ceci engendre des chemins plus longs pour l acheminement des paquets nuisant potentiellement à la qualité de service.

17 L asymétrie du trafic : généralement au niveau des points d interconnexion, un des deux acteur transmet plus de trafic que l autre. Cette asymétrie avantageant un des deux connecté, l autre ne voudra pas augmenter les capacités du point de connexion afin de ne pas se faire surcharger par un surplus de trafic venant de l autre peer. Problème de route partielle : dans les relations d interconnexion et d échange, les domaines ne fournissent pas totalement leur table de routage. Ce qui ne permet pas de trouver les chemins de transit les plus court (shortest path). Manque de contrat de service, SLA (Service Level Agreement) : les relations de connexion d échange sont basées sur une équité des parties et il n y a pas clairement un client et un fournisseur, aussi n il y a pas clairement de SLA spécifié. Chaque domaine forme une sorte de barrière pour mettre en œuvre des solutions de QoS pour les applications demandant des garanties spécifiques. Les relations de connexion équitable et les NAPs ne sont pas des solutions suffisantes pour faire face à ces demandes. Les NAPs sont la plupart du temps congestionnés puisque généralement la connexion à ces derniers est gratuite. Les NSPs eux aussi, sont souvent congestionnés à cause de la croissance continuelle du volume de trafic échangé. Ainsi les infrastructures déployées aujourd hui dérivent en partie des relations financières et peuvent donc ainsi être considérées comme une des causes pour le manque de QoS dans l Internet [8]. Les échanges de données n étant pas facturés de bout en bout aussitôt que le trafic passe un point d interconnexion de deux réseaux, sa qualité est diminuée à cause de l absence de paiement. Dans le scénario actuel, à la vue de la structure de l Internet, améliorer ou mettre en place des garanties de QoS semble être une chose difficile à réaliser si la solution consiste à établir un garantie de bout en bout entre les clients et les serveurs [9] LA NOTION DE QUALITE DE SERVICE DANS L INTERNET Le réseau Internet est passé en quelques années de l état de réseau confidentiel, plutôt dédié à l enseignement et à la recherche à l état de réseau très grand public, industriel et commercial. Cette mutation a engendré une augmentation de volume des débits d informations transitant dans le réseau. Malgré l évolution des infrastructures, les problèmes de congestion subsistent et la qualité de service perçue par l utilisateur final s en ressent. Une définition possible de la qualité de service est [10] : «La qualité de service est un ensemble de paramètres quantitatifs et qualitatifs qui décrivent les caractéristiques des services désirés par les applications, et les caractéristiques des services fournis instantanément par le système». Le support de la qualité de service consiste à déterminer, contrôler, garantir certains de ces paramètres, et ainsi s engager dans une certaine mesure auprès des utilisateurs du système. Les premières garanties nécessaires à l exploitation des réseaux par les application informatiques furent l ordre et la fiabilité pour pallier aux problèmes liés à la nature même du service «Au mieux» proposé par le protocole Internet et dû aux faibles contraintes sur les moyens physiques et protocolaires de l interconnexion des divers domaines Le service «Au mieux» (Best Effort) Le protocole IP s est imposé comme le protocole d interconnexion de réseaux hétérogènes pour le transfert de données informatiques. Son service est de type «best effort», sans aucune garantie de QoS [11]. Ce type de service, sans engagement et équitable entre les

18 utilisateurs, a permis un développement rapide et flexible de l infrastructure de l Internet. En repoussant la complexité des communications au niveau des extrémités du réseau (les hôtes IP), tout en imposant très peu de contraintes sur les technologies de réseaux sous-jacents, son déploiement à très large échelle a pu avoir lieu sans difficulté majeure [1]. Cependant, l augmentation de trafic due à la croissance rapide de l utilisation d Internet ces dernières années peut néanmoins engendrer des manques de ressources dans le réseau, induisant un accroissement des délais d acheminement et des pertes de données. Certaines applications, qualifiées d élastiques, comme l , le transfert de fichier, voire même le Web, ne sont que peu affectées par ces manques temporaires de ressources. Notons cependant que l utilisateur du Web apprécie de moins en moins un délai de réponse trop long à ses requêtes. D autres applications plus récentes, qualifiées d applications à contraintes de temps (applications multimédia, temps réel), se satisfont beaucoup moins bien des variations de qualité de service. Les approches pour résoudre ce problème sont de gérer les ressources du réseau de manière différentiée et d adapter le service brut du réseau par des mécanismes de bout en bout, de manière à offrir un service plus en adéquation avec le besoin des applications Les besoins en terme de qualité de service Il n existe pas une unique façon de définir la QoS. Les principaux acteurs de la communauté Internet, les utilisateurs, les fournisseurs d accès, les opérateurs de télécommunication et les vendeurs d équipement réseaux tentent de définir et de mettre en place la QoS dans l Internet. Les utilisateurs demandent de plus en plus souvent des services leur assurant des garanties de QoS en corrélation avec l évolution des médias échangés, des ordinateurs et des performances du réseau. Ces nouvelles applications multimédia, telle que la voix sur IP, la visioconférence, la vidéo à la demande nécessitent des garanties de QoS plus importantes que ce qui peuvent être fournies à l heure actuelle par le réseau Internet. Les fournisseurs d accès à Internet et les opérateurs de télécommunication voient eux aussi le déploiement de la QoS comme un moyen de valoriser les capacités de leurs réseaux et ainsi d augmenter notablement leurs profits [12] ceci en faisant converger leurs réseaux de données et leurs réseaux téléphoniques en un seul et même réseau IP à garantie de QoS. Les organismes de standardisation de L Internet ont mis en avant des caractéristiques et ont définis des standards pour permettre une caractérisation des éléments de QoS. Les recommandations de l ITU-T (International Telecommunication Union), les standards du modèle ISO permettent de fixer certains paramètres de communication pour caractériser la QoS : La bande passante : Elle définie la capacité d un système de communication par le débit maximal lors d une transmission de donnée, celle-ci s exprime le plus souvent en Kbps ou kilobits par seconde. Les paramètres temporels : 1- Le délai, il caractérise le temps de transfert d un paquet de donnée depuis l émetteur jusqu au récepteur. Il peut être caractérisé par le temps d aller-retour RTT (round-trip-time). 2- La gigue, elle est définie par la variation du délai entre des paquets de données reçus par le récepteur. Cette variation est notamment due au stockage des paquets de données dans les files d attente des nœuds de communication intermédiaires (routeurs). La fiabilité : elle décrit les contraintes de fiabilité d un flux. Classiquement, la fiabilité peut être totale (pas de perte admise) ou nulle (aucune contrainte de fiabilité). Plus généralement il est possible de définir la fiabilité partielle permettant de perdre certaines informations du flux. Selon les besoins, plusieurs outils de spécifications peuvent être utilisés pour exprimer ce

19 paramètre. On peut par exemple la définir par le biais d un nombre maximum de pertes consécutives, ou un pourcentage de pertes. Une autre technique permet de définir quels objets peuvent être perdus [13]. L ordre : il est associé à la synchronisation logique des unités d informations transmises par l application. Traditionnellement, les contraintes d ordre sont soit totales (aucun désordre admis) ou quelconques (tous les ordres peuvent être admis). L ordre partiel correspond à la possibilité de définir un ensemble de séquences d unités d information admissibles parmi les séquences possibles. Les réseaux de Pétri constituent un exemple de formalisme adapté à la spécification de ce paramètre. Cependant, l introduction et la gestion des la QoS dans les réseaux ne permettront pas de créer de la bande passante. Les techniques de QoS permettent de gérer l utilisation de la bande passante du réseau en fonction des demandes des applications et des utilisateurs. Aucune garantie de QoS ne peut être assurée actuellement dans l Internet traditionnel. Les systèmes et techniques offrant le support de la qualité de service peuvent mettre en œuvre et gérer celle-ci à différents niveaux de l architecture de communication LES DIFFERENTES COMPOSANTES POUR LE SUPPORT DE LA QOS DANS L INTERNET Les principales approches pour mettre en œuvre un service à garanties de QoS dans l Internet se situent à deux niveaux complémentaires. L adaptation de la qualité de service du réseau aux besoins de l application est classiquement située au niveau de la couche transport. Le protocole TCP est un exemple de telle adaptation, rendant un service fiable et ordonné sur la base du service du réseau IP sans garantie ni de fiabilité, ni d ordre. Cependant, l adaptation de service au niveau transport est limitée. S il est possible d offrir un service fiable ou ordonné sans quasiment aucune contrainte sur les réseaux sous-jacents, il est par contre impossible de s engager sur des paramètres de performances tels que le délai de bout en bout ou le débit. Pourtant, les besoins des applications s orientent de plus en plus vers ces caractéristiques de service. Il s agit alors de modifier le service de la couche IP. Ainsi, cette approche, plus récemment développée dans le contexte de l Internet, est supportée au niveau de la couche réseau (et au dessous). Elle consiste à étendre le service de la couche IP pour lui adjoindre des alternatives au traditionnel service «au mieux» et offrir des garanties de service plus importantes. La section suivante va présenter les différentes approches au niveau réseau et transport pour mettre en œuvre la QoS Gestion de la QoS au niveau de la composante réseau Durant les dernières années, plusieurs approches ont été proposées pour traiter la QoS au niveau de la couche réseau [14]. Les approches qui sont détaillées dans cette section sont les principales approches développées dans le contexte de l IETF (Internet Engineering Task Force) : Intserv /RSVP, Diffserv, le surdimensionnement, la gestion de trafic, MPLS, et le routage basé sur la QoS ou basé sur des contraintes (QoS ou constraint based routing) Intserv Services intégrés Le modèle Intserv (Integrated Services) [15] a pour but de fournir des garanties de QoS de bout en bout pour chaque flux individuellement en mettant en œuvre une réservation de ressources dans chaque routeur entre la source et le destinataire. Ce modèle de réservation repose fortement sur celui de la réservation des ressources dans un réseau de télécommunication classique. L'information relative à la QoS désirée est acheminée de

20 routeur en routeur. L approche Intserv définit deux nouvelles classes de service en addition au service «au mieux». En premier lieu, le service garanti (Guaranteed Service) [16] qui offre des garanties de QoS dures. Les limites définies par le service sont fermes (mathématiquement prouvable) pour le délai et le débit des applications temps réel ne pouvant pas s adapter au condition du réseau. Le second service est le service contrôlé (Controlled Load service) [17], il offre des caractéristiques similaires à un réseau IP non congestionné pour le flux de trafic considéré. Le modèle Intserv propose un contexte de travail (Framework) qui met en œuvre quatre composantes : un protocole de signalisation, un contrôle d admission, un classificateur (classifier) et planificateur (scheduler) de paquets. Une application demandant un service garanti ou contrôlé doit tout d abord déterminer un chemin et effectuer une réservation de ressources sur le chemin déterminé avant de pouvoir transmettre ses paquets. Le contrôle d admission est responsable de la prise de décision s il y a suffisamment de ressources pour accorder la demande. Lors de la phase de transfert, chaque fois qu'un paquet Intserv parvient à un routeur, le classificateur identifie ce paquet et met celui-ci dans la file d'attente spécifique avant de le réexpédier. Finalement, le planificateur de paquet déterminera le moment adéquat correspondant à la QoS désirée pour envoyer le paquet. Figure Fonctionnement de RSVP Bien que n importe quel protocole de signalisation puisse être utilisé avec l approche Intserv, le protocole RSVP (Resource Reservation Protocol) [18] s est imposé comme un standard. RSVP est un protocole soft-state orienté récepteur. Il est basé sur l échange de deux messages entre l émetteur et le récepteur : le message PATH et le message RESV comme le montre la Figure L émetteur envoi un message PATH au destinataire en spécifiant les caractéristique du trafic. Chaque routeur intermédiaire situé le long du chemin transmet le message PATH au suivant en fonction de sa table de routage. Après avoir reçu un message PATH chaque récepteur doit répondre avec un message RESV pour effectuer la réservation de ressources s il est en mesure d accepter celle-ci. Chaque élément le long du chemin peut accepter ou rejeter le message RESV en fonction du contrôle d admission. Si une demande est rejetée, un message d erreur est envoyé à l émetteur. Dans le cas contraire, les ressources sont réservées et le RESV est transmis suivant le même chemin. La mise en œuvre d une telle réservation de ressources implique la mise en place d un système d information permettant de connaître chaque flux et ses besoins. Pour faire face au problème d instabilité de routage dans l Internet, RSVP est un protocole soft-state, les réservations effectuées par celui-ci ne sont valables que pour une durée déterminée et sont automatiquement annulées si elle ne sont pas réactivées. En conséquence, l émetteur doit régulièrement envoyer des messages PATH pour maintenir les réservations actives. L approche Intserv représente une avancée importante dans le monde de l Internet. Elle permet de rapprocher le monde des télécommunications et de l Internet en essayant de le faire correspondre au modèle téléphonique. Un changement systématique des routeurs est quasi nécessaire pour la mise en place de cette approche (bien qu aujourd hui de nombreux routeurs possèdent le support RSVP). De plus, deux points critiques sont soulevés par cette

21 approche, tout d abord un nombre trop important d informations est nécessaire pour maintenir les réservations actives et deuxièmement le nombre de messages de signalisation échangés est très important pour obtenir des garanties au niveau de chaque flux. En conséquence, si l on trouve quelques fois Intserv au niveau de réseaux de taille réduite (p.ex., LAN ou MAN), Intserv n a pas été implanté dans le cœur d Internet car ce dernier constitué de milliers de routeurs très haut débit demanderait un maintient d information par routeur considérable. Cette approche ne présente donc pas une solution simple à mettre en œuvre dans l Internet actuel Diffserv Services différentiés L approche des services différentiés (Diffserv) a été proposée pour palier au manque d adaptabilité et à la complexité du modèle Intserv. Aussi, aucune information d état et message de signalisation le long du chemin ne sont nécessaire pour mettre en œuvre cette approche. Le cœur de l approche Diffserv repose sur la division du trafic en différentes classes de service dont le traitement est différent pour chaque classe. Diffserv vise à simplifier le déploiement et l évolution de l approche en permettant l agrégation de flux ayant un même comportement (BA, Behavior Aggregate), permettant de provisionner les routeurs pour de tels agrégats. De plus, les fonctions des routeurs de bordure et des routeurs de cœur sont bien définies et distinctes, les routeurs de bordure échangent les paquets entre domaines et les routeurs de cœur ne sont responsables que des connexions internes. Un domaine implémentant Diffserv est appelé un domaine Diffserv (DS). Figure L'architecture Diffserv Les routeurs effectuent un traitement différent pour les paquets, en fonction de leur BA, nommé le comportement par étape (PHB Per Hop Behavior). Le PHB des paquets est déterminé par un marquage Diffserv particulier (DSCP Diffserv Codepoint) indiqué par le champ DS (ancien TOS dans l entête IPv4 ou champ de classe de trafic dans l entête IPv6). Les routeurs de bordure conditionnent le trafic et peuvent maintenir des informations par flux. Le conditionnement du trafic est nécessaire pour assurer que le trafic sortant et entrant respectent les conditions (ou limites) de profil prédéfinies. L approche Diffserv suppose que les domaines DS ont précédemment négocié un SLA (Service Level Agreement) qui définit les conditions d échange des paquets entre les deux domaines et qui permet de configurer les routeurs de bordures. Les routeurs de cœur examinent seulement le champ DSCP des paquets IP et appliquent le PHB correspondant, induisant ainsi le traitement voulu pour l envoi des paquets. De même que pour l approche Intserv les garanties obtenues avec Diffserv le sont pour un seul sens de communication comme le montre la Figure Un BA est défini comme un agrégat de paquets ayant le même DSCP allant d un même domaine vers le même autre domaine DS. Le volume de paquets d un BA peut fluctuer en fonction des demandes des applications. Les routeurs repartissent les ressources pour les BAs en fonction des PHBs définis. La forme la plus simple de PHB peut par exemple être une allocation d un pourcentage de la bande passante.

22 Deux principaux PHB ont été définis avec Diffserv : Le service EF (Expedited Forwarding) [19] et le service AF (Assured Forwarding) [20]. De plus Diffserv définit un PHB pour le service «au mieux» et huit PHBs pour une rétro compatibilité [21]. Le service EF fournit des garanties de QoS strictes pour les applications sensibles aux variations de délai dans le réseau. Cette approche est le service permettant d obtenir le délai, la gigue les plus faibles ainsi qu une bande passante garantie sur le réseau. Cependant comme l approche Diffserv traite le trafic comme un agrégat de flux, même le comportement EF ne permet pas d obtenir des garanties de QoS absolues pour tous les flux d un même agrégat. Le service AF est en réalité un groupe de 12 PHBs, 4 classes AF et 3 niveaux de priorité de suppression de paquets, drop precedence. Les classes AF ne sont pas associées à des niveaux de garanties de QoS. Le traitement des paquets AF dépend complètement de la capacité réservée sur la liaison. Quand une classe AF obtient une ressource de bande passante importante, elle peut être utilisée pour le déploiement d applications multimédia, dans le cas contraire, avec un manque de ressources les paquets peuvent être traités de façons équivalentes ou pire que les paquets du service «au mieux». Trois niveaux de drop precedence sont définis pour les classes AF qui permettent de déterminer quels paquets seront supprimés en cas de congestion de réseau. En terme de services offerts, la différence entre Intserv et Diffserv est qu Intserv fournit un service de bout en bout garantissant des ressources acquises pour chaque flux à l aide du protocole RSVP, alors que Diffserv fournit un service par étape (per hop) pour un agrégat de trafic basé sur l introduction de priorités de paquets, demandant un dimensionnement de ressource préalable pour obtenir le résultat escompté. Une des questions soulevées par l utilisation de Diffserv est comment construire un service de bout en bout et en quantifier sa QoS avec la connaissance des PHBs et des mécanismes de conditionnement de trafic. Les relations entre domaine n étant pas toujours sans problèmes, la connaissance réelle du traitement des paquets intra domaine sera difficile à déterminer. Malgré le souci de simplicité de l approche Diffserv celle-ci n est toujours pas déployée globalement dans l Internet, elle demande toujours un déploiement de routeur et surtout une définition claire des PHBs et des traitements intra domaine [22] La commutation de label, MPLS - Multiprocotol Label Switching Multiprotocol Label Switching (MPLS) [23] est un système d expédition de paquets (forward scheme) évolué ou la destination suivante est déterminée par une étiquette de longueur fixée. Ceci représente une cassure avec le monde de l Internet classique traditionnellement basé sur l utilisation des adresses IP pour déterminer la retransmission. Le protocole IP est un protocole sans connexion : l envoi d un paquet entre la source et le destinataire, chaque routeur doit prendre une décision individuelle en déterminant le nœud suivant à partir de sa table de routage et de l adresse du paquet. MPLS permet la création d étiquettes et de chemins commutés (LSP) qui assure un contrôle plus évolué sur les paquets traversant un domaine. Quand un paquet entre dans un réseau MPLS, il reçoit une entête spécifique de 32 bits contenant parmi d autres informations, une étiquette de 20 bits et un champ expérimental de 3 bits (EXP, permettant d assigner des classes de services aux paquets). L entête MPLS est inséré entre la couche 2 et la couche 3 ou alors est mappé sur une entête spécifique au niveau de la couche 2 par exemple le champ VCI/VPI de ATM. Différents critères sont utilisés pour déterminer le label d un paquet. Les paquets sont groupés en classes d équivalence (Forwarding Equivalence Classes) en utilisant la combinaison de plusieurs critères comme l entrée de la table de routage, l interface entrante,

23 le PHB Diffserv. Les paquets d une même classe sont alors expédiés suivant le LSP correspondant au label. MPLS n'est pas directement une technique de mise en oeuvre de la QoS. MPLS est utilisé principalement pour mieux gérer le trafic d un réseau dans le cadre de l ingénierie du trafic. Cependant, la combinaison de MPLS avec Diffserv et le routage contraint (Constraint Based Routing), forment une stratégie intéressante pour provisionner des ressources et de la QoS dans l'internet [24] Le routage contraint ou basé sur la QoS - QoS Routing et Constraint based routing Le routage dans l Internet repose sur la connectivité, cela en cherchant les routes existantes pour le service best effort. Les protocoles de routages actuels, comme OSPF pour l intra domaine et BGP pour l inter domaine détermine toujours le chemin de plus court (shortest path) basé sur des métriques simples comme souvent le nombre de hop. Ces protocoles sont toujours capable de déterminer le chemin le plus court même si celui-ci n est pas le plus approprié. Aucun chemin alternatif ne sera étudié même s il pouvait acheminer des flux de trafic avec des contraintes de QoS particulières. Le routage basé sur la QoS, QoS routing (QoSR) [25] est un mécanisme de routage qui choisi le chemin à suivre par un flux en fonction de la connaissance des ressources disponibles sur le réseau et des caractéristiques du flux en terme de délai et débit. Ainsi, le QoSR peut préférer un chemin plus long et non congestionné. Un routeur supportant le routage contraint par la QoS possède une table de routage contenant des informations complémentaires comme le taux de saturation des routes en fonction de critères de QoS. Des protocoles QoSR spécifiques doivent être utilisés pour échanger des informations de QoS sur les routes. Des extensions de BGP et OSPF intégrant des tables de routage comprenant une entrée étendue avec les conditions actuelles du réseau selon des critères de QoS et, comme il peut y avoir plusieurs chemins pour la même destination avec différentes QoS, plusieurs entrées pour la même destination sont alors ajoutées. Le routage contraint (avec contrainte), Constraint-Based Routing (CR) est un concept qui permet de calculer des routes en fonction de critères multiples [26]. Une des ces contraintes peut être la QoS, aussi le CR est un sur ensemble qui englobe le QoSR. Le CR est une évolution du QoSR mais l un et l autre sont parfois utilisés comme synonymes. Le routage contraint peut être utilisé par exemple dans MPLS pour former les chemins LSP en fonctions de différentes contraintes incluant la QoS. Le CR et le QoSR sont des approches orthogonales aux études classiques sur la QoS de bout en bout. Ces approches permettent de trouver des chemins en fonction de contraintes de QoS. Elles ne garantissent pas que les paquets seront toujours routés par le même chemin et ne fournissent aucune garantie de QoS sur ces chemins par opposition à Intserv ou Diffserv. L utilisation de ces approches est surtout développée dans le routage intra domaine. Cependant le QoSR et le CR peuvent être des approches associées à Diffserv et Intserv pour un déploiement effectif de la QoS dans l Internet L Ingénierie de Trafic L ingénierie de trafic (Traffic Engineering, TE) traite de l évaluation de performance et de l optimisation des réseaux IP opérationnels. Le TE peut être défini comme le moyen «d arranger les flux de trafic» dans le réseau afin d éviter les congestions. Un des buts du TE est d offrir un réseau efficace et fiable tout en optimisant en même temps l utilisation des

24 ressources et les performances en terme de trafic. En changeant soigneusement la route de certains paquets dans le réseau, il est possible d obtenir des garanties de QoS pour certains flux de trafic particulier. Comme nous l avons mentionné dans le paragraphe , les protocoles de routage cherchent le plus court chemin. Ce dernier peut pourtant, pour une paire donnée de sources et récepteurs inclure des goulots d étranglements en raison des caractéristiques du réseau. La plupart du trafic étant acheminé par ce chemin, celui-ci devient facilement congestionné. Un aspect négatif est visible lorsqu un flux est routé sur un chemin qui ne possède plus les capacités suffisantes pour lui offrir un traitement correct. Ces deux aspects représentent les domaines d action du TE : Gestion des ressources : ceci en tenant compte de la charge des différents chemins et en évitant d avoir des liens surchargés et d autre sous utilisés. Optimisation du trafic : ceci comprend la gestion de certains flux afin de leurs fournir des contraintes de QoS meilleurs comme un délai plus faible et un débit plus important. Le TE peut être mis en œuvre de différentes façons, soit en configurant de façon manuelle les routes, en utilisant des liens particuliers (configuration de circuit virtuel VC ATM), en utilisant des poids différents pour les protocoles de routage, en déterminant des chemins avec un QoSR. Le TE peut être utilisé sur un réseau de type best effort comme sur un réseau à garantie de service de type Intserv ou Diffserv. En d autres termes, le TE peut être vu comme un moyen d optimiser et gérer au mieux les ressources du réseau Le surdimensionnement Les technologies précédemment citées pour mettre en œuvre la QoS sont basées sur la gestion des ressources du réseau. Cependant l utilisation de telles technologies conduit inévitablement à une augmentation de la complexité interne du réseau (en matière de signalisation, de traitement, etc.) ce qui va à l encontre des fondements de l Internet qui voulait repousser la complexité dans les hôtes terminaux en laissant le réseau le plus simple possible. Le surdimensionnement ou Over-provisioning [27] est une approche pragmatique qui propose simplement d offrir une bande passante suffisante pour fonctionner, tout en conservant une politique de service «au mieux» (best effort). Cette solution consiste donc à augmenter les capacités des liens lorsque ces derniers semblent congestionnés. Le raisonnement repose sur le principe que si l on maintient une charge de réseau faible, les paquets ne seront jamais jetés et il n y aura pas d augmentation de délai car les files d attentes seront toujours quasiment vides. Ainsi une bonne QoS sera réalisée implicitement. Les avancées technologiques sur la fibre optique et le DWDM (Dense Wavelength-Division Multiplexing) ont fait croître la bande passante disponible et baisser le coût de transfert des données par unité de volume laissant penser que le surdimensionnement peut créer une bande passante toujours supérieure aux besoins. La nécessité de mécanisme pour gérer la QoS même dans les réseaux à très hauts débits est bien réelle, l augmentation constante des volumes de trafic induisent une course au débit nécessitant une continuelle remise en question du dimensionnement des infrastructures. Même si le surdimensionnement semble être une solution simple et réaliste, cette approche est considérée par beaucoup comme peu efficace car tous les problèmes de réseaux ne peuvent pas être résolus en augmentant la bande passante. En effet, les demandes des utilisateurs et les nouvelles applications ne cessent d augmenter leur besoin en terme de bande passante. Aussi le surdimensionnement ne permet pas seul de gérer et d obtenir des garanties de QoS.

25 Les études pour supporter la QoS au niveau du réseau permettent de conclure que le modèle «au mieux» sera encore un bon moment le modèle prédominant dans l Internet. Outre la complexité de déploiement des solutions de QoS basées sur le réseau, il n existe toujours pas de standard ou d accord pour obtenir des garanties de QoS de bout en bout avec le modèle Diffserv. Les autres méthodes de gestion, comme la commutation de label MPLS, l ingénierie de trafic, etc., augmentent la rapidité de traitement des paquets mais ne fournissent aucune garantie de service. Les études menées au niveau des protocoles de transport elles aussi essayent de fournir des garanties de QoS Gestion de la QoS au niveau de la composante transport Comme évoqué au début du chapitre, la gestion de la qualité de service est également liée à la couche transport. Celle-ci adapte notamment le service brut du réseau aux besoins des applications. L architecture Internet traditionnelle offre la possibilité aux applications de choisir entre deux principaux services : le service point à point en mode datagramme non connecté par le biais du protocole UDP et le service point à point fiable en mode flux d octets connecté basé sur le protocole TCP. Cette section va présenter les protocoles de transports traditionnels de l Internet et les nouvelles approches pour obtenir des garanties de QoS Le Protocole UDP Le service best effort du protocole IP a été adapté par l intermédiaire du protocole de transport UDP, (User Datagram Protocol) [29], pour fournir aux applications un service de communication en mode non connecté. Le protocole UDP n offre aucune garantie en terme de fiabilité ou d ordre. Le service de transport n inclut pas de phase de connexion ni de mécanisme de contrôle de congestion. Sa somme de contrôle (Checksum) lui permet cependant d écarter les datagrammes UDP comportant des erreurs bit dans les données. Le protocole UDP peut prendre en charge des communications point à point et point à multipoint. Sa simplicité lui permet d être utilisé dans le cadre d application ayant besoin de communication à faible délai, sans pour autant avoir de contraintes importantes au niveau des pertes. Le protocole UDP offre aussi un service de multiplexage permettant aux applications de pouvoir transmettre différents flux de données en utilisant la même adresse IP Le Protocole TCP Le protocole TCP (Transmission Control Protocol) [28] adapte le service brut du protocole IP pour fournir aux applications un service de communication point à point en mode connecté. Du point de vue de l application, TCP offre un service avec connexion assurant une fiabilité et un ordre total, i.e. aucune perte de paquets, au prix quelque fois coûteux de retransmissions. Comme le protocole UDP, le protocole TCP offre un service de multiplexage. Le protocole TCP comporte de plus un mécanisme de récupération d erreur pour les paquets corrompus ou perdus mis en œuvre par l intermédiaire de retransmissions. TCP implémente aussi un mécanisme de contrôle de flux et un mécanisme de contrôle de congestion afin d éviter respectivement une saturation des files d attentes (buffer) de réceptions et de congestionner le réseau. Les mécanismes de contrôle de congestion, de contrôle de flux, de correction d erreurs, peuvent introduirent un délai de transmission et une variation du débit. Ceci peut être gênant dans le cadre d application multimédia ou temps réel. Pour cette raison, d autres protocoles ont été construits au dessus d UDP (par exemple RTP/RTCP) pour obtenir des contraintes compatibles avec les attentes d applications comme la visioconférence.

26 RTP/RTCP Le protocole de transport RTP (Real-Time Transport Protocol) [35] a été conçu pour faire face aux besoins des applications nécessitant des transmissions de données temps réel, telle que l audio, la vidéo ou les simulations de données. Ce protocole de transport repose sur un service réseau IP unicast pour la communication point à point ou IP multicast pour les communications multipoints. RTP est doté en complément d un protocole de contrôle RTCP (Real-Time Control Protocol). RTCP permet de vérifier la délivrance des paquets de données aux récepteurs ainsi qu un ensemble de fonctionnalités d identification et de contrôle sur les flux de données. RTP et RTCP ont été conçus pour être indépendants des protocoles sous jacents. RTP permet une identification des données du flux en introduisant des informations au niveau d une entête RTP, comme le type de profil (format audio ou vidéo), un numéro de séquence dans le flux et une estampille temporelle. Les informations contenus dans cette entête permettent aux applications réceptrices de détecter et de récupérer des erreurs, de ré ordonner un flux le cas échéant ou alors de détruire des données si celle-ci ne sont plus valides. De plus les estampilles temporelles permettent aussi d effectuer des opérations de synchronisation entre différents flux provenant d un même émetteur. RTCP fournit un ensemble de paquets générés par l émetteur et les récepteurs permettant de déterminer la QoS effective au niveau de l application réceptrice. RTP utilise les concepts d ALF «Application Level Framing» (ALF) [30]. Ces concepts sont basés sur un principe commun : la prise en compte par le système de transport des propriétés intrinsèques des données échangées (les ADU ou «Application Data Unit»). Les protocoles basés sur les architectures ALF adaptent l application aux caractéristiques du réseau. Bien qu il soit défini comme un protocole de transport RTP ne fournit pas un service transport complet et les TPDU (Transport Protocol Data Unit) doivent être encapsulées dans un autre protocole de transport (UDP ou TCP). La plupart des implémentations sont basées sur UDP dans un souci de réduction du délai introduit par TCP pour les applications multimédia comme le streaming. Néanmoins, il existe des implémentations de RTP au dessus de TCP notamment motivées par le passage des barrières de sécurité comme les firewalls. Dans ce cas, RTP est mis en oeuvre au niveau applicatif sous la forme d une bibliothèque de fonctions et non dans le noyau du système d exploitation. RTP/RTCP ne possédant pas de contrôle de congestion et les applications utilisant le protocole RTP/RTCP étant susceptibles de consommer une bande passante importante (transport de données vidéo et/ou données audio) les concepteurs recommandent la mise en place de mécanisme de contrôle pour ne pas détériorer la QoS des autres applications utilisant le même réseau SCTP SCTP (Stream Control Transmission Protocol) [36] est un protocole de transport fiable reposant sur un concept multi-flux (stream). Il offre un service de transport fiable ordonné et orienté session entre un émetteur et un récepteur. Les capacités de multi homing de SCTP permettent d utiliser plusieurs adresses IP. Ce service permet d augmenter la probabilité de survie d une connexion SCTP en cas de problème sur le réseau et donc un routage par des chemins alternatifs des unités de données en cas de faille sur un réseau. De plus comme TCP, SCTP est un protocole adaptatif qui permettra de réduire l envoi des données en fonction du taux de congestion du réseau. Par opposition au protocole TCP qui est orienté flux, le protocole SCTP est lui orienté message. Les messages SCTP sont composés d un header commun et de segments de

27 données. Plusieurs segments de données peuvent être multiplexés dans un même paquet à concurrence de la taille maximale du MTU (Maximum Transmission Unit). Chaque segment de données peut comporter des données utilisateurs ou des informations de contrôles. SCTP permet grâce à son service multi-flux de partitionner les données applicatives dans différents flux d une même session pouvant être délivrées dans des séquences indépendantes, ainsi la perte d un message dans un flux affectera seulement celui-ci et n affectera pas les autres flux. SCTP n impose aucune contrainte d ordre entre les différents flux. Ceci permet un service ordonné au niveau intra-flux et désordonné au niveau inter-flux. Les applications acceptant un service de transport à ordre partiel peuvent alors tirer les avantages du service multi-flux de SCTP, cependant le caractère totalement fiable de SCTP ne permet pas de lui assurer une compatibilité avec les applications multimédia ayant de fortes contraintes de bande passante, délai et gigue DCCP DCCP (Datagram Congestion Control Protocol) [37] offre un service de transport non fiable pour les flux de datagrammes, le tout régulé par un mécanisme de contrôle de congestion. DCCP se destine aux applications utilisant actuellement le protocole de transport UDP et qui n intègrent pas de mécanisme leur permettant de réguler leur flux selon les conditions du réseau. DCCP veut tirer les avantages de UDP et d un contrôle de congestion compatible avec TCP. Ces applications ont des contraintes temporelles (par exemple la diffusion d un flux multimédia) mais ne peuvent pas se satisfaire d un service totalement ordonné et totalement fiable comme le propose le protocole TCP qui induirait une chute de la QoS perçue par l application. Le côté non fiable du protocole DCCP peut lui aussi poser des problèmes pour certaines applications, ainsi les concepteurs du protocole recommandent une mise en place de mécanisme de récupération d erreur au niveau applicatif le cas échéant Autres approches Certains profils d applications ne se satisfont pas de ces services basiques offerts par TCP et UDP. L alternative est donc de créer de nouvelles architectures, plus adaptées aux caractéristiques et besoins des nouvelles applications. Dans cet esprit, des protocoles de transports adaptatifs comme POC (Partial Order Connections) [31][32]et FPTP (Fully Programable Transport Protocol) [33] ont été proposés. Ces deux protocoles suivent comme RTP les concepts ALF. POC a été mis en œuvre sous la forme d un service et protocole de niveau transport qui adapte le service de communication au plus près des besoins de l application, alors que les protocoles basés sur les architectures ALF adaptent l application aux caractéristiques du réseau. Le protocole FPTP quant à lui essaye de prendre en compte aussi bien les besoins de l application que les capacités sous jacentes du réseau. Ces protocoles (i.e. POC et FPTP) offrent un paramétrage de la connexion évolué. Il permet notamment d offrir un contrôle fin de la fiabilité et de l ordre partiel selon plusieurs techniques complémentaires. L utilisateur peut spécifier le niveau de fiabilité souhaitée, i.e. le taux de pertes admissible ainsi que le degré d ordre désiré. D autres techniques de spécifications permettent de décrire une fiabilité par unité d information, plus adaptée à des profils d applications tels que la vidéo [34]. Ceci rend ces approches plus flexibles et plus simples d utilisation que le concept ALF qui demande un développement «ad hoc» pour chaque application. L étude des protocoles de transport traditionnels et de nouvelle génération montre que ces derniers ont été conçus pour prendre en compte un sous ensemble des contraintes de qualité de service des applications multimédia. La plupart se concentrent sur la mise en œuvre

28 du contrôle de congestion afin de préserver les ressources du réseau. Aujourd hui il n existe pas de protocole de transport capable d offrir un service garantissant des contraintes de délai, pertes, gigue, débit CONCLUSION DU CHAPITRE Dans le contexte actuel, le déploiement global du support de la qualité de service dans l Internet n a toujours pas été opéré. Le but de ce chapitre était de montrer la complexité de la structure de l Internet actuel et de mettre en avant les différentes approches actuelles aussi bien au niveau réseau et transport pour la gestion de la QoS. L interconnexion de domaine ayant opté pour différentes technologies comme support de QoS peuvent aboutir à un service aussi bon que le traditionnel service «au mieux» (best effort). Même si de nombreux travaux ont été réalisés sur les approches de gestion de la qualité de service au niveau de la composante réseau, un service de garantie de QoS de bout en bout n est pas prêt à être déployé. Le service «au mieux» sera encore prédominant pendant quelques années dans l Internet. Les approches transport quant à elle, ne permettent pas de tenir compte de l ensemble des caractéristiques des média considérés, ou sont alors trop liée à un profil de média comme RTP pour les flux audio ou vidéo. Les solutions les plus adaptatives comme l approche FPTP permettant de tenir compte des caractéristiques de l application et des contraintes réseaux sont elles coûteuses en terme de déploiement ou impliquent des difficultés de mise à l échelle. D autre part, gérer et maintenir des garanties de QoS sur des paramètres tels que le délai de bout en bout, la gigue ou le débit, peut être considérés comme trop coûteux pour certaines applications traditionnelles comme le Web. Le chapitre suivant va présenter la réplication comme une alternative à la gestion de la QoS au niveau transport et réseaux en se basant sur les propriétés des structures overlay comme les CDN (Content Delivery Network) et les réseaux de Peer-to-Peer (P2P).

29 CHAPITRE 3. LA REPLICATION DE CONTENU COMME SUPPORT DE LA QUALITE DE SERVICE Résumé Dans ce chapitre, une solution alternative aux approches traditionnelles de gestion de la qualité de service dans l Internet va être présentée. Les principes de base de cette solution basée sur la réplication d information vont être mis en avant dans leurs utilisations classiques dans les structures de recouvrements. Les structures de recouvrement les plus connues étant les Content Delivery Network et les réseaux de Peer-to-Peer, ces dernières seront alors détaillées. Les motivations, les principes ainsi que les protocoles de fonctionnement des CDN sont caractérisés pour les différents types de média pouvant tirer profit de ce type de structure. De la même façon, les systèmes de Peer-to-Peer sont eux aussi détaillés. L étude des CDN et réseaux de Peer-to-Peer a permis de proposer un modèle qui permet de caractériser les structures de recouvrement afin d y étudier l impact de la réplication sur la qualité de service. Ce modèle sera utilisé pour essayer de fournir des solutions afin d améliorer les performances ou la gestion de certains types de structure de recouvrement INTRODUCTION Afin de pallier à l augmentation croissante du trafic et dans un souci d obtenir une meilleure qualité de service, des solutions alternatives aux approches réseaux et transports ont vu le jour. Une de ces techniques est le stockage distribué du contenu à différents points dans le réseau. Ce concept consiste à distribuer dans une unité de stockage une copie d un contenu initialement disponible sur un serveur centralisé. Cette copie peut alors être substituée au contenu d origine tant que sa validité est assurée. Cette approche conduit à diminuer le trafic dans le cœur du réseau : dans la situation idéale, le cœur du réseau est uniquement sollicité pour la mise à jour des contenus déployés sur les unités de stockage. Ce concept a notamment été mis en oeuvre dans le cadre du caching depuis de nombreuses années, avant d être mise à nouveau à profit dans des systèmes P2P (Peer to Peer) ou des CDN (Content Delivery Network). Ces nouveaux systèmes, P2P et CDN, font parti des structures de recouvrement (Overlay Network) qui sont mis en place au dessus des fonctionnalités du réseau existant. Les structures de recouvrement sont des réseaux logiques reposant sur les services offerts par des hôtes IP interconnectés par l architecture réseau. Ils constituent une manière de mieux satisfaire les besoins des applications et donc d améliorer la qualité de service rendue aux utilisateurs finaux. Ce chapitre présente en premier lieu les principes et avantages de la réplication pour améliorer le support de la QoS. Les sections 3.3 et 3.4 présenteront en détails deux architectures de recouvrement particulières mettant en œuvre la réplication, les CDN et les réseaux de P2P ainsi que leurs faiblesses pour offrir des garanties de QoS. Finalement, un modèle permettant de formaliser une structure overlay sera proposé en vue de l optimisation de différents exemples comme les CDN et les réseaux de P2P LA REPLICATION COMME ALTERNATIVE AUX APPROCHES TRANSPORT ET RESEAU Une solution alternative pour augmenter les performances d accès à des contenus en terme de qualité de service peut être basée sur la technologie de réplication. D un point de vue général, la réplication consiste à distribuer un contenu au niveau de serveurs disséminés sur le

30 réseau, au plus près des clients finaux. L objectif est ici d utiliser de préférence le contenu répliqué plutôt que l original. L accès des clients finaux à l unité de réplication évite d utiliser les ressources du réseau nécessaires pour contacter le serveur original et rapatrier le contenu sollicité. De plus, comme le contenu est déposé à proximité des utilisateurs, les temps de réponse et les débits d accès à ces données sont optimisés. La réduction du chemin entre le client et le lieu de stockage ne peut qu augmenter la qualité de service ressentie par l usager final. Cette approche conduit à diminuer le trafic dans le réseau : dans le meilleur des cas, le réseau est uniquement sollicité pour la mise à jour des unités de stockage. D autre part, elle augmente le nombre d utilisateurs pris en charge par une distribution sur plusieurs unités distribuées de la charge totale du service. Il existe deux principales applications des techniques de réplication de contenu [38]. La première, concerne l utilisation des serveurs de cache reposant sur la copie des éléments accédés par un utilisateur. Le «caching» d un contenu s effectue sur un modèle de type «pull». Lorsqu une requête pour un contenu est effectuée par un utilisateur, le serveur de cache l intercepte, détermine si le contenu est présent localement et le délivre à l utilisateur le cas échéant. Dans le cas contraire, il effectue une requête jusqu au serveur original (elle-même éventuellement interceptée par un serveur cache en amont) puis effectue une copie locale en exploitant les informations de l entête HTTP (Hypertext Transport Protocol) pour déterminer la possibilité de cacher ce contenu. La seconde application des techniques de réplication concerne le pré-chargement (prefetching) de contenu au sein de réseaux de serveurs, sur un modèle de type «push». Ce système est déployé sous le terme général de Content Delivery Network (CDN) [39]. Les CDN sont des réseaux de serveurs distribués offrant leurs services à des fournisseurs de contenu permettant d augmenter le nombre d utilisateurs et la QoS globale d accès au contenu en répliquant les données aux différents points de présence. Ils doivent gérer la maintenance du réseau et des serveurs pour délivrer les contenus stockés dans les meilleures conditions possibles. Figure Modèle d'un système de réplication La Figure illustre le fonctionnement d un système mettant en œuvre la réplication. Le contenu original est initialement présent dans l unité source. Par rapport à l unité de réplication, la partie amont ou réseau de réplication est responsable de l acheminement du contenu entre l unité source et les unités de réplication. Le flux de réplication est associé au trafic nécessaire à l acheminement du contenu original, de l entité source à une unité de réplication. Ce processus peut être répété entre plusieurs unités de réplication pour distribuer hiérarchiquement le contenu (en pointillés sur la figure). La partie aval, ou réseau de distribution, concerne l accès des clients finaux au contenu par le biais des unités de présentation. Le flux de distribution est associé au trafic nécessaire à l acheminement du contenu (répliqué ou original en fonction des cas) en vue de sa présentation à l utilisateur. Chaque partie, en amont et aval de l entité de réplication, peut

31 utiliser (cas distribué) ou non (cas centralisé) un service réseau qui possède ses propres caractéristiques en terme de QoS. Les flux de réplication et de distribution issus du transport du contenu pour sa réplication ou sa distribution peuvent avoir des caractéristiques (en terme de QoS) et des besoins de communication différents. Par exemple, le flux de réplication engendré par le déplacement d un site web d un serveur source à une unité de réplication peut contenir des pages web, des images, voire éventuellement des scripts exécutables, le tout compressé dans une archive. La qualité de service de communication nécessaire au transport de ce contenu d un point à un autre du réseau correspond par exemple à un profil de transfert de fichier (fiabilité totale, ordre total, pas de contrainte de temps, service réseau «au mieux» et communication multipoints si plusieurs unités de réplication). En revanche, le flux de distribution associé à ce contenu est lié à l accès par le client à l une des pages du site. Ainsi, les contraintes de distribution intègrent par exemple un service point à point offrant un délai de bout en bout maximum entre l unité de réplication et l unité de présentation. En d autres termes, la QoS qu il aurait fallu assurer, dans le cas d une architecture sans réplication, entre l unité source et le client final est désormais à assurer entre chaque unité de réplication et leurs clients finaux. Une position stratégique de l unité de réplication permet ainsi de limiter le déploiement d une QoS de bout en bout complexe. Maintenir des contraintes de QoS est plus facile lorsque le chemin réseau à parcourir est court, au plus près de l utilisateur final. Tous les types de contenus ne sont pas forcément candidats à la réplication. Pour qu une donnée soit «réplicable», elle doit notamment satisfaire un critère de pérennité. Sa durée de vie doit être suffisamment longue pour pouvoir être stockée dans une unité de réplication et être utilisée potentiellement par les utilisateurs. Impossible par exemple de répliquer la vidéo issue d une application de vidéoconférence car l instant de présentation doit être proche de l instant de génération. La pérennité d une image diffusée en direct est par définition faible puisqu elle est sensée «photographier» l instant présent. Par contre, si les données d une application sont telles que leur génération est décorrélé de leur présentation, il est sans doute possible de les répliquer. On peut ainsi remarquer que certains médias comme la vidéo issue d une application de vidéo à la demande, ne nécessitent une qualité de service importante en terme de délai, gigue et débit, qu au niveau de leur distribution. Les impacts de cette technique ne se bornent pas au client final. L information est distribuée aux serveurs de réplication par le biais du réseau. En théorie, une fois la réplication d un contenu effectuée, le réseau n est plus sollicité pour ce contenu. Sa charge en est ainsi réduite, ses congestions également. Les applications temps réel dont le contenu ne peut être répliqué profitent ainsi indirectement d un réseau moins chargé. D autre part, la charge du serveur de contenu d origine est également distribuée à travers l architecture de réplication. Cependant, même si le service offert par les systèmes de réplication est sans réelle garantie de QoS et peut ainsi être qualifié de service «au mieux», l amélioration de l accès aux données par les utilisateurs est notable. Ainsi, pour la gestion de la QoS de bout en bout, la composante de réplication peut fournir une alternative aux deux autres composantes réseau et transport. Les systèmes de réplication de type pull (caching traditionnel) sont déjà largement déployés dans les réseaux, mais il n y a pas de réelle gestion de leur contenu en fonction de la QoS désirée. D autre part, le déploiement des CDN est, par le fait qu ils dépendent d un opérateur unique, beaucoup mieux coordonné. Cependant, l utilisation des serveurs de réplication comme composante d un système de gestion de QoS n est que peu développée actuellement [40]. Les protocoles et techniques utilisés pour mettre en œuvre une architecture de réplication sont traditionnellement les protocoles des méthodes de caching de l Internet classique. Ces derniers vont être détaillés dans la section suivante.

32 3.3. LES RESEAUX DE DISTRIBUTION DE CONTENUS (CONTENT DELIVERY NETWORK CDN) Les motivations et évolutions du transport de contenus Depuis la fin des années 60, le réseau ARPANET qui interconnectait exclusivement la communauté scientifique, a évolué vers l Internet actuel, offrant une connectivité universelle. Ce réseau est passé de l état d un outil de travail qui permettait de partager des ressources et de communiquer entre scientifiques, à un état de vaste outil de communication, où commerce, information et amusement ont pris une place prédominante. Les utilisateurs actuels de l Internet sont sans cesse en quête de nouvelles sources d intérêt, d information et de nouveaux types de média. Aussi les données transitant sur l Internet ont évolué du simple échange de courrier électronique en ASCII 7bits ( ) et de transfert de fichier informatiques, à la mise à disposition et l accès à de multiples contenus - document texte, page web, images, photos, vidéos, logiciels, etc. Ces nouveaux types de contenus demandent souvent des besoins en terme de fiabilité, de débit et de temps plus contraignants. Ces contraintes ont un impact au niveau des systèmes de stockage, de présentation, mais aussi en ce qui concerne le système de communication - des délais de bout en bout plus en plus faible, avec moins de variation, et une bande passante accrue. Le comportement des Internautes a luimême évolué de sorte que ces derniers sont devenus impatients, versatiles et exigeants. Les demandes en terme de qualité d image et audio sont de plus en plus importantes, et 47% des utilisateurs sont prêt à ne plus consulter un site si ce dernier ne répond pas suffisamment vite [41]. Ces contenus variés et le changement d habitude des utilisateurs ont transformé le réseau en système de stockage de contenus variés. L infrastructure du réseau a due s adapter aux nouvelles demandes des utilisateurs. Le mode de fonctionnement basique de l Internet, modèle Client/Serveur, a du être remis en question pour s orienter vers des solutions de Content Networking distribuées comme les CDN qui sont détaillés dans la section suivante Evolution des architectures de réplication L'Internet a évolué au point où la fourniture de la simple connectivité pour soutenir la navigation Web et le courrier électronique n'est plus une valeur suffisante. Les sociétés de commerce électronique, éditeurs et fournisseurs de contenus voient le Web comme un moyen de véhiculer des contenus riches à leurs clients, partout où ils sont, et à chaque fois qu'ils le désirent. Les besoins de ces nouveaux services et applications comme, (des services de divertissement, des transactions de commerce électronique, etc.) ont eu besoin de faire évoluer les techniques traditionnelles de communication et de stockage de l Internet. Au cours des années, différentes solutions sont apparues pour faire face à cette demande toujours grandissante des internautes. La base du fonctionnement des communications repose sur un modèle centralisé client/serveur (cf. Figure 3.3-1(a)). L ensemble des clients accède un unique serveur, ce qui peut entraîner des problèmes de communications (débit insuffisant, pertes, connexion impossible) lorsqu un nombre de client important essaye d accéder un contenu. L idée de pouvoir accéder à un contenu à plusieurs endroits est le fondement de la première alternative qui fut mise en place, le caching traditionnel (cf. Figure 3.3-1(b)). Le caching repose sur l installation de proxy-cache (serveur mandataire) qui vont effectuer, une copie des données qui transitent par eux. Cette copie pourra alors être utilisée lors des nouvelles requêtes des utilisateurs, à condition qu elle soit toujours valide par rapport au serveur d origine. Des solutions plus évoluées ont abouti à des services de caching hiérarchisés. Cette technique a apporté beaucoup d avantages aux utilisateurs de l Internet,

33 (réduction du temps d accès aux données, réduction de bande passante dans les réseaux de cœur, etc.), mais elle ne permet pas malgré tout de cibler les utilisateurs par avance et repose en fait sur les requêtes effectuées par les internautes, donc difficilement maîtrisable. Finalement, l architecture la plus adaptée pour les fournisseurs de contenus et de services, permettant un management des contenus et services est apparue, le CDN (cf. Figure 3.3-1(c)). L infrastructure du CDN vient répliquer les contenus et les services dans des serveurs de caches situés dans des POP, point de présence (Point of Presence). Ainsi grâce à des algorithmes de redirection les utilisateurs accèderont un des répliquas du contenu original en fonction d une métrique définie par le fournisseur de service CDN (CDN provider) qui est généralement basée sur le délai de réponse minimum. Les CDNs ajoutent à l approche traditionnelle du caching, une meilleure gestion et de meilleures performances des unités de réplication (proxy-cache) en répliquant le contenu par avance. Ils offrent de nouvelles possibilités pour des services à valeur ajoutée, pour l ensemble des fournisseurs de contenus. Figure Evolution des architectures de communication de l'internet. L infrastructure d un CDN prise dans son ensemble, constituée par l ensemble des services et équipements, peut être considérée comme une structure de recouvrement reposant sur les services de l Internet actuel (Figure 3.3-2). Elle facilite ainsi la gestion, le déploiement et l accès des contenus multimédia pour l ensemble des utilisateurs allant des fournisseurs de contenus aux utilisateurs finaux (consommateurs). Le CDN fonctionne comme un intermédiaire entre le fournisseur de contenus et l utilisateur final. Il offre au fournisseur de contenu une infrastructure constituée par un ensemble de nœuds (serveur de réplication) positionné au plus près des utilisateurs finaux (dans le meilleur des cas, le réseau d accès) afin de faciliter et d augmenter au mieux la QoS perçue par ces derniers. Ces serveurs de

34 réplications sont mis en œuvre par le déploiement de proxy-cache (serveur de cache) classique. Ces proxy-caches sont des caches Web HTTP, dans le cadre du trafic Web traditionnel et des serveurs de caches RTSP (RTSP Real Time Streaming Protocol), en ce qui concerne le trafic multimédia streamé. Chaque unité de réplication peut être considérée comme un serveur Web ou un serveur de streaming potentiel. Ces nœuds sont interconnectés par un réseau propriétaire ou un réseau loué à un opérateur. L utilisation d un CDN pour l utilisateur final est totalement transparente. Figure Architecture d'un CDN. Le CDN fournit traditionnellement les fonctions suivantes : Service de redirection et de distribution : Il permet de rediriger les utilisateurs finaux vers un serveur de réplication adapté, (par exemple, le plus proche et le moins chargé). Il permet aussi la distribution du contenu entre le serveur de cache et l utilisateur. Service d acheminement : Ce service permet d alimenter les unités de réplication par avance et de façon optimale. Il peut utiliser des protocoles traditionnels de caching ou mettre en œuvre des approches basées sur IP Multicast. Service de facturation : Il permet la gestion des droits au niveau des contenus, il permet la facturation des fournisseurs de contenus et gère un enregistrement des traces des accès au contenu. L utilisation d un CDN permet de tirer profit des techniques de réplication évoquées au paragraphe 3.2. Ainsi il permet au niveau du réseau de réduire le délai en diminuant le trafic au cœur du réseau et la zone géographique à traverser pour accéder à un serveur. Au niveau des clients, celui-ci permet de réduire le temps de réponse, car les unités de réplication sont proches des utilisateurs finaux, de plus le nombre de hop est généralement réduit. Finalement, la charge des serveurs d origine est globalement réduite. Le contenu étant répliqué à plusieurs endroits la charge est donc partagée. Le nombre d utilisateurs potentiels est donc plus important et le service est lui-même amélioré, chaque serveur traitant moins de connexion, la disponibilité du contenu est donc améliorée. De nombreuses compagnies ont émergé dans le domaine du Content Networking et en particulier dans le domaines des CDN, comme AKAMAI [43], Digital Island [42], etc.. Ces compagnies ont créé leur réseau global virtuel qui permet d accélérer l accès aux divers contenus. La première génération de CDN se contentait d améliorer les performances du réseau et de l accès. Aujourd hui l évolution des connexions d accès pour les particuliers (câble, xdsl) fait évoluer les CDN vers des fournisseurs de contenus et de services variés, comme l adaptation de contenus. De nombreux efforts sont faits par les compagnies

35 fournissant des services de CDN pour standardiser au maximum les méthodes et protocoles au sein des organismes comme le W3C et l IETF. Malgré l émergence de nouveaux protocoles comme le protocole ICAP ou OPES qui seront détaillé dans la section , les techniques utilisées par les CDN reposent sur les techniques de caching traditionnelles qui vont être détaillées dans la section suivante Techniques de caching pour le transport de contenus Web Le World Wide Web (WWW) a été créé au début des années 1990 par des chercheurs de l Organisation Européenne pour la Recherche (CERN). Les informations à échanger entre chercheurs ont eu besoin d'être traduites ou écrites dans un format qui permettait à chaque chercheur de voir le document et de faire des compléments ou des corrections, si nécessaire. Le premier navigateur et le logiciel serveur ont eu besoin d'un protocole de communication pour faciliter ces échanges de documents. Ces exigences de conception ont été la base pour HTTP (HyperText Transfert Protocol) : le protocole devait être capable d effectuer une demande (requête) et permettre au serveur de produire une réponse. Ainsi, le protocole fonctionnait dans un environnement client/serveur et utilisait l'infrastructure existante. Le client et le serveur ont eu besoin d'utiliser un langage commun pour communiquer HTTP a été développé. La première version de HTTP (HTTP 0.9) est sortie en 1991, depuis deux autres versions ont été mise à disposition : la version 1.0 en 1996 et la version 1.1 en Le transport de contenus sur le Web, protocole HTTP HTTP est construit sur le modèle de client/serveur, où le client effectue une requête vers le serveur. Le serveur traite cette demande et envoie une réponse au client. HTTP a été conçu pour profiter de l'infrastructure d'internet existante et il est basé sur le protocole de transport TCP. La requête HTTP du client contient une méthode, une version et une entête. Une réponse HTTP contient un code de statut (status code), une entête et le contenu demandé. L URL (Uniform Resource Locator) donne les informations nécessaires pour consulter un ensemble de données. L'URL spécifie le nom de la ressource et définit son emplacement et le protocole à utiliser pour avoir accès à cette ressource avec succès. Le port par défaut pour HTTP est le port de 80. Pour spécifier un port différent, le numéro de port suivrait immédiatement après le nom de domaine, par exemple comme suit, ( Le fonctionnement de HTTP est illustré Figure L ensemble des fonctions suivantes constitue HTTP : La connexion : le client effectue une connexion TCP/IP avec le serveur en utilisant le nom de la machine et son nom de domaine ou l'adresse IP et le numéro de port. Si le port n est pas spécifié, le port 80 est utilisé. Le serveur accepte ou refuse la connexion. Si le serveur accepte la connexion, la requête est analysée. La requête : Elle contient une méthode demande simple, GET. La requête GET contient l adresse du document. La réponse : Le serveur traite la demande et répond au client avec un flot d'octet de texte d'ascii. Il n existe aucun moyen de savoir si la connexion a été réussie. La déconnexion : Une fois que la réponse est complète, le serveur envoi une demande de déconnexion pour terminer la session de TCP/IP. (Note : quelques serveurs peuvent imposer une période de timeout avant la fermeture de la connexion, comme 30 secondes.)

36 HTTP/1.0 a mis en place des améliorations importantes par rapport à a version 0.9 mais devait être compatible avec la version précédente. Le protocole ainsi développé a été le premier standard. Ses fonctions ont été plus détaillées et ont inclus différents types d entêtes, y compris de codes d'erreur. HTTP 1.0 inclut aussi la capacité d'authentifier un client en utilisant une authentification de base, ou en texte clair. Figure Fonctionnement de HTTP. Comme HTTP 1.0, HTTP 1.1 devait être compatible avec les versions précédentes de HTTP. La croissance rapide de l'internet a stipulé des exigences robustes pour HTTP 1.1 et a aussi ajouté des nouvelles fonctionnalités. La plus importante était l'utilisation de connexions persistantes. Ces dernières ont permis au client de soumettre des demandes multiples sur une même connexion TCP/IP en utilisant la valeur Keep-Alive dans l entête de connexion. Avant cela, HTTP devait ouvrir une connexion TCP/IP différente pour chaque nouvelle requête. De plus, une nouvelle session ne pouvait pas être ouverte tant que la session antérieure n était terminée ou hors délai (timeouted). Ouvrir des sessions TCP multiples pour transférer de petite quantité de données était extrêmement coûteux au niveau du réseau et induisait un surcoût (overhead) important par rapport au volume de données transmises. Les connexions persistantes étaient donc une amélioration importante, qui a augmenté notablement les performances du protocole. Une autre amélioration de HTTP 1.1 est l'utilisation de request pipelining, qui permet au client d effectuer plusieurs requêtes avant qu'il ne reçoive une réponse d'une demande précédente. Le couplage du pipelining avec les connexions persistantes a augmenté la vitesse et l'efficacité de n'importe quel transfert de données. HTTP 1.1 a aussi offert d autres avantages, comme une méthode débbugage des requête HTTP en utilisant la méthode de TRACE et des mécanismes de contrôle des proxy caches, par lequel HTTP 1.1 peut inclure des informations pour indiquer aux caches quelles données peuvent ou ne peuvent pas être cachées grâce à une utilisation évoluée de l entête HTTP (cf. Figure 3.3-4). Figure Exemple de header HTTP (entête HTTP)

37 Grâce au champ Expires de l entête HTTP, il est possible de contrôler la validité d un contenu. Ce dernier permet de spécifier à l ensemble des caches le moment où le contenu deviendra obsolète. Il est possible de spécifier l information de validité de plusieurs façons : en utilisant un date d expiration ou bien en utilisant une date relative au dernier accès par un client (last access time). Une autre possibilité est d utiliser la date de la dernière modification de la page sur le serveur. Ceci est particulièrement intéressant pour les objets peu dynamiques comme les boutons ou les barres d outils ou encore pour les sites ayant des mises à jour quotidiennes. Le protocole HTTP 1.1 a mis en place un Cache-Control Header permettant de définir des politiques plus variées pour la gestion des pages par les différentes architectures. Cet entête contient l ensemble des champs suivants : max-age = [secondes] - permet de spécifier la durée en secondes pendant laquelle le contenu sera valide, il est similaire a l utilisation du Header EXPIRES. s-maxage = [secondes] - spécifie la même chose que le champ max-age mais, ce dernier ne s applique qu aux proxy caches. public - permet de rendre «cachable» une réponse même si celle-ci ne l était pas. Par exemple, une page authentifié n est pas cachable, avec cette marque celle-ci le devient. no-cache - Ce champ permet de forcer les caches (aussi bien les caches de navigateurs que les proxy caches) à effectuer une requête jusqu au serveur d origine avant de pouvoir utiliser la copie stockée dans le cache. Cela permet de maintenir une «fraîcheur» importante des données mais perd énormément de l intérêt d utilisation du cache. must-revalidate - Ce champ permet de spécifier à l ensemble des caches qu ils doivent respecter strictement les informations sur la validité des données, car ces derniers sont susceptibles de modifier l entête. Une fois activé, ce champ empêchera toute modification. proxy-revalidate C est le même champ que must-revalidate mais s appliquant uniquement sur les proxy caches. Ce système repose ainsi sur un modèle de validation qui est utilisé par les serveurs Web et les caches afin de déterminer si un objet a été modifié, définissant ainsi s il est nécessaire de mettre à jour la copie locale du cache. Il existe d autres entités qui permettent de spécifier si un contenu peu être caché ou non. Les Validators en sont un exemple. S il n y a pas de Validators ni d information de contrôle pour les caches, la plupart des caches ne stockeront pas l objet. Ainsi le Validator le plus utilisé est la date de dernière modification de l objet, Last Modified time. Ainsi un cache pourra utiliser ce Validator auprès du serveur père afin de savoir si le contenu a été modifié depuis cette date en utilisant une requête If- Modified-Since, lors d une demande de mise à jour. L ensemble des propriétés du protocole HTTP a été utilisé pour mettre en place des architectures de caching permettant de diminuer le temps de réponse pour les clients. Celles-ci vont être détaillées dans la section suivante Terminologie Les termes suivants représentent les différentes entités susceptibles de prendre part à une communication HTTP1.1 entre un client et un serveur. Client : Programme applicatif qui établit des connexions ayant pour but d envoyer des requêtes.

38 Serveur : Programme applicatif qui accepte les connexions entrantes et qui a pour but de répondre à des requêtes. Serveur d origine : Serveur où réside le contenu ou bien où il y a été créé. Proxy : Programme intermédiaire qui agit comme un serveur et comme un client. Il effectue des requêtes en se faisant passer pour un client. Web switch : Ceux sont des éléments réseaux qui permettent d effectuer une redirection du trafic vers un autre serveur différent du serveur d origine. Proxy d interception : Ces entités se trouvent derrière un Web switch, ceux sont les proxy qui reçoivent la requête après la redirection. Cache : Programme qui stocke des messages de réponses et du contenu afin de servir le plus rapidement possible, en utilisant le moins de bande passante possible les requêtes lui parvenant. Réseau de Cache (Caching Mesh) : Ensemble de caches organisé en maillage. Surrogate ou Reverse Proxy : Ceux sont des proxys généralement proches du serveur d origine qui ont pour but de rendre le service du serveur d origine afin d augmenter le nombre d utilisateurs potentiels et la rapidité d accès aux contenus. Ils sont connus pour effectuer une accélération du serveur d origine Architecture de caching Le modèle des communications Web repose sur l architecture client/serveur classique. Le client effectue une requête et le serveur lui répond avec les données. Lorsque le nombre d utilisateurs augmente, la charge du serveur et du réseau et le temps d accès augmentent. L idée d introduire une entité permettant de répondre à la place du serveur d origine est la base des architectures de caching. Ainsi lorsqu un client effectue une requête (cf. Figure 3.3-5), le cache situé entre le serveur et le client effectue une copie locale du contenu. Lors d une nouvelle demande par d autres clients, si le contenu caché est toujours valide, le cache pourra se substituer au serveur d origine et délivrer directement le contenu. Figure Principe de fonctionnement d'un cache. Comme le montre la Figure 3.3-6, les bénéfices du caching ne sont pas négligeables. Dans le cas d un ISP local du New Jersey [44] possédant 3 liens T1 d une capacité totale de 4.5Mbits/sec, lorsque des clients accèdent des contenus, le trafic entrant est égal au trafic sortant dans le cas où aucun cache n est présent chez ISP. Avec un cache, ceci n est plus vrai et l ISP effectue des économies sur le volume de trafic entrant, ou permet un meilleur accès aux contenus non présents dans les caches.

39 Figure Bénéfice du caching ISP du New Jersey. (Capacité totale de 4.5mbits/sec). Il existe deux principales manières de mettre en œuvre des architectures de caching en utilisant des proxy. La première, méthode basique consiste à placer un Forward Proxy devant les utilisateurs finaux (Figure 3.3-7). Le client effectue une requête vers un serveur d origine qui est d abord interceptée par le ou les proxy locaux qu elle rencontre. Ces derniers effectuent une recherche parmi leurs contenus et dans le cas où le contenu est présent localement et est valide, il le fournisse directement au client. Dans le cas contraire, ils transfèrent la requête jusqu au serveur d origine. Figure Exemple de Forward Proxy. La deuxième méthode est lorsqu un client communique avec un Reverse Proxy (cf. Figure 3.3-8), la communication s effectue comme si le client était directement connecté avec le serveur d origine. Le Reverse Proxy traite les requêtes soit avec son contenu, soit joue le rôle de tunnel jusqu au serveur d origine. L avantage d un Reverse Proxy est lorsque celui-ci est en mesure de fournir le même service que le serveur d origine. Il sert alors d accélérateur de serveur. Figure Exemple de Reverse Proxy. L ensemble des communications présentées précédemment repose sur différents protocoles tels que ICP, HTCP, CARP qui permettent aux proxy de dialoguer entre eux et

40 avec les serveurs d origine. Ils permettent une communication entre les caches et un échange de contenus le cas échéant. Ces protocoles sont présentés dans la section suivante Protocoles de caching et réplication Comme l a montré la section précédente, l utilisation d un serveur de cache permet de réduire le volume de trafic sur un réseau, aussi des solutions mettant en œuvre plusieurs caches sont possibles, soit en utilisant des caches de façons hiérarchiques, soit en en créant des maillages de serveurs communiquant à l aide de protocole de caching. Cette section décrit certains des protocoles les plus fréquemment utilisés dans l'internet actuel dans les architectures de caching. Une vue d'ensemble plus complète peut être trouvée dans la RFC [45]. ICP (Internet Cache Protocol) Le protocole ICP, actuellement la version 2 est issue de la demande de l IETF dans les RFC [46][47] et a été développé par le Laboratoire National pour la Recherche en Réseau Appliquée (NLANR) en ICP définit un format de message léger à utiliser pour communiquer entre cache. Il est utilisé pour échanger des hints définissant l'existence d'url dans des caches voisins. Les caches échangent des requêtes et réponses ICP pour déterminer les informations les plus appropriées pour récupérer l objet demandé. Bien que les caches Web utilisent HTTP pour le transfert de d'objet, les caches bénéficient d'un protocole de communication plus simple, plus léger. ICP est principalement utilisé dans un maillage de cache pour déterminer la place des objets dans les caches voisins. ICP est mis en oeuvre au dessus d'udp, mais il n'existe aucune restriction le limitant à UDP. ICP sur UDP montre des avantages important pour le caching Web l échange de requête/réponse doit être réalisé rapidement, typiquement dans une seconde ou deux. Un cache ne peut pas attendre plus longtemps avant de commencer à récupérer un objet. L'échec de réception du message de réponse signifie que le réseau est soit congestionné, soit coupé. ICP peut être utilisé pour le choix de caches. Cache Digest Cache Digest [48] est un protocole d échange et un format de données développé par le NLANR en Il est une réponse aux problèmes de latence et congestion associées aux autres mécanismes de communications d'inter-cache, comme ICP ou HTCP. A la différence de ces protocoles, celui-ci accepte des relations d égal à égal (peering) entre les caches et ne nécessite plus des échanges de requête/réponse, le digest est mis en commun entre les caches «égaux». Les autres serveurs peer récupèrent un résumé des contenus stockés dans le cache (le Digest). Il est alors possible de déterminer avec une quasi exactitude quel cache stocke les données d une certaine URL. Cache Digest est autant un protocole qu'un format de données, dans le sens que la construction du Digest est bien définie et que le protocole pour accéder à ces digests sur un réseau est défini aussi - actuellement via HTTP mais d autre protocole comme FTP peuvent être utilisé. Un serveur peer répondant à une demande de son digest spécifiera qu'une date d'expiration pour son digest en utilisant le HTTP Expire de l entête HTTP. Le cache ayant effectué la demande connaîtra la date où il devra mettre à jour le digest du cache correspondant. Un digest est un résumé des contenus stockés dans un serveur de cache. Il contient, dans un format compact (compressé), une indication sur les URL particulières stockées ou non dans le serveur. Les serveurs de cache échangent périodiquement leurs digests. Quand une requête pour un objet (URL) est reçue d'un client, le cache utilise les digests de ses peers

41 pour découvrir lequel possède cet objet (le cas échéant). Le cache peut alors demander l'objet au peer le plus proche plutôt qu au serveur d origine. Le protocole cache digest permet de diminuer la latence de traitement des requêtes et les messages requête/réponse transitant sur le réseau. HTCP (Hyper Text Caching Protocol) Le protocole HTCP permet de découvrir des caches HTTP et les données stockées. Il assure une gestion d un ensemble de caches et contrôle leur activité. Il a été développé par l ICP Working Group dans un draft en 1999 [49]. HTTP 1.1 permet le transfert d'objets Web entre les serveurs d'origine, éventuellement via des proxy caches, et les clients. HTTP 1.0 et les versions suivantes ont mis en place des entêtes permettant le management des caches, alors que HTTP 0.9 ne tenait compte que de l URL sans aucune entête. ICP a été conçu sur la base de HTTP 0.9. HTCP lui repose sur les versions plus récentes de HTTP et permet d utiliser pleinement les entêtes pour gérer au mieux l ensemble des caches. Ainsi, il dirige la gestion à distance des caches et peut effacer des contenus ou en ajouter dans certains caches. Il effectue une meilleure gestion des contenus au niveau des caches. CARP (Cache Array Routing Protocol) Le protocole CARP est basé sur un draft IETF co-développé avec Microsoft [50]. Il divise l espace des URL par une méthode de hachage dans un tableau. Les proxy et clients acheminent leurs demandes à n'importe quel membre de cette table de hash. En raison de ce routage par table de hash, les répliquas de contenus dans les serveurs n existent plus. De plus déterminer le bon cache est effectué en une seule étape. CARP gère automatiquement l ajout et la suppression de serveur dans sa table de routage. Les avantages permettent de dire que finalement peux d URL devront être re-stockées. CARP utilise le standard HTTP pour les communications, ce qui permet une compatibilité accrue même pour les serveurs derrière des firewall. De plus, ce dernier peut être mise en œuvre directement sur des clients terminaux en utilisant le standard industriel PAC (Proxy Auto-Config file), alors que ICP lui ne peut être mise en place que sur des proxy caches dédiés. OPES (Open Pluggable Edge Services) L'architecture OPES, développée dans le cadre de l'ietf [51], permet la construction de services exécutés sur des proxy intermédiaires prenant part à la communication entre le client et le serveur. Le caching est le service le plus basique, qui n exige qu une simple compréhension de la sémantique de l application par le serveur de cache. Le but de OPES est de définir les protocoles et l'api (Application Programming Interface) qui permettent un large jeu de services et facilitent la distribution de contenus complexes ou des services. L'architecture est capable de mettre en oeuvre des services contenus dans un des intermédiaires de transit ou placés dans d'autres serveurs. Cette action est typiquement l'exécution d un proxylet (code d'application spécifique exécuté sur le système intermédiaire), qui peut contenir un appel à un serveur callout (une entité éloignée). Le protocole entre le proxy et le serveur de callout est souvent basé sur ICAP [52]. Le protocole ICAP est développé pour transporter les entêtes et données HTTP entre des entités coopératives ; d'autres protocoles comme SMTP ou autres sont supportés par cette architecture si ils sont déjà ou dès qu ils seront disponibles. Le modèle de sécurité pour des services intermédiaires implique la définition des rôles d'administrateur et les privilèges pour l'application cliente, le serveur d'application, les proxy intermédiaires et le serveur auxiliaire.

42 Techniques de caching pour le transport de flux vidéo (Streaming) Délivrer des données multimédia avec une bonne qualité sur l Internet présente beaucoup de défis à relever. Le streaming fait référence au transport de média ayant des contraintes temporelles et un flux de données continu, (vidéoconférence, audioconférence, etc.). Contrairement à ce qui était disponible dans les premières années du Web, où il fallait télécharger le média en entier avant de pouvoir le visualiser, le streaming de média permet une visualisation en flux tendu des données dès que celles-ci sont reçues. Contrairement au transport de données Web traditionnel, le streaming de média consomme beaucoup plus de bande passante et requiert des contraintes plus importantes, comme un flux continu avec de faible tolérance de variation de délai. Le streaming de média est en train de devenir l un des plus important enjeux économiques de l Internet avec un chiffre de 2.5Milliard de dollars prévu pour 2004 [53]. Les principales difficultés du streaming sont la bande passante importante utilisée, le besoin d un flux continu, les problèmes de gestion de droits d auteurs et le besoin de protocole de transport (RSTP Real Time Streaming Protocol, MMS- Microsoft Media Streaming). Les applications de streaming peuvent être classés en deux groupes importants. La première catégorie d application est la famille des applications de streaming en différé (ou simplement streaming) : le contenu est préparé et est diffusé à la demande, la diffusion intègre les contraintes temporelles. Ce sont des applications de Multimédia à la demande, etc., le contenu est enregistré à l avance et peut donc être déporté ou transporté à différents endroits. La seconde famille d application est la famille des applications de streaming en direct (streaming live) : le contenu diffusé est constitué en temps réel puis diffusé. Ce type d applications peut être associé à la diffusion d émission de télévision ou de radio, voir même les applications de vidéoconférence et jeux distribués. Dans ce cas là, les contraintes temporelles sont importantes pour supporter l interactivité des média. Les sections suivantes vont présenter des techniques de caching pour les applications et données de streaming en distinguant le cas des applications de streaming et de streaming live Streaming Le streaming de média n a pas les mêmes besoins que le transport de trafic conventionnel du Web. La taille des objets est beaucoup plus importante et les contraintes (temporelles notamment) à maintenir sur les flux sont plus rigoureuses. Les protocoles utilisés sont donc différents. Deux méthodes de caching pour les applications de streaming sont présentées. Le Caching «traditionnel» : Le cache doit être équipé d un serveur de streaming et il doit aussi être capable de stocker à la demande un flux streamé. Quand le cache reçoit une requête d un client pour un média, il détermine si le contenu est «cachable». Ensuite il vérifie si le média est déjà stocké dans son cache local. Si le média n est pas présent, le cache acquiert le fichier du contenu en même temps que le serveur source le délivre au client. Dès la demande suivante le média sera distribué aux autres clients à partir de la copie locale (cf. Figure 3.3-9).

43 Figure Caching de streaming traditionnel. La réplication : Dans le cas de la réplication, une ou plusieurs copies d'un même média ou même un système de fichiers entier, contenant plusieurs médias peuvent être maintenues sur un ou plusieurs serveurs, appelés unités de réplication. Les clients déterminent l unité de réplication optimale et accèdent au contenu à partir de celui-ci (Figure ). La décision pour déterminer le serveur optimal est souvent basée sur la proximité, mais peut également être basée sur d'autres critères comme la charge des unités de réplication. Figure Réplication de Streaming multimédia Streaming live Le streaming Live possède des contraintes différentes du streaming traditionnel. Le stockage total du média est impossible, puisqu il est constitué de la diffusion d un événement en direct. Les techniques présentées dans cette section essayent de tirer partie au maximum de l infrastructure de caching pour améliorer les performances pour le streaming live. IP multicast : La solution optimale théorique pour le streaming live vers plusieurs clients est la diffusion de média à l aide du protocole IP multicast. Les paquets de données ne sont répliqués qu aux endroits nécessaires (Figure ). Cela permet de réduire la charge du réseau et la charge du serveur d origine. Cependant cette solution n est pas toujours possible à déployer car le support d IP multicast n est toujours pas généralisé sur l Internet actuel.

44 Figure Streaming avec IP Multicast. Unicast split : Après avoir établi une connexion unicast avec le serveur d origine, le cache est en mesure de transmettre vers tous les clients le flux de média streamé en live jusqu'à lui par l intermédiaire de connexion unicast avec les clients (Figure ). Aussi pour toutes les demandes suivantes du même flux, les données seront directement dupliquées au niveau du proxy sans effectuer un nouvelle connexion jusqu au serveur d origine. Cette technique peut être apparentée à du Multicast applicatif. Figure Streaming avec un Unicast split. Multicast split : Le serveur de cache est dans le cas d un Multicast split capable de réémettre le flux live unicast qu il perçoit vers ses clients à l aide d une communication IP Multicast (Figure ). Ceci nécessite que le réseau derrière le proxy soit compatible avec IP Multicast et que les clients soient aussi capables d effectuer des communications IP Multicast. Figure Streaming avec un Multicast split.

45 Pass throught Delivery (Livraison par passage): Dans le cas où le contenu ne peut pas être dupliqué, le flux va simplement passer au travers du serveur de réplication. Néanmoins, cela permet de découper la connexion de bout en bout entre le client et le serveur en deux morceaux (Figure ). Le client est alors connecté avec le cache et le serveur d origine communique avec le cache. Cela permet le cas échéant d avoir un débit plus important entre le serveur d origine et le cache permettant de stocker quelques secondes du média. Figure Steaming par Pass Through Delivery Du caching à la distribution de contenus Principe de Redirection Les architectures de CDN reposent sur les techniques et architectures de caching traditionnelles. Le caching permet d alimenter certains utilisateurs spécifiques avec tous types de contenus, alors que le Content Distribution and Delivery (CDD) permet de délivrer des contenus spécifiques à tous les utilisateurs du Web. Les différences entre les deux approches, caching ou CDN, sont tout d abord la façon de gérer les contenus (réplication des contenus à l avance ou non) et surtout sur la différence d accès aux contenus. Dans un cas, pour le caching, les requêtes des utilisateurs sont reçues par un proxy et ensuite ce dernier effectue la recherche du contenu, c est du content switching (Figure ). Le Content Switch possède l adresse IP du site Web (adresse donnée par la résolution DNS (Domain Name System) au client). Lors d une requête, le client est connecté directement au content switch, ce dernier en fonction de règles prédéfinies par le Webmaster, redirigera la requête vers un des serveurs ou caches (toutes les requêtes d une même session seront alors redirigées vers le même serveur). Figure Exemple de Content Switching. Dans le cas d un CDN, les mécanismes de redirection font parties intégrantes de l architecture et conditionnent souvent les performances de l architecture globale du CDN.

46 Ces mécanismes de redirection sont basés en majorité sur des algorithmes identiques à la résolution DNS (cf. Figure ). Chaque architecture CDN met en place son propre système de DNS pour permettre la redirection des requêtes utilisateurs. Cette technique se rapporte au Content Routing, les requêtes des utilisateurs sont routées dès la première interception vers le bon serveur ou cache. Figure Exemple de résolution DNS local dans un CDN (Content Routing). Les algorithmes de redirection sont généralement privés et diffèrent dans chacune des compagnies fournissant des services de CDN. Ils reposent cependant tous sur une résolution DNS mais chacun possède ses propres règles de résolution du «meilleur» serveur cache. Les métriques généralement utilisées reposent sur, la position géographique, le RTT, le nombre de hop, le taux de pertes, etc. Le maintient de la valeur de ces critères est basé sur des mesures passives, actives ou proactives de l état du réseau. Certains algorithmes à apprentissage mesurent périodiquement le RTT vers différent îlot d adresse IP, afin de maintenir les valeurs vers certaines IP, pour choisir les redirection DNS les meilleures Discussion Les architectures CDN possèdent en fait trois grandes phases. La première consiste en l acheminement des contenus. Cette phase est plutôt réalisée de façon basique car l ensemble des contenus est généralement répliqué dans toutes les unités de réplications. Différentes méthodes peuvent être utilisées, par exemple IP Multicast, l utilisation de satellite ou plus traditionnellement un simple transfert de fichier avec FTP (File Transfert Protocol) ou RDIST (Remote software distribution system). La deuxième phase d une architecture CDN est la partie de redirection. Comme nous l avons vu dans la section précédente, ces mécanismes sont basés sur des algorithmes semblables à la résolution DNS et peuvent dépendre de différentes métriques. La dernière phase est la phase de distribution des contenus aux utilisateurs finaux. Cette phase est basée sur les techniques classiques de communication client/serveur, néanmoins elle peut être mise en œuvre à l aide de protocoles spécifiques pour obtenir de meilleures performances. Les CDN sont des architectures réseaux intelligentes constituées de nœuds interconnectés et communicants. Ils permettent une diminution substantielle de la charge réseau et augmentent les performances d accès aux contenus. Néanmoins, le coût d exploitation reste encore élevé et la facturation de l utilisation des ressources reste un problème. D autre part, la phase de déploiement des contenus n est pas optimale, en effet

47 encore 85% de l acheminement est effectué par des connexions unicast [54]. Finalement, les services offerts restent encore assez peu variés et aucune garantie de QoS ou performance ne sont clairement garantie. Les nouvelles architectures CDN essayent de déployer au mieux de nouveau service grâce au protocole OPES (cf ), cependant ceci est très peu réalisé. L adaptation des contenus en fonction du type de connexion ou du type de périphérique fait partie des nouveaux services étudiés. Les CDN sont des structures overlay qui permettent de mettre à disposition de l ensemble des utilisateurs des contenus avec une meilleure QoS globale pour l ensemble des utilisateurs. Cependant il est clair qu aucune garantie réelle n est offerte par ce type d architecture LES RESEAUX DE PEER-TO-PEER Généralités Le réseau ARPANET (fin des années 1960), à l origine de l Internet actuel, était basé sur un système de P2P (Peer to Peer ou Pair à Pair), tous les participants étaient égaux et partageaient l ensemble de ses ressources. Le but premier était le partage des ressources de calcul et des données. Les applications phares de l Internet des années suivantes, comme FTP et Telnet, ont fait évoluer le réseau vers un système client/serveur qui c est imposé jusque dans les années 90. Le renouveau des applications de P2P est apparu avec l arrivée de NAPSTER [55] vers la fin des années 1990, qui permettait le téléchargement de morceaux de musique gratuitement. Le terme «Peer to Peer» se réfère à une classe d application et de système qui emploient des ressources distribuées ou qui exécutent des fonctions plus ou moins critiques de façon décentralisée. Le P2P est souvent confondu avec d autres termes, comme le traditionnel calcul distribué (distributed computing) ou les réseaux ad hoc (adhoc networking). La popularité des applications de P2P est venue des nouvelles perspectives offertes aux utilisateurs finaux. Les utilisateurs ont pu passer d un état de simple client passif et tributaire des serveurs, à un état d acteur capable de partager et de mettre à disposition des données. Les réseaux de P2P sont des réseaux logiques de haut niveau (structure de recouvrement, structure overlay) reposant sur des nœuds terminaux interconnectés par l infrastructure réseau existante. Les principaux services et applications sont détaillés dans la Figure Une des caractéristiques principales des systèmes P2P est de ne pas posséder de point privilégié ou centralisé (serveur), ce qui permet la définition de nouveaux services qui ne sont plus basés sur le modèle classique client/serveur. Figure Services et applications des systèmes de P2P.

48 Les systèmes de P2P reposent sur des architectures de peering qui offrent l accès à différents services (cf. Figure 3.4-1) comme l accès à un service de Multicast applicatif ou le partage de fichiers entre plusieurs peers. En utilisant les services mis à disposition par ces architectures, chaque peer est capable de connaître ses peers et de localiser un contenu sur l ensemble du réseau de P2P. Les applications les plus courantes des réseaux de P2P sont des systèmes de partages de fichiers, comme Gnutella [57], Kazaa [58], Edonkey [59], ou alors des systèmes de stockage distribué, de type Oceanstore [60]ou BitTorrent [61]. Des nouveaux types de réseaux de P2P issus du monde de la recherche ont fait leur apparition reposant sur la distribution des objets et des fonctions de routage pour supporter une large mise à l échelle, comme CHORD [67], PASTRY [68], TAPESTRY [69], etc. Figure Exemple de représentation d'un réseau de P2P. La Figure montre une représentation classique d une structure de P2P. Basée sur l infrastructure réseau existante, les nœuds du système ou peer forment la structure de recouvrement du réseau de P2P. La représentation des liens entre les peers (en pointillés), n est en fait que la connexion logique en terme de structure de recouvrement, elle ne représente en aucun cas un lien réseau de l architecture physique. Les bénéfices majeurs des architectures de P2P sont de permettre une meilleure utilisation des ressources, une meilleure utilisation de la bande passante et d accéder plus facilement et rapidement aux informations [56] Architecture et fonctionnement Architecture Par opposition aux architectures client/serveur, la force des systèmes de P2P repose sur l indépendance par rapport au serveur et la décentralisation de l ensemble des contrôles de l architecture. Dans le modèle client/serveur, le serveur devient très facilement un point de congestion (bottleneck), dès que le nombre de clients devient important, aussi l utilisation de réseau de P2P permet d éviter ce type de problèmes. Certains systèmes de P2P ne nécessitent pas de serveur même pour la connexion au réseau. Ainsi il existe différents types de systèmes de P2P qui vont être détaillés ci-dessous. Système de P2P avec serveur de découverte, recherche et contenus Dans ce modèle, le serveur dirige les communications comme dans le modèle client/serveur. Toutes les informations nécessaires pour la recherche sont contenues dans le serveur (cf. Figure 3.4-3). Les peers ne sont pas autorisés à ce connecter entre eux. Lorsqu un peer a besoin d informations, il doit les demander au serveur qui traite la demande et lui retourne la ou les réponses correspondantes.

49 Figure Système de P2P avec serveur de découverte, recherche et contenus. L'inconvénient principal de ce modèle est que le serveur est saturé si trop de demandes arrivent simultanément. Un autre inconvénient est le coût élevé d un telle solution, le serveur doit gérer et stocker les contenus et données et répondre à toutes les requêtes des clients. De plus, puisqu un tel système repose entièrement sur un serveur central, les risques de pannes sont plus importants et peuvent compromettre l ensemble du système. Système de P2P avec serveur de découverte De tels modèles de P2P n utilisent un serveur que pour la phase initiale de découverte. Dans un souci, de simplification et de gestion, le rôle du serveur se limite à fournir la liste des peers connectés sur le réseau pour faciliter la connexion. Une fois la connexion établie au réseau, les communications sont ensuite effectuées directement entre les peers (cf. Figure 3.4-4). Figure Modèle P2P avec serveur de découverte. Un tel modèle offre un service supplémentaire par rapport au modèle P2P pur, puisqu il fourni une liste des peers connectés ce qui augmente la chance de trouver un peer. Une fois les peers trouvés, chaque peer doit ensuite se connecter avec les différents peers, ce qui peut induire un délai supplémentaire. Système de P2P avec serveur de découverte et recherche Dans ce modèle, le serveur fourni en plus de la liste des peers connectés, la liste des contenus que chacun de ses derniers possèdent. La Figure peut donc aussi représenter un tel modèle, si le serveur possède des fonctionnalités supplémentaires. Ce modèle réduit la charge sur chaque peer. Lors d une recherche d information, les peers ont besoin de communiquer seulement avec le serveur pour obtenir une réponse. Le serveur initie la connexion entre les peers, surveille le bon fonctionnement et enregistre les informations relatives aux contenus et aux peers du réseau. Système de P2P pur

50 Le modèle de P2P pur ne possède pas de serveur central ni pour la recherche, ni pour la connexion. Chaque peer est à la fois client et serveur du système. Une fois l application de P2P exécutée, la machine se connecte aux autres peers sur le réseau dynamiquement. Toute la communication, (transfert de données, recherche, demande d envoi et réponse, etc.) se passe entre les peers connectés sans la moindre assistance d un serveur (cf. Figure ). Figure Modèle P2P pur. Ce modèle de communication brise les méthodes conventionnelles de communication du modèle client/serveur ou la communication est régie par les règles du serveur. Les peers sont capables de définir leurs propres règles de fonctionnement à la vue de leur environnement réseau. Ce modèle offre des possibilités importantes dans le sens ou dès que la connectivité est assurée (par le biais d Internet), il est possible d accéder aux services du réseau de P2P. Ce modèle est aussi intéressant pour le déploiement d application dans un réseau local ou intranet. La seule difficulté de ce modèle est de déterminer un peer initial avec lequel se connecter au réseau, car aucun serveur ne gère la liste des peers. Généralement, une liste de peers de «rencontre» est mise à jour à chaque connexion. A la vue des différentes architectures de P2P, il est facile de se rendre compte que seules les architectures P2P pures et systèmes avec serveur de découvertes sont intéressantes, car seules ces dernières s affranchissent totalement du modèle traditionnel client/serveur. Ces dernières ne possédant pas de serveur centralisé ayant la connaissance des contenus dans le réseau, nous allons nous intéresser à leurs algorithmes de recherche Algorithme de recherche Les méthodes de recherches dans les réseaux de P2P sont toujours de vastes sujets de recherches. Nous allons nous concentrer sur les algorithmes de recherche classique mis en œuvre dans la plupart des systèmes de P2P, par exemple comme Gnutella, Edonkey, etc. Classiquement, il existe des algorithmes utilisés avec quelques variantes de mise en œuvre. Le BFS, (Breadth-First Search): Avant de pouvoir télécharger un contenu, le peer doit déterminer où il se trouve dans le réseau. Sa requête parcourt le réseau par l intermédiaire de l algorithme Breadth-Firs- Search, BFS. Cet algorithme effectue une recherche en largeur. Il correspond à une simple diffusion de la requête à chacun de ses voisins. Ainsi, cet algorithme est utilisé pour envoyer les requêtes de peer en peer en attendant une réponse (cf. Figure 3.4-6). Une valeur maximale de hop est fixée par défaut afin de ne pas trop surcharger le réseau.

51 Figure Exemple de recherche en BFS. Diffuser de la sorte des messages entraîne beaucoup de trafic hors téléchargement. La recherche est moins efficace lorsque l on diffuse les demandes. Le DBFS, Directed-BFS: L algorithme DBFS a introduit des améliorations sur le BFS initial. Il permet à partir d informations (sorte de table de routage en fonction des contenus) stockées sur le réseau de déterminer les peers à qui envoyer ou faire suivre une requête. Ainsi, au lieu de diffuser la requête à tous les peers dans le réseau, un certain nombre de peers donnés vont recevoir les requêtes, limitant ainsi le trafic généré (cf. Figure 3.4-7). Figure Exemple de recherche en DBFS. Les méthodes pour choisir les peers à qui envoyer les requêtes peuvent dépendre de plusieurs heuristiques, (les peers répondant le plus vite, les peers les plus proches en nombre de hop, etc.). Les méthodes mise en œuvre visant une efficacité accrue, reposent sur des tables de routage construites à partir de la base des données des contenus stockés dans le réseau. Dans cette table de routage, sont associés le hash h unique, résultat d une fonction de hashage sur un mot clé (généralement le nom du fichier), avec le nombre minimal de hop pour atteindre un fichier ayant ce mot clé. Cette table est partagée ensuite entre les peers et lors d une requête, il ne reste plus qu à suivre les informations de routages au niveau de chaque peer pour déterminer l endroit de stockage. Cette table de routage repose sur la capacité de nommer ou référencer les fichiers Partage de données et algorithme de référencement Lorsqu un peer reçoit une requête, il doit être capable de déterminer s il possède le contenu ou alors de transmettre la requête au peer correspondant. Pour cela il utilise sa table de routage basée sur le référencement et le classement des contenus en fonction des peers.

52 Chaque peer crée localement une indexation (unique) de ses fichiers partagés en les triant tout d abord dans un ordre lexicographique. Lors de la connexion du peer sur le réseau celui-ci construit une structure arborescente qui lui permet de classer ses fichiers partagés. Cet arbre indexé est alors la base de l algorithme de recherche et de routage vu dans la section précédente. Chaque peer ayant réalisé cette construction, peut ensuite la partager avec l ensemble du réseau. Cette table d index est ensuite partagée entre les peers, ce qui permet lors des opérations de recherche de déterminer les peers correspondant à la recherche d un index particulier. Des structures de stockage des index et des algorithmes de recherche ont fait l objet de nombreux travaux de recherches. Une des alternatives les plus efficaces repose sur l utilisation d une structure de stockage d arbre binaire. Ce système d indexation et de recherche est la base de l algorithme P-Grid, qui a été déployé dans le système de P2P Gridella [62][63]. Ce système est compatible avec le système d indexation de Gnutella mais permet sur l ensemble des peers ayant une structure P-Grid de diminuer le temps de recherche Discussion Les systèmes de P2P prennent une ampleur de plus en plus importante à l heure actuelle. Des systèmes de voix sur IP utilisent même ce type d architecture pour créer un réseau overlay dédié à la voix [64]. Les services offerts par de telle architecture permettent de concevoir de nouvelles applications distribuées. Cependant l utilisation majoritaire des réseaux de P2P reste toujours le téléchargement de fichiers ou le stockage distribué. Dans le cadre de ces approches, l accès aux contenus et données est amélioré par rapport à un système basé sur le modèle client/serveur. Néanmoins aujourd hui, aucunes garanties ne sont fournies par ce type de système. Les temps de téléchargements restent toujours importants malgré un nombre de clients toujours en augmentation. Les architectures de P2P possèdent des services de bases (cf. Figure 3.4-1) qui offrent les possibilités d améliorer les performances de chaque type de système de P2P en utilisant les services déjà disponibles. Dans le chapitre suivant nous présenterons une solution pour tirer profit encore plus avant des caractéristiques des réseaux de P2P MODELISATION DES RESEAUX DE RECOUVREMENT Les structures de recouvrement sont une idée ancienne, en effet, l'internet a lui-même été développé comme un réseau de recouvrement sur le réseau téléphonique. Alors que le cœur du réseau a évolué vers un environnement basique servant au transfert des bits de données sur de longues distances, c est en «bord de réseau» (edges network) que l on voit apparaître de nouvelles intelligences. En bord de réseau, on peut trouver des routeurs d accès (edge device), passerelles (IP Multicast, etc.) directement interconnectés aux cœurs du réseau et offrant aux utilisateurs finaux de nouveaux types de services (connexion VPN, serveur dédié, etc.). De la même façon de services de caching ou systèmes de stockage distribué ont été implémentés derrière ces connexions de bordure. Cet ensemble d équipements évolués constitue différents types de réseaux de recouvrement. De nombreuses structures de recouvrement ont déjà était mise en place sur l Internet actuel, le MBone (réseau de recouvrement Multicast), 6Bone (réseau overlay IPv6), les CDN, etc. En d autres termes, une structure de recouvrement peut être définie comme un ensemble de «tunnels», qui interconnecte un ensemble de nœuds formé par des utilisateurs ou entités en bordure de réseaux pour faire transiter des données en reposant sur

53 l infrastructure physique du réseau opérationnel. Ces tunnels mettent en œuvre des connexions unicast entre les peers, que ce soit pour la gestion du réseau et pour le transfert des données. Nous proposons un modèle simple représentant les caractéristiques d un réseau de recouvrement par : Caractérisation de la structure Cela revient à caractériser et quantifier de façon globale le réseau de recouvrement. Les paramètres caractéristiques vont être : o Le nombre de nœud N n : la caractérisation spécifique des nœuds sera faite ci-après. o Les services offerts par la structure : Ces services dépendent de l utilisation de la structure de recouvrement. Ils peuvent être des services de stockage, service de multicast applicatif, etc. Caractérisation d un nœud Les nœuds sont classiquement des machines d utilisateurs finaux, des serveurs, ou des entités réseaux actives comme des routeurs. Un modèle générique pour caractériser un nœud comporte les paramètres suivants : o Capacité de traitement S CPU : elle représente les performances de traitement possible par le nœud. Elle peut être exprimé en terme de CPU et être exprimée en MégaHertz. o Capacité de stockage S ST : cette capacité est le volume de stockage disponible sur le nœud pour stocker des données ou contenus. Elle est exprimée en Mégaoctets. o Nombre de connexions supportées N Xmax : C est le nombre maximal de connexions simultanées que le nœud peut accepter. o Services Disponible : L ensemble des services du système de recouvrement n est pas forcément implémenté dans tous les nœuds. o Lien d accès réseau : le lien d accès réseau est la capacité de connexion du nœud à l Internet et pas nécessairement la taille du «tuyaux virtuel» entre les nœuds. Il est caractérisé par des paramètres traditionnels. Débit maximum du lien en download et upload X up, X dw en Kbits/s. Délai de bout en bout minimum du lien d, en secondes. Taux de pertes minimales du lien l en pourcentage de pertes. o Un ensemble de contenu M : Cet ensemble représente les différents contenus ou données disponibles sur ce nœud particulier. Caractérisation d un utilisateur final Les utilisateurs finaux peuvent être soit des nœuds de la structure de recouvrement, soit des utilisateurs des services de la structure. Ces derniers sont caractérisés par : o Zone géographique : en fait ceci représente une liste de point de connexion de la structure de recouvrement. Cela caractérise les nœuds de la structure, les plus proche du client final. o Lien d accès : comme précédemment. Débit d accès Délai du lien d accès

54 Caractérisation du contenu Taux de pertes du lien d accès La caractérisation des données ou contenus transitant sur le réseau de recouvrement permet d optimiser l utilisation de la structure en facilitant le choix et l accès des utilisateurs aux bons contenus. Les contenus sont caractérisés comme suit : o La taille S : c est la taille du contenu ou des données en Kbit. o Le service de distribution : c est l architecture de communication nécessaire à l acheminement du contenu (services + protocoles). Ceci peut être traditionnellement, un service TCP/IP, HTTP, RTP, RTSP o Une QoS d accès : c est la qualité de service minimale pour visualiser ou accéder le contenu de façon correcte. Le détail de cette QoS peut dépendre de la structure et des services fournis. Elle s exprime à l aide des paramètres classiques définis dans la section Caractérisation de la charge de la structure overlay Afin de modéliser entièrement le fonctionnement d une structure de recouvrement, il est nécessaire de pouvoir caractériser la charge sur cette structure. Cette charge peut être définie de façon globale ou discrète. o Charge globale : ce sont les capacités maximales de la structure overlay vue de façon globale. C'est-à-dire, le nombre d utilisateurs maximum à un instant donné et le débit maximal (débit engendré par l ensemble des connexions supportées par l architecture) supporté par l ensemble de la structure. o Charge discrète : C est de la même façon que précédemment la quantification du nombre d utilisateurs maximum et du débit maximum supportable cette fois ci par chacun des nœuds de la structure. Le modèle que nous venons de définir permet d être instancié de multiples façons. Chaque partie détaillée de ce modèle permet de caractériser par exemple la structure de recouvrement de la Figure Ainsi en fonction des paramètres d instanciation, il est possible de caractériser différents types de structure de recouvrement, par exemple un réseau de CDN (structure de recouvrement pour le caching), un réseau de P2P (structure de recouvrement de partage de fichier) Un des avantages des réseaux overlay est leur décorrélation du réseau sous-jacent. Une connectivité IP est suffisante pour mettre en œuvre ce type de structure. Cela permet un déploiement rapide et une flexibilité accrue pour les nouveaux services. De plus, il est possible de faire coexister plusieurs réseaux overlay sur une même entité, permettant ainsi de cumuler les services offerts sur ce nœud. Bien que ce type de structure soit de plus en plus déployé, certaines structures de recouvrement ne fournissent que l accès à des services, sans pour autant garantir le fonctionnement de ceux-ci et l accès aux données ou contenus correspondants. Le prochain chapitre utilisera le modèle défini dans cette section pour caractériser deux types de structures de recouvrement, les CDN et les réseaux de P2P afin optimiser et gérer au mieux la structure pour obtenir des garanties de QoS CONCLUSION DU CHAPITRE Ce chapitre a mis en évidence l intérêt de la réplication pour obtenir des garanties de QoS. Ces garanties sont en fait une conséquence des systèmes de caching, les contenus sont

55 plus près des utilisateurs finaux, les chemins sont donc raccourcis et la QoS ressentie est améliorée. Dans le cadre des systèmes de P2P, la réplication des contenus augmente le choix du lieu de rapatriement de ce dernier. Les garanties obtenues sont une conséquence de la popularité du partage d un contenu. Nous avons présenté les CDN mettant en œuvre des solutions de réplications en utilisant les propriétés du caching. Nous avons ensuite abordé les réseaux de P2P qui eux aussi dans leur orientation stockage de données ou partage de fichier compte sur la réplication des données, contenus ou fichiers entre les utilisateurs pour un meilleur fonctionnement. Finalement nous avons proposé un modèle caractérisant les structures overlay. Les deux approches précédemment étudiées sont en fait des cas particuliers de réseau overlay. Le modèle défini dans ce chapitre vise à être suffisamment général pour pouvoir englober les différents types de structures overlay. Dans le chapitre suivant, le modèle ainsi défini sera utilisé de deux façons différentes pour caractériser les deux architectures de réplication étudiées dans ce chapitre. Une fois instancié, le modèle sera utilisé pour quantifier les apports de la réplication et les propositions d optimisation en terme de qualité de service dans chacun de ces réseaux.

56

57 CHAPITRE 4. GESTION DE LA REPLICATION DE CONTENUS DANS LES STRUCTURES DE RECOUVREMENT Résumé Le modèle de caractérisation des structures de recouvrement est utilisé dans ce chapitre pour caractériser tour à tour les systèmes de Peer-to-Peer et les architectures de CDN. En utilisant les caractéristiques de chacune des deux structures de recouvrement, une solution pour améliorer les performances d accès aux contenus, mais aussi permettant de quantifier la qualité de service dans les systèmes de Peer-to-Peer est proposée. Cette approche reposant sur l utilisation de codes correcteurs d erreurs, nommée PeerFecT, est détaillé puis étudiée afin de déterminer les gains par rapport aux approches traditionnelles des systèmes de Peer-to-Peer classique. Dans le cadre des Content Delivery Network, une proposition d amélioration de la gestion des entités de réplication est proposée en se basant la gestion du déploiement effectif du contenu nécessaire pour obtenir un certain type de garantie. Une meilleure gestion de la capacité de stockage peut alors être réalisée et mise à profit pour le déploiement éventuel de nouveaux contenus INTRODUCTION Le Chapitre 2 a mis en évidence les besoins de QoS pour les utilisateurs de l Internet et pour l accès aux nouveaux types de média. Dans le chapitre précédent, nous avons présenté la réplication comme une application alternative au déploiement de la QoS par l intermédiaire des approches réseaux et transport. Deux types de structures de recouvrement utilisant la réplication ont été présentés, les CDN et les réseaux de P2P. Finalement, un modèle plus général venant caractériser les structures de recouvrement a été présenté. Bien que les CDN et les réseaux de P2P mettent en œuvre des solutions basées sur la réplication il n existe toujours pas de réelles garanties de QoS, même statistique pour l accès à un contenu. Dans ce chapitre, nous allons utiliser le modèle présenté dans le chapitre précédent et l instancier pour caractériser chacun à leur tour les paramètres des réseaux de P2P et des CDN afin de proposer des solutions pour optimiser chacune des architectures. La section 4.2 proposera une solution basée sur l utilisation de codes à effacements (erasure code) et de réplication pour augmenter les performances et obtenir des garanties de QoS dans les réseaux de P2P. Ce chapitre se poursuivra par la proposition d un moyen d optimiser l utilisation d un CDN en effectuant une gestion de la réplication des contenus. En effet, dans les CDN classiques, les contenus sont totalement répliqués dans toutes les unités de réplication augmentant la disponibilité de ces derniers mais ne garantissant en rien une QoS de distribution, QoS d accès, pour les utilisateurs finaux. Nous conclurons ce chapitre en ayant obtenues deux solutions pour optimiser des structures de recouvrement particulières nous permettant de proposer une architecture de réplication à gestion de QoS dans le chapitre suivant GESTION DE LA REPLICATION DANS UN SYSTEME DE PEER-TO-PEER Le renouveau des applications de P2P est apparu grâce à l avènement de système de téléchargement de fichiers musicaux comme Napster ou Kazaa. Ces systèmes ont offert de nouvelles possibilités aux utilisateurs de l Internet. Dans le cadre de notre étude, afin

58 d optimiser un système de P2P nous allons nous intéresser plus particulièrement aux architecture de P2P utilisées comme application de partage de fichier. Comme nous l avons montré dans la section 3.4, les réseaux de P2P sont des architectures de recouvrement pouvant offrir différents types de service. Accéder à des données en utilisant un système de P2P permet, par opposition au modèle client/serveur classique, un meilleur accès dans le sens où le contenu peut se situer à plusieurs endroits distincts. En effet, la centralisation d informations sur de simples serveurs qui reçoivent toutes les requêtes des clients, forme assurément un point de congestions pour le réseau. Dans le cadre des serveurs Web, des Web Farms (ensemble de serveurs) ont été déployées à plusieurs endroits dans le réseau pour palier à ce problème. La dissémination des informations et contenus entre plusieurs peers permet de distribuer naturellement la charge réseau entre les différents hôtes. De la même façon, l augmentation des capacités du réseau augmente naturellement les capacités des systèmes de P2P en facilitant les fonctions de routage de haut niveau, (par exemple du load balancing etc.). Finalement, les ressources de stockage et de traitement sont elles aussi partagées entre les différents peers, un même fichier de donnée pouvant être par exemple présent sur plusieurs nœuds. Nous allons à l aide des caractéristiques des applications P2P traditionnelles de partage de fichiers, instancier le modèle qui a été défini dans le chapitre précédent en vue d étudier une solution d optimisation basée sur la réplication et l utilisation de codes correcteurs d erreurs Caractérisation Les applications de P2P de partage de fichiers ont des caractéristiques comparables aux systèmes de stockage distribué classiques, chaque peer représentant une entité de stockage distribuée. La différence majeure est ici le nombre potentiel important de peer, (plus de 1,5 millions d utilisateurs connectés en permanence sur le système Kazaa en mai 2002 [58]). De plus, les peers ne possèdent pas tous les mêmes caractéristiques en terme de stockage, de puissance calcul et de lien d accès. En outre, l infrastructure constituée par ces noeuds est très versatile car chaque peer ne reste pas connecté en permanence. Les paramètres de capacités de stockage, de puissance de calcul, de bande passante et de temps de connexion peuvent varier en moyenne entre 3 et 5 en fonctions des peers du réseau [65]. La majeure partie des nœuds constituant ce type de réseaux est en fait un ensemble d ordinateurs personnels (particuliers) connectés à l Internet par des connexions de type Modem, xdsl ou câble. Le reste des peers est constitué par les nœuds se trouvant dans des réseaux d entreprises ou sur les réseaux académiques. Ces derniers nœuds possèdent alors des capacités d accès en terme de débit beaucoup plus importantes. Les données stockées sont elles aussi différentes entres les différents nœuds. Le type de fichier que l on peut trouver sur ces réseaux de P2P, peut varier de fichier texte de quelques kilos octets à des fichiers de données de plusieurs Gigaoctets. Bien que leurs natures puissent être grandement différentes, (contenus audio (MP3, WMA), vidéo (Divx, MPEG), image (JPEG, GIF), archive (ZIP, RAR), texte, PDF, etc.), ils sont tous présents dans l optique d être téléchargés de peer à peer. Aussi, l un des facteurs important de la qualité de service de ce type de système est le temps téléchargement, directement lié à au débit moyen pour accéder à un fichier de données. Ce temps de téléchargement est généralement le temps le plus important lors de l utilisation d un système de P2P, en effet, les temps de recherches peuvent être négligeables devant le temps de téléchargement d un fichier de grande taille, plusieurs dizaines de Mégaoctets.

59 Compte tenu de ces éléments, la caractérisation des applications traditionnelles de partage de fichiers basées sur une architecture de P2P peut être réalisée de la manière suivante : Caractérisation de la structure globale o Le nombre de nœud N n : le nombre de nœud est variable mais est, en moyenne, toujours très important, (1,5 millions sur le système Kazaa en mai 2002 [58]) ; o Les services offerts par la structure : Il est au moins possible d effectuer des recherches de contenus et de les télécharger. De plus lors de la recherche, il est possible de choisir les peers effectivement utilisés pour le téléchargement. Le résultat des recherches sur les peers et les contenus peut être classée avec une estimation de la bande passante moyenne disponible d accès. Caractérisation d un peer Dans le cas considéré, (système P2P de partage de fichiers), les nœuds sont tous des clients ou utilisateurs finaux de la structure. Ceux-ci sont en majorité des machines (PC de bureaux) de diverses capacités. o Capacité de traitement S CPU : elles sont variables en fonction du type de machine des clients. Cependant, ce paramètre n est pas important pour notre cas d utilisation pour le fonctionnement de la structure. o Capacité de stockage S ST : Elle aussi est variable en fonction des peers. Chacun est à même de configurer la quantité de stockage qu il désire partager ou mettre à disposition. Elle varie entre une cinquantaine de Mégaoctets et plusieurs Gigaoctets pour les peers les plus importants. o Nombre de connexions supportées N Xmax : Ce paramètre est lui aussi paramétrable au niveau de chaque peer, en moyenne avec des réglages par défaut des systèmes classiques, le nombre de connexion supporté par peer est de l ordre d une dizaine de connexions. o Lien d accès au réseau : Comme nous l avons dit dans le paragraphe précédent le lien d accès au réseau du client est souvent une connexion privée. Cependant les architectures de P2P permettent de régler le débit maximum utilisable comme une fraction de débit du lien d accès total. Débit maximum du lien en download et upload X up, X dw varient entre 1 kilobit/s et 3Mégabits/s en moyenne [104]. Délai minimum. Dans le cadre de téléchargement ce paramètre n est pas important. En effet le délai n a pas de sens car le téléchargement ne s effectue pas nécessairement un seul peer. La contrainte temporelle importante est le temps de téléchargement qui n est pas un paramètre caractéristique du lien. Taux de pertes minimal du lien. Au niveau des peers les connexions effectuées reposent sur le protocole TCP, aussi nous considèrerons celui-ci comme négligeable. o Un ensemble de contenu M : Chaque peer détermine s il partage et stocke des données ou non. Ce paramètre est difficilement exprimable ou quantifiable dans le cas d un système de partage de fichier en Peerto-Peer.

60 o Zone géographique : La zone géographique couverte par ce type d architecture est très vaste. Elle comprend des peers sur chaque continent. Caractérisation des contenus Bien que différents types de contenus soient partagé dans le réseau, le système peut être perçu comme un simple service de stockage distribué avec un service de téléchargement comme un site FTP : o La taille S : Elle varie en fonction des contenus de 1kilobit pour de petits fichiers textes ou PDF à 2 GigaBits pour des archives vidéo, la majorité des fichiers étant généralement des morceaux de musique d environ 5Mégaoctets et des vidéos d environ 700 Mégaoctets. o Le service de distribution : Suivant les protocoles sous jacents, les services utilisés majoritairement sont des connexions TCP/IP directes ou des connexions HTTP qui permettent des connexions au travers de certain firewall. o Une QoS d accès : La QoS d accès dépend du type de contenu, afin, pour ce contenu d être visualisé dans les meilleures conditions. Cependant dans le cas d un système de partage de fichier classique, ce paramètre n est pas important pour le système puisque le seul service étudié ici est le téléchargement. Caractérisation de la charge de la structure overlay Que ce soit de façon globale ou discrète, les paramètres de charges sont difficilement quantifiables sans une connaissance pointue du peer, de sa connexion et de ses contenus. o Charge globale : il est difficile de connaître le débit supporté sur l ensemble d une structure de P2P vu le nombre de nœuds. o Charge discrète : par des campagnes de mesures de téléchargement il est possible d obtenir une estimation au niveau de chaque peer. Nous avons pu caractériser notre système de partage de fichier en P2P grâce au modèle défini dans le chapitre précédent. Certains paramètres ne sont pas nécessaires ou n ont pas une influence importante dans le cadre de notre étude. Les paramètres les plus difficiles à caractériser et parmi les plus importants sont en fait globalement la structure réelle du réseau et la charge des divers peers. Nous verrons dans la section suivante comment ces paramètres sont utilisés pour évaluer la proposition d optimisation du système de P2P, appelée PeerFecT PeerFecT : un système de peer-to-peer utilisant une technique de FEC Les travaux de recherches dans le domaine des réseaux de P2P sont divers et variés au vue de la complexité de la structure même du système. La tolérance aux fautes, l authentification, la localisation et l acheminement des données, font partis des domaines de recherches actuels. La mise à l échelle qui fut un point faible des premières architectures de P2P a fait naître de nouveau système basé sur les tables de hachage distribuées ou DHT (Distributed Hash Table), comme CAN [66], CHORD [67], PASTRY [68] ou TAPESTRY [69]. Cependant, dans le cadre d application de partage de fichiers P2P, un point crucial auquel doit faire face chaque utilisateur est le temps d accès aux données et le temps de téléchargement. C est le temps qui sera nécessaire pour récupérer le fichier complet sur un nœud particulier. En effet, dans la plupart des cas le temps de téléchargement est de loin le temps le plus long en comparaison avec les autres délais du processus, comme le temps de

61 recherche. Aussi dans le cadre de notre contribution nous allons nous intéresser particulièrement au temps de téléchargement. Les approches classiques dans ce domaine consistent à déterminer la meilleure position des données dans le réseau pour un peer considéré, et finalement à accéder et télécharger le contenu depuis cette position «optimale» [70][71][72]. L intérêt de cette technique est de pouvoir alors télécharger en parallèle différents morceaux de la donnée stockée sur différents peers. Notre contribution est de proposer en complément à cette technique, l utilisation d un code à effacement (erasure code, également utilisé dans le cadre des «FEC», Forward Error Correction) pour encoder les blocs de données et pour augmenter les performances de téléchargement. Nous nommerons cette approche PeerFecT pour : Peer to Peer with FEC dissemination Technique [102][103][104]. L utilisation de code à effacement sur les blocs de données permet de diluer l information sur un ensemble de blocs plus important, induisant la possibilité de choisir un sous-ensemble de ces blocs pour reconstituer les données initiales et ainsi une disponibilité plus importante de l information disséminées dans les peers. Grâce à la valeur universelle de chaque bloc encodé, l obtention du nombre de blocs nécessaire au décodage sera statistiquement plus rapide que dans le cadre de l approche classique consistant en un simple découpage/dissémination des blocs. Les performances de téléchargement sont alors augmentées et le temps de téléchargement diminue. Nous allons montrer que l approche PeerFecT est statistiquement plus efficace que la réplication de fichier totale sur différent peer dans le réseau ou même la réplication de bloc, pour une même quantité de donnée stockée dans le réseau. Cette propriété est vérifiée dans le cas de téléchargements séquentiels ou parallèles sur différents peers. PeerFect est d autant plus intéressant dans ce contexte de réseau hétérogène et versatile. L utilisation de FEC permet non seulement d augmenter les performances de téléchargement mais améliore également la fiabilité et robustesse comme le montre leur utilisation dans le cadre des systèmes de stockage distribués [73]. La section suivante présente brièvement les codes à effacement et montre quelques une de leurs utilisations. Ils seront ensuite utilisés dans le cadre du système de partage de fichiers en P2P Les codes à effacements (erasures codes) Les codes à effacement sont classiquement utilisés pour protéger les informations des erreurs ou des pertes durant une transmission. Le principe est d ajouter de la redondance d information aux données qui vont être transmises pour permettre à l ensemble des récepteurs de retrouver les données initiales malgré d éventuels problèmes de transmission. Dans les couches hautes des architectures de communication, les pertes de données sont souvent résolues en utilisant des techniques basées sur des ARQ (Automatic Repeat ReQuest). Cependant, dans plusieurs contextes (comme les communications satellites, le lecture de CD-ROM, etc.), ces retransmissions sont remplacées par des codes à effacement qui sont des codes correcteurs définis pour le canal à effacement. Dans le domaine du réseau, les codes FEC utilisés sont en fait un cas particulier de codes à effacement (erasures codes). Généralement, un code FEC considère un groupe de k blocs et génère un groupe de n-k blocs. Avec ces hypothèses, la propriété fondamentale des codes correcteurs d erreurs est de permettre à un récepteur de retrouver les k blocs initiaux dès qu il aura reçu k blocs quelconques parmi l ensemble des n blocs transmis.

62 Plusieurs types de codes peuvent être utilisés dans cet objectif. Cette propriété s applique au code MDS (Maximum Distance Separable) comme les codes Reed-Solomon [74][75][76]. Ces codes sont optimums dans le sens où seuls k blocs parmi les n suffisent au décodage. Une nouvelle génération de code ayant des propriétés de codage/décodage rapide a été proposée pour le canal à effacement [77][78]. Ces codes ont une complexité de codage/décodage linéaire et deviennent «MDS» lorsque la longueur du code «n» tend vers l infini. Dans leurs cas, un ensemble supérieur à k blocs est souvent nécessaire pour reconstruire les données initiales. Dans le domaine du réseau, les codes correcteurs d erreurs sont utilisés dans différents contextes. La communication multipoint fiable utilise des techniques utilisant des FEC afin d éviter l implosion des acquittements et acquittements négatifs, ACK/NACK due au grand nombre de récepteurs. Pour les transmission en temps réel, par exemple la visioconférence, les FEC permettent d éviter d ajouter un délai supplémentaire du à la retransmission des paquets. Au niveau des systèmes de stockage distribué, au lieu de répliquer simplement les données sur différents serveurs, les systèmes supportant la tolérance aux fautes, utilisent des techniques de FEC pour améliorer leur fiabilité. Ceci est réalisé en encodant les données et en les découpant en morceaux qui vont être distribués sur les différents serveurs [79]. L idée est qu un fragment encodé situé sur un serveur pourra compenser la perte de n importe quel autre fragment due à un problème. Dans ce cadre, les codes à effacement sont utilisés pour diminuer le temps moyen de panne [73] Principes de PeerFecT Le système considéré est un système de partage de fichier en P2P classique mettant en œuvre les services définis dans le chapitre précédent (i.e. Gnutella, Kazaa, etc.). Chaque peer est capable connaître les peers du réseau et de localiser des données dans l architecture. On supposera de plus que ces services permettent la dissémination d informations dans le réseau et que l algorithme de recherche permet de déterminer un coût en terme de bande passante pour récupérer une donnée sur un peer. L approche PeerFecT est basée sur le principe suivant. Lorsqu un fichier doit être publié dans le réseau, il est tout d abord découpé en k blocs. Ces différents blocs sont alors encodés avec un code FEC comme le montre la Figure Figure Mécanismes d'encodage et de partage des données. Les k blocs qui constituaient le fichier initial deviennent alors un nouvel ensemble de n blocs encodés. En fonction du code FEC utilisé, les k premiers blocs de l ensemble des n peuvent être ou non les k blocs initiaux. Dans le premier cas, nous sommes dans le cadre d une forme systématique, les k premiers blocs résultent alors du simple découpage du fichier. Les n-k autres blocs intègrent la redondance introduite par le code FEC. Dans le second cas, forme non sémantique, les données originales sont diluées au travers de l ensemble des blocs. La dernière phase, phase de publication, est la dissémination des différents blocs dans le réseau P2P.

63 Une fois les blocs disséminés dans le réseau par un algorithme déterminé ou de façon aléatoire, l obtention d un contenu consiste à télécharger k blocs parmi les n blocs issus de l encodage du contenu original. Ainsi en comparaison à l approche sans encodage FEC, les possibilités de choix des k différents blocs sera beaucoup plus important pour reconstruire les données originales. Quand les blocs sont disséminés dans le réseau, les services de recherche et d évaluation du coût permettent de déterminer les k blocs les plus proches à l aide d une fonction de coût (par exemple dépendant de la bande passante). Les k blocs les plus proches sont alors téléchargés de manière classique. Le contenu original est alors obtenu en décodant ces k blocs. Afin d illustrer le concept et de montrer les bénéfices de notre approche, nous allons présenter un exemple mettant en œuvre PeerFecT sur un réseau de P2P intentionnellement très simple. Comme dans le cas réel, dans cet exemple, le transfert de fichier entre deux peers est réalisé par une connexion directe ayant un coût donné. La structure du réseau est fixée et différentes solutions de dissémination de blocs ou fichier sont alors comparées en fonction de leur coût de téléchargement (Figure 4.2-2). Les trois approches qui vont être comparées sont les suivantes : (a) la réplication de fichier. Dans ce cas le fichier est copié intégralement sur un peer lors de la réplication. Rapatrier le fichier avec le coût le plus faible revient à déterminer le peer possédant le fichier avec un coût de lien le plus petit. (b) la réplication de blocs bruts. Dans ce cas, le fichier est d abord découpé en blocs bruts. Les blocs bruts sont ensuite répliqués sur différents peer aléatoirement. Rapatrier le fichier avec le coût le plus faible revient à déterminer le peer possédant le bloc avec le coût de lien le plus bas pour chaque constituant le fichier. (a) la réplication de blocs FEC (approche PeerFecT). Dans ce cas, le fichier est d abord découpé en blocs puis encodé à l aide d un code FEC MDS. Les propriétés de cet encodage permettent donc, pour reconstituer le fichier original, avec le même nombre de blocs qui constituait le fichier découpé. Les blocs encodés sont ensuite répliqués sur différents peer aléatoirement. Rapatrier le fichier avec le coût le plus faible revient à déterminer un nombre de peer suffisant (nombre de blocs constituant le fichier) possédant un bloc, (n importe lequel) avec le coût de lien le plus bas.

64 Figure Exemple simple illustrant le principe et les bénéfices de PeerFecT par rapport aux approches traditionnelles, par le calcul du coût de rapatriement du fichier. Supposons que le peer n 31 veuille récupérer le fichier. L unité de calcul de coût étant le bloc, dans le cas de la première approche (a), réplication de fichier, télécharger le fichier est donc équivalent à télécharger 4 blocs situés au même sur un même peer, le peer n 7. Le fichier est situé à un coût de 2, ainsi le coût C de téléchargement du fichier est de. Dans le cas de la seconde approche (b), réplication de blocs bruts, chaque bloc brut est répliqué au hasard 2 fois dans le réseau afin de maintenir un volume total de donnée de 8 blocs. Dans le cas du présent scénario, le bloc n 1 est à un coût de 1 ou 2, le choix sera donc pour le plus proche au coût de 1. Le bloc n 2 est à un coût de 2 ou 3, le bloc n 3 est à un coût de 0 ou 2 et le bloc n 4 est à un coût de 4. Reconstituer le fichier original revient à retrouver un exemplaire de chaque type de bloc en faisant la somme des coûts pour chacun. Le coût total est ainsi de. Finalement dans le cadre de la troisième approche (c), réplication de blocs FEC, 8 blocs sont stockés dans le réseau de P2P qui ont été encodés avec un code MDS. Cet encodage permet alors de choisir 4 blocs différents dans l ensemble des 8 disséminés dans le réseau, ce qui permet un plus grand choix (le choix se portant sur les blocs ayant les coûts les plus bas). Ainsi, avec cette approche, nous trouvons un bloc à un coût de 0, un autre à un coût de 1, et 2 autres à un coût de 2, le coût total est alors. Ainsi à l aide de ce petit exemple, nous avons illustré l intérêt qu apporte la proposition. Nous allons présenter dans la section suivante, le modèle que nous avons utilisé pour évaluer les gains de l approche PeerFecT Etude de performances Nous allons quantifier les gains obtenus par notre proposition reposant sur l utilisation d un code FEC. En utilisant un modèle permettant de calculer le coût de téléchargement d un fichier dans trois cas de disséminations différentes : (a) réplication de fichier, (b) réplication de blocs bruts et (c) réplication de blocs FEC, nous avons évalué ce coût de rapatriement du fichier, pour des téléchargements séquentiels et parallèles. Ce coût représente en fait le temps de téléchargement du fichier (i.e. la bande passante moyenne pour accéder à ce fichier).

65 Modélisation du cas séquentiel Intéressons nous en premier lieu au cas du téléchargement séquentiel des blocs. Dans le cas de dissémination (a), le fichier de taille S F est répliqué r fois dans le réseau. Chaque peer possède une bande passante d accès Bw i. Ainsi le coût C (a) pour télécharger le fichier peut s exprimer ainsi : (1) Où C j représente le coût pour télécharger le fichier au niveau du j ième répliqua du fichier entier, S F la taille totale du fichier et Bw j la bande passante correspondante. Dans le cas de réplication de blocs bruts, cas (b), le fichier est alors coupé en k blocs de taille S b égale et chacun des blocs est répliqué r fois. Dans ce cas la, le téléchargement du fichier entier revient à télécharger les k blocs les plus proches et faire la somme du coût de téléchargement de chaque bloc. Ainsi le coût C (b) s exprime ainsi : (2) Où C i,j est le coût de téléchargement du j ième répliqua du i ième bloc, S b la taille d un bloc brut et Bw i,j représente la bande passante associée au rapatriement de ce bloc. Finalement, pour l approche réplication de blocs FEC (c), les k blocs originaux vont devenir un ensemble de n blocs où n-k blocs vont être dus à la redondance induite par le code FEC. Télécharger le fichier revient donc maintenant à télécharger les k blocs les plus proches blocs parmi les n répliqués r fois dans le réseau. Nous définissons, pour i=1,..,n et la fonction telle que : (3) Ainsi le coût de téléchargement du fichier entier dans le cas (c) est C (c) : (4) Afin d être comparable avec les autres approches, nous avons garantie que le volume total de données dans le réseau est équivalent dans toutes les approches. Ceci se traduit par un nombre de blocs r égal à : (5) Ce modèle permet de déterminer le coût de téléchargement d un fichier en accès séquentiel dans les trois cas de dissémination. Cependant, une caractéristique des différents logiciels de téléchargement de fichiers Peer to Peer, est de supporter le téléchargement en parallèle sur plusieurs peers, (i.e. plusieurs blocs peuvent être téléchargés en même temps). Actuellement, lorsqu une donnée est trouvée, plusieurs connexions sont effectuées sur différentes parties du fichiers et différents peers. Le rapatriement en parallèle permet d augmenter les performances de téléchargement, comme dans le cas du mirroring pour les sites Web [80]. Aussi le prochain paragraphe présente une extension du modèle pour évaluer le coût de téléchargement du fichier suivant les 3 approches précédentes avec des accès parallèles aux différents peers.

66 Modélisation du cas parallèle Comme précédemment, dans le cas (a), réplication de fichier, nous considérons le fichier répliqué r fois dans le réseau, chaque fichier pouvant être téléchargé indépendamment, avec les bandes passantes correspondantes, Bw 1, Bw 2,., Bw r. En ouvrant r connexions sur différentes partie du fichier, la bande passante maximale atteinte peut alors être de Bw 1 +Bw 2 + +Bw r. Ce maximum étant atteint si les connexions sont disjointes et n ont pas d influence les unes sur les autres, (bottleneck disjoint). Dans un réseau de P2P, où les connexions peuvent être établies sur des milliers de peers différents, il est difficile de déterminer les points de congestion dus aux téléchargements en parallèle d un même fichier. En supposant le surdimentionnement du réseau de cœur (surdimmensionnement des réseaux d opérateurs), nous considérons qu il ne peut pas apparaître de congestion dans le cœur du réseau (backbone) à cause du trafic du aux téléchargement parallèle d un même fichier. Cependant une congestion peut se produire près du client au niveau du réseau d accès, à cause de la limitation de bande passante, celle-ci dépendant de l abonnement de l usager et donc du coût. Cette hypothèse sera vérifiée par expérimentation dans la suite du document. Ainsi, définissons Bw 0, la bande passante d accès du peer considéré. En utilisant ce nouveau paramètre, il est alors possible de dire que la bande passante disponible pour le peer est le, ainsi le coût C de téléchargement du fichier dans le cas (a) est de : (6) Où représente la bande passante disponible pour le peer considéré et S F la taille totale du fichier. Dans le cas de réplication de blocs bruts (b), le fichier est découpé en k blocs de taille S b et chaque bloc est répliqué r fois. Si on reprend les notations précédentes, de l équation (2), un bloc peut être téléchargé avec un coût, où. Il est alors possible d ouvrir de nombreuses connexions sur différents répliquas d un même bloc, mais cela serait équivalent à avoir un très grand nombre de blocs. De plus ceci pourrait être pénalisant à cause du nombre de connexions ouvertes. Aussi, nous nous restreindrons à une connexion par bloc. Compte tenu de cette hypothèse, k connexions en parallèles sont aux maximums ouvertes. Le coût de téléchargement du fichier dans le cas de l approche (b) est alors. Cette expression est valable de la même façon que dans le cas précédent, si les accès en parallèle sont indépendant les uns des autres. Aussi, si des congestions apparaissent au niveau du réseau d accès à cause de la limitation de bande passante Bw 0. Si, alors le coût est donné par la formule précédente. Si dans le cas ou,, nous supposerons que le débit sera partagé équitablement par le mécanisme de transport (par la propriété d équité du contrôle de congestion de TCP) entre les k connexions, avec une valeur de. Mais si,, la connexion vers se bloc n est pas affectée par cette limitation de bande passante. Le coût ne dépend alors plus que de

67 la valeur minimale de, ainsi le coût de téléchargement du fichier dans le cas de l approche en bloc (b) est égal à : (7) On remarquera que dans le second cas, C(b) est égal à. Dans le cas (c) de réplication de blocs FEC, l analyse peut être la même que dans le cas précédent. Les k blocs originaux deviennent un nouvel ensemble de n blocs avec la redondance introduite par le code FEC. Récupérer le fichier revient à télécharger les k blocs les plus proches parmi les n. Si chacun des blocs est répliqué r fois dans le réseau, on définit comme pour le cas séquentiel, pour i=1,.., n et la fonction f : (8) telle que : Alors la seule différence avec le cas (b), est qu il faut considérer les bandes passantes suivantes,. Avec les mêmes hypothèses, pour les congestions, le coût de téléchargement du fichier dans le cas parallèle pour la dissémination (c) est le suivant : (9) On remarque que l équation (9) utilise le fait que. Simulation Grâce au modèle que nous venons de définir dans le cadre de téléchargements séquentiels et parallèles, nous avons effectués des simulations pour quantifier les gains de notre approche basée sur l utilisation d un code FEC. L idée a été de définir 3 tableaux de taille r pour le cas de la réplication de fichier, de taille k*r et n*r respectivement pour les cas de réplication de blocs bruts et de blocs FEC. Un exemple de tableau et donné à la Figure 4.2-3, en se basant sur l étude de cas de la Figure Afin de garantir une comparaison équitable, nous avons bien sur vérifié l équation (5) qui garantie que dans tous les cas le volume de données stockées dans le réseau est bien égal dans toutes les approches. Figure Exemple de tableau de simulation (cf. étude de cas Figure 4.2-2).

68 Les tableaux sont alors remplis aléatoirement en tirant une valeur selon une loi de probabilité représentative de la distribution des peers en fonction de la bande passante. Chaque valeur du tableau est la valeur de la bande passante correspondante pour télécharger le bloc ou le fichier correspondant. Les équations précédentes permettent alors de calculer facilement et rapidement le coût de téléchargement du fichier. La valeur de référence est le téléchargement du fichier entier, les approches de réplication de blocs bruts et de blocs FEC sont comparées par rapport à cette dernière en calculant le gain entre les deux approches. Ces expériences ont été répétées de fois. Dans le cas de l approche (a) pour la réplication de fichier, nous n avons autorisé que k connexions pour limiter le nombre de connexion TCP ouverte et afin d être dans le même cadre de comparaison que des approches (b) et (c). Comme nous l avons expliqué auparavant, ces simulations ont été réalisées en tirant au sort des bandes passantes suivant une loi de probabilité. Cette loi de probabilité représente la distribution des peers en termes de bande passante. Afin d utiliser une loi de probabilité réaliste, une campagne de mesures a été menée sur le réseau Gnutella pour obtenir une représentation du déploiement des peers en fonction de leur bande passante. Ces mesures ont été réalisées dans le cadre de téléchargements séquentiels et parallèles pour valider les hypothèses que les connexions sont disjointes et n ont pas d influence les unes sur les autres et que les congestions n apparaissent qu au niveau des réseaux d accès. Nous avons réalisé ces mesures sur un réseau d'accès ayant une bande passante suffisamment importante pour ne pas être un point de congestion. En utilisant un client Gnutella, nous avons mesuré la bande passante moyenne lors du téléchargement de 1000 fichiers différents, entre le 1 er et le 29 janvier 2003, sur 1000 peers différents. Ces 1000 fichiers ont été téléchargés deux fois. Dans un premier temps, cas des mesures en parallèle, ils ont été téléchargés 10 par 10, sur 10 peers choisis aléatoirement. Nous avons donc fait 100 téléchargements sur un total de 100*10 peers. Dans un deuxième temps, nous avons téléchargé séquentiellement sur chacun des peers (du cas parallèle), le même fichier que précédemment. Notre client Gnutella été situé sur le réseau local de l'ensica, qui est connecté à un réseau métropolitain par un lien gigabit, ce réseau étant luimême connecté au cœur de réseau (backbone) de la recherche française RENATER, avec un lien d'accès à 155 Mbit/s. Les fichiers téléchargés avaient une taille comprise entre 3 et 4 Mégaoctets. Grâce à cette taille suffisante, les bandes passantes observées peuvent être considérées comme représentatives de la connexion entre le peer considéré et notre nœud. De plus, cette taille de fichier représente une taille typique des fichiers téléchargés sur les réseaux de P2P. Nous pouvons remarquer que le fait d'avoir mesuré la bande passante moyenne permet de tenir compte de l'influence des téléchargements parallèles entre plusieurs peers, les résultats de cette campagne de mesure sont détaillés dans la Figure

69 Figure Topologie du réseau Gnutella en terme de bande passante. La Figure montre que la plupart des peers se situe dans un intervalle entre 1Kbits/s et 30 Kbit/s quel que soit le type de téléchargements parallèles ou séquentiels. Les bandes passantes mesurées ont été regroupées par tranche de 5 Kbit/s pour cette représentation. La similitude des deux courbes nous permet de vérifier les hypothèses émises plus haut, c'est-à-dire que l influence des téléchargements en parallèle l'induit pas de congestion dans le réseau de cœur, les congestions apparaissent uniquement au niveau du réseau d accès. Résultats dans le cas de téléchargements séquentiels Cette première simulation étudie l'impact du nombre de blocs k dans lequel le fichier va être découpé. Ce nombre k, (nombre de blocs constituant le fichier), varie entre 1 et 100 afin de déterminer l impact sur le coût de téléchargement du fichier complet. Dans un premier temps, une comparaison entre les résultats de l'approche réplication de blocs bruts et l'approche réplication de fichier permet de déterminer le gain entre ces deux techniques. Dans un deuxième temps le gain entre l'approche réplication de blocs FEC et l approche réplication de fichier est calculé. Dans cette simulation, le nombre de répliquas r est de 10 pour le fichier comme pour les blocs. Le facteur de redondance n/k pour l'approche avec des blocs encodés FEC est de 5. Aussi, afin de vérifier l'équation (5), le nombre de répliquas pour la réplication de blocs FEC r est égal à 2. Figure Etude du gain en fonction du nombre de blocs k.

70 La Figure montre que dans le cas de téléchargements séquentiels l'approche réplication de blocs bruts ou l approche réplication de fichier sont équivalentes. En d autres termes, que le fichier soit découpé en blocs ou pas ne change pas le coût de rapatriement. La deuxième comparaison montre le gain entre l'approche réplications de blocs FEC et l'approche réplication de fichier. Dans ce cas, le gain atteint très vite 20 % pour en faible nombre de blocs k (environ 15). Le gain se stabilise pour une valeur de k = 30. Découper le fichier et encoder ces blocs à l aide d un code FEC permet de diminuer le coût de téléchargement et cela sans avoir besoin de découper celui-ci en un nombre important de blocs. Ce petit nombre de blocs permet de ne pas surcharger l algorithme de recherche de l architecture de recouvrement P2P. Cette seconde simulation étudie l impact du taux de redondance (n/k) du code FEC sur le coût de téléchargement. Dans ce cas, le fichier est découpé en 20 blocs qui sont répliqués 10 fois. Le nombre total de blocs est fixé à 200. Le coût de référence est le coût pour télécharger le fichier dans l'approche (a) (réplication de fichier). Le gain calculé est obtenu en faisant varier le taux de redondance FEC (n/k), tout en vérifiant l'équation (5) pour déterminer le nombre de blocs à répliquer dans le cas de la réplication de blocs FEC. Comparer le gain entre la réplication de fichier et la réplication de blocs bruts n aurait pas eu de sens dans cette simulation. La figure suivante présente les résultats obtenus pour le calcul du gain. Figure Etude du gain en fonction du taux de redondance n/k. La courbe de la Figure montre que jusqu'à un facteur de redondance égale à 5, le gain croit rapidement de zéro à 18 %, ensuite ce dernier se stabilise. Cette simulation permet de conclure qu un important taux de redondance n est pas important pour obtenir un gain significatif. Ceci permet de limiter la complexité du code et de limiter le temps de codage/décodage. L'utilisation d'un taux de redondance FEC égal à 5 est un bon compromis. Cette simulation étudie la variation du gain en fonction du nombre total de blocs stockés dans le réseau. Le nombre total de blocs dans le réseau est ici limité à 400. Le nombre de blocs bruts constituant le fichier est égal à 20 et le nombre de répliquas varie entre 5 et 20. Le taux de redondance FEC est égal à 5, les blocs FEC sont alors répliqués entre 1 et 4 fois. Les gains obtenus comparent le cas de référence réplication de fichier (a) et les cas de réplication de blocs bruts (b) et de blocs FEC (c). La Figure permet de montrer que l'approche réplication de blocs FEC (PeerFect) obtient toujours de meilleurs résultats en terme de performances de téléchargements.

71 Figure Impact du nombre total de blocs sur le gain. Lorsque le nombre de répliquas augmente l'approche réplication de blocs FEC devient moins intéressante. Ce phénomène s'explique par le fait que lorsque le nombre de répliquas est important la disponibilité de chaque bloc est d autant plus importante. Cependant, augmenter le nombre de répliquas implique augmenter la capacité de stockage de chaque peer dans le réseau. L approche réplication de blocs FEC, (approche PeerFecT), est, dans le cadre de téléchargement séquentiel, toujours plus performante que les autres approches. Les résultats obtenus sont d autant plus important que le nombre de blocs constituant le fichier est faible et que le nombre de blocs stockés dans le réseaux est lui aussi peu important. Résultats dans le cas de téléchargements parallèles L'évaluation de notre proposition PeerFecT est menée cette fois ci dans le cadre de téléchargements parallèles. Les simulations précédentes sont à nouveau réalisées en utilisant cette fois-ci une bande passante d'accès Bw 0 limitée à 500Kbits/s sauf dans le cas de la dernière simulation où l'impact de la bande passante d accès sur les performances de téléchargement est étudié. Cette simulation étudie l'impact du nombre de blocs k dans lequel le fichier va être découpé. Dans les cas de la réplication de blocs bruts et de fichier, le nombre de répliquas est fixé à r = 10, afin de ne pas avoir un nombre blocs répliqués dans le réseau trop important lors de la variation du nombre de blocs bruts de 1 à 40, (400 blocs). Dans le cas de l'approche réplication de blocs FEC, le taux de redondance est fixé à n/k = 5, grâce aux résultats obtenus dans la simulation de la Figure Afin de vérifier l'équation (5), le nombre de répliquas r est égal à 2. La Figure montre que l'approche réplication de blocs FEC est toujours meilleure que l'approche réplication de blocs brut mêmes dans le cas de téléchargements parallèles. De plus, le gain maximum est atteint (environ 60%) pour de petites valeurs de k. Aussi un nombre de blocs k égal à 10 semble être un bon compromis entre les performances de téléchargements et la charge du stockage induite dans le réseau.

72 Figure Etude du gain en fonction du nombre de blocs k. Le gain négatif qui apparaît sur la courbe s'explique lorsque le nombre de blocs est trop faible. Il est alors possible dans des cas particuliers de réplication aléatoire d'obtenir de meilleurs résultats avec de simples répliquas de fichier. Les résultats de la Figure lors de téléchargements en parallèle, viennent confirmer les résultats obtenus dans le cadre de téléchargements séquentiels. Aussi le fichier a besoin d être découpé en un nombre limité de blocs pour obtenir d importants gains de performances. Cette simulation étudie l'impact de la variation du taux de redondance FEC sur les performances de téléchargement. Dans cette simulation le nombre de blocs k est fixé à 20, les simulations précédentes ayant montrées qu un petit nombre de blocs étaient suffisant. Le nombres de répliquas r est égal à 10 pour le cas de référence réplication de fichier (a), de la même façon, un nombre important de répliquas n apportant pas de meilleurs résultats. En faisant varier le taux de redondance, le nombre de répliquas r varie tout en vérifiant l'équation (5). La Figure montre qu avec un faible taux de redondance 2 ou 3, le gain maximum est atteint. Figure Etude du gain en fonction du taux de redondance n/k. Les résultats de la Figure lors de téléchargements en parallèles, confirment les résultats obtenus dans le cadre des téléchargements séquentiels. Un faible taux de redondance suffit pour obtenir un gain de performances important en limitant la complexité du code FEC. Cette simulation étudie l impact de la variation du nombre total de blocs stockés dans le réseau sur les performances de téléchargements. Le nombre de blocs bruts constituant le fichier est égal à 20, nombre limités d après les résultats précédents. Lors de cette simulation,

73 r et r vont varier. Le taux de redondance FEC (n/k) est fixé à 5, conformément aux résultats précédents. Le nombre de répliquas r varie entre 5 et 20, et le nombre de blocs FEC répliqués varie entre 1 et 4. Les gains obtenus comparent le cas de référence réplication de fichier (a) et les cas de réplication de blocs bruts (b) et de blocs FEC (c). Figure Impact du nombre total de blocs sur le gain. La Figure montre que lorsque le nombre de répliquas augmente, l'approche réplication de blocs FEC, PeerFecT, devient moins intéressante, tout en restant largement plus performante pour un nombre total de blocs limités (inférieur à 400). Le phénomène déjà remarqué dans le cadre de téléchargements séquentiels est confirmé, lorsque le nombre de répliquas est important la disponibilité de chaque bloc est d autant plus importante. Cependant, augmenter le nombre de répliquas implique augmenter la capacité de stockage de chaque peer dans le réseau et peut introduire une complexification de la recherche des différents répliquas. Cette dernière simulation étudie l'impact de la bande passante d'accès sur les performances de téléchargement. Le fichier est découpé en k = 20 blocs bruts, (en accord avec les résultats précédents). Le nombre de répliquas pour l approche de référence réplication de fichier et l approche réplication de blocs bruts est r = 10. Dans le cas de l'approche réplication de blocs FEC, le taux de redondance est fixé à n/k = 5 et le nombre de répliquas r = 2 afin d utiliser les résultats obtenus dans les autres simulations. La Figure montre les résultats pour le gain entre les différentes approches et l approche réplication de fichier. Figure Impact de la bande passante d'accès Bw 0 sur le gain.

74 La Figure permet de définir le domaine d'intérêt de PeerFecT. La partie gauche de la courbe (jusqu'à 350Kbits/s), montre que le gain est équivalent entre l'approche réplication de blocs bruts et réplication de blocs FEC. Ce résultat illustre le fait que lorsque le réseau d'accès est un point de congestion le gain n est pas amélioré. Au-delà de cette limite, l'approche PeerFecT, (réplication de blocs FEC), démontre alors tout son intérêt. Globalement, dès que l'utilisateur possède une connexion ADSL, l'approche PeerFecT permet d obtenir un gain de performance non négligeable. L approche réplication de blocs FEC, nommée PeerFecT, est donc particulièrement intéressante aussi bien dans le cadre de téléchargements parallèles que dans le cadre de téléchargements séquentiels. Celle-ci est d autant plus efficace, lorsque le nombre de blocs est relativement petit, environ 20 blocs, lorsque le taux de redondance FEC est petit n/k = 5 et lorsque le volume de données stockées dans le réseau est moyen. La dernière simulation montre que l introduction de bloc FEC ne détériore pas les performances de téléchargements des utilisateurs ayant des faibles débits d accès et améliore de façon importante les performances des utilisateurs ayant des débits d accès supérieur ou égal à des connexions ADSL à 512Kbits/s. Discussion Nous avons donc montré l'intérêt de notre proposition PeerFecT. Cette approche repose sur une architecture de P2P classique, mettant en oeuvre un service de gestion du système de P2P, un service de recherche, un service de téléchargement et un service d'estimations de la bande passante. L idée de devoir rechercher différents blocs séparément pour reconstituer le fichier laisse penser que le temps de recherche risque d être plus important que dans le cas classique de la réplication de fichier. En utilisant un service de nommage adapté pour les blocs et un service de recherche basé par exemple sur l'algorithme de Gridella [63], ce surplus de temps n'est pas introduit. En effet, l'algorithme de Gridella permet de trouver l'ensemble des fichiers ayant un même préfixe. Aussi en nommant chaque bloc avec un préfixe commun, une seule recherche sera nécessaire pour trouver tous les blocs. Une autre remarque peut être faite au niveau de l'estimation de la bande passante vers chaque peer. Cette estimation est importante puisque c'est elle qui permet de déterminer les blocs à télécharger. La plupart des systèmes P2P fournissent des mécanismes pour estimer cette bande passante. Cependant cette estimation n'est pas très précise. Des mécanismes plus évolués pourraient être mis en place pour obtenir une meilleure estimation, tels que [81]. Les mécanismes mis en oeuvre actuellement permettent tout de même de classifier l'ensemble des peers. La valeur exacte de l'estimation n'est pas nécessaire, seul le classement des peers est important. PeerFecT repose sur l'utilisation d'un code FEC pour encoder les blocs. Le code doit posséder différentes propriétés afin de ne pas introduire de surcoût, (overhead). Le temps de codage et de décodage doit être relativement faible. Le nombre de blocs du fichier original est compris entre 10 et 20. L'implémentation de ce code sera faite de façon logicielle et son exécution devra être rapide. Dans la plupart des cas le temps de codage/décodage sera plus rapide que le temps de transmission, aussi le choix du code se porte vers un code MDS. Un code tel que celui proposé dans [82] et basé sur des matrices de Cauchy utilisant des entiers possède de bonnes performances. Le dernier point se penche sur le problème de la dissémination des blocs. Notre proposition suppose que les blocs sont déjà disséminés dans le réseau. Une dissémination réalisée avant tous téléchargements aura un coût non négligeable sur l'utilisation du réseau.

75 Deux possibilités sont alors envisageables. La première consiste à utiliser le téléchargement des utilisateurs. À chaque téléchargement, différents blocs resteront partagés sur les peers ayant obtenus le fichier. Ce mécanisme n introduira pas de coûts supplémentaires dus à la dissémination. La seconde possibilité qui offrirait de meilleures performances pour le téléchargement mais qui possèderait un coût non négligeable, serait lorsqu'une donnée est partagée, celle-ci est alors disséminée dans le réseau en suivant un algorithme préalablement défini limitant le coût de dissémination. L étude d un tel algorithme ne fait pas parti des contributions de ce manuscrit. La section suivante montre comment évaluer la qualité de service dans un réseau de P2P en utilisant les modèles définis dans cette section est en reprenant l'approche PeerFecT Evaluation de la qualité de service dans un réseau de peer-topeer Un facteur important influant le service d un système de téléchargement P2P est lié à la disponibilité du contenu dans le réseau. La qualité de service dans les réseaux P2P peut être définie en terme de disponibilité d'accès du contenu. La plupart des travaux sur la QoS dans les réseaux P2P consistent à étudier la popularité des fichiers afin de déterminer une heuristique pour pouvoir répliquer le contenu [83][84]. La QoS est associée à la fiabilité et au temps pour télécharger la donnée partagée. Ainsi, pour une distribution de peers donnée dans le réseau, le type de garantie statistique qui peut être obtenue est : «Fixant un débit d'accès pour un peer donné, la probabilité de télécharger le contenu C avec une bande passante effective supérieure à un seuil fixé est de X %». Ce seuil dépendra alors de la stratégie de dissémination, du nombre de répliquas dans le réseau, du nombre de blocs k constituant le fichier et du taux d'encodage FEC. En utilisant le modèle défini dans la section précédente, et en considérant les trois approches de réplication de fichier, de blocs bruts, et de blocs FEC, la QoS d'accès dans un réseau de P2P est évaluée. Simulation Le modèle de simulation de la section précédente est utilisé pour évaluer la QoS d accès dans un réseau de P2P en considérant les trois approches de réplication, réplication de fichier, de blocs bruts et de blocs FEC. En ce limitant au cadre de téléchargements en parallèle, 3 tableaux de taille r pour la réplication de fichiers, de taille k*r et n*r, respectivement pour la réplication de bloc brut et de blocs FEC, (cf. les notations de la section ), sont utilisés comme dans la Figure Les tableaux sont remplis par un tirage aléatoire de la bande passante suivant la loi de probabilité définie par la Figure Chaque valeur du tableau représente alors la valeur de la bande passante correspondante au téléchargement du bloc considéré, respectivement du fichier. En utilisant le modèle de simulation précédent, le temps de téléchargement du fichier dans le cas des trois approches de réplication sur un réseau de peers est déterminé. Ces simulations ont été répétées fois afin de tenir des valeurs statistiques représentatives. Le débit moyen de téléchargement (1) a été évalué, puis (2) (respectivement (3), (4)) les débits garantis à 90 % (respectivement 95% et 99%). Ces trois dernières mesures peuvent être considérées comme des exemples de garantie statistique de QoS d'accès à un contenu dans le réseau de P2P, défini dans le paragraphe précédent. Le nombre de connexions en parallèles k à été limité dans le cas de la réplication de fichier afin de rester dans le même ordre de grandeur de comparaison pour les autres approches de réplication de blocs bruts et de blocs FEC.

76 Evaluation de la QoS Cette simulation étudie l'impact du nombre de blocs k dans lequel le fichier est découpé sur la bande passante effective. Afin de rester conforme aux résultats obtenus dans les simulations précédentes, le nombre de répliquas pour le fichier ou pour la réplication de blocs bruts est fixé à r = 10. Pour l approche de réplication de blocs FEC, le taux de redondance est fixé à n/k = 5, et le nombre de répliquas à r = 2 (toujours afin de vérifier l'équation (5)). La Figure présente les résultats au niveau de la bande passante effective obtenue. Figure Impact du nombre de bloc k sur la bande passante effective. La Figure montre que la réplication de blocs FEC permet d'obtenir dans tous les cas une meilleure bande passante effective qu avec les autres approches de réplication. Par conséquent, les garanties de QoS obtenues par la réplication de blocs FEC sont donc meilleures. De plus, nous pouvons remarquer que pour un petit nombre de blocs k = 20, la bande passante moyenne ou les bandes passantes garanties à X % dans le cas de réplication de blocs FEC, sont toutes déjà deux fois supérieures à celles obtenues par la réplication de blocs bruts, le tout pour un même volume de donnée stocké dans le réseau. Cette simulation étudie l'impact du nombre total de blocs stockés dans le réseau sur la bande passante effective perçue. En restant en accord avec les résultats des simulations précédentes, le taux de redondance est fixé à n/k = 5, le nombre de blocs bruts est fixé à k = 20. Le nombre de répliquas pour la réplication de fichier et la réplication de blocs bruts r varie entre 5 et 20, et le nombre de blocs FEC répliqués varie entre 1 et 4. Les résultats de l étude de l impact du nombre de blocs total stockés dans le réseau sur la bande passante effective observée dans le réseau de P2P sont détaillés dans la figure suivante.

77 Figure Impact du nombre total de blocs (répliqua et FEC) sur la bande passante effective. La Figure montre que pour un nombre de blocs limités les garanties de QoS obtenues avec l'approche réplication de blocs FEC sont meilleures que dans le cadre des deux autres approches de réplication. Même si la bande passante effective continue de croître avec lorsque le nombre de blocs stockés dans le réseau augmente, la réplication de bloc FEC devient de moins en moins intéressante en comparaison à la réplication de blocs brut. Comme le montre la Figure , lorsque le nombre de blocs augmente, la disponibilité de chaque bloc augmente aussi limitant ainsi l intérêt d utiliser un code FEC. Néanmoins ceci implique une augmentation notable de la capacité de stockage du réseau. Cette simulation étudie l'impact de la bande passante d'accès du peer considéré sur la bande passante effective. Lorsque le peer étudié, possède un faible débit d accès, l utilisation de la réplication de blocs FEC ne va pas créer une augmentation de débit. Pour rester conforme aux résultats des simulations précédentes, le fichier sera découpé en k = 20 blocs bruts et chacun de ces blocs brut ou le fichier seront répliqués r = 10 fois. Dans le cadre de la réplication de blocs FEC le taux de redondance est fixé à n/k = 5 et le nombre de répliquas à r = 2. Les résultats de l impact de la bande passante d accès sur la bande passante effective perçues sont détaillés dans la Figure Figure Impact de la bande passante d'accès sur la bande passante effective.

78 Les courbes de la Figure démontrent le domaine d'intérêt de la réplication de blocs FEC. La partie gauche de la courbe montre que jusqu'à une bande passante de 350Kbits/s la réplication de blocs bruts et de blocs FEC sont équivalentes en termes de bande passante effective. Si la bande passante d'accès est un point de congestion alors aucun gain ne sera obtenu. La partie droite de la courbe permet de visualiser la bande passante effective maximale qui peut être obtenue dans les divers cas de réplications. Cette bande passante est en fait limitée par la distribution des peers. Finalement, l'approche de réplication de blocs FEC, nommée PeerFecT, permet d'obtenir dans tous les cas une meilleure bande passante effective avec un volume de données stockées dans le réseau identique. Discussion et application Les résultats obtenus dans les dernières simulations permettent de proposer des services statistiques garantis de qualité de service dans un réseau P2P. Il est possible de déterminer une valeur de k, nombre de blocs brut dans lequel le fichier doit être découpé, une valeur de taux de redondance n/k et un nombre de répliquas r pour un contenu donné, afin d'obtenir une bande passante effective statistiquement garantie. Ainsi pour une donnée D nécessitant un débit d accès X, à l aide des simulations précédentes, le nombre de blocs k, le taux de redondance n/k et le nombre de répliquas r peuvent être déterminés pour un réseau de P2P donné afin d obtenir des garanties statistiques de bande passante effective. Une fois déterminé, si ce nombre de répliquas r obtenus à partir de la donnée D sont répliqués aléatoirement dans le réseau de P2P, alors les peers pourront accéder à la donnée D avec une bande passante effective garantie. Un exemple d'application de streaming va illustrer ce concept. Une application de streaming a pour but de distribuer un contenu avec un flux tendu. Ce contenu nécessite un débit pour une visualisation correcte en flux tendu R p. Le but de l utilisation de la réplication de blocs FEC pour cette application est de définir un niveau de «priorité de lecture». En d autre terme, la fin du film ou du morceau de musique ne sera pas accédée avant le début. L idée est donc de découper le fichier en morceau nécessitant des débits garantis différents. Supposons le contenu découpé en morceaux de même taille s, stockés dans un réseau P2P. Chaque morceau est considéré comme un «fichier» pour les trois différentes approches de réplication. Ainsi, chaque morceau peut être simplement répliqué, il peut être découpé en blocs puis répliqués ou alors coupé en blocs et encodé à l'aide d'un code FEC puis répliqué. Soit t p0 la date où doit être visualisé le premier morceau. Le débit X 0 pour récupérer le premier morceau est supposé fixe, le temps (hypothèse : La visualisation du média ne commencera à la réception complète du premier morceau). On suppose que la demande des autres morceaux a été effectuée au même temps t 0. Ainsi les débits nécessaires pour accéder aux différents morceaux, X 1, X 2,.., X n sont tous décroissants et peuvent s'exprimer comme suit : (10) Cette expression permet de déterminer les débits nécessaires pour que le récepteur puisse recevoir le bloc suivant pendant qu'il visualise le contenu. Considérant les débits obtenus et les résultats des simulations précédentes, les paramètres nécessaires pour obtenir une QoS compatible avec le contenu peuvent être déterminés.

79 Un exemple concret évalue cette approche. Considérons un fichier MP3 d'une taille totale de 5Moctets encodé un taux de 128Kbits/s. Découpons le fichier en cinq morceaux de taille 1Moctet. Supposons que le client possède une connexion ADSL avec un débit de 512Kbits/s et utilise 50Kbits/s pour télécharger le premier morceau. Après 160 secondes de téléchargement l'écoute du morceau débute. Les résultats de la Figure sont utilisés pour déterminer les paramètres nécessaires pour obtenir la bande passante suffisante avec 99 % de garanties. Dans le cas d'une réplication de fichier afin de garantir une bande passante de 50Kbits/s, le fichier doit être répliqué plus de 400 fois. Cette approche est trop coûteuse. Les deux autres approches de réplication permettent d obtenir les résultats exprimer dans le tableau ci-après. N du morceau Besoin en terme de débit (Kb/s) 1 50,0 2 28,1 3 23,0 4 19,5 5 16,9 Total 137,5 Blocs sans FEC (k=20) r (taille in Ko) 20 (20000) 8 (8000) 7 (7000) 5 (5000) 5 (5000) 900 Blocs (45000) Blocs FEC (k=20, Fec Factor =5) r' (taille Ko) 1 (5000) 1 (5000) 1 (5000) 1 (5000) 1 (5000) 500 Blocs FEC (25000) Figure Paramètres de dissémination en fonction des bandes passantes requises. Nous pouvons remarquer, que le débit maximum nécessaire pour jouer le média et de 137,5Kbits/s. Ce débit maximal est atteint au début du transfert du fichier et est décroissant tout au long de l'écoute. Le nombre de flux nécessaires pour cet exemple et de 20*5 = 100 et diminue continuellement durant l'écoute. La remarque la plus importante est en fait, que l'approche PeerFecT est clairement plus intéressante en terme de capacité de stockage pour obtenir la même bande passante effective. Dans ce cas-là la capacité de stockage est quasiment divisée par 2. Ainsi le modèle proposé utilisant un encodage des données à l'aide d'un code FEC permet d obtenir des garanties statistiques en terme de bande passante effective pour une application de streaming avec une capacité de stockage réduite par rapport à toutes les autres approches de réplications. Cette approche, PeerFecT, a été étudiée et comparée aux approches traditionnelles. À la vue des résultats obtenus, notre proposition permet une meilleure gestion de la capacité de stockage, tout en obtenant des garanties statistiques de bande passante effective d accès aux contenus REPLICATION PARTIELLE DE CONTENUS DANS UN CDN Les architectures de caching font partie intégrante de l Internet. Sans la présence de serveurs de cache, l Internet ne pourrait pas supporter aujourd hui la charge globale induite par les utilisateurs. Les CDN sont le renouveau des architectures de caching. Ce type de structure de recouvrement offre les services de base des architectures de caching ainsi que les services des Web farms. Des services complémentaires, comme l adaptation des contenus et la redirection des utilisateurs vers un serveur ayant un délai de réponse faible, peuvent être fournis. La popularité et l efficacité des CDN ont pris un essor particulier avec la modification des habitudes des internautes et leur engouement pour de nouveaux contenus multimédias ayant des contraintes de QoS de plus en plus importantes. Ce chapitre propose en premier lieu une caractérisation de ce type de structure de recouvrement en utilisant le modèle qui a été défini dans le paragraphe 3.5. Ainsi, à partir de

80 cette modélisation, et des résultats de la section précédente pour les systèmes de P2P, nous étudierons une solution permettant l obtention de garanties de QoS et une meilleure utilisation de ce type d architecture Caractérisation Les CDN sont des structures de recouvrement offrant différent types de services, comme nous avons pu le voir en détail dans la section Ces systèmes sont constitués de serveurs de grande capacité interconnectés par un réseau privé, ce dernier possédant généralement des ressources importantes. Chaque serveur est positionné en un point stratégique du réseau afin de servir au mieux les utilisateurs finaux. Contrairement aux réseaux de P2P, les différents nœuds sont gérés par une même entité de supervision, le prestataire de service CDN, CDN provider. Les clients des CDN, fournisseurs de contenus, fournissent les contenus à stocker dans l architecture. Cette architecture offre des services de stockage distribué et de redirection simplifiant la mise à disposition d information et de contenus à destination des utilisateurs finaux. Cette opération est transparente pour le client qui n a pas à gérer l ensemble de serveur. Les trois grandes classes de services offerts par les CDN, sont le stockage classique (accès en FTP ou HTTP), le stockage pour contenus streamés (accès en RTP, RTSP, HTTP, etc.), et un service de streaming de flux live. A la vue de ces différents types de services, les contenus et leur QoS d accès vont donc être différents et les solutions d optimisation, vont elles aussi être différentes. En se basant sur le modèle proposé dans le chapitre précédant, la suite de cette section propose une caractérisation des CDN adaptée à l étude de l impact de la réplication sur la QoS perçue. Caractérisation de la structure globale o Le nombre de nœud N n : le nombre de nœud est généralement fixe (sauf cas de panne). Il est constitué par un ensemble de serveurs appartenant au prestataire de service CDN. Le nombre peut varier entre une centaine et quelques milliers, en fonction du marché visé par le CDN provider. o Les services offerts par la structure : Les services offerts sont des services de stockage, de services d accès (p. ex., HTTP, streaming, FTP) et de redirection des utilisateurs finaux vers les contenus. Généralement, des mécanismes de mesures de délai sont mis en œuvre pour déterminer les serveurs ayant le délai le plus faible pour la redirection des utilisateurs finaux. Caractérisation d un nœud ou entité de réplication Dans le cas d un CDN, les nœuds sont des serveurs de grande capacité qui sont interconnectés par un réseau privé ou loué (de grande capacité lui aussi) par le prestataire de service CDN. Les serveurs sont généralement (ou supposés) tous identiques en terme de capacités de stockage et traitement. Seule leur localisation est différente. o Capacité de traitement S CPU : Ces nœuds sont des machines utilisées comme serveur de grande capacité, les performances sont donc importantes et ne posent pas un problème dans le cadre de notre étude. o Capacité de stockage S ST : Celle-ci n est donc pas variable et est généralement la même sur tous les serveurs. En effet les architectures de CDN traditionnelle, comme [42], [43] effectuent des copies miroirs d un serveur donné sur tous les autres pour effectuer les mises à jours.

81 La capacité de stockage de chaque serveur est importante mais finie. Elle s exprime en Giga ou Téra Octets. o Nombre de connexions supportées N Xmax : Ce paramètre dépend de la configuration des serveurs. Les capacités d un serveur HTTP ou d un serveur de streaming peuvent aller de quelques utilisateurs à 5000 connexions simultanées [43]. o Lien d accès au réseau : Le lien d accès de chaque entité est primordial afin de pouvoir offrir un service avec les meilleures garanties possibles. Débit maximum du lien en download et upload X up, X dw sont généralement symétrique sur un réseau professionnel de type CDN. Les connexions sont de l ordre de 10 Mbits/s à 155Mbits/s pour les connexions vers les utilisateurs finaux. L évolution des technologies peut aussi faire augmenter les capacités de liens très facilement. Délai minimum. Ce paramètre varie en fonction des utilisateurs (position géographique) et de la charge de l architecture. Taux de pertes minimales du lien. Dans le cadre de téléchargement entre les unités de réplication ou avec les utilisateurs finaux, nous considèrerons celui-ci comme négligeable. o Un ensemble de contenu M : Chaque entité de réplication possède le même ensemble de contenus. Chaque serveur est un clone de l unité de réplication principale. o Zone géographique : cette zone représente l ensemble des clients qui peuvent être servis par cette entité de réplication avec une QoS maximale garantie. C est dans la plupart des cas cette zone est représenté par les utilisateurs qui sont directement connectés au point de présence POP. Caractérisation d un utilisateur final Les utilisateurs finaux sont les internautes. Aussi leurs caractéristiques peuvent variées très largement. Ces derniers sont caractérisés par : o Zone géographique : C est la liste des serveurs les plus proches en terme de délai et de bande passante (en terme de QoS). o Lien d accès : comme précédemment. Débit d accès il varie de 56kbits/s à 100Mbits/s pour les utilisateurs sur des réseaux d entreprises ou des réseaux universitaires. Délai du lien d accès, variable en fonction de la position Taux de pertes du lien d accès : négligeable. Caractérisation des contenus Les contenus qui vont être stockés dans un CDN sont plutôt des contenus de taille importante. En effet, ceux sont pour la plupart des sites Web complet, et pour la majorité des contenus des vidéos streamées de grande taille :

82 o La taille S : Elle varie en fonction des contenus d une dizaine de mégaoctets pour les contenus les plus fréquents comme des courtes séquences vidéo à 2 GigaBits pour des films complets. o Le service de distribution : Suivant les services utilisés, la distribution utilise différents protocoles. Classiquement, les services de distribution utiliseront des connexions, HTTP, FTP, RTP, RTSP. o Une QoS d accès : Chaque contenu possède ses propres caractéristiques d accès. Ces caractéristiques sont définies à l aide des paramètres traditionnels de QoS [33]. Les contraintes de délai, et bande passante sont les paramètres qui nous intéresseront. Caractérisation de la charge de la structure overlay : La charge d un réseau CDN caractérisée de façon globale ou discrète est difficilement quantifiable. Le nombre de connexion peut être déterminé mais la charge en terme de réseau est difficilement quantifiable. o Charge globale : Il est difficile de connaître le débit global (généré par l ensemble des connexions des utilisateurs finaux) supporté par l ensemble d une structure CDN, le réseau d accès ne faisant pas parti de la structure CDN. o Charge discrète : Par des campagnes de mesures de téléchargements ou par interpolation du nombre de connexions par serveur, il est possible d obtenir une estimation au niveau de chaque serveur. L architecture CDN a pu être exprimée grâce au modèle défini dans le chapitre précédent. Certains paramètres ne sont pas nécessaires ou n ont qu une faible importance dans le cadre de notre étude, d autres sont plus difficiles à caractériser comme la charge ou la représentation de la structure globale en terme de bande passante pour les utilisateurs finaux. La section suivante va exploiter certains aspects de cette caractérisation afin d étudier l impact de la gestion des contenus sur la QoS fournie par l architecture CDN Gestion des contenus Les travaux de recherche dans le domaine des CDN s'intéressent aux diverses phases de fonctionnement de l'architecture. De nombreux travaux portent sur l'interconnexion de CDN, visant à faire face aux problèmes de facturation, d'authentification et aux problèmes de redirection entre les différents CDN. La gestion des entités réplication fait aussi partie des études prioritaires, en se basant l étude des habitudes d accès des utilisateurs. La prédiction du comportement des utilisateurs et l'accès aux divers contenus sont étudiés et essayaient d'être gérés à l'aide de filtres de Kalmann-Bloom ou des mécanismes en gestion de priorités de type Diffserv. Finalement, l étude du déploiement des contenus est étudiée afin de déterminer l'impact sur les utilisateurs finaux [85]. Cependant ces études se basent pour la plupart sur une structure de graphe et n'étudient généralement que l'impact en termes du nombre de réponses («hits») du système, comme pour les architectures de caching traditionnelle. Contrairement à ces études, cette contribution étudie le déploiement des contenus afin d'évaluer l'impact sur la QoS ressentie par les utilisateurs finaux. Comme précédemment à l'aide d'une représentation en terme de débit de la structure overlay CDN, l'impact de la variation du nombre de contenus est étudié.

83 Etude préliminaire Les CDN sont des structures de recouvrement privées appartement à un prestataire de service CDN. Elles sont constituées d'entités de réplication de grande capacité et de connexions réseau à très haut débit. Ce type d'architecture est relativement statique contrairement au cas précédent des réseaux de P2P. En effet ici, la présence des nœuds est stable au sein de la structure. Les entités de réplication sont placées à des endroits stratégiques dans le réseau en fonction des clients potentiels visés. Aussi, pour un utilisateur donné, la répartition en terme de bande passante peut être déterminée par avance en fonction de la construction du CDN. La variation de cette répartition est ensuite due uniquement à la charge du réseau et de l'architecture. La plupart des CDN utilise le principe de mirroring de leurs entités de réplication. Chaque noeud est en fait le miroir des autres et tous les nœuds possèdent exactement les mêmes contenus : c est une réplication totale du contenu. Ce principe, permet d'obtenir les performances maximales, mais peut aussi amener une utilisation non optimale de l'architecture, au niveau de la gestion de la capacité de stockage. Les CDN offrent de plus différents types de services pour des contenus variés ayant des QoS différentes. Chacun des services présentés dans la section (p.ex., streaming, streaming live, stockage, distribution FTP, http) peut demander une gestion différente de la réplication des contenus. En effet, au niveau du stockage de contenus devant être accédés par téléchargement (FTP, HTTP, etc.), ou dans le cadre d'accès à des contenus streamés, les résultats obtenus dans la section précédente avec les réseaux de P2P peuvent être directement utilisés. En effet, la structure de recouvrement étudiée correspond au modèle de structure stockant des contenus qui doivent être téléchargés avant d'être utilisés. Il est alors possible de déterminer un nombre de blocs et un taux de redondance à utiliser pour disséminer aléatoirement les blocs sur la structure de recouvrement afin de satisfaire une QoS déterminée. Ainsi, optimiser ce type de service peut être réalisé en utilisant les résultats précédent et en utilisant un service de P2P. Le cas du streaming live n est pas caractérisé par le même type de contraintes. Ce type de service s apparente à la diffusion d'un flux continu de média. La distribution d'un flux continu live ne peut pas tirer parti efficacement d'une architecture de réplication. La section a montré qu une structure de recouvrement peut être utilisée pour effectuer une distribution multipoint applicatif. Optimiser ce service, revient à étudier et optimiser la diffusion de flux continu à l'aide de IP multicast ou en utilisant une structure de recouvrement. L'optimisation de ce service ne fait pas partie de la présente étude. Le dernier type de service offert par les architectures CDN est le stockage et la distribution de site Web utilisant les protocoles HTTP ou HTTPS. Le cas de ce type de contenus ne peut pas être traité comme précédemment pour le stockage de contenus téléchargés dans une structure de recouvrement. Ces contenus sont constitués par de nombreuses pages Web ou autres média qui doivent être accédés par un navigateur. Il est difficilement concevable d'imaginer découper en morceaux et d encoder à l'aide d'un code FEC une simple page ou même une partie de site Web. En effet, la qualité de service (débit, délai, etc.) pour des contenus de si petites tailles est peu élevée. Le temps de redirection vers les bons blocs et le temps de décodage, dans le cadre d'une approche utilisant une dissémination basée sur un découpage et un encodage FEC, seraient plus important que le téléchargement de la page Web seule.

84 L approche pour la gestion de ce type de contenus dans le cadre des architectures CDN est différente. L idée est d étudier comment une réplication partielle peut être menée pour répondre à un objectif en terme de qualité de service. Une solution étudiant les caractéristiques des contenus et ne demandant qu une réplication partielle va être étudiée. L impact de la variation du nombre de répliquas dans le CDN sur le nombre de connexions avec une QoS prédéfinie possible va être quantifié Etude de performances de la réplication partielle Modélisation de l architecture Afin d étudier, l'intérêt du mirroring employé dans les structures CDN, et de proposer une solution basée sur une utilisation d'un nombre de répliquas moins important, intéressons nous à une architecture CDN de moyenne envergure, (par exemple un prestataire de service CDN national). Ce système sera par exemple constitué de 100 entités de réplication ayant une capacité de stockage Cs, pouvant supporter 5000 connexions simultanées et ayant un lien d accès réseau de 5Mbits/s. Afin de faciliter l'étude, seule une zone géographique particulière va être considérée. Comme dans le cadre de l'étude du système de P2P, où le cas d un peer particulier a été considéré, l'impact de la variation du nombre de répliquas pour les utilisateurs d'une zone géographique donnée va être étudié. Considérons des utilisateurs connectés à Internet par l'intermédiaire d'une connexion réseau haut débit de type xdsl ou câble de capacité 1024Kbits/s. Etant tous connectés chez un même prestataire, les serveurs du CDN étant fixes, l'ensemble des utilisateurs de cette zone géographique aura la même vision en terme de bande passante du système CDN. La Figure donne un exemple possible de distribution des entités de réplication d un CDN pour une zone géographique donnée. Figure Exemple de Distribution - Regroupement par ligne de niveau. Pour simplifier l'étude, des ensembles d'entités de réplication sont regroupés selon les capacités de bande passante qu'ils peuvent fournir aux utilisateurs de la zone géographique. Ce regroupement permet de créer, comme le montre la Figure 4.3-1, un ensemble de courbes de niveaux. La distribution des entités de réplication de notre CDN pour la zone géographique considérée, est telle que : Niveau 1024Kbits/s Niveau 512Kbits/s Niveau 256Kbits/s Niveau 128Kbits/s Niveau 64Kbits/s Niveau 32Kbits/s Zone A 5 entités C 1, C 2,.., C 5 5 entités C 6, C 7,.., C entités C 11, C 12,, C entités C 41, C 42,., C entités C 71, C 72,., C entités C 91, C 92,, C 100 Figure Distribution des entités de réplications en terme de bande passante pour la zone A

85 Le tableau présenté Figure permet par exemple de constater que 5 entités de réplication peuvent stocker des contenus ayant une contrainte de QoS comprise entre 1024 et 512Kbits/s. De manière similaire, pour un contenu associé à un débit de 150Kbits/s, 40 entités de réplication au total peuvent fournir cette QoS. La Figure permet alors d'effectuer une représentation de la distribution des noeuds du CDN en terme de bande passante pour les utilisateurs de la zone géographique considérée. Figure Distribution des noeuds CDN en terme de bande passante. Les représentations de la Figure sont les distributions des entités de réplication en fonction de la charge réseau considérée. La courbe foncée la plus à droite est la représentation graphique des résultats du tableau présentée Figure 4.3-2, c est la représentation en terme de débit des entités de réplication de la structure considéré pour les utilisateurs de la zone géographique à charge nulle. En considérant la charge réseau uniformément répartie sur les entités de réplications, cette hypothèse se justifiant par l utilisation d algorithmes de redirection qui permettent d'effectuer du load balancing entre les serveurs et donc de répartir la charge équitablement entre les différents serveurs, (cf. chapitre 3.3). Ainsi, les courbes suivantes se déduisent par un calcul de distribution de charge uniformément répartie sur l ensemble des entités de réplication. Ces premières courbes permettent déjà de dire, que pour une architecture chargée à 65% (courbe claire la plus à gauche), les utilisateurs de la zone considérée ne peuvent obtenir dans le meilleur des cas des contenus d'au plus 384 Kbits/s. De plus, pour un contenu ayant une QoS de 200Kbits/s, avec une charge réseau de 65%, seulement 10 entités de réplication peuvent fournir cette QoS. Si l hypothèse de réplication totale est prise, il est alors possible de conclure qu'un grand nombre de répliquas de ce contenu est inutilement stocké dans le système CDN. Déterminons le nombre d'utilisateurs de la zone géographique qui peuvent accéder un contenu ayant une QoS fixée, en respectant cette limite. Nous ne nous intéresserons pas au nombre maximal de réponse possible de l architecture, mais au nombre maximal de réponse possible satisfaisant la QoS désirée. L équation (11) formalise pour chaque entité de réplication en fonction de sa charge, combien d utilisateurs peuvent être servis avec une QoS déterminée dans le cas de l architecture considérée à la Figure En fonction du débit restant sur l entité de réplication, le nombre de connexion possible selon une QoS donnée (dans ce cas un débit fixé) est calculé.

86 (11) L équation (11) va permettre de calculer le nombre d'utilisateurs qu'il est possible de servir avec une QoS donnée, soit dans le cas d'une approche CDN (mirroring des entités de réplications), soit dans le cas de notre proposition visant à diminuer le nombre de répliquas en les positionnant à des places stratégiques dans le réseau. Résultats Etudions tout d abord, le nombre d'utilisateurs qu'il était possible de contenter avec une QoS fixée, en utilisant l'approche classique du CDN (réplication totale des contenus, soit toutes les entités contiennent tous les contenus), la répartition des entités de réplication étant basée sur la distribution en terme de débit de la Figure Pour différentes valeurs de contraintes de QoS de contenus, la Figure présentent l'évolution du nombre de connectés pouvant accéder le contenu avec sa QoS associée, en faisant varier la charge globale du réseau de façon uniformément répartie. A partir de l équation (11) en faisant varier la charge (bande passante utilisée) de 0 à 90%, pour différentes QoS à assurer, le nombre d utilisateurs pouvant être servie par l architecture est ainsi calculé. Les courbes de la Figure sont sans surprise, au fur et à mesure que la charge augmente le nombre de connectés pouvant être servis avec la QoS correspondante diminue. Toutefois des paliers apparaissent définissant les zones ou des ensembles de serveurs ne sont plus en mesures de répondre aux contraintes de QoS. Figure Nombre maximal de connectés possible (approche quecdn) pour une QoS fixée à charge variable. Ainsi la Figure montre que lorsque la charge croit, une partie des serveurs n'est plus en mesure de fournir une QoS donnée.

87 Quantifions alors la capacité de stockage utilisée inutilement dans l architecture, dans le cadre d une réplication totale. En reprenant la distribution des entités de réplication de la Figure et à l aide de l équation (11), le nombre de serveur ne pouvant pas fournir une QoS fixée est calculé. Les résultats de la Figure mettent en évidence la capacité de stockage utilisée inutilement dans le cas de l approche CDN pour un contenu ayant une QoS de 50Kbits/s en faisant varier la charge globale du réseau. Figure Capacité de stockage perdue pour le cas d'un CDN. La courbe de la Figure permet de mettre en évidence le nombre de répliquas inutiles dans le CDN global pour garantir une QoS fixée à 50Kbits/s pour une zone géographique donnée. Dans le cas d'une charge réseau comprise entre 30 et 60%, 30% du volume occupé au niveau de l architecture CDN par le contenu donné est inutile. En conclusion 30% des entités réplication ne sont pas en mesure de répondre avec la QoS correspondante au contenu, ne serait-ce qu'à un seul utilisateur de la zone géographique étudiée. Etudions maintenant l impact d une réplication partielle. A la vue des résultats obtenus à la figure précédente, pour une QoS fixée et une charge réseau donnée, seul un ensemble de serveurs est capable de contenter les utilisateurs finaux. Aussi étudions l'impact du nombre de répliquas sur le nombre de connectés pouvant être servi avec des contraintes de QoS imposées. Le positionnement de ces répliquas aura une importance non négligeable dans ce cas là. Afin d être le plus compétitif possible par rapport à l'approche traditionnelle CDN, les répliquas sont placés dans les entités de réplication selon l'ordre suivant : 1 répliqua dans l entité C 1, 2 répliquas dans les entités C 1, C 2, etc. Ainsi le but est de remplir les entités ayant les plus grandes capacités en termes de débit en priorité. Pour une charge réseau fixée à 50%, à l aide de l équation (11) et de la répartition des entités de réplication (Figure pour une charge de 50%), le nombre d utilisateurs pouvant être servis avec une QoS fixée est déterminé en faisant varier le nombre de répliquas stockés dans l architecture, de 1 a 100 (100 étant la cas d une réplication totale, approche CDN).

88 Figure Nombre de connectés possible pour une QoS fixée en fonction du nombre de répliquas (meilleur positionnement). La Figure montre l'évolution du nombre d utilisateurs pouvant accéder à des contenus avec différentes valeurs de QoS associées, avec une charge réseau de 50% et la répartition des entités de réplications suivant la distribution de la Figure Les résultats obtenus montrent la croissance du nombre d'utilisateurs en fonction du nombre de répliquas jusqu'à l arrivée à la valeur maximale égale au remplissage complet de toutes les entités de réplication (cas du CDN). Ces résultats permettent de déterminer un nombre minimal de répliquas nécessaire pour garantir statistiquement un nombre d utilisateurs accédant à un contenu avec une QoS donnée. Etudions maintenant le gain entre l approche de réplication partielle et l approche traditionnelle de réplication totale CDN. Comme dans le cas précédent, la distribution des entités de réplication est celle de la Figure avec une charge réseau uniformément répartie de 50%. Pour 3 contenus avec des QoS associées différentes, (5Kbits/s, 40Kbits/s et 150Kbits/s), l équation (11) permet de calculer le nombre total d utilisateurs pouvant être contentés avec la bonne QoS pour le cas d un remplissage complet du CDN et en faisant varier le nombre de répliquas. Une fois se nombre d utilisateurs calculés dans tous les cas, le gain entre la réplication totale (CDN) et la réplication partielle peut être calculé en faisant varier le nombre de total de répliquas dans l architecture. Figure Gain de comparaison entre un CDN et une architecture à nombre de répliquas variable. La Figure montrent que pour des contenus de faible QoS (5Kbits/s) une diminution de 50 % du nombre de répliquas n'induit qu une perte de 20 % sur les

89 performances obtenues avec une architecture CDN. Cependant le gain en terme de capacité de stockage lui n est pas négligeable (50% de capacité de stockage libérée). De la même façon, pour les contenus à forte qualité de service (>150Kbits/s), il est possible de récupérer 90 % de capacité de stockage, le gain du remplissage complet de l'architecture CDN étant nul pour la zone géographique considérée pour un nombre de répliquas supérieur à 10, les serveurs n étant pas en mesure de fournir aux utilisateurs la QoS désirée Discussion Les résultats obtenus dans le cadre d une réplication partielle mettent en évidence le fait qu'une grande capacité de stockage peut souvent être utilisée de façon inadéquate dans le cas d'une approche CDN traditionnelle où la réplication des contenus est totale. Ainsi en définissant pour l architecture, un service de garantie statistique de QoS, qui doit assurer un nombre minimal de connexion pour une QoS fixée et pour une charge réseau donnée, il est possible de déterminer le nombre de répliquas nécessaires et la position de ces derniers pour obtenir le service désiré pour une zone géographique donnée. Une meilleure gestion (en terme de stockage et de QoS) de la structure de recouvrement CDN est ainsi réalisée en utilisant la place minimale pour le contenu considéré. Ainsi, le volume de stockage libéré peut permettre de prendre en charge plus de contenus. En d'autres termes, en gérant le nombre de répliquas des divers contenus et leurs positions, pour une même architecture de recouvrement CDN, l approche de réplication partielle permet de stocker un nombre plus important de contenus, en garantissant statistiquement un nombre de connexions minimales avec la QoS correspondante au contenu CONCLUSION DU CHAPITRE Ce chapitre a présenté deux propositions de gestion de la réplication dans des structures de recouvrements différentes. En utilisant une modélisation des systèmes de recouvrement adaptée à l étude de la réplication, nous avons étudié les systèmes de P2P et proposé une solution de gestion des répliquas reposant sur le découpage en bloc des contenus et l'encodage à l'aide d'un code correcteur d'erreur (FEC). Cette proposition nommée PeerFecT a été évaluée dans différents contextes de téléchargements. La caractérisation des CDN et de leurs services ont permis de proposer une solution de gestion des répliquas adaptée à chacun des services. Dans le cadre de ce chapitre, l'impact de la réplication partielle des contenus a été étudié afin d'obtenir un service de gestion de la réplication pouvant fournir des garanties statistiques de QoS, utilisant un nombre minimal de répliquas placés en des positions caractéristiques. Cette solution de gestion des répliquas a permis de conclure que pour une architecture donnée, le nombre de contenus à disposition des utilisateurs finaux sera plus important que dans le cadre d'un système CDN traditionnel. Les propositions d amélioration de la gestion de la réplication dans le cadre de ces deux types de systèmes recouvrement permettent de définir des briques de bases, pour construire une architecture de réplication à gestion de qualité des services statistiques. Le chapitre suivant va présenter notre proposition d'architecture de réplication à gestion de QoS.

90

91 CHAPITRE 5. PROPOSITION D UNE ARCHITECTURE DE REPLICATION A GESTION DE GARANTIE DE QUALITE DE SERVICE Résumé Dans ce chapitre, une proposition d architecture de réplication à gestion de garantie de qualité de service statistique est étudiée en utilisant les propositions d amélioration des deux différents types de structures de recouvrement que sont les réseaux de Peer-to-Peer et les Content Delivery Network détaillées dans le chapitre précédent. Cette architecture reposant sur la réplication, la notion de contenu est tout d abord définie afin de déterminer quels types de contenus peuvent bénéficier des avantages de la réplication. Pour cela, un modèle de description des contenus en XML est proposé. Reposant en partie sur une architecture de Content Delivery Network, la description physique et logicielle de cette proposition d architecture de réplication est mise en avant. Les services de l architecture sont détaillés ainsi que le fonctionnement général utilisant la description des contenus et les différentes caractéristiques des services. Les différentes phases de la communication entre les entités de réplication, phase de réplication et phase de distribution des contenus sont étudiées pour finir la caractérisation complète de cette architecture de réplication à gestion de qualité de service INTRODUCTION Les Chapitre 2 et Chapitre 3 ont mis en évidence les besoins en termes de QoS des utilisateurs et des applications ainsi que les structures et moyens mis en œuvre à l heure actuelle pour déployer des garanties de services alternatifs au traditionnel service «au mieux» (Best Effort). Deux types de structure de recouvrement ont été présentés avec les services qu ils peuvent fournir. Le Chapitre 4 a proposé des solutions pour la gestion des répliquas dans les systèmes P2P et CDN, afin d obtenir des garanties statistiques de QoS ou une meilleure gestion de l architecture globale. Finalement, ceci a permis de définir des briques de bases pour construire une architecture de réplication à gestion de garanties de QoS. Basée sur le principe d une architecture de CDN classique, ce chapitre propose une architecture de réplication mettant en œuvre les solutions du chapitre précédent pour offrir des garanties statistiques de QoS et une meilleure gestion globale. La section 5.2 défini la notion de contenu dans le cadre de notre proposition ainsi que le modèle de spécification utilisé pour la mise en œuvre. La section 5.3 décrit les choix matériels et logiciel de l architecture. La section suivante, défini les services et types de garanties qui peuvent être mis en œuvre avec cette architecture. Le fonctionnement et les protocoles utilisés sont présentés dans la section 5.5. Finalement, le chapitre est conclu en évoquant les perspectives et évolution possible de cette architecture DESCRIPTION DE CONTENU La définition d une architecture de distribution de contenus basée sur l utilisation de la réplication pour assurer des garanties de QoS en complément des approches traditionnelles de niveau réseau et transport va être réalisé. Celle-ci repose sur le principe d une architecture de caching ou de CDN : un contenu sera répliqué dans le système si celui-ci possède des contraintes temporelles souples, une pérennité suffisamment importante. La première étape de

92 cette construction est un raffinage de la notion de contenu afin de déterminer si celui-ci sera réplicable ou non Définition Un contenu est considéré comme un ensemble de données multimédia à distribuer. Traditionnellement, dans le contexte de la spécification de la qualité de service dans les réseaux, seules les caractéristiques afférentes aux données effectivement acheminées par le réseau sont décrites. Par exemple, la description de la qualité de service nécessaire à la diffusion d une séquence vidéo sera exploitée pour déduire les ressources de communication à mettre en œuvre pour la réalisation cette distribution. Il est ainsi naturel de ne s intéresser qu au média vidéo qui transitera effectivement par le réseau. Cependant, dans le contexte de la réplication de donnée, il est nécessaire de caractériser également les services permettant la distribution du contenu. Pour reprendre l exemple d une séquence vidéo, une hypothèse forte concerne la disponibilité au niveau du serveur comme du client, des protocoles pour véhiculer le contenu. Une version adéquate du protocole de niveau application est supposée exister dans chaque protagoniste de la communication, pour assurer la distribution du média de bout en bout (par exemple, un client/serveur de vidéo à la demande). De manière analogue, toute la communication repose sur l existence d une pile de protocole TCP/IP pour la communication de niveau transport et réseau. Nous supposerons que le contexte de communication de l architecture présentée ici assure l existence, sur tous les nœuds, des protocoles assurant la connectivité Internet (architecture TCP/IP), éventuellement complétée par des services avancés au niveau transport (p.ex., protocole FPTP [33]) comme au niveau réseau (p.ex., Diffserv, Intserv [15][20]). Il reste cependant à s assurer de la disponibilité des services de niveau application si une réplication du contenu est envisagée. En conséquence, nous supposerons qu un contenu est modélisé par un objet, regroupant un ensemble de données et un ensemble de services. Les services peuvent être des références à des protocoles normalisés (par exemple, HTTP, FTP, RTP, etc.) ou éventuellement des méthodes spécifiquement adaptées. Au niveau d un nœud, si les services nécessaires à la distribution d un contenu sont disponibles localement, cela indique que l environnement de distribution du nœud est adapté à la réplication de ce contenu. Seul, l acheminement des données sera ainsi nécessaire pour assurer la réplication Description de contenus Tous les types de contenus ne sont pas forcément candidats à la réplication. Un contenu est «réplicable», si les données le caractérisant au niveau de l application sont telles que leur génération est décorrélé de leur présentation. Certains médias comme la vidéo issue d une application de vidéo à la demande, ne nécessitent une QoS importante qu au niveau de leur distribution. Pour permettre d exploiter cette possibilité de réplication, il faudra donc distinguer leurs besoins de communication pour leur acheminement vers l entité de réplication, de ceux permettant leur distribution. La figure suivante illustre cette idée.

93 Figure Besoin en terme de communication pour la réplication et la distribution. Une expression des besoins en terme de communication permet de décrire les contraintes associées à la réplication comme celle associées à la distribution. En ce qui concerne la distribution, il s agit ici d une technique classique visant, à partir de la spécification des besoins applicatifs, à déterminer comment acheminer le flux de distribution vers le client final. Notons qu il est possible que les ressources de distribution ne soient pas compatibles avec les contraintes exprimées. Dans ce cas, aucunes garanties ne pourront être obtenues pour le contenu considéré. L expression des besoins doit également permettre de décider si la réplication est possible. Il se peut qu il n y ait pas moyen de répliquer ce contenu car le contenu ne s y prête pas ou parce que les ressources de réplication ne sont pas disponibles. Si la réplication est envisageable, il reste à définir la mise en œuvre de cette réplication, dans le cadre d une architecture «ad hoc» préalablement déployée. Déterminer comment mettre en oeuvre la réplication demande plusieurs autres informations, notamment au niveau de la topologie de réplication, de la localisation des clients et des ressources réseau permettant d assurer la qualité de service de réplication. Les paragraphes suivants présentent les paramètres de spécification nécessaires à la description des aspects de distribution et de réplication Aspects liés à la distribution La caractérisation des contraintes liées à la qualité de service de distribution revient à définir les paramètres classiques de qualité de service pour un flux. Les organismes de standardisation de l Internet ont mis en avant des caractéristiques et ont définis des standards pour permettre une caractérisation ces éléments de QoS. Les recommandations de L ITU-T [87], les standards du modèle ISO permettent de fixer certains paramètres de communication pour caractériser les besoins du flux de distribution. Ces besoins peuvent être exprimés en terme de : Débit : Elle définie la capacité d un système de communication par le débit maximal lors d une transmission de donnée, celle-ci s exprime le plus souvent en Kbps ou kilobits par seconde. Les paramètres temporels : (a) Le délai, il caractérise le temps de transfert d un paquet de donnée depuis l émetteur jusqu au récepteur. Il peut être caractérisé par le temps d aller-retour RTT (Round-Trip-Time). (b) La gigue, elle est définie par la variation du délai entre des paquets de données reçus par le récepteur. Cette variation est notamment due au stockage des paquets de données dans les files d attente des nœuds de communication intermédiaire (routeurs). La fiabilité : elle décrit les contraintes de fiabilité d un flux. Classiquement, la fiabilité peut être totale (pas de perte admise) ou nulle (aucune contrainte de

94 fiabilité). Plus généralement il est possible de définir la fiabilité partielle permettant de perdre certaines informations du flux. Selon les besoins, plusieurs outils de spécifications peuvent être utilisés pour exprimer ce paramètre. On peut par exemple la définir par le biais d un nombre de pertes maximum consécutives, ou un pourcentage de pertes. Une autre technique permet de définir quels objets peuvent être perdus [13]. L ordre : il est associé à la synchronisation logique des unités d informations transmises par l application. Traditionnellement, les contraintes d ordre sont soit totales (aucun désordre admis) ou quelconque (tous les ordre peuvent être admis). L ordre partiel correspond à la possibilité de définir un ensemble de séquences d unités d information admissibles parmi les séquences possibles. Les réseaux de Pétri constituent un exemple de formalisme adapté à la spécification de ce paramètre. En complément de ces paramètres caractérisant le contenu, le choix d un service et d un type de garantie est nécessaire pour prendre les décisions de réplication dans l architecture. En fonction du choix de certaines classes de services, la modélisation du trafic peut être nécessaire pour établir le lien entre les besoins applicatifs et le paramétrage des mécanismes de réservation de ressources. Elle sera utilisée pour déterminer si le réseau a les capacités d assurer cette qualité, et permettra par exemple de provisionner cette ressource si nécessaire. Par exemple, RSVP propose pour cela un modèle permettant de caractériser le trafic applicatif (token bucket). [86] a montré que l interprétation de cette QoS par un gestionnaire approprié permet de décider du support couplé des composantes réseaux et transport pour la distribution du contenu Aspects liés à la réplication La spécification du contenu est un élément déterminant permettant notamment de définir les ressources nécessaires à la mise en œuvre de la qualité de service. Vis-à-vis de la réplication, cette spécification correspond à une description permettant en premier lieu de déterminer la faisabilité de la réplication vis-à-vis de ce contenu, et le cas échéant, de dimensionner les ressources nécessaires à cette opération. Couplée à la connaissance de l infrastructure, elle permettra également de décider comment déployer les répliquas dans le réseau. Pour pouvoir être répliqué, un contenu doit posséder des caractéristiques particulières. Il doit exister un découplage temporel entre la génération du contenu et sa présentation. De plus, les ressources réseau et système permettant la distribution du contenu vers les utilisateurs finaux doivent être déterminées et disponibles au niveau l entité de réplication et du réseau de distribution. Compte tenu de ces contraintes, les paramètres caractérisant la spécification du contenu pour la réplication sont les suivants : La pérennité : elle caractérise la durée de validité du contenu permettant d assurer que sa validité est assez importante pour envisager sa réplication. Cette pérennité est supérieure au délai d acheminement nécessaire à sa distribution. Par exemple, la durée de vie d une page dynamique sécurisée est faible ; par contre, le service complet permettant de construire la page dynamique (données + méthodes) a une pérennité plus importante. On peut exprimer la pérennité de manière absolue : une date jusqu à laquelle le contenu est valable, ou de manière relative : une durée pendant laquelle le contenu est valide depuis la date de réception.

95 Les protocoles et l environnement de distribution : exprime les besoins système et l ensemble des protocoles de niveau application nécessaires à la distribution du contenu, (par ex. RTP, RSTP, HTTP, etc.). La taille : elle caractérise le volume d octets requis pour déporter le contenu d une unité de génération ou de réplication à une autre unité de réplication. Elle permet de déterminer quand et combien de temps il faudra pour acheminer le contenu dans la ou les entités de réplication. La taille est au moins celle des données. Elle peut être complétée par celle des services si certains protocoles ou applications sont nécessaires à la distribution et ne sont pas présents dans l unité de réplication. La date de disponibilité : Elle caractérise la date de présence du contenu dans les unités de réplication. Elle peut être exprimée de manière absolue à partir de dates fixes ou de manière opportuniste selon la demande des clients envers ce contenu Représentation des paramètres Une partie de ces paramètres pourrait être mis en œuvre par le biais de l entête HTTP qui permet de gérer la réplication des pages Web lors des utilisations traditionnelles des serveurs de caches. Les serveurs Web ajoutent une entête lors de l envoi des données HTML contenant des informations permettant ou non de cacher les données dans les proxy caches éventuellement rencontrés sur le chemin vers le client. Néanmoins, la spécification précédente n est pas réservée uniquement au trafic HTTP. De plus, il est nécessaire d y intégrer des informations complémentaires (protocole, taille, etc.) qui ne sont pas prévu dans l entête standard HTTP. La spécification pour la réplication correspond ainsi à une extension des informations intégrées aux entêtes HTTP et sera appliquée à l ensemble des contenus. Afin d'utiliser les spécifications précédentes pour tous les types contenus, une approche générique et extensible pouvant s adapter à de nouveaux services ou de nouveaux contenus est utilisée. Le choix du langage de spécification de la QoS s est porté sur XQoS [88] à cause de sa nature extensible reposant sur XML. XQoS est un langage de spécification basé sur XML qui permet de décrire aussi bien les besoins des applications que les ressources en terme de système et de communication disponible. Ce langage permet d'obtenir une spécification technique globale qualifiant les besoins des applications. Il est possible de traduire cette spécification en terme de composantes réseau, transport ou système à garanties de QoS. XQoS propose une méthodologie générale qui permet à l'utilisateur de caractériser les exigences des applications et de dresser la carte des services de communication disponibles. Le langage XQoS est destiné à fournir une spécification générique des besoins en terme de QoS et des services disponibles. La Figure montre un exemple de document caractérisant une présentation multimédia contenant un flux audio et un flux vidéo dans le cadre de la visualisation d une vidéo à la demande. Le document décrit les paramètres de QoS pour les deux flux acheminés en parallèle. Chaque flux est caractérisé par les adresses source et destination ainsi que par le port utilisé par le processus applicatif. La définition des flux est complétée par un document XQoS caractérisant des types de médias particuliers, ici un flux RTP_DVI et un flux RTP_MPEG2. Les paramètres d'ordre, de fiabilité et de bande passante sont aussi exprimés dans ce document pour chaque caractéristique du média.

96 Figure Exemple de spécification d'une présentation multimédia avec XQoS. En exprimant la qualité de service nécessaire à la présentation d un flux, le langage XQoS permet de décrire complètement les éléments nécessaires à la caractérisation des paramètres liés à la distribution. Par contre, celui-ci ne prend pas en compte les contraintes liées à la réplication. Une extension au langage permettant la description des aspects spécifiques est donc définie comme une extension de XQoS. A la manière d'une entête HTTP un document XQoS viendra compléter la caractérisation d un contenu en apportant une caractérisation des paramètres liés aux besoins de réplication définis précédemment. Le modèle d extension repose sur le schéma XML de la Figure Ce schéma permet la description d un contenu à l aide des paramètres mis en avant dans la section , en précisant le choix d expression de ces derniers de façon explicite ou implicite, (par exemple avec une date explicite pour la durée de validité ou une durée implicite). Figure Schéma XML de l'extension XQoS pour la réplication. La Figure montre un exemple d utilisation de cette extension (XQoS Replication Header). Elle vient compléter la description du média précédent (flux audio vidéo d un média à la demande) qui possèderait une durée de vie de 1 semaine, pouvant être streamé par différent protocole, (HTTP, RTP, RTSP), ayant une taille globale de 1GigaOctet et devant être disponible à partir du 10/10/2002 à 20h35.

97 Figure Exemple de header de réplication étendant le langage XQoS. Ainsi grâce à ce complément d information au niveau des contenus et aux propriétés de XQoS la description des contenus est possible. Couplé à la description des ressources disponibles exprimée à l aide de XQoS, il est possible de déterminer comment répliquer les contenus le cas échéant DESCRIPTION DE L ARCHITECTURE Cette architecture basée sur la réplication a pour but de contrôler la qualité de service ou d optimiser l'utilisation d'une architecture CDN traditionnelle. Les trois services traditionnels des systèmes CDN, l'accès à des contenus Web, l'accès à des contenus stockés et streamés et l'accès à des contenus streamés live doivent être pris en compte. Dans le cadre des contenus streamés live optimiser le système revient à étudier la meilleure façon de diffuser un contenu vers plusieurs récepteurs (communication multipoint) sur une structure de recouvrement et ceci ne fait pas l objet de notre contribution. Les propriétés des structures de recouvrement vont être utilisées pour optimiser les autres services du système. La gestion de l'optimisation des contenus Web et des contenus streamés est réalisée séparément. L'optimisation au niveau des contenus Web est réalisée en étudiant le nombre de contenus à répliquer et leurs positions à l'aide des résultats obtenus dans le chapitre précédent. En ce qui concerne les contenus stockés et streamés, le contrôle de la qualité de service est obtenu à l'aide d'un système de P2P reposant sur le système PeerFecT. Les différents composants de l'architecture vont être maintenant caractérisés. Dans un premier temps l'architecture physique globale est présentée, (serveurs et liaisons réseaux) puis détaillée et dans un second temps les composants logiciel de l'architecture sont eux aussi décrits Architecture physique La structure de l'architecture physique repose sur une structure de CDN classique. En d'autres termes, celle-ci est donc constituée d'un ensemble de serveurs de réplication qui sont interconnectés par des liens réseaux. Cette structure constitue un réseau de recouvrement qui pourra être géré à partir d une entité maître. Cette entité maître est responsable du choix de déploiement des différents contenus. Les fournisseurs de contenus proposent le contenu au niveau de cette entité ainsi que les paramètres de QoS désirés. L entité maître communique avec les différentes entités de réplication pour déterminer les possibilités de garanties de QoS et s occupe finalement du déploiement. Afin d'obtenir les meilleurs résultats possibles en terme de garanties de QoS, des engagements doivent être pris avec les ISP et IAP afin de positionner des unités de réplication au plus près des utilisateurs finaux (p.ex., au niveau des POP), permettant d'obtenir une qualité de service garantie au niveau du réseau d accès. Par exemple, une entité de réplication pourrait être placée au niveau d'un DSLAM ADSL afin de pouvoir garantir la qualité de service offerte par le contrat souscrit entre l'utilisateur final et le FAI. Comme le montre la Figure 5.3-1, il est intéressant de pouvoir placer une entité de réplication au niveau des POP car la zone «proche» de l unité de réplication est une zone de QoS privilégiée.

98 Figure Représentation de l'architecture. Les unités de réplication sont basées sur l utilisation de serveurs classiques. Ces serveurs possèdent de grande capacité de stockage afin de pouvoir contenir un maximum de contenus. La capacité de stockage n étant pas infinie, notre architecture permet de répliquer les contenus uniquement au niveau des unités de réplication nécessaires pour obtenir les garanties voulues par le fournisseur de contenus. Comme le montre la Figure 5.3-2, la capacité de stockage de chaque unité de réplication est découpée en 3 parties égales ou non, chacune des parties étant responsable d un type de service spécifique : service HTTP, service de streaming, ou fonctionnement et streaming live. Le volume de stockage dédié au streaming est utilisé pour le stockage de blocs de données encodé FEC par le système de P2P basé sur PeerFecT. Le volume de stockage dédié au service HTTP contient les répliquas de site Web ou les données à accéder par l intermédiaire du service HTTP. La dernière partie de l espace de stockage est utilisée quant à elle pour le fonctionnement du système. Elle sert par exemple si besoin est, lors de la distribution d un contenu en streaming live à effectuer un ré encodage «à la volée», elle sert de stockage temporaire pour le système de streaming lors de la récupération de bloc pour le streaming des contenus et pour le fonctionnement général du système. Figure Stockage des unités de réplication. Ce découpage en 3 capacités de stockages distinctes permet de traiter le problème comme l optimisation de 3 structures de recouvrements différentes. Les unités de réplications sont interconnectées par des connexions réseaux dédiées. Ces connexions sont soit louées à un ISP avec des garanties sur le débit, délai, et pertes, soit font parties intégrantes de l architecture et forment un réseau privé. Cette structure permet de

99 construire le réseau de recouvrement de réplication qui n est pas influencé par la charge du réseau Internet. De plus chaque entité possède une connexion vers l Internet par l intermédiaire de l IAP ou de l ISP où se trouve l entité de réplication. Ainsi le trafic induit par les requêtes utilisateurs et la distribution des contenus ne chargera pas le réseau de réplication. Cette connexion vers l Internet est provisionné de la façon suivante, comme le montre la Figure Figure Provisionnement du lien réseau de connexion à l'internet. Une réservation de ressources est effectuée sur le lien de connexion à l Internet, afin de créer une structure de recouvrement distincte pour chaque type de contenus. Cette réservation est réalisée de façon à ce que le trafic induit par un contenu Web n'influence pas les ressources du réseaux des contenus streamés et réciproquement. En surveillant le comportement de l'architecture et des utilisateurs, il est possible de mettre à jour cette réservation pour la faire évoluer vers une réservation plus fine, et in fine vers un dimensionnement de la connexion Internet pouvant supporter l agrégation des trafics induits par l'accès aux différents services. Grâce au modèle définit dans la section 3.5, chaque entité de réplication peut être caractérisée. Afin de représenter totalement notre architecture, le modèle caractérisant une unité de réplication doit tenir compte des 3 capacités de stockages différentes (cf. Figure 5.3-2), et des deux connexions réseaux différentes, (en terme de débit, délai, pertes et charge) correspondant aux lien d interconnexion avec l architecture et au lien d accès Internet. De plus, le lien d accès à l Internet peut être détaillé comme 3 trois liens d accès réseau distincts, correspondant aux ressources réservées pour chaque type de service. À partir de l'ensemble de ces paramètres et des possibilités de XQoS en terme d'expression des ressources, il est possible de former le document permettant de caractériser les ressources de chaque entité de réplication. Ce document est mis à jour pendant le fonctionnement du système et peut être transféré jusqu'à l entité de réplication maître afin de connaître l'évolution des ressources de chaque unité de réplication. Ces descriptions permettent de prendre des décisions de réplication ou non dans une unité donnée. L architecture de réplication est constituée de serveurs de stockage de grande capacité qui sont dispersés dans le réseau et interconnectés. Certaines unités de réplication sont positionnées sur des réseaux d accès d ISP ou d IAP. Ces serveurs définissent des zones de QoS privilégiées ou les garanties peuvent être absolues si les ressources du client final sont suffisantes. Comme le montre la Figure 5.3-4, chacune de ces zones est identifiée afin de définir des services particuliers qui seront détaillés dans la section 5.4.

100 Figure Modélisation de l'architecture. La connaissance de la structure même du système est nécessaire pour pouvoir déterminer le nombre de répliquas et la ou les positions de ces derniers pour obtenir le service voulu. La définition de l architecture à l aide des paramètres précédent permet de déterminer la répartition en terme de bande passante des unités de réplication pour chaque zone géographique et chaque type de service. Ainsi les résultats obtenus dans le chapitre précédent peuvent être appliqués à ce système de recouvrement. De plus, comme pour les systèmes CDN traditionnels, un système de serveur DNS hiérarchique «privé» est installé au niveau de chaque zone pour effectuer la redirection des utilisateurs vers le serveur de réplication adéquat Architecture logicielle L'architecture logicielle des différents éléments constituant le système est détaillée dans cette section. Pour cela nous considérerons chacune des différentes phases rencontrées par les contenus utilisant cette architecture : la phase de distribution, de redirection et de réplication. Bien évidemment, nous supposons que chaque entité possède les protocoles classiques de Internet (IP, TCP, UDP, etc.) assurant la connectivité vers les utilisateurs finaux. De plus, au niveau de l interconnexion des serveurs avec l architecture de distribution, le protocole IP multicast sera lui aussi disponible pour optimiser l utilisation du réseau lors de la réplication des contenus. Au niveau de la redirection, les serveurs de redirection, déployés dans le système exécutent un démon DNS hiérarchique identique à ce qui peut être déployé dans un architecture CDN classique. Ce système fondé sur un algorithme DNS est la base qui permet la redirection des requêtes des utilisateurs finaux vers une entité de réplication qui assurera la distribution du contenu. La différence par rapport à un système de redirection d un CDN classique est que l'algorithme de redirection devra tenir compte du fait que tous les serveurs ne possèdent pas forcément le contenu demandé. Le nombre de contenus sera alors plus important mais le choix pour la redirection sera par contre restreint au nombre de serveur possédant le contenu. Au niveau de la distribution, les unités de réplication doivent être en mesure de distribuer tout type de contenus. Ainsi comme nous avons vu précédemment pour le stockage, chaque entité possède un serveur Web qui est responsable de la distribution des pages HTML, un serveur de streaming responsable du service de streaming audio et vidéo dans les différents

101 protocoles de transport (RTP, RTSP, HTTP, etc.), ainsi qu'un serveur FTP permettant du stockage et du transfert de fichier pour les utilisateurs finaux. Au niveau de la réplication et de la gestion de l architecture, chaque entité de réplication possède un système de gestion et surveillance de l entité de réplication. Ce système surveille la capacité de stockage utilisée pour les différents services, les contenus stockés, et est également en charge de l estimation de la charge CPU et réseau utilisée. Ce gestionnaire de système est responsable de la création du document XQoS décrivant les ressources disponibles pour l entité considérée. Un module de communication et de configuration réside sur l entité de réplication afin de communiquer avec l entité de réplication maître et qui permet de configurer le téléchargement des contenus. Une fois la configuration du transfert de contenus effectuée par l entité maître, un module de transfert de fichier en mode unicast (p.ex., le protocole FTP) et en mode multipoint fiable sont présents afin de récupérer les contenus distribués par l entité de réplication maître. Le module de communication unicast est utilisé pour des transferts point à point entre une entité de réplication et l entité de réplication maître, alors que le module de communication multipoint est sollicité pour la réceptions de contenus destinés à plusieurs entités de réplication. Figure Architecture logicielle d'une entité de réplication. La Figure propose une vision globale de la structure logicielle d une entité de réplication. En détaillant plus finement les modules de communication avec l architecture et de distribution de streaming, on fait apparaître les services P2P du système PeerFecT. Ces derniers permettent la recherche et le téléchargement de blocs entre les unités de réplication ainsi que le codage ou décodage des blocs si nécessaire. Le fonctionnement est détaillé dans la section 5.5. L entité de réplication maître est responsable de la récupération des contenus originaux. Les fournisseurs de contenus viennent déposer les contenus et la description des services désirés. Cette dernière possède donc un serveur FTP. Un module de communication avec les entités de réplication permet de communiquer et de connaître l état de chaque unité. Des systèmes de transfert de fichier en unicast et multicast fiable sont disponibles pour transférer les contenus vers unités de réplication. Les services P2P du système PeerFecT sont disponibles pour pouvoir découper les données en blocs et les encoder à l aide d un code FEC le cas échéant. Finalement, un module décisionnel rassemble toutes les informations sur l état de l architecture (entité, charge réseau ), et est en charge de déterminer les paramètres de réplication pour un contenu et une demande de service donnée.

102 Figure Architecture logicielle de l'entité maître. La Figure détaille la structure logicielle et de communication de l entité maître de l architecture. La caractérisation de notre architecture avec la structure matérielle et logicielle permet de définir celle-ci comme la superposition de 3 services fournis par 3 structures de recouvrement. La première est en charge des contenus de types Web (structure proche d un CDN). La seconde est en charge des contenus streamés et repose sur un système de P2P. Finalement la troisième est une structure de recouvrement chargée de l acheminement de contenus streamés Live, dont l optimisation n est pas traitée dans cette thèse mais qui a déjà fait l objet d études [89] TYPES DE SERVICES ET GARANTIES Les garanties de QoS qui peuvent être obtenues par les utilisateurs finaux dépendent non seulement de la mise en œuvre de la réplication, mais aussi de paramètres caractérisant l architecture, comme la position des unités de réplication et la charge réseau. Dans la section suivante, un ensemble de services qui peuvent être offerts et garantis par une architecture à gestion de QoS par réplication est détaillé. Le fournisseur de contenus spécifie des paramètres de QoS pour un contenu et le type de service ou de garanties qu il désire assurer pour ce dernier. Ce service permet au producteur de ressources de définir la qualité de service vis-àvis de la distribution d un certain contenu. Le producteur de ressource peut ainsi choisir le coût qu il souhaite investir en fonction de la QoS et des garanties qu il souhaite obtenir pour les utilisateurs finaux Paramètres de contrat de service La liste ci-après propose un ensemble de paramètres qui spécifient le contrat de service et les garanties qui peuvent être obtenues avec une architecture de réplication. Ces garanties sont en fait dues à la structure même de l architecture et donc au déploiement des différentes entités de réplications. Le contenu C : Un contenu est constitué d un ensemble de données multimédias à distribuer et de services permettant leur distribution. Les données multimédias sont effectivement les données transmises dans le cadre de la distribution à l usager final, pour leur présentation. Les services sont les protocoles de communication et l environnement permettant d assurer correctement la distribution de ces données. La qualité de service Q : La qualité de service définit un ensemble de paramètres (cf. section ) qui sont gérés par le contrat de service. Elle va décrire les contraintes associées à la distribution du contenu. Celle-ci va en fait spécifier les différents paramètres de QoS qui sont traditionnellement employés au niveau du réseau ou du transport. Dès lors, les paramètres qui

103 seront pris en compte principalement sont les suivants, la fiabilité, l ordre et le délai de bout en bout ou le temps qui permettent d exprimer des contraintes temporelles au niveau d un flux. La durée D : La durée du contrat concerne la période de temps pendant laquelle les termes du contrat doivent être assurés. L expression de cette durée peut être définie de façon implicite ou explicite (i.e. en spécifiant la durée, ou en spécifiant une date de fin de contrat). Elle peut être infinie, prédéfinie (valeur par défaut) ou spécifiée de façon explicite en donnant une durée, ou bien réévaluée en fonction de critères extérieurs par exemple un nombre de requêtes pour un contenu trop faible pourrait engendrer une diminution de la durée de validité du contrat. L étendue géographique G : Le paramètre G exprime l étendue ou la zone géographique du contrat de service. Cette étendue fait à priori partie du réseau couvert par l architecture. Il est ainsi possible de spécifier par exemple : o Une station hôte particulière (une adresse IP) o un réseau o toute l infrastructure o ou en utilisant les zones géographique qui sont définies et nommées par le fournisseur de service en fonction du déploiement de l architecture (cf. Figure 5.3-4), ce paramètre étant à priori le plus judicieux car il repose sur la capacité du réseau d accès au contenu. Plage de fonctionnement P, N u : cette plage de fonctionnement correspond en fait la limite de charge réseau P supportée par l architecture jusqu à laquelle le service doit être garantie pour un nombre connectés maximum N u. En d autres termes, c est le pourcentage de charge limite à partir duquel le service ne devra plus être rendu. Pour un contenu donné C (p. ex. une vidéo streamé), le fournisseur de contenus devra spécifier la QoS de distribution Q qu il souhaite fournir pour les utilisateurs finaux. Cette QoS est exprimée à l aide des paramètres classiques de spécification de la QoS transport, (délai<150ms, débit = CBR 300Kbits/s, pertes 10 %, ordre total), de la durée du service D (pendant 1 journée) et la zone géographique G (zone géographique A) sur laquelle il voudra obtenir le service désiré. De plus, celui-ci devra définir dans quelle plage de fonctionnement (P, Nu) de l architecture (pour une charge réseau globale de l architecture inférieure à 50% et pour un nombre de connectés inférieurs à 200) le service devra être fourni Les types de services Une fois les paramètres de contrat de service définis, les producteurs de ressources ou fournisseurs de contenus ont le choix entre plusieurs types de services assurés par l architecture. Chaque type de service tient compte des contraintes liées à la distribution, (paramètres de QoS réseau et transport), ainsi que des contraintes liées à la réplication, (espace de stockage, position géographique du ou des serveurs de réplication, etc.). Un ensemble de services et les différents types de garanties qui seront assurées par l architecture sont définis dans la suite de cette section Service déterministe Pour le service déterministe, le fournisseur de contenu désire une qualité de service Q assurée pour un contenu C. Si le système accepte de rendre ce service déterministe, il s engage à assurer au moins la QoS Q pour le contenu C, pendant une durée D sur un espace

104 géographique G tant que la charge réseau de l architecture sera inférieure à P pour un nombre minimum N u de connectés. Ceci nécessite donc la réservation des ressources (capacités de stockage et éventuellement capacité réseau au niveau de l accès) au niveau du nombre nécessaire d entité de réplication pour assurer cette QoS. De plus la surveillance des ressources de l architecture est indispensable, connaissance de la charge réseau et des capacités de stockage restantes Service moyen Dans le cas d un service moyen, le fournisseur de contenu désire une qualité de service Q assurée pour un contenu C de façon moyenne ou statistique. En d autres termes, si le système accepte de rendre ce service, il s engage à assurer en moyenne la qualité Q pour le contenu C, pendant la durée D du contrat sur un espace G donné pour la plage de fonctionnement (P, N u ) donnée. On peut ainsi déterminer un ensemble de serveurs de réplication minimal et maximal qui seront susceptibles de recevoir un répliqua du contenu. En fonction de la charge des entités, ces répliquas seront à disposition ou supprimés par l entité maître afin d assurer le service. L entité de réplication maître effectue périodiquement une mise à jour des informations de chaque entités de réplication lui permettant de déterminer si un contenu peut ou doit être supprimé Service combiné Le service combiné permet au fournisseur de contenus de définir une marge de tolérance de fonctionnement. Ce service peut alors se décliner sous différents aspects. Le fournisseur de contenu désire une qualité de service Q pour un contenu C pendant une durée de contrat D sur une zone géographique G et pour une plage de fonctionnement (P, N u ) donnés. La marge de tolérance peut alors s appliquer sur un seul des paramètres comme suit : Le service devra être assuré pour l ensemble des paramètres tout au long de la durée D contrat avec une qualité de service Q 0 (<Q) minimale à assurer pour les N u utilisateurs. La QoS Q devra être assurée pour l ensemble des paramètres définis durant la durée D pour une charge réseau P 0 (<P) ou pour un nombre d utilisateur N 0 (<N u ) Le service est assuré dans tous les cas et n est pas dégradé au-delà du seuil défini par le contrat. Ce type de service est en fait la combinaison de garanties moyennes (statistiques) et déterministes Service orienté coût Le fournisseur de contenu désire une qualité de service Q assurée pour un contenu C avec un service orienté coût. Un objectif de QoS Q est fixé. Le système essaye de fournir ce service en minimisant l aspect financier et donc le nombre de répliquas. Si le système accepte de rendre ce service, il s engage à assurer la meilleure QoS possible (pas nécessaire Q en fonction de la charge et du nombre d utilisateurs) pour le contenu C avec un maximum de N répliquas (dépendant uniquement de la contrainte de coût du fournisseur de contenus et non de la QoS désirée), pendant la durée D sur un espace G. Le service obtenu peut être du service déterministe lorsque l architecture n est pas chargée et du service mieux que le service «au mieux» pour une architecture très chargée. Il est donc nécessaire de maintenir une connaissance complète de l architecture afin de réaliser cette optimisation.

105 Service «Au mieux» Le service de type «au mieux» ou best effort correspond au service de type caching traditionnel. De plus il est possible de créer un scénario de service pour un contenu. Dans ce cas là, le fournisseur de contenu décrira l évolution des garanties de QoS pour le contenu donné en fonction du temps Conclusion sur les types de services La différentiation des types de service offerts par l architecture permet de choisir les garanties de QoS que l on souhaite obtenir pour un certain contenu. Des services garantis peuvent être destinés à des contenus «sensibles» ou nécessitant une qualité de service importante. Ils ont recourt à une utilisation de ressources plus importantes, c'est-à-dire de l utilisation d un espace de stockage qui doit être garanti ainsi que la gestion des ressources réseaux jusqu aux utilisateurs de la zone géographique, induisant un coût élevé pour ce type de service. D autre part, des services moyens et combinés sont eux destinés à des contenus plus «opportunistes» ayant besoin de ressources relatives mais pouvant tout de même se satisfaire de contraintes plus souples ou bien pour des fournisseurs de contenus ayant des contraintes budgétaires strictes. La caching traditionnel peut être assimilé à un service «au mieux» quant à l approche CDN de réplication totale elle correspond à la QoS maximale qui pourra être obtenu pour un contenu. Différentes utilisations des services définis précédemment peuvent être envisagées. Le service déterministe offre des garanties «dures» pouvant convenir pour des utilisations où il est nécessaire d assurer une certain QoS, par exemple dans le cadre d une application de télévision interactive, le contenu visualisé doit correspondre à la qualité visuelle habituelle des émissions, des garanties importantes sont donc nécessaires. Le service moyen et le service au mieux peuvent être utilisés dans le cadre d un site web possédant par exemple des archives. Les archives du mois en cours peuvent être stockées avec un service moyen afin d assurer une qualité de service moyenne, ces dernières sont relativement accédées, quant aux archives plus anciennes, un service au mieux offrira un service compatible vu le nombre de consultations. Le service combiné peut lui être une solution pour des contenus opportunistes des documents audio ou vidéo de qualité moyenne et de courte durée devant être distribués à un nombre peu important d utilisateurs. Finalement, le service orienté coût est lui destiné à des fournisseurs de contenus ne voulant offrir un service avec des garanties «dures» pour un contenu donnée mais voulant adapter le service en fonction des consultations des utilisateurs finaux. L ensemble des services définis précédemment permet d offrir un panel de garanties de service qui n est pas exhaustif. Il est envisageable de définir d autres types de services pour faire face aux demandes futures. Le choix de service est lui aussi, comme la plupart des informations nécessaires au bon fonctionnement de l architecture, décrit à l aide d un document XML (cf. Figure 5.4-1) qui caractérise chaque paramètre pour le service considéré. Ce document complète la description du contenu avec les paramètres de service désirés. Figure Document XML de description de service.

106 5.5. PROTOCOLE ET FONCTIONNEMENT L architecture définie dans ce document a pour but de fournir un système de distribution offrant des garanties statistiques de qualité de service. Pour cela, les fournisseurs de contenus doivent en premier lieu spécifier les contenus et la qualité de service avec laquelle ils souhaitent que ces derniers soient accédés. Ainsi en exprimant l ensemble des contraintes au niveau distribution, réplication, et infrastructure, l architecture peut mettre en place, une gestion du déploiement et de la réplication du contenu dans les entité de réplication afin de garantir le service et la QoS associée Fonctionnement général Le fonctionnement général de l architecture est présenté selon un déroulement chronologique de son utilisation et des mécanismes mis en jeu. Le fonctionnement de l'architecture est en premier lieu présenté, puis les mécanismes gérant une requête de QoS pour un contenu donné seront indiqués. Comme nous l'avons vu dans la section précédente, l'entité maître est responsable du déploiement des contenus dans l'architecture. C'est elle qui décide, en fonction du service désiré, des ressources des différentes entités de réplication et du réseau, du nombre de contenus et de leur position à l aide d'un algorithme qui sera détaillé dans la section suivante. Pour cela, un client et serveur FTP classique et IP multicast sont exécutés sur l entité maître. Respectivement un client FTP classique et un client FTP multicast sont disponibles sur des entités de réplication. Les entités de réplication et l'entité maître intègrent un module de communication permettant de connaître l'état et la charge réseaux de chaque entité. Les détails de ce protocole de communication seront donnés dans la section suivante. Une fois initialisée l architecture est alors capable de déployer des contenus pour offrir des garanties de qualité de service en utilisant la réplication. L'utilisation de l'architecture commence tout d'abord par la génération des contenus à déployer. À partir de ce moment-là, le fournisseur de contenu vient déposer ce contenu au niveau de l'entité maître et effectue la description de ce dernier à l aide des documents XQoS et spécifie le type de service et de garanties qu il souhaite pour ce contenu. Pour simplifier le travail de description des fournisseurs de contenu, il est possible de fournir des profils prédéfinis de contenus et de description de services, pour des contenus ou des services clairement identifiés et récurrents, par exemple une description de service pour un contenu de vidéo à la demande ou un streaming de radio. Une fois cette description effectuée, le module décisionnel de l'entité de réplication maître va déterminer le nombre de répliquas nécessaires et toutes les positions possibles pour pouvoir assurer le service. Les positions possibles sont déterminées à partir de la répartition en termes de bande passante du réseau. Le module décisionnel choisi alors aléatoirement des serveurs et effectue une requête sur chacun d eux pour connaître leur état (requête du document XML (cf. Figure 5.5-1) de description des ressources de l entité de réplication). Il répète ceci jusqu'à l'obtention du nombre de serveurs correspondant au nombre de répliquas nécessaires. Figure Document de description de ressource XQoS.

107 Si ce nombre de ne peut être atteint et en fonction du service, les garanties de QoS ne pourront pas être fournies. Aussi, le système n'acceptera pas de déployer le contenu et informera le fournisseur de celui-ci. Dans le cas contraire, si le nombre de serveurs est atteint l'entité maître effectuera une réservation et une configuration des entités de réplication choisies. Cette configuration aura pour effet de configurer le transfert du contenu à l'aide du module FTP unicast ou multicast. Une fois le contenu répliqué, le service désiré pourra être rendu, seul la surveillance des entités et de l architecture doit être maintenue périodiquement. Pour un contenu streamé, le module décisionnel déterminera le nombre de blocs, le taux d'encodage, le nombre de répliquas en fonction de la répartition en terme de bande passante du réseau comme décrit dans la section Une fois le nombre de répliquas déterminées, le module décisionnel va aléatoirement effectuer des requêtes sur l'état des entités en leurs demandant leur description de ressources. Si le nombre de réponses positives est suffisant les blocs sont alors déployés après une configuration des entités pour un transfert FTP unicast ou multicast. Dans le cas contraire, une deuxième passe est effectuée pour déterminer si une entité peut stocker plusieurs blocs encodés. Si le nombre de répliquas ne peut être atteint le déploiement du contenu est refusé, le service ne pourra pas être rendu, et le fournisseur doit en être averti. Dans tous les cas de déploiement, l'algorithme de redirection et le système basé sur l algorithme DNS sont informés du nouveau contenu présent dans les entités de réplication afin de permettre une redirection des utilisateurs finaux vers les entités correspondantes. Le service de QoS peut alors être rendu Protocoles, API Pour accéder au service du système de communication, l application dispose d une API spécifique, composée d un ensemble de primitives destinées à la gestion de l architecture, la configuration et le transfert des contenus vers les entités de réplication. Les primitives de service de l API sont les suivantes : Gestion de l architecture : o open_session() : L ouverture de session est la première primitive qui doit être effectuée pour permettre a l entité de prendre part à la réplication de contenu. Cela permet à l entité de réplication maître d ajouter l entité de réplication considérée pour prendre par à la réplication sur l ensemble de l architecture. o close_session() : La fermeture de session permet de terminer la participation de l entité à la réplication de contenu et libère les ressources. o request() : La demande d information est réalisée par l entité maître aux les entités de réplication. Cette demande nécessite l emploi de paramètre afin de déterminer que va être le type de requête. ressources : demande la description XQoS des ressources de l entité (capacités de stockage et charge réseau). content : demande la liste des contenus de l entité de réplication all : demande l ensemble des descriptions (description des ressources + la liste des contenus). o list() : c est la réponse à une demande request(), elle transfère donc le ou les documents XML/XQoS des descriptions. Gestion et transferts des contenus :

108 o reserv() : La réservation de ressource est effectué auprès de l entité de réplication pour l informer qu un nouveau contenu va lui être attribué. Les paramètres de description du contenu sont transférés à l entité de réplication qui effectue la réservation. o free() : La libération de ressource permet de libérer les ressources utilisées pour un contenu donné ou pour l ensemble des contenus, à l aide des paramètres all, ou content. o configure() : La configuration est utilisée pour spécifier le service FTP unicast ou multicast ainsi que les paramètres pour le transfert du contenu. Les paramètres suivants sont utilisés : address : adresse IP pour le transfert du contenu port : numéro de port pour le transfert id : ID du contenu à récupérer L ensemble de ces primitives de services permet la communication entre l entité maître et les entités de réplications Algorithmes La communication à l aide de l API précédente permet à l entité maître d obtenir les informations de description de l ensemble des entités de réplication qui lui permette de prendre les décisions de réplication. Cette section présente tout d abord le fonctionnement et le choix du nombre de répliquas en fonction de chaque service défini dans la section Finalement, le fonctionnement du module décisionnel est détaillé Calcul du nombre de répliquas Le nombre de répliquas stocké dans l architecture va dépendre de la QoS et du type de service désirés par le fournisseur de contenus. (Voir les types de services proposés en section 5.4.2) Dans le cas d un service déterministe, le nombre de répliquas est déterminé de façon simple. Les résultats de la section 4.3 peuvent s appliquer directement. La répartition des entités de réplication étant contenue, le service déterministe est caractérisé par une zone géographique, une QoS Q pour un contenu C donné, ainsi que par une charge P et un nombre d utilisateurs donnés N u. A l aide de la répartition en terme de débit, en considérant la charge uniformément répartie, il possible de déterminer le nombre d utilisateur qu il est possible de servir avec la QoS considérée à l aide de l architecture de réplication. Le nombre de répliquas nécessaire est obtenu par des courbes similaires à celle de la Figure pour l architecture donnée. Ainsi si la charge réseau de l architecture globale reste en dessous de la limite pour laquelle le service est défini, le service sera nécessairement assuré d après les calculs de la section 4.3. Aussi la surveillance périodique des entités de réplications par l entité de réplication maître permet d assurer que la charge réseau sera assurée en utilisant l algorithme de load balancing. Dans le cadre d un service moyen, le nombre de répliquas peut être obtenu de la même façon que pour le service déterministe. Le nombre de répliquas correspondant à un service déterministe peut être déterminé N d. Le service moyen nécessite alors de maintenir ce nombre de répliquas N d pendant la moitié de la durée du contrat de service. Ainsi le service moyen sera obtenu. En fait, le nombre N d correspond au nombre maximal de contenus qui sera stocké dans l architecture. Lors de la surveillance périodique des entités de réplication, si une entité de réplication est trop chargée (niveau réseau) à cause d un contenu ayant un service moyen,

109 une solution de load balancing peut être utilisée ou alors une suppression d un contenu ayant un service moyen. Le calcul de la durée moyenne du service est assuré par l entité maître. Pour satisfaire aux conditions d un service combiné, le fonctionnement est presque similaire. Le nombre maximum de répliquas correspondant au service déterministe est calculé N d. Le service combiné contrairement au service moyen défini un seuil minimal en dessous duquel le service ne sera plus conforme. Le nombre de répliquas correspondant à ce seuil est alors calculé en le considérant comme un service déterministe avec les paramètres de seuil (P 0, N 0 définis dans la section ). Une fois ce nombre de serveur minimal déterminé N m, le système doit assurer pendant la toute la durée du service au minimum ce nombre de répliquas et pendant la moitié du temps le nombre de répliquas N d correspondant au nombre de serveurs dans le cas d un service déterministe. Le service est vérifié par l entité maître lors de la mise à jours des informations des différentes entités de réplications. Finalement, le cas d un service orienté coût est lui dépendant de contrainte financière. Le coût d un répliqua est fixé par le prestataire de service de l architecture de réplication. Un service orienté coût, fixe un budget à ne pas dépasser. Aussi en fonction de ce budget, le nombre de répliquas maximal est déterminé seule la position pour la zone géographique est alors à déterminer. Ces services reposent sur les calculs de la section 4.3, en fait, si les contraintes sont respectées alors le service ne pourra être que rendu. Aussi l important est de surveiller l ensemble des entités de réplications afin d assurer la validité de chaque paramètre, charge réseau et capacité de stockage Fonctionnement du module décisionnel Grâce à l ensemble des informations sur les contenus et services, ainsi que la connaissance de la topologie du réseau et la répartition en terme de bande passante, et le nombre de répliquas en fonction du service considéré, le module décisionnel de l entité maître va pouvoir déterminer la position des divers répliquas grâce au schéma décisionnel décrit à la Figure

110 Figure Schéma décisionnel de réplication des contenus. Le point dur de ce schéma décisionnel réside dans le choix des serveurs de réplication. Le nombre de répliquas nécessaire pour assurer le service désiré N r est à ce moment là déjà déterminé comme décrit dans la section précédente. La connaissance de la topologie et de la distribution en terme de débit des entités de réplication permettent d effectuer un calcul a priori pour chaque zone géographique, de l'ensemble des serveurs capables d'assurer une qualité de service QoS 0 (pour ce qui est des contenus Web), comme nous l'avons vu dans le chapitre précédent. Une fois cette liste déterminée (pour chaque zone géographique considérée), il suffit alors de choisir aléatoirement, parmi cette liste, le nombre de serveurs nécessaires N r pour assurer le les garanties désirées. En fonction de la charge des entités de réplication ou du type de garantie, ce nombre minimal de serveur Nr peut ne pas être obtenu, dans ce cas le service ne peut être assuré. Dans le cas contraire, le déploiement du contenu peut être effectué sur ces serveurs déterminer aléatoirement dans la liste prédéfinie, le service peut alors être assuré. Le problème se complique lorsque la zone de garantie de QoS est composée de plusieurs zones géographiques. Le principe détaillé juste avant doit alors être reproduit pour chacune des zones géographiques considérées. En fonction des paramètres du service, si une seule des zones n est pas en mesure de fournir le service, alors le service global ne peut être rendu et le contenu ne sera pas déployé. Si au contraire, toutes les zones sont à même de fournir le service demandé alors, la première chose à déterminer afin de minimiser le nombre de répliquas pour utiliser au mieux l architecture est de déterminer l intersection des serveurs capables de distribuer le contenu à plusieurs zone géographique. Ceci est réalisé par la comparaison des listes de serveurs de chaque zone. Si aucun serveur n est commun à au moins deux zones géographique, en d autres termes, les zones géographiques sont totalement disjointes, alors le déploiement s effectue simplement sur chaque zone. Si l ensemble des serveurs en commun est non vide et que ces serveurs ont la capacité de stocker ce contenu, alors les serveurs de cette intersection seront choisis en premier lieu dans un souci de minimisation du nombre de répliquas. Le contenu pourra être déployé dans les zones

111 considérées, complété par l utilisation de serveurs pouvant fournir les garanties de QoS choisis dans la liste correspondante à chaque zone. Dans le cadre de contenus streamés, le module décisionnel détermine le nombre de blocs N b et le nombre de répliquas N r nécessaires pour assurer le service désiré. Le schéma considéré ici est plus simple car les zones géographique ici ne sont pas importantes, seule la répartition en terme de débit est nécessaire pour déterminer le nombre de répliquas et de blocs. Dans ce cas-là, il faut trouver N b *N r positions de stockage choisies aléatoirement dans l ensemble de serveurs de réplication, sachant qu'un serveur est à même de stocker plusieurs blocs différents. Si ce volume de stockage est trouvé et réservé dans l'architecture, le service peut être rendu et les blocs sont déployés. Dans le cas contraire le service ne peut être obtenu Accès aux contenus La dernière phase par laquelle passe les contenus est la phase de distribution. L accès des utilisateurs finaux à la distribution du contenu de tous les types de services est effectué par une redirection vers l entité de réplication en mesure de fournir le contenu avec le service demandé par le fournisseur de contenu. Cette redirection est mise en œuvre par un algorithme de redirection classique d un système de CDN. La distribution des divers types de contenus est effectuée de la façon suivante : Accès à un contenu Web ou FTP : Une fois le contenu déployé dans l'architecture, l'algorithme de redirection est informé de la présence d'un nouveau contenu ainsi que de la liste des serveurs de réplication ou ce dernier est répliqué. Lorsqu un utilisateur final effectue une requête à l'aide d un logiciel classique, celle-ci est interceptée puis redirigée vers l'entité de réplication capable de distribuer le contenu avec le service désiré. Comme dans un CDN classique, ce mécanisme est rendu transparent pour les utilisateurs finaux et leurs permet d'accéder à une distribution de contenu avec des garanties de QoS. Accès à un contenu streamé : Comme précédemment, une fois le contenu déployé, l'algorithme de redirection est informé de la présence de ce nouveau contenu. L'utilisation d'une architecture de P2P basé sur le système PeerFecT pour contrôler la QoS des contenus streamés peut permettre d'aboutir à deux types de distribution. La première, utilisant un logiciel traditionnel de visualisation multimédia streamés, lors de l envoi d une requête, celle-ci est interceptée et est redirigé vers l'entité de réplication correspondante. Le streaming peut alors commencer à partir de cette entité. Cette dernière doit alors récupérer les blocs correspondants pour la suite du streaming du média considéré. Le système de P2P est utilisé par les entités de réplications dans ce cas là pour accéder au contenu et le streamer. Cette solution est alors totalement transparente pour les utilisateurs finaux. La deuxième possibilité de distribution utilise un logiciel de visualisation de streaming propriétaire ayant les capacités de se connecter au réseau de P2P de streaming. Dans ce cas là, l utilisateur final utilise le réseau de P2P pour accéder au contenu stréamé. La première solution permet d obtenir une amélioration du service de façon transparente pour l utilisateur final, mais nécessite un fonctionnement plus important de l entité de réplication. La seconde approche permet quant à elle d offrir le même service en reportant la complexité dans l application propriétaire d accès au contenu streamé. Accès à un contenu streamé Live : L accès à un contenu streamé live est similaire à l accès à un contenu de type Web. Le flux live est distribué à l ensemble des entités de réplication, par une méthode d optimisation de communication multicast sur une structure overlay. Lors de la requête d un utilisateur

112 final, celle-ci est interceptée et est redirigée vers le serveur correspondant à la zone de distribution de l utilisateur. Dès cet instant, l entité de réplication commence à distribuer le flux live jusqu à l utilisateur final. Ce dernier vient se rattacher à la structure globale de diffusion. L acheminement du contenu jusqu à l entité de réplication est transparent pour l utilisateur final CONCLUSION DU CHAPITRE Ce chapitre a présenté une description d architecture de distribution avec contrôle de la QoS, reposant sur l utilisation d un service de réplication. Reposant sur les services classiques d une architecture de CDN, des propositions de gestion des services de réplications de contenus Web, de contenus streamés et de contenus streamé live ont été proposés pour obtenir des garanties statistiques de QoS ou une meilleure gestion globale de l architecture. La connaissance de la topologie du réseau et la répartition des entités de réplication couplées à une description des contenus et services à l aide d une extension du langage de description de la qualité de service XQoS permettent d effectuer les choix de réplication adaptés. Ainsi les contenus sont répliqués uniquement dans les serveurs nécessaires pour assurer les garanties de service, les capacités de stockage sont alors mieux utilisées et permettent un stockage plus important de contenus dans l architecture. Les utilisateurs finaux peuvent alors accéder à la distribution des contenus avec les garanties de services définies par les fournisseurs de contenus. Ce modèle d architecture peut être mise en œuvre dans différents types de réseaux IP à condition de respecter le déploiement des entités de réplication et de déterminer par avance la topologie et la distribution en terme de bande passante des entités de réplication.

113 CHAPITRE 6. MITV : UN SYSTEME DE TELEVISION MULTICAST INTERACTIVE BASEE SUR LA REPLICATION Résumé Ce chapitre propose une mise en œuvre possible d une solution de télévision interactive appelé MITv. Cette solution de télévision interactive, étudiée dans le cadre d un projet RNRT DIPCAST, repose sur une architecture de réplication avec contrôle de la qualité de service utilisant un service de communication multipoint par satellite, pour fournir aux utilisateurs finaux un accès dans de bonnes conditions aux contenus interactifs associés aux émissions télévisées. Dans un premier temps, l environnement réseau et de communication sont détaillés pour le système MITv. L architecture de communication de MITv et son fonctionnement complètent la description du système. Une maquette de ce système a été réalisée puis évaluée sur un émulateur de l environnement réseaux et de communication afin de valider le fonctionnement global du système MITv et l intérêt de l architecture de réplication. Une discussion générale sur les gains potentiels de ce type d architecture de réplication à garantie de qualité de service est alors menée en guise de conclusion, en étudiant la répartition géographique des entités de réplication de l architecture INTRODUCTION Dans le cadre du projet RNRT (Réseau National de Recherche en Télécommunications) DIPCAST (Dvb comme support de l'ip multicast par SaTellite), le système MITv (Multicast Interactive Television) [106] a été développé afin de tirer partie au mieux du service offert par le réseau et d offrir un complément de contenu multimédia aux émissions télévisuelles. MITv est un système de télévision interactive se basant sur le couplage de services de diffusion télévisée numérique traditionnelle (p.ex., MPEG2/DVB) et de réplication de contenus multimédia utilisant le support de IP Multicast. Ce système repose sur une architecture de réplication qui va déployer les contenus ayant besoin de garanties de QoS au plus près des utilisateurs avant de pouvoir alors les distribuer en respectant les contraintes imposées. Ce système est un exemple de mise en œuvre d architecture de réplication à gestion de qualité de service. Ce chapitre va présenter en premier lieu le réseau de réplication et le cadre de l étude pour le système MITv. L application de télévision interactive sera ensuite détaillée. Le fonctionnement, l implémentation et les tests effectués sur le système seront ensuite présentés. Finalement, une discussion générale sur le système MITv ainsi que sur le modèle d architecture de réplication à garantie de service défini précédemment conclura le chapitre LE SYSTEME MITV Contexte de l étude Le projet RNRT DIPCAST a étudié le déploiement d un service IP multicast dans le cadre d un support satellite DVB-S/DVB-RCS géostationnaire multi spots. Actuellement le marché des applications multimédia se développe avec des systèmes satellites transparents. Dans ce cadre le consortium du projet a initié des réflexions sur de nouveaux systèmes satellite se positionnant comme des systèmes de transport de données vers des têtes de réseaux d accès (ADSL, LAN d entreprise, etc.). L étude DIPCAST est en particulier restreinte à une mission de type de réseau de bordure «edge network» (cf. Figure 6.2-1) qui a pour but d assurer la connectivité entre des ISP et des serveurs d accès (PoP) ainsi que

114 différents types de serveurs d accès transportant des applications interactives liant les utilisateurs du réseau DIPCAST. Comme le montre la figure, les utilisateurs sont interconnectés par un réseau ADSL classique. Le satellite assure l interconnexion des réseaux de bordure et en particulier le service IP Multicast. Le système satellite considéré est un système de communication à double bond, lors de la communication entre deux réseaux, le message doit être transféré par une gateway. L utilisation du système satellite en tant que réseau de bordure permet de mettre en avant un ensemble d application cible pour un tel environnement, et en particulier le caching de contenus. Cette solution fourni un accès à un ensemble de contenu au plus près des utilisateurs afin de limiter l échange de trafic entre les réseaux des différents ISP. L architecture DIPCAST repose sur un système de diffusion DVB comme la plupart des systèmes satellites actuels et est donc capable de fournir des flux vidéo de type télévisuel. La diffusion de télévision constitue une des applications majeures chez les opérateurs satellite actuels. La mise en place d un réseau multicast par satellite à haut débit parallèlement à la diffusion de flux télévisé peut permettre de développer un nouveau type de télévision, une télévision interactive permettant de palier aux limites statiques actuelles de la simple diffusion d émission par le couplage de la diffusion vidéo et de l utilisation d un système de réplication. Figure Architecture du système DIPCAST. Un scénario de mission privilégié pour le système DIPCAST est donc l alimentation en contenus de caches au niveau des DSLAM des abonnés ADSL. Les exigences et besoins des utilisateurs en termes de QoS sont de plus en plus importants. L alimentation en contenus à fortes QoS d une architecture de réplication permet de limiter le trafic entre les différents ISP, de réduire le délai d accès à certains contenus. De plus l alimentation des caches en utilisant une communication multipoint basée sur un support à diffusion tel que le satellite est une des solutions les plus efficaces [90]. Le réseau ainsi défini par DIPCAST rassemble donc un ensemble d avantage pour le déploiement d une architecture de réplication à gestion de QoS. Un système satellite multi spots offrant un service IP multicast peut alimenter efficacement des entités de réplication de façon continue et personnalisée en fonction de chaque spot. Les réseaux d accès ADSL ou Ethernet constituent également un support adapté à la distribution de contenu nécessitant un support haut débit. De plus, la technologie DVB utilisée de manière sous-jacente par le système satellite permet de déployer aisément le service télévisuel traditionnel. Une des

115 applications particulièrement adaptée à l architecture du système DIPCAST est donc une évolution de la télévision introduisant la possibilité d accéder de manière interactive à des contenus à la demande Fonctionnement général de MITv MITv est un système de télévision interactive se basant sur le couplage de services de diffusion télévisée numérique traditionnelle et de réplication de contenus multimédia utilisant le support de IP Multicast. La réplication de contenus près des utilisateurs permet d assurer une forte interactivité entre l usager et le service de diffusion ainsi qu une présentation de très bonne qualité des contenus associés aux émissions télévisées. Une mise en oeuvre d un tel système est la suivante. Dans une émission de Talk show, lors de la présentation d un invité, (pour la présentation d un film, un livre, un album, etc.), les entités de réplications auraient été préalablement remplies avec la bande annonce du film, un résumé du livre, la biographie de l invité etc., accessibles aux utilisateurs finaux par l intermédiaire de leur réseaux d accès. L interactivité dans le contexte de la télévision consiste à permettre à l usager final d intervenir pendant la diffusion des programmes qui lui sont proposés. Cela peut se traduire par la possibilité de visualiser des contenus multimédias associés et venant enrichir les émissions en cours. Les exemples typiques de contenus multimédias pouvant être associés sont des sites Web, des documents audio ou vidéo. L objectif du système MITv est d assurer aux utilisateurs finaux une présentation de bonne qualité des contenus associés aux émissions télévisées. Ceci implique des contraintes fortes en termes de qualité de service au niveau du système de communication et ceci ne peut être réalisé avec l utilisation de l Internet public classique. Ainsi, l utilisation d une architecture de réplication permettra de tirer partie des propriétés temporelles des émissions de télévision pour le stockage des contenus et d offrir des garanties de QoS de distribution. Le système de télévision interactive MITv repose sur l utilisation d un service multipoint exploitant une liaison satellite pour alimenter en contenus une architecture de réplication à garantie de QoS. Les récepteurs finaux accèdent au contenu ainsi déployé par le biais d un réseau d accès terrestre. Le choix d un environnement réseau satellite supportant les communications multipoints, comme le système DIPCAST, est une composante de l architecture de MITv. Ainsi, l utilisation de la technologie DVB permet de mettre en œuvre la diffusion de télévision par l intermédiaire du réseau satellite et peut être complétée par une diffusion sur les réseaux d accès câblés ou ADSL [95]. De la même façon, l environnement réseau de DIPCAST a été choisi comme la base d une architecture de réplication. Ainsi, un système de diffusion satellite multi spots supportant le service de communication IP multicast interconnecte l ensemble des entités de réplication de l architecture. Plusieurs entités de réplication sont déployées dans chaque spot, au niveau de chaque connexion de réseau d accès haut débit. Ces entités possèdent les 3 trois types de services définis dans le chapitre précédent et les connexions réseaux correspondantes. Les entités de réplication étant situées au niveau de ces points d accès haut débit, des garanties de QoS sont obtenues par le positionnement à un endroit stratégique du réseau. De plus les caractéristiques multi spots d un tel environnement permettent facilement une régionalisation des contenus en fonction de la langue ou des caractéristiques d un pays en fonction des spots. Cela permet de ne répliquer que le contenu correspondant aux critères du pays, (langues, cultures, etc.), il en résulte un gain de stockage au niveau de chaque entité de réplication.

116 L architecture de réplication s appui sur le service de communication IP multicast pour l alimentation des entités de réplication en contenus, ce qui permet une meilleure utilisation des ressources du réseau lors de l acheminement d un même contenu à plus d une entité de réplication. La Figure montre un exemple de déploiement du système de télévision interactive MITv. Figure Exemple de déploiement du système MITv. Le système satellite est utilisé pour la diffusion du flux de télévision entre l Unité de Production (UP) et les utilisateurs finaux. La réception des émissions nécessite au niveau des utilisateurs finaux de posséder soit une antenne de réception satellite classique, soit un réception télévisuel câblé ou ADSL. De plus une connexion à un réseau d accès haut débit de type LAN, xdsl, ou câble est aussi nécessaire pour accéder aux services complémentaires interactifs MITv. Le système satellite est aussi utilisé entre l Unité de Production et les entité de réplication et distribution (ERD) de l architecture de réplication, pour acheminer les contenus interactifs (CI) à l aide du service de communication multipoint. L entité de réplication maître est en fait située au niveau de l entité de production, c est de là que cette dernière déterminera s il faut ou non répliquer le contenu et vers quelles zones géographiques. La réplication des contenus a besoin du système de communication multipoint du satellite en utilisant un protocole de transport fiable. Ce protocole doit donc tenir compte des caractéristiques propres de l environnement satellite. Le système MITv a été testé avec différents protocoles multipoints fiables comme RAMP [91], FCAST/ALC [92], bien qu ils ne soient pas adaptés spécifiquement à l environnement satellite à cause du délai de transmission élevé et des répartitions de pertes spécifique. Dans un souci d adaptation, un protocole de communication multipoint fiable hybride terrestre/satellite tenant compte des caractéristiques de l environnement satellite et du nombre potentiel de récepteurs est proposé dans [93] et [94]. Ce dernier utilise le système satellite lorsque le nombre de récepteurs est important et lorsque la communication multipoint par satellite devient trop coûteuse, les utilisateurs finaux complètent la réception des données par des communications terrestres dans un réseau pair à pair formé par les différents récepteurs. Outre les média audio/vidéo télévisés transmis par le réseau de diffusion de télévision classique et les contenus interactifs associés transmis par le système satellite, il est également nécessaire d informer, au moment opportun et choisi par le fournisseur de contenu, les utilisateurs finaux de la disponibilité de contenus associés au programme courant pouvant être accédés. Des déclencheurs ou trigger «pointant» comme un lien logique vers les contenus

117 multimédia sont donc également transmis vers les récepteurs en utilisant le système de communication multipoint. Le système satellite puis le réseau d accès, le cas échéant, sont donc aussi utilisés pour transmettre ce flux de déclencheurs. Lorsque les déclencheurs signalent la présence d un contenu associé au niveau de l unité de présentation, le téléspectateur peut alors accéder au contenu par le biais du processus de distribution via le réseau de d accès terrestre. Le positionnement des entités de réplication au niveau des points d accès aux réseaux haut débit permet d obtenir la meilleure répartition en terme de bande passante des entités de réplication. En plaçant une ou plusieurs entités de réplication au niveau d un POP, la bande passante est garantie entre le POP et l utilisateur final par contrat. Les différentes parties du système MITv sont détaillées dans la section suivante Architecture du système MITv Le système de télévision interactive MITv est constitué d un ensemble de trois parties complémentaires. Ces parties, le système de production, le système de communication et les systèmes utilisateurs sont détaillés dans les paragraphes suivants Unité de Production Le système de production permet la spécification du scénario des programmes et des contenus associés. Il peut être vu comme la régie de production de la télévision interactive. Il est constitué d un logiciel permettant de spécifier le programme et les contenus associés ainsi que de l unité de réplication maître. Le système de production permet de créer et gérer le scénario constitué de l enchaînement des différents médias constituant le programme interactif. En premier lieu, le système de production permet d effectuer la description précise du scénario du programme interactif en associant les contenus télévisés et les contenus interactifs. A l aide d un logiciel de production «ad hoc», le diffuseur défini le séquencement des contenus télévisés et contenus interactifs associés. Ce logiciel permet de réaliser une spécification du programme intégrant tous les éléments nécessaires qui permettent de déduire les caractéristiques en termes de réplication et de distribution pour le contenu associé. Un exemple de spécification est illustré dans la Figure

118 Figure Exemple de spécification de programme interactif. L exemple de la Figure montre la réalisation d un talk show. Lors du déroulement de cette émission, trois contenus associés sont définis. Après 3 minutes du début de l émission, le téléspectateur aura à sa disponibilité une bande son illustrant les propos de l invité. Dix minutes après le début de l émission, un extrait de film présenté durant l émission sera à son tour disponible au niveau des entités de réplication et pour terminer, un site Web permettra aux téléspectateurs de retrouver et compléter les informations évoquées lors de l émission. La spécification détaillée des caractéristiques de l extrait de film permet de déterminer les besoins en termes de réplication et distribution. L utilisation de la grille des programmes ainsi que les caractéristiques détaillées de chaque contenus permettent au système de production de réaliser les documents XQoS nécessaires au fonctionnement de l architecture de réplication. L ensemble des informations temporelle et propre au contenu, décrite dans la spécification du programme interactif, fournissent les paramètres pour le fonctionnement du système de réplication. En complément à ces informations, des profils de contenus ont été définis, comme le montre la Figure L architecture de réplication peut alors déterminer la possibilité ou non de répliquer le contenu dans les entités de réplication correspondantes et peut alors effectuer des réservations de ressources (capacité de stockage) le cas échéant. Média Débit Délai Gigue Fiabilité CI (Web) 50Kb/s (10 à 100Kb/s) 150ms 50ms Totale CI (audio) 175Kb/s 150ms 30ms Totale CI (audio/vidéo) 500Kb/s 150ms 30ms Totale Figure Profil de QoS pour la distribution des contenus interactifs (CI). En se basant la grille des programmes et le scénario du système interactif, un ordonnanceur s occupe de la gestion du service télévisuel et de l alimentation des entités de réplication au moment opportun. Cet ordonnanceur effectue la création des déclencheurs et gère leurs émissions au moment correspondant à la date de présence et périodiquement pendant une durée déterminée, vers les utilisateurs finaux pour les inciter à accéder aux contenus préalablement téléchargés dans les entités de réplication. L accès au contenu est

119 alors réalisé par exemple, par le biais d un modèle de communication classique client/serveur entre le client final et l entité de réplication Système de communication de MITv Le système de communication a pour rôle le transport des flux associés aux contenus télévisés, aux contenus associés, aux déclencheurs et au fonctionnement de l architecture de réplication. Il exploite la spécification de programme pour déterminer quand et comment émettre les flux de contenus et les déclencheurs associés. Il utilise des systèmes de communication différents et adaptés pour l acheminement des différents types de flux. Flux télévisé : Le contenu télévisé est acheminé depuis le système de production jusqu aux utilisateurs finaux. Il est constitué d informations audiovisuelles de qualité visuelle et sonore aux normes de qualité de la télévision numérique (Couleurs, 25 images/s, son stéréo Hifi, etc.). Ces informations sont traditionnellement codées selon la norme MPEG2. Un tel flux est traditionnellement acheminé par un système satellite MPEG2/DVBS, sur des réseaux câblés MPEG2/DVB-T ou sur des réseaux MPEG2 sur xdsl. Ces protocoles assurent un service en parfaite adéquation avec ce type de flux. Flux des déclencheurs : Le flux de déclencheurs correspond au flux d information visant à informer les téléspectateurs de la présence d un contenu associé au niveau des entités de réplication liés à l émission en cours. Le déclencheur est constitué en fait d une URL pointant vers le contenu interactif. Le débit nécessaire à l acheminement du flux des déclencheurs est donc très faible (quelques octets par déclencheurs), la synchronisation vers toutes les destinations (multi destination) et avec le flux télévisé (synchronisation inter flux) doit être assuré et la fiabilité doit être bonne pas nécessairement totale. L acheminement du flux de déclencheur est réalisé par le service de communication IP multicast jusqu aux utilisateurs finaux. Les terminaux abonnés au service de télévision interactive (i.e., au groupe multicast caractérisant l émission de déclencheurs) recevront les déclencheurs (au niveau application). Les déclencheurs sont donc transmis par le système multipoint satellite et leur acheminement peut être prolongé au niveau des réseaux d accès. Dans ce cas, le transit des déclencheurs au niveau des réseaux d accès du système n induira pas (par hypothèse) de désynchronisation du flux par rapport au système d acheminement de télévision (contraintes de synchronisation inter flux et multi destination). Dans ce contexte, ce solution ne suppose rien sur le support de diffusion télévisuel, il est alors possible de mettre en œuvre le système MITv en utilisant un quelconque système de diffusion numérique ou analogique. Notons cependant que le nombre de destinataire étant potentiellement très élevé (i. e., les téléspectateurs) et que l utilisation du système satellite pour l acheminement des triggers est particulièrement adapté. Flux des contenus interactifs ou contenus associés : L acheminement du flux des contenus interactifs est scindé en deux phases. La première phase correspond à l acheminement des contenus entre le système de production et les entités de réplication (phase de réplication). La seconde phase correspond à la distribution du contenu entre l entité de réplication et le système terminal (phase de distribution). Dans la phase de réplication, les contenus sont déployés par le système de réplication. Les caractéristiques de communication pour la réplication sont l utilisation d une communication multipoint fiable et ordonnée pour assurer la présence du contenu à la date déterminée, avec des contraintes temporelles faibles déterminées par le système de production. Afin de garantir la présence du contenu dans l entité de réplication lors de la

120 première requête d un utilisateur, le système de production ajoute une marge de sécurité à la date de présence dans l entité de réplication (cette date correspondant à la présentation du déclencheur sur les unités de télévision interactive). Dans la phase de distribution, l accès aux contenus est assuré par le système de redirection et distribution de l architecture de réplication. Les contenus interactifs sont acheminés en fonction des requêtes utilisateurs par le biais du réseau d accès, LAN ou ADSL. Les profils de distributions correspondent à ceux de la Figure En fonction du type des contenus, contenu streamé ou Web, ces derniers sont acheminés par le serveur HTTP ou le serveur de streaming. Ces serveurs sont capables de mettre en place une communication point à point classique entre eux et les clients, ces connexions ont un débits suffisant pour acheminer le contenu (cela sera vérifié par la position de l entité de réplication), le délai et ses variations sont le plus stable possible, le délai restant faible afin d assurer une bonne interactivité entre l utilisateur et le serveur. La fiabilité doit être totale même si certains codages peuvent supporter des pertes. Ces besoins et objectifs de qualité sont dépendants du type de contenu. Flux associé au fonctionnement de l architecture de réplication : Le flux de fonctionnement de l architecture de réplication correspond au flux d échange des messages d état des différentes entités de réplications avec l entité maître. De la même façon cela inclut les messages de configuration des entités de réplication pour le rapatriement des contenus. Le débit de ce flux de messages est faible car constitué de document XML de quelques kilooctets de description. Ce flux est acheminé pas le système de communication satellite ou terrestre suivant le déploiement des entités de réplication, en utilisant un service de communication point à point, éventuellement multipoint pour des communication de groupe à l ensemble des entités Système utilisateur Le système utilisateur permet de gérer les interactions entre le téléspectateur et le système global de télévision interactive. Les fonctionnalités associées à ce système sont d assurer la visualisation du flux télévisé, la visualisation des déclencheurs lors de la présence d un contenu associé et finalement la présentation des contenus interactifs associés à l émission lors de la demande du téléspectateur. Ce système est caractérisé par le l unité de télévision interactive (UTI). L UTI permet la visualisation du flux télévisé, c est le flux audio-visuel MPEG2 classique issue de la diffusion télévisuelle. Les conditions de visualisation sont les conditions traditionnelles d un flux télévisé plein écran. L UTI doit de plus être en mesure d effectuer une incrustation vidéo sur un écran secondaire (p.ex. une fenêtre), pour l affichage des contenus interactifs. L écran de visualisation secondaire permet la restitution des contenus associés (vidéo, audio, ou Web) dans une fenêtre de taille réduite incrustée sur l écran de visualisation. Lors de la présence d un contenu interactif au niveau des unités de réplication, le système de production aura émis un déclencheur. L UTI prévient le téléspectateur de la présence du contenu par un signal visuel approprié. Afin de ne pas trop interférer avec la visualisation de l émission, ce signal se matérialise par une incrustation vidéo au bas de l écran de visualisation télévisuel. L utilisateur peut déclencher l accès aux contenus interactifs par le biais d une série de modes permettant la visualisation couplée du flux télévisé et du contenu associé. Selon le type de média associé, les dispositifs de visualisation et le système de restitution audio, peuvent

121 restituer tout ou partie des deux flux. Lors de l accès à un contenu interactif, l écran des contenus interactifs est incrusté dans le coin supérieur gauche avec l accès au dispositif de restitution sonore. L ITU permet ensuite de changer les modes de visualisation pour visualiser soit l écran des contenus interactifs seul, avec l incrustation de l écran télévisuel, et réciproquement. L écran des contenus interactifs permet d accéder aux contenus stockés dans les unités de réplication par l intermédiaire du réseau d accès et des protocoles de l Internet Implémentation et test Une maquette fonctionnelle du système MITv a été développé en utilisant le langage de programmation JAVA (JDK 1.4.1) et les librairies additionnelles multimédia JMF (Java Media Framework 2.1.1) et Quicktime, dans un souci de portabilité du code et grâce à la richesse des bibliothèques de communication et multimédia. De plus, les bonnes performances du langage JAVA et la facilité de gestion des environnements graphiques ont confirmé ce choix. Les différentes parties du système de télévision interactive vont être détaillées. Le système de production est constitué d une interface (cf. Figure 6.2-5) permettant de définir le programme de télévision en spécifiant le flux TV à émettre, les données associées et les déclencheurs. Figure Interface du système de production. Le programme télévisé à émettre est constitué d un fichier vidéo unique (de taille) à la place d un flux vidéo de direct à distribuer afin de simplifier l application. En effet, le choix d émuler le service de télévision numérique (MPEG2/DVB) a été fait car ce type de service est connu est bien maîtrisé actuellement. Les contenus multimédia associés et les déclencheurs peuvent alors être définis. Le contenu associé est spécifié par un ensemble de fichiers multimédia à transférer entre l entité de réplication maître et les entités de réplication. La date de début et la durée de disponibilité du contenu sont alors spécifiées par l intermédiaire de la création des déclencheurs associés à l émission et au contenu. En complément de ces informations, le type de contenu doit être

122 spécifié pour le déclencheur afin de connaître la nature du contenu Web, Vidéo ou Audio et donc de déterminer les protocoles à mettre en œuvre au niveau de unité de télévision interactive pour la présentation, ainsi que la zone de diffusion définie par un groupe de réception multipoint dans notre cas pour l envoi du contenu et des déclencheurs à l aide du système de communication multipoint. Cette spécification détermine alors le scénario et les dates d émissions des contenus associés pour assurer la présence dans les entités de réplication. Ces informations peuvent alors être fourni à l entité de réplication maître. L entité de réplication maître fait partie intégrante du système de production. L implémentation du protocole de communication entre les entités réplication a elle aussi été simplifiée pour cette maquette. L intérêt de ce système était de montrer l obtention des garanties de QoS pour les utilisateurs finaux. Aussi les hypothèses suivantes ont été faites, les entités de réplication possède les capacités réseaux et de stockage pour assurer les garanties pour le spot considéré. Ainsi le système vérifie simplement la présence de l entité de réplication. De plus, toutes les entités de réplications sont identiques et sont constitués d un serveur Web Apache permettant les connexions HTTP, et d un serveur de streaming Darwin acceptant les connexions RTP, RSTP et http pour le streaming. Le protocole de redirection n a pas non plus été émulé dans un soucis de simplification de la maquette. Les utilisateurs d un spot particulier connaissent explicitement leur entité de réplication attitrée. Les entités de réplication possèdent le module de réception multipoint et point à point pour communiquer et transférer les contenus. Le système utilisateur est en charge de la présentation des différents flux de données du système et gère l interactivité avec l utilisateur final. Pour ce, l interface se présente sous la forme de trois fenêtres. La première permet la visualisation des images. La seconde correspond à une représentation de la télécommande du système. La dernière représente le décodeur numérique MPEG2/DVB-S (cf. Figure 6.2-6). Figure Interface du système utilisateur. La télécommande permet de gérer les interactions de façon simple entre utilisateur final, les informations arrivant sur son terminal de présentation et les contenus stockés au niveau des entités de réplication. La maquette de MITv n a pas pour but de montrer la faisabilité d un système de transmission de flux télévisuel (technologie bien maîtrisée), mais de montrer l intérêt d un

123 couplage service MPEG2/DVB et service réseau IP Multicast et plus particulièrement l obtention des garanties de QoS par l intermédiaire de l architecture de réplication. La réalisation de la maquette MITv a entraîné une simplification au niveau de l architecture de réplication mais elle permet tout de même de quantifier l apport en terme de qualité de service pour les utilisateurs finaux. Le test de cette maquette dans à l aide d un environnement satellite réel aurait été particulièrement difficile et coûteux. Aussi, le système MITv a été testé sur une plate forme d émulation de réseau IP, NINE (Nine Is a Network Emulator). Cette plate forme d émulation reproduit le comportement d un réseau IP dont les caractéristiques en terme de QoS sont issues d un modèle d émulation, ici correspondant au système DIPCAST. En configurant, les contraintes associées au traitement des flux dans les divers environnements réseaux, il en résulte une émulation du comportement des applications, protocoles de communication et de l infrastructure satellite DIPCAST. Cette plate forme repose sur le moteur d émulation Dummynet [96] proposé dans le système FreeBSD et d un logiciel de configuration développé au laboratoire ENSICA/DMI, qui gère le déploiement de la configuration de la plate forme et le contrôle dynamique de l évolution du scénario d émulation. NINE a été configurée pour reproduire le service du système satellite et d un réseau ADSL en temps réel. Un modèle d émulation dynamique définissant un ensemble de règles a permis de contraindre les différents flux transitant dans le système. Plusieurs scénarii introduisant différentes conditions de propagation de signal permettent de tester le fonctionnement du système dans des situations réalistes. La figure suivante montre le modèle d émulation qui a été utilisé pour tester l environnement de MITv. Les plr (packet loss rate) évoluent au cours du temps en fonction des conditions atmosphériques. Figure Représentation du système émulé pour MITv. Ainsi, si l hôte ST1 envoie un message vers l hôte ST2, le message transite d abord par le réseau ADSL avec la QoS correspondante, avant d être envoyé par le système DVB- RCS (i.e. et en appliquant la QoS correspondante) jusqu à la gateway avant d être réémis vers l hôte ST2 selon la technologie DVB-S. De nombreuses expériences ont été menées en utilisant la plate forme d émulation NINE avec les conditions d émulation définies à la Figure Les résultats de la Figure mettent en avant quelques valeurs obtenues concernant les performances réseaux lors

124 des échanges entre les diverses entités du système, (Communication utilisateurs final/entité de réplication, Entité de réplication maître/entité de réplication, etc.). Média Débit Délai Fiabilité CI (Web) 53Kb/s 41ms Totale CI (audio) 133Kb/s 41ms Totale CI (audio/vidéo) 874Kb/s 41ms Totale Alimentation ER 1562Kb/s 302ms Totale Déclencheur 4.82Kb/s 344ms Totale Figure Performances du système résultantes de l'émulation. Les résultats de ces tests et mesures permettent de montrer l intérêt d un système de télévision interactive couplant les systèmes de communication DVB et IP multicast. L indépendance du support de diffusion télévisuel est un des points à souligner dans la réalisation d un système de télévision interactive utilisant des technologies actuellement déployées. Le système reposant sur une architecture de réplication, les mesures obtenues permettent de montrer l intérêt et l obtention du respect des paramètres de QoS. De plus la nature multi spots a permis de conforter l idée du partitionnement de contenu et ne répliquant plus que les contenus nécessaires au niveau des entités concernées. Cela s est traduit par la régionalisation du contenu en fonction des caractéristiques de langue ou du pays. En complément, l utilisation de cette architecture de réplication a montré que les requêtes des utilisateurs sont envoyées vers les entités de réplication et ne transite par sur le réseau satellite. Ainsi, cette solution de télévision interactive est évolutive, car le nombre potentiel de clients finaux n induit pas de charge supplémentaire pour le lien satellite qui est considéré comme la ressource critique d un tel système DISCUSSION La solution MITv de télévision interactive, associant un système de communication satellite et une architecture de réplication permet de fournir une qualité de service en adéquation avec les besoins des applications de consultation de multimédia à la demande. Le nombre d utilisateurs potentiellement intéressés par un tel service correspond au nombre d utilisateurs utilisant les services de diffusion de télévision actuellement disponibles, et donc potentiellement très important. Les utilisateurs peuvent être disséminés sur toute la zone de couverture du satellite. De plus, les particularités linguistiques et culturelles des différents pays d Europe sont prises en compte dans les systèmes de diffusion télévision MPEG2/DVB et au niveau de la distribution des contenus dans l architecture de réplication. Bien que les hypothèses effectuées sur la maquette du système MITv et l architecture de réplication soient quelque peu restrictives, les résultats obtenus par l émulation du système permettent de montrer l intérêt d un système de réplication à garantie de QoS. Les expériences ont permis de montrer le fonctionnement global du système et de valider l obtention de la QoS attendu au niveau des utilisateurs finaux. De plus, la régionalisation du contenu a permis de mettre en évidence le gain de capacités de stockage en tenant compte des particularités linguistiques et culturelles des utilisateurs finaux, en ne stockant que les contenus correspondant au zone géographique. Cette solution de distribution s appuyant sur un système de communication multipoint par satellite est particulièrement adaptée à la copie des contenus dans les entités de réplication. Les entités de réplication sont potentiellement nombreuses et distribuées géographiquement à l échelle d une région, d un pays voire d un continent. Un système de communication multipoint basé sur un support à diffusion à large échelle permet d optimiser

125 l utilisation des ressources réseau. Le service de communication multipoint permet de gérer simplement la diffusion des déclencheurs, les groupes d utilisateurs et les particularités linguistiques et culturelles des contenus associés. L utilisation du système satellite permet d assurer une synchronisation de la disponibilité des contenus dans toutes les entités de réplication. Les attentes en terme de QoS au niveau des utilisateurs finaux sont elles aussi bien atteintes grâce aux propriétés des réseaux d accès et par le placement des entités de réplication au niveau de ces points d accès. Outre l obtention des attentes en terme de QoS, la gestion des entités de réplication est facilitée par le système MITv, car il est possible de prévoir un scénario de présence pour les contenus en fonction des émissions télévisées. De la même façon, il est possible de déterminer des pics d accès au contenu en fonction de leur annonce par les déclencheurs. Un autre point important concernant l architecture de réplication et de la gestion du déploiement des contenus sur plusieurs zones géographiques. Le schéma décisionnel du déploiement des contenus et la détermination du nombre de répliquas dépendent de la distribution en terme de bande passante des entités de réplication pour une zone géographique considérée. La proposition d architecture de réplication permet alors lorsque des zones géographiques ne sont pas disjointes et doivent être traitées de façon commune de déterminer le nombre de serveur en commun pour diminuer le nombre de répliquas et obtenir le service considéré. Dans le cadre de l application MITv, les différentes zones géographiques sont constituées des différents spots du satellite. De plus, les contraintes en terme de QoS pour les utilisateurs finaux, à cause du double bond, peuvent être des critères pour considérer chaque zone géographique disjointe, le double bond induisant des délais de plus de 500ms limitant l interactivité. Aussi dans ce cadre d étude, le déploiement d un contenu doit être étudié pour chaque zone géographique séparément. Le résultat obtenu sera optimal pour le service considéré en terme du nombre de répliquas et de capacité de stockage utilisée. Ainsi, en fonction de l intersection des zones géographiques l intérêt d une telle architecture peut être discutée. Comme le montre la Figure 6.3-1, trois cas particuliers de répartition des zones géographiques peuvent survenir.

126 Figure Cas de répartition des zones géographiques. Le premier cas, cas (a), considère deux zones géographiques disjointes, c est le cas d étude de MITv. Déterminer le nombre de répliquas et leur déploiement revient pour un même contenu donné dans les 2 zones, à étudier le déploiement de ce contenu pour chacune des zones séparées. La capacité de stockage utilisée sera minimale pour chaque zone. Le second cas, cas (b), met en avant deux zones géographiques, dont les répartitions en terme de bande passante ne sont plus cette fois disjointe. Leur intersection est cette fois non vide. Pour un contenu et un service de QoS donné, déterminer le nombre de répliquas et leur dissémination revient à étudier séparément les deux zones, puis déterminer le nombre d entité de réplication commune pouvant recevoir le contenu et assurer le service. Cela revient à déterminer le plus grand ensemble de serveur commun entre les zones géographique. Une fois cela déterminé la réplication des contenus pourra être effectuée et le nombre de contenu comme la capacité de stockage utilisée seront limités au minimum pour assurer le service pour l ensemble des zones. Bien évidemment le gain obtenu dans le cadre d une intersection non vide dépend du nombre serveurs communs et de leurs capacités en termes de bande passante vers les différentes zones. Finalement, le dernier cas, le cas (c), où cette fois ci, les deux zones géographiques se recouvrent. En d autres termes, les entités de réplication appartiennent aux deux zones géographiques mais ne sont pas dans les mêmes zones de répartition en terme de bande passante. Ainsi, le cas le pire est celui représenté dans le cas (c) de la Figure Les serveurs ayant un débit important pour la zone géographique A, sont les serveurs ayant les plus faibles débits pour la zone B. Réciproquement, les serveurs ayant le plus faible débit vers la zone A sont les serveurs ayant les débits les plus important pour la zone B. Pour un même contenu ayant des contraintes de QoS importantes, le déploiement dans les deux zones va impliquer que seul les serveurs avec des débits important pour assurer le service. Or

127 l intersection des serveurs capables de fournir le contenu avec les contraintes considérées sera vide et en plus complémentaire. Ainsi les serveurs qui ne sont pas en mesure de fournir le service pour la zone A, seront en mesure de le rendre pour la zone B et réciproquement. L étude du partitionnement du contenu dans ce cas la n apporte qu une complication superflue. Une répartition de zone géographique et des entités de réplication en termes de bande passante similaire permet de conclure que les solutions actuellement déployées comme les CDN obtiennent de bons résultats en utilisant une capacité de stockage quasi minimale. Bien évidemment, ce cas est un cas extrême, et dans toutes les autres configurations le nombre de répliquas et la capacité de stockage utilisé sont minimum pour un contenu et un service donné CONCLUSION DU CHAPITRE Le système de télévision interactive MITv couple l utilisation des systèmes de diffusion numérique de télévision et d une architecture de réplication à garantie de qualité de service. Ce chapitre a mis en avant une utilisation possible d une architecture de réplication et les gains apportés pour les utilisateurs finaux. De plus, l utilisation d un système de communication multipoint par satellite a montré un intérêt particulier pour le déploiement de contenus régionalisé en fonction des caractéristiques culturelles et linguistiques des utilisateurs. L émulation du système MITv a permis de montrer le gain en terme de QoS pour les utilisateurs. D autre part, cette solution résiste au facteur d échelle car mise à l échelle car le nombre d utilisateurs n est pas limitant car ne crée pas d utilisation de ressource réseau supplémentaire sur le lien satellite. Outre le respect des contraintes de qualité de service imposées pour un contenu donné, le gain en terme de capacité de stockage a été mis en avant. La discussion sur la répartition en terme de bande passante des entités de réplication pour un ensemble de zone géographique a permis de montrer les avantages et les limitations du partitionnement des contenus et de leur régionalisation. Néanmoins, dans la majorité des cas, le partitionnement des contenus pour une entité de réplication permet d obtenir des garanties de qualité de service et soit une capacité de stockage mieux gérée, soit un nombre de contenu stocké plus important, synonyme de revenus plus important pour le fournisseur de service de réplication.

128

129 CHAPITRE 7. CONCLUSION GENERALE La gestion de la qualité de service dans le domaine des réseaux et télécommunication est un objectif récurrent. L évolution du comportement des utilisateurs finaux et l apparition de nouvelles applications ayant des contraintes en terme de performances réseau de plus en plus importantes, ne cesseront de faire évoluer les besoins de gestion de la qualité de service. L étude bibliographique des travaux du domaine a illustré les manières classiques de gérer les contraintes de QoS en utilisant des approches de niveau transport et réseau. Cependant, des difficultés d ordre techniques et extra techniques apparaissent dès qu il s agit d assurer des garanties de bout en bout dans un contexte multi domaines. D autre part, gérer et maintenir des garanties de QoS sur des paramètres tels que le délai de bout en bout, la gigue ou le débit, peut être considérés comme trop coûteux pour certaines applications traditionnelles comme le Web. Fort de ce constat, nous avons analysé et étudié les approches complémentaires comme le surdimensionnement, la gestion de trafic, et d autres approches techniques afin de proposer une approche alternative et complémentaire aux approches traditionnelles RAPPELS DES CONTRIBUTIONS Afin de pallier à l augmentation croissante du trafic et dans un souci d obtenir une meilleure qualité de service, des solutions transversales aux approches réseaux et transports ont vues le jour. Une de ces techniques est le stockage distribué, approche générale mise en œuvre dans le cadre du caching depuis de nombreuses années, avant d être mise à nouveau à profit dans des systèmes P2P (Peer to Peer) ou des CDN (Content Delivery Network). Dans le but de gérer différemment les contraintes de qualité de service, nous proposons une approche de la gestion de la QoS à l aide de la réplication. Etude de la réplication comme composante de gestion de la qualité de service La première contribution proposée dans cette thèse (Chapitre 3) caractérise la réplication comme une composante de gestion de la qualité de service. La réplication est définie comme une solution alternative pour augmenter les performances d accès à des contenus en terme de qualité de service (section 3.2). L idée sous jacente de la réplication est d utiliser de préférence un contenu répliqué plutôt que l original. Les clients finaux accèdent à une unité de réplication, ce qui évite d utiliser les ressources réseau éventuellement nécessaires pour contacter le serveur original et recevoir le contenu. Le contenu est stocké à proximité des utilisateurs, les temps de réponse et les débits d accès à ces données sont optimisés. La qualité de service ressentie par l usager final est finalement améliorée. L état de l art des solutions les plus courantes mettant en œuvre la réplication comme les Content Delivery Network (section 3.3) ou les réseaux de Peer to Peer (section 3.4) a permis de proposer une représentation des structures de recouvrement (section 3.5) afin d y étudier l impact de la réplication et les caractéristiques obtenues en termes de qualité de service. Proposition d amélioration de la gestion de la réplication dans des structures de recouvrements

130 Notre deuxième contribution (Chapitre 4) consiste à évaluer et quantifier la gestion de la réplication dans des structures de recouvrements particulières que sont les CDN et les réseaux de Peer to Peer. En utilisant la modélisation des structures de recouvrement définie dans la précédente contribution, couplé aux caractéristiques de chacune des deux structures, nous avons proposé des solutions pour améliorer les performances d accès aux contenus tout en quantifiant la qualité de service pouvant être obtenue. Dans le contexte des réseaux de Peer to Peer, cette solution PeerFecT (section 4.2.2) repose sur l utilisation d un code à effacement qui permet d augmenter la disponibilité des contenus en augmentant la diversité, grâce aux propriétés introduites par l utilisation du code. Dans le cadre des CDN (section 4.3), la proposition consiste à gérer la réplication en fonction des contraintes du contenus et en fonction des capacités des différentes entités de réplication. Cela revient à déterminer le déploiement effectif qu il est nécessaire d opérer pour obtenir des garanties statistiques de QoS. Cette gestion des contenus permet alors d obtenir des garanties statistiques et une meilleure gestion des capacités de stockages des entités de réplication. Définition d une architecture de réplication à garantie de qualité de service En combinant les améliorations obtenues dans le cadre de chacun des types d architecture de recouvrement, notre contribution a été de proposer une architecture reposant sur la réplication pour fournir une amélioration de la qualité de service (Chapitre 5). Afin de tirer partie, de cette architecture, la notion de contenu a été définie est décrite à l aide d un modèle XML (section 5.2). En se basant, sur les descriptions de contenus et sur les propriétés des entités de réplications, le détail de l architecture de réplication a été effectué, reposant sur le couplage des deux systèmes de recouvrement étudiés et améliorés précédemment. Etude d une mise en œuvre possible d une architecture de réplication Afin d évaluer notre réponse au problème de gestion de la qualité de service, une évaluation dans le cadre d une étude expérimentale (Chapitre 6) a été réalisé dans le cadre d un réseau satellitaire pouvant mettre en œuvre des communications multipoints. L architecture de réplication basée sur se réseau a pu être simplifiée et utilisé dans le cadre d une application de télévision interactive MITv (section 6.2.3). Ce système de télévision interactive tire profit du couplage des services traditionnels de diffusion télévisuelle des systèmes satellite classique et des garanties de service obtenues par l intermédiaire de l architecture de réplication. Une maquette du système a été réalisée et évaluée sur une émulateur de réseaux IP, permettant de reproduire le comportement en temps réel des conditions de fonctionnement d un réseau IP multicast par satellite (section 6.2.4). Le fonctionnement global du système et les gains obtenus grâce à l architecture de réplication ont ainsi été validés et mesurés PERSPECTIVES Evaluation de l architecture de réplication dans un environnement complexe L évaluation de l architecture de réplication dans le contexte d une application de télévision interactive utilisant un système de communication multipoint par satellite a bénéficié des avantages et éventuels inconvénients induits par le contexte satellitaire, (débits ou des délais de diffusion important, une zone géographique très vaste, etc.). Une évaluation de l architecture de réplication dans un environnement conforme à un réseau filaire d accès traditionnel permettrait de quantifier le gain obtenu dans des conditions de fonctionnement proche de la réalité. Bien sur, un déploiement de l architecture étant difficilement envisageable, une évaluation par simulation ou par émulation validera comme dans le cadre de l application de télévision interactive les résultats obtenus dans un contexte réseau traditionnel.

131 Evaluation dans un contexte de réseau mobile L intérêt de l architecture de réplication s est basé sur l utilisation d un réseau IP sans contrainte particulière. L évaluation des gains obtenus dans un contexte de réseau mobile pourrait fournir une solution de stockage adaptée aux environnements mobile. Les études menées dans [97] et [98] montrent les gains en termes de réduction de trafic et étudient des moyens de gestions des caches dans un contexte mobile. Des solutions de type réseaux de bordure (edge network) ou éventuellement d entité de réplication mobile pourrait être étudiées afin d obtenir une amélioration de la qualité de service pour la distribution de contenus multimédia dans un tel contexte. Etude d un déploiement actif d un service de réplication L étude menée dans le cadre de cette thèse repose sur un déploiement préalable des entités de réplication dans le réseau. Les travaux actuels dans le domaine des CDN étudient les déploiements de nouveaux types de service, comme le ré encodage de vidéo à la volée, ou l adaptation de résolution pour les images, à l aide par exemple du protocole OPES [51]. Les réseaux programmables ou réseaux actifs permettrent de déployer de nouveaux services multimédia ou service de gestion de la QoS, [99], [100], [101]. Une étude sur le déploiement actif d un service de réplication afin de garantir une amélioration des paramètres de QoS, dans des nœuds du réseau privilégiés pourrait montrer un intérêt supplémentaire et complémentaire aux améliorations envisagées à l aide du protocole OPES.

132

133 ACRONYMES ATM, Asynchronous Transfert Mode QoS, Quality of Service xdsl, x Digital Suscriber Line IP, Internet Protocol NSP, Network Service Provider NAP, Network Access Point HTTP, Hypertext Transfert Protocol HTTPS, Hypertext Transfert Protocol Securized ICP, Internet Cache Protocol HTCP,Hyper Text Cache Portocol CARP, Cache Array Routing Protocol IETF, Internet Engineering Task Force URL, Uniforml Resource Locator RTP, Real Time Protocol RTSP, Real Time Streaming Protocol FTP, File Transfert Protocol CDN, Content Delivery Network POP, Point of Presence P2P, Peer to Peer FEC, Forward Error Correction LAN, Plocal Area Network RNIS, Réseau Numérique à Intégration de Service GPRS, General Packet Radio Service ASP, Application Service Provider ISP, Internet Service Provider WSP, Wireless Service Provider SSP, Storage Service Provider HSP, Hosting Service Provider RTT, Round Trip Time ITU-T, International Telecommunication Union TCP, Transmission Control Protocol UDP, User Datagram Protocol RSVP, Resource ReservationProtocol MPLS, Multi Protocol Label Switching PHB, Per Hop Behavior DWDM, Dense Wavelength-Division Multiplexing POC, Partial Order Connexion FPTP, Fully Programmable Transport Protocol ALF, Application Level Framing SCTP, Stream Control Transmission Protocol MTU, Maximum Transmission Unit DCCP, Datagram Congestion Control Protocol WWW, World Wide Web OPES, Open Pluggable Edges Services MMS, Microsoft Media Streaming DNS, Domain Name System RDIST, Remote Software Distribution System BFS, Breadth First Search

134 DBFS, Directed Breadth First Search ARQ, Automatic Repeat Request MDS, Maximum Distance Separable RNRT, Réseau National de Recherche en Télécommunications DVB, Digital Video Broadcast DIPCAST, Dvb comme support de l'ip multicast par SaTellite MiTV, Multicast Interactive Television DSLAM, Digital Subscriber Line Access Multiplexor

135 BIBLIOGRAPHIE [1] Saltzer J., Reed D., Clark D., «End to end arguments in system design», In : ACM Transaction Computer System, [2] The service provider Industry Network xsp, [3] Chuah, C. N., A Scalable Framework for IP-Network Resource Provisioning Through Aggregation and Hierarchical Control, Ph.D. Thesis, University of California at Berkeley, Fall [4] Norton, W. B., Interconnection Strategies for ISPs, personal draft v2.0, May [5] Akamai Technologies, Internet Bottlenecks: the Case for Edge Delivery Services, White Paper, [6] Allen, D., The Impact of Peering on ISP Performance: What s the Best for You?, Network Magazine, November, [7] Huston, G., Interconnection, Peering, and Settlements, Internet Society Conference 99 (INET99), June [8] Thomas Serval, «Aspects de l'économie de l'internet», École normale supérieure & Harvard University, octobre 1999 [9] Samir Chatterjee, Jongbok Byun: "Quest for the End-to-End Network QoS", Americas Conference on Information Systems, August 2003, Dallas, Texas, USA [10] Gressier E., «Les Principes de la QoS, Notion de Qualité de Service», Compte rendu du Groupe SCI, CNAM Paris, juin [11] Baker, F. (editor) et al., Requirements for IP Version 4 Routers, RFC 1812, June [12] Xiao, X., Providing Quality of Service in the Internet, Ph.D. Thesis, Michigan State University, May [13] Rojas L., Dairaine L., Sénac P., Diaz M., «Service d ordre et de fiabilité partiels : Etude et implantation de la fiabilité conforme à la sémantique de l application», 7ème Colloque Francophone sur l'ingénierie des Protocoles (CFIP'99) Nancy, avril [14] Smirnov, M. & Einsiedler, H. J., Key QoS Management Issues, Internet Draft, <draftsmirnov- key-qosissues-00.txt>, November [15] Braden, R., Clark, D. & Shenker, S., Integrated Services in the Internet Architecture: an Overview, RFC 1633, June [16] Shenker, S., Partridge, C. & Guerin, R., Specification of Guaranteed Quality of Service, RFC 2212, September [17] Wroclawski, J., Specification of the Controlled-Load Network Element Service, RFC 2211, September [18] Braden, R. et al., Resource Reservation Protocol (RSVP) Version 1 Functional Specification, RFC 2205, September [19] Cukier, K. N., Peering and Fearing: ISP Interconnection and Regulatory Issues, Conference on the Impact on Communications Policy, Harvard University, December [20] Heinamen, J. et al., Assured Forwarding PHB Group, RFC 2597, June [21] Nichols, K. et al., Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, December [22] Jan Gerke et al, Quality of Service for Application Service Provider TIK report N 170, January [23] Rosen, E., Viswanathan, A. & Callon, R., Multiprotocol Label Switching Architecture, RFC 3031, January [24] Xiao, X., Traffic Engineering with MPLS in the Internet, IEEE Network, March [25] Crawley, E. et al., A Framework for QoS-based Routing in the Internet, RFC 2386, August [26] Xiao, X. & Ni, L. M., Internet QoS: A Big Picture, IEEE Network, March [27] Allard. H., "Understanding QoS. How to obtain quality over bursty networks", Teleconference, January [28] Postel J., "Transmission Control Protocol; DARPA Internet Program Protocol Specification," RFC 793, September 1981 [29] Postel J., "User Datagram Protocol (UDP)", RFC 768, August 1980 [30] Clark D. et Tenenhouse D., «Architectural Considerations for a New Generation of Protocols», proceedings ACM SIGCOMM, Philadelphia, septembre [31] Diaz M., Lozes A., Chassot C., Amer P., «Partial Order Connections: a New Concept for High Speed and Multimedia Services and Protocols», Annales des Télécommunications, vol. 49, n 5-6, [32] Amer P., Chassot C., Connolly T., et Diaz M., «Partial Order Transport Service for Multimedia Applica-tions», IEEE/ACM Transactions on Networking, vol. 2, no 5, octobre [33] E. Exposito, «Spécification et mise en œuvre d'un protocole de transport orienté Qualité de Service pour les applications multimédias», Thèse de doctorat de l'institut National Polytechnique de Toulouse, décembre 2003

136 [34] Rojas L., Dairaine L., Sénac P., Diaz M., «Service d ordre et de fiabilité partiels : Etude et implantation de la fiabilité conforme à la sémantique de l application», 7ème Colloque Francophone sur l'ingénierie des Proto-coles (CFIP'99) Nancy, avril [35] Schulzrinne H., Casner S., Frederick R., and Jacobson V., "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, Jan 1996 [36] Stewart R. et al., "Stream control transmission protocol", RFC 2960, Octobre 2000 [37] Kohler E. et al, "Datagram Congestion Control Protocol (DCCP)", Internet Draft : draftkohler-dcp-04.txt, Octobre [38] Barish G., Obraczka K., «World Wide Web Caching : Trends and Techniques», IEEE Communications Magazine Internet Technology Series, mai [39] Gadde S., Chase J., «Web Caching and Content Distribution: a View from the Interior», Proceedings : 5TH International Web Caching and Content Delivery Workshop, [40] J. Chuang «Distributed network storage service with quality-of-service guarantees», actes de la conference Inter-net Society INET'99, San Jose CA, juin [41] Juniper communications, Survey of 2369 users, pub.6/99, june [42] Digital Island, [43] Akamai, [44] Markus Hofmann, Content Delivery and beyond, Bell Labs Lucent Technologies, NGC [45] RFC Internet Web Replication and Caching Taxonomy [46] RFC Internet Cache Protocol (ICP), version 2 [47] RFC Application of Internet Cache Protocol (ICP), version 2 [48] NLANR Cache Digest specification - version [49] RFC Hyper Text Caching Protocol [50] Internet Draft Cache Array Routing Protocol v1.0, 1998 [51] RFC Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios [52] RFC Internet Content Adaptation Protocol (ICAP) [53] Cnet News, [54] Telematica Instituut, Content Distribution Network, june [55] Napster, [56] Li Gong, Peer-to-Peer Networks in Action, IEEE Internet Computing, January-February 2002 [57] [58] [59] [60] John Kubiatowicz, David Bindel, Yan Chen, Steven Czerwinski, Patrick Eaton, Dennis Geels, Ramakrishna Gummadi, Sean Rhea, Hakim Weatherspoon, Westley Weimer, Chris Wells, and Ben Zhao, OceanStore: An Architecture for Global-Scale Persistent Storage,. Appears in Proceedings of the Ninth international Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS 2000), November [61] [62] [63] Roman Schmidt, Gridella: an open and efficient Gnutella-compatible Peer-to-Peer System based on the P-Grid approach, [64] [65] S. Saroiu, P. Gummadi, S. Gribble, A Measurement Study of Peer-to-Peer File Sharing Systems, Technical Report, UW-CSE , University of Washington, Department of Computer Science and Engineering, Seattle, WA , July 2001 [66] Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, and Scott Shenker. A scalable content-addressable network. In Proc. ACM SIGCOMM 01, San Diego, California, August [67] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari Balakrishnan. Chord: A scalable peer-to-peer lookup service for Internet applications. In Proc. ACM SIGCOMM 01, San Diego, California, August [68] Antony Rowstron and Peter Druschel. Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems. In Proc. IFIP/ACM Middleware 2001, Heidelberg, Germany, November [69] Ben Y. Zhao, John D. Kubiatowicz, and Anthony D. Joseph. Tapestry: An infrastructure for fault-resilient wide-area location and routing. Technical Report UCB//CSD , U. C. Berkeley, April [70] K. Aberer, M. Punceva, M. Hauswirth, R. Schmidt, Improving Data Access in P2P Systems, IEEE Internet Computing 6, 1, pp , Jan./Feb [71] E. Cohen, S. Shenker Replication Strategies in Unstructured Peer-to-peer Networks, ACM SIGCOMM 2002, August [72] C. G. Plaxton, R. Rajaraman, A. W. Richa, Accessing Nearby Copies of Replicated Objects in Distributed Environment, Proc. ACM Symp. Parallel Algorithms and Architectures, ACM Press, New York, June 1997.

137 [73] H.Weatherspoon, J. D. Kubiatowicz, Erasure Coding vs. Replication : A Quantitative Comparison, inproc. of IPTPS '02, March [74] I. S. Reed, G. Solomon, Polynomial Codes Over Certain Finite Field, J. SIAM, vol. 8, pp , [75] L. Rizzo, Effective Erasure Codes for Reliable Computer Communication Protocols, In Computer Communication Review, April [76] J. Bloemer, M. Kalfane, M. Karpinski, R. Karp, M. Luby, D. Zuckerman, An XOR- Based Erasure-Resilient Coding Scheme, ICSI TR , August [77] J. W. Byers, M. Luby, M. Mitzenmacher, A. Rege, A Digital Fountain Approach to Reliable Distribution of Bulk Data, ACM SIGCOMM '98, September 2-4, [78] R. G. Gallager, Low-density parity check codes, MIT Press, [79] Y. Chen, J. Edler, A. Goldberg, A. Goettlieb, S. Sobti, P. Yianilos Prototype Implementation of Archival Intermemory, in Proc. of IEEE ICDE, February [80] P. Rodriguez, A. Kirpal, E. W. Biersack, Parallel-Access for Mirror Sites in the Internet, In Proceedings of IEEE/Infocom'2000, Tel-Aviv, Israel. March [81] K. Lai, M Baker, Nettimer : a tool for measuring bottleneck link bandwidth, in INFOCOM 01, [82] Jérôme Lacan, Laurent Dairaine, Laurent Lancerica, Jérôme Fimes PeerFecT : Efficient Peer to Peer Data Access Scheme Using a Fast Integer-based Cauchy Erasure Code, Research Report ENSICA, 2003 [83] D. Hugues, I. Warren, G Coulson, QoS Assurance on Decentralized Peer-to-Peer Networks, submitted to IPTPS'03. [84] [2] I. Clarke, O. Sandberg, B. Wiley, T.W. Hong; Freenet: A distributed anonymous information storage and retrieval system": Workshop on Design Issues in Anonymity and Unobservability, Berkeley, CA, pp , [85] Giwon On and Jens Schmitt and ralf steinmetz, On Availability QoS for Replicated Multimedia Service and Content, Proceedings of International Workshop on Interactive Distributed Multimedia Systems 2002 (IDMS02), Coimbra [86] F. Garcia, C. Chassot, A. Lozes, M. Diaz, P. Anelli, E. Lochin, «Conception, Implémentation and Evalua-tion of a QoS-based Architecture for an IP Environnement Supporting Differentiated Services», 8th International Workshop on Interactive Distributed Multimedia Systems (IDMS'2001), Lancaster (GB), Septembre [87] ITU-T recommendation F700. [88] Ernesto Exposito, Mathieu Gineste, Romain Peyrichou, Patrick Senac, Michel Diaz XQOS : XML-based QoS specification language - MMM 03 The 9th International Conference on Multi-Media Modeling, January 7-10, 2003, Taiwan. [89] Yunxi Sherlia Shi, DESIGN OF OVERLAY NETWORKS FOR INTERNET MULTICAST Ph D Thesis, Washingtin University, August [90] Dan Li, David R. Cheriton Scalable web caching of frequently updated objects unsing reliable multicast, Proceedings of USITS 99, October [91] A. Koifman; S. Zabele; RAMP: A Reliable Adaptive Multicast Protocol, Infocom, p , 1996 [92] V. Roca, B. Mordelet ``Design of a multicast file transfer tool on top of ALC'', 7th IEEE Symposium on Computers and Communications (ISCC'02), Toarmina, Italy, July 2002 [93] F. de Belleville, L. Dairaine, C. Fraboul, J. Lacan, «Une Approche Hybride Satellite/Terrestre pour le transport fiable multipoint à grande échelle», CFIP2003, Evry, [94] : F. de Belleville, L. Dairaine, J. Lacan, C. Fraboul, Reliable Multicast Transport by Satellite : a Hybrid Satellite/Terrestrial Solution with Erasure Code, 7th IEEE International Conference on High Speed Networks and Multimedia Communications HSNMC 04, Toulouse, France, 2004 [95] Architecture for video over ADSL: IP & ATM Technology, White paper Allied Telesync. [96] Rizzo, L. Dummynet: a simple approach to the evaluation of network protocols ACM Computer Communication Review 27, 1 (Jan. 1997). [97] A. Prasad Sistla, Ouri Wolfson, Yixiu Huang, Minimization of Communication Cost Through Caching in Mobile Environments IEEE Transactions on Parallel and Distributed Systems, [98] A. Kahol S. Khurana S. K. S. Gupta and P. K. Srimani, An Efficient Cache Maintenance Scheme for Mobile Environment, International Conference on Distributed Computing Systems, [99] M.Uruena, D. Larrabeiti, M. Calderon, A. Azcorra, J. Kristensen, An active network aprroch to support multimedia relays, IDMS/PROMS Coimbra, [100] Pierre-Antoine Queloz, Alex Villazón, Distributed Services Built with Mobile Code, [101] Kalaiarul Dharmalingam and Martin Collier, Netlets: A New Active Network Architecture, 2001.

138

139 BIBLIOGRAPHIE DE L AUTEUR [102] J. Lacan, L. Lancérica, L. Dairaine, When FEC Speed up Data Access in P2P Networks, Proceedings of IDMS'02 Conference (Interactive Distributed Multimedia Systems), Coimbra, Portugal, [103] Jerome Lacan, Laurent Lancerica, Laurent Dairaine, Speedup of Data Access using Error Correcting Codes in Peer to Peer Networks, in IEEE International Symposium on Information Theory (ISIT-2003) to be held in Yokohama, Japan, June [104] L. Dairaine, L. Lancérica, J. Lacan, Enhancing Peer to Peer Parallel Data Access with PeerFecT, in NGC proceedings, Munich, Germany, September [105] L. Lancérica, L. Dairaine, J. Lacan, Evaluation of Content-Access QoS for Various Dissemination Strategies in Peer to Peer Networks, in IEEE ICON, Sydney, Australia, September [106] L. Lancerica, L. Dairaine, F. de Belleville, H. Thalmensy, C. Fraboul, MITv A Solution for an Interactive TV Based on IP Multicast over Satellite, IEEE ICME 2004, Taipei 2004.

140

141 RESUME La notion de qualité de service soulève un fort intérêt dans le contexte des réseaux de communication et en particulier de l Internet. Les nouveaux besoins en termes de qualité de service et les attentes des utilisateurs finaux ont fait évoluer les contraintes à prendre en compte. Les approches classiques pour résoudre ces problèmes sont d une part de réaliser un traitement de bout en bout pour offrir un service de communication en adéquation avec le besoin des applications et d autre part de gérer les ressources de communication au sein du réseau de manière différentiée. Dans le contexte actuel, le déploiement global du support de la qualité de service dans l Internet n a toujours pas été opéré. L objectif de ce mémoire est de présenter une solution alternative mais aussi complémentaire aux approches traditionnelles de gestion de la qualité de service qui se situent généralement au niveau du réseau ou des protocoles de transport. Cette solution est basée sur la définition et l étude de la réplication au sein des architectures de recouvrement. TITLE ENHANCING QUALITY OF SERVICE IN DATA NETWORK USING MULTIMEDIA CONTENT REPLICATION ABSTRACT The notion of quality of service raises a strong interest in the context of the communication networks and particularly in the Internet context. The quality of service needs and the expectations of the end users developed news constraints to be taken into account. The classic approaches to resolve these problems are based on one hand to realize an end-to-end treatment to offer a communication service in equivalence with the need of the applications and on the other hand, to manage the communication resources in the network within differentiated ways. In the current context, the global display of the quality of service support in the Internet is not still operated. The aim of this report is to present an alternative but also additional solution to the traditional approaches of the quality of service management, which are generally situated at the network level or transport protocols. This solution is based on the definition and the study of the replication in overlay structures. DISCIPLINE RESEAUX ET TELECOMMUNICATIONS MOTS-CLES Qualité de service, CDN, Peer to Peer, architecture de recouvrement, réplication, contenus ENSICA, 1 Place Emile Blouin Toulouse cedex 5 France