Thème. le cadre des Applications Vidéo.

Transcription

1 Ministère de l Enseignement Supérieur et de la Recherche Scientifique Ecole nationale Supérieure d Informatique (E.S.I) Oued-Smar, Alger Ecole Doctorale en Science et Technologie de l Information et de la Communication (STIC) MEMOIRE Présenté pour l obtention du grade de MAGISTERE Spécialité : Informatique Option : Informatique Répartie et Mobile (IRM) Par : Sana AROUSSI Thème Méta-Routage basé sur la Qualité d Expérience dans le cadre des Applications Vidéo. Soutenu le 9 Juillet 2012 publiquement devant le Jury composé de : M r ZEGOUR Djamel Eddine Professeur (ESI) Président M r HAFFAF Hafid Professeur (Univ. Oran Es Sénia) Examinateur M r HADDADOU Hamid M.C. (ESI) Examinateur M r MELLOUK Abdelhamid Professeur (Univ. UPEC, France) Directeur de mémoire M me BOUABANA-TEBIBEL Thouraya M.C. (ESI) Co-directrice de mémoire Promotion 2010/2011

2 Dédicaces Je dédie ce travail de magistère: À mes parents qui depuis mon plus jeune âge ont toujours fait leur maximum, en consacrant temps et argent, pour m éveiller et m encourager dans mes passions. C est grâce à vous et pour vous que j ai fait mon mémoire. Aucun mot sur cette page ne saurait exprimer ce que je vous dois, ni combien je vous aime. Qu Allah vous bénisse, vous assiste, vous vienne en aide. À mes sœurs, Habiba et Hana, pour avoir contribué à la réussite de ce travail d une manière indirecte, d y avoir apporté tant d humeur et d amour et pour tout le soutien moral prodigué dans les moments les plus difficiles. À mes plus fidèles amies Amina et Lamia. Je prends le temps de vous remercier pour votre soutien, votre aide et les services que vous m avez rendus. Je vous en serais éternellement reconnaissante. À mon très cher Hamid pour ses encouragements permanents, son aide précieuse et son soutien sans faille. Je te remercie de tout mon cœur. Merci à tous. SANA

3 REMERCIEMENTS Le travail que nous allons présenter dans ce document est une synthèse de nos activités au cours d une année et demi. C est avec l aide de Dieu qu a vu le jour ce présent travail. Je commence d abord par adresser mes sincères remerciements à mon directeur de mémoire, Monsieur A. MELLOUK, pour m avoir accordé l honneur de travailler avec lui, pour m avoir permis, par la même occasion, de mettre un pas dans le grand monde de la recherche et pour tous les conseils qu il m a prodigué tout au long de la réalisation de mon travail. J exprime ma profonde gratitude à Madame T. BOUABANE-TEBIBEL pour avoir accepté de m'encadrer, pour sa disponibilité, pour la qualité de ses conseils et pour les nombreuses discussions que nous avons eues. Je tiens à remercier Monsieur D. E. ZEGGOUR, Monsieur H. HAFFAF et Monsieur H. HADDADOU qui m ont fait l honneur d accepter de juger mon travail. Je tiens à exprimer toute ma reconnaissance à Madame L. HAMDAD pour m avoir dirigée durant l analyse de mon échantillon de données. Je la remercie pour son aide précieuse, pour son immense patience et pour sa disponibilité. L ensemble des tests d expérimentation présentés dans ce mémoire a été effectué au Laboratoire de la Communication dans les Systèmes Informatiques (L.C.S.I) de l ESI. Je tiens à remercier toutes les personnes, qui ont participé à mes tests, pour l'effort et le temps qu elles m ont accordé. Je tiens également à remercier l ensemble des membres du L.C.S.I qui m ont permis de mener ces tests dans une ambiance très amicale. De nombreuses personnes ont contribué à la réalisation de ce travail. Que toutes celles que je n ai pas citées, soient assurées de ma gratitude. iii

4 RÉSUMÉ L acceptabilité et le succès des services vidéo sur Internet sont conditionnés par le degré de satisfaction des utilisateurs finaux mesuré en termes de la Qualité d Expérience (Quality of Experience, QoE). Cependant, l architecture d Internet n a pas été conçue pour supporter ces types de services, et de ce fait, la QoE n est pas aussi bonne que l on souhaiterait. Il est donc nécessaire de concevoir des architectures et des protocoles réseaux capables de garantir la QoE des services vidéo. L objectif principal de notre travail consiste à proposer un protocole de routage de requêtes (méta-routage) basé sur la QoE dans les réseaux de distribution de contenu de type vidéo. Nous avons dans un premier temps défini un modèle propre aux services vidéo définissant les principales métriques de la QoE. Ce modèle se base sur le concept hiérarchique des indicateurs de qualité et de performance dans lequel la QoE est rapportée à trois indicateurs clé de qualité (disponibilité, réactivité et qualité de vidéo) corrélés à deux indicateurs clé de performance du réseau (la latence et le taux de perte). L expérimentation de ce modèle de métriques a permis ensuite de déduire plusieurs modèles de corrélation de forme exponentielle entre la QoE et plusieurs paramètres de la qualité de service. Afin de valider notre approche, nous nous sommes intéressés, dans un deuxième temps, au protocole de méta-routage correspondant. Ce dernier permet de rediriger en temps réel, et de manière adaptative, les requêtes de l utilisateur au niveau de la phase résolution des noms (Domain Name System, DNS) vers le meilleur serveur vidéo offrant la meilleure QoE. Pour mettre en œuvre ce protocole, il a été nécessaire d introduire une extension sur le simulateur réseau NS-2 capable de simuler à la fois la redirection DNS et la transmission vidéo dans un réseau de distribution de vidéo. Les résultats préliminaires nous permettent d'entrevoir la suite de nos travaux avec beaucoup de confiance. Mots clés :Qualité d Expérience, Qualité de Service, Services Vidéos, Réseaux de Distribution de Contenu, Modèle de Métriques, Indicateurs Clé de Qualité, Indicateurs Clé de Performance, Modèle de Corrélation Exponentiel, Routage des requêtes (Méta- Routage), Simulateur réseau NS-2. iv

5 ABSTRACT The acceptability and success of video services over Internet are conditioned by the end-user satisfaction degree measured in terms of Quality of Experience (QoE). However, the Internet architecture was not designed to support these types of services, and thus the QoE is not as good as one would wish. It is therefore necessary to design network architectures and protocols to guarantee the QoE of these video services. The main goal of our work consists in proposing a request routing (meta-routing) protocol based on QoE in video content delivery networks. We first defined a model specific to video service defining main metrics of QoE. This model is based on the hierarchical concept of KQI/KPI (Key Quality Indicators/Key Performance Indicators) where the QoE is related to three KQIs (availability, reactivity and quality of video) correlated to two network-level KPIs (latency and loss rate). The experimentation of this metric model was enabled to deduce several exponential correlation models between QoE and several parameters of quality of service. In order to validate our approach, we are then interested in the corresponding meta-routing protocol. The latter enables to redirect, in real time adaptive way, the user requests at the level of Domain Name System (DNS) to the best video server given the best QoE. To implement this protocol, it was necessary to introduce an extension in network simulator NS-2 that can simulate DNS redirection and video transmission in a video delivery network. Preliminary results enable us to catch a glimpse of our future work with much confidence. Keyword: Quality of Experience, Quality of Service, Video Services, Content Delivery Networks, Metrics Model, Key Quality Indicators, Key Performance Indicators, Exponential Correlation Model, Request-Routing (Meta-Routing), network simulator NS-2. v

6 TABLE DES MATIERES INTRODUCTION GENERALE Contexte et Motivation Problématique Objectifs Contributions Structure du Mémoire CHAPITRE I: LA VIDEO SUR INTERNET INTRODUCTION I. APERÇU SUR LES SERVICES VIDEO SUR INTERNET I.1. DU SYSTEME AU SERVICE VIDEO I.2. DU TELECHARGEMENT AU STREAMING VIDEO I.2.1. Exemples de Services de Streaming I.3. LES ARCHITECTURES DES SERVICES STREAMING VIDEO I.3.1. Les Architectures des Réseaux de Distribution de Contenu I.3.2. Les Architectures des Réseaux Pair-à-Pair I.3.3. Les Architectures Hybrides I.4. LES PROTOCOLES SPECIFIQUES AU STREAMING VIDEO I.4.1. Le Protocole IP I.4.2. Le protocole UDP I.4.3. Le protocole RTP I.4.4. Le protocole RTCP I.4.5. Le protocole RTSP II. LA QUALITE DE VIDEO SUR INTERNET II.1. LES FACTEURS IMPACTANT LA QUALITE DE VIDEO II.2. LES METHODES D EVALUATION II.2.1. Les Méthodes Subjectives vi

7 II.2.2. Les Méthodes Objectives II Les Méthodes sans Référence II.3. LES MECANISMES DE GESTION II.3.1. Au Niveau de l Application II Gestion de la Bande Passante II Gestion de Pertes II Gestion du Délai et de la Gigue II.3.2. Au Niveau du Réseau CONCLUSION CHAPITRE II: LA QUALITE D'EXPERIENCE PROPRE AUX SERVICES VIDEO INTRODUCTION I. DEFINITION DE LA QUALITE D EXPERIENCE II. LES METRIQUES DE LA QUALITE D EXPERIENCE II.1. LA STRUCTURE DE LA QOE II.2. LA MULTI-DIMENSIONNALITE DE LA QOE II.2.1. Le Modèle du DSL Forum II.2.2. Le Modèle de Marez & Moor II.3. LES INDICATEURS CLES DE QUALITE ET DE PERFORMANCE II.4. LES INDEX DE LA QOE III. LA RELATION ENTRE LA QOE ET LA QOS III.1. LE MODELE MATHEMATIQUE III.2. LE MODELE PENTAGRAMME III.3. LE MODELE DE KIM ET AL III.4. LE MODELE IQX III.5. LE MODELE POLYNOMIAL IV. LES MECANISMES DE CONTROLE DE LA QOE IV.1. SYSTEME DE GESTION DE LA QOE POUR LES SERVICES IPTV vii

8 IV.2. MECANISME ADAPTATIF DE STREAMING VIDEO POUR LES RESEAUX DE DISTRIBUTION DE VIDEO IV.3. ROUTAGE ADAPTATIF SUR LA BASE DE LA QOE DANS LES RESEAUX DE DISTRIBUTION DE CONTENUS CONCLUSION CHAPITRE III: LE ROUTAGE DES REQUETES DANS LES RESEAUX DE DISTRIBUTION DU CONTENU INTRODUCTION I. GENERALITES SUR LES RESEAUX DE DISTRIBUTION DE CONTENUS I.1. L ARCHITECTURE GENERALE D UN CDN I.2. LES PRINCIPAUX PROBLEMES LIES A LA CONCEPTION D UN CDN I.2.1. Le Problème du Placement des Serveurs Réplica I.2.2. Les Problèmes du Système de Distribution du Contenu I.2.3. Les Problèmes du Système de Routage des Requêtes I.3. LES RESEAUX DE DISTRIBUTION DU CONTENU EN STREAMING II. LA SELECTION DU MEILLEUR SERVEUR REPLICA II.1. LES TECHNIQUES D ACQUISITION DES CRITERES DE SELECTION II.1.1. Enquête Active du Réseau II.1.2. Surveillance Passive du Réseau II.1.3. Rétroaction des Serveurs Réplica II.2. CLASSIFICATION DES ALGORITHMES DE SELECTION III. LES MECANISMES DE REDIRECTION DES REQUETES III.1. LES MECANISMES OPERANT AU NIVEAU DE LA COUCHE APPLICATION III.1.1. La Redirection HTTP III.1.2. La Réécriture URL III.1.3. La Redirection DNS III.1.4. La Technique de l Anycast III.2. LES MECANISMES OPERANT AU NIVEAU DE LA COUCHE TRANSPORT III.3. LES MECANISMES OPERANT AU NIVEAU DE LA COUCHE RESEAU viii

9 III.4. DISCUSSION IV. UN EXEMPLE D UN SYSTEME DE ROUTAGE DE REQUETE: AKAMAI IV.1. LA REDIRECTION DNS IV.2. L ALGORITHME DE SELECTION CONCLUSION CHAPITRE IV: UNE ANALYSE STATISTIQUE DU MODELE DE METRIQUES DE LA QoE INTRODUCTION I. PRESENTATION GENERALE DU MODELE DE METRIQUES PROPOSE I.1. LA DISPONIBILITE I.2. LA REACTIVITE I.3. LA QUALITE DE VIDEO I.4. SYNTHESE II. DESCRIPTION DU MODELE DE CORRELATION PROPOSE III. EXPERIMENTATION III.1. ETAPE 1 : COLLECTE DES DONNEES III.2. ETAPE 2 : IMPACT DES KPIS SUR LES KQIS III.2.1. Impact du Taux de Perte sur la Qualité de Vidéo III.2.2. Impact de la Latence sur la Qualité de la Vidéo III.2.3. Impact Collectif des KPIs sur la Qualité de la Vidéo III.2.4. Impact du Taux de Perte sur la Réactivité III.2.5. Impact de la Latence sur la Réactivité III.2.6. L Impact Collectif des KPIs sur la Réactivité III.3. ETAPE 3 : IMPACT DES KQIS SUR LA QUALITE D EXPERIENCE III.3.1. Impact de la Qualité de Vidéo sur la Qualité d Expérience III.3.2. Impact de la Réactivité sur la Qualité d Expérience III.3.3. Impact Collectif des KQIs sur la Qualité d Expérience III.3.4. Le Modèle de Corrélation proposé entre la QoE et la QoS CONCLUSION ix

10 CHAPITRE V: CONCEPTION D UN PROTOCOLE DE META- ROUTAGE BASE SUR LA QoE DANS LES CDNS INTRODUCTION I. PRESENTATION GENERALE DU PROTOCOLE PROPOSE I. 1. LA PHASE D INITIATION I. 2. LA PHASE DE SELECTION I. 3. LA PHASE DE CONNEXION I. 4. LA PHASE DE RETROACTION I. 5. LA PHASE D ADAPTATION II. UNE EXTENSION SUR NS-2 POUR LA VALIDATION DE LA REDIRECTION DNS DANS LES RESEAUX DE DISTRIBUTION DE VIDEO II.1. LE PROTOCOLE RTP-CDN II.1.1. Mesure de Performance du Réseau II.2. AGENT DNS-CDN II.3. NOUVEAUX PAQUETS CONCLUSION CONCLUSION GENERALE & PERSPECTIVES ANNEXES REFERENCES BIBLIOGRAPHIQUES x

11 LISTE DES FIGURES INTRODUCTION GENERALE Figure 1. Les objectifs de notre travail Figure 2. Les principales contributions Figure 3. La structure du mémoire CHAPITRE I: LA VIDEO SUR INTERNET Figure I.1. La relation entre un système, une application et un service vidéo Figure I.2. Comparaison entre le téléchargement et le streaming vidéo Figure I.3. La pile de protocoles pour le streaming vidéo sur Internet [WOZ, 02] Figure I.4. Un service de distribution de paquet vidéo sur Internet Figure I.5. La corrélation entre le modèle d opinion et la perception humaine Figure I.6. Les normes de compression vidéo [AHM, 08] Figure I.7. Techniques de contrôle de pertes [AHM, 08] CHAPITRE II: LA QUALITE D'EXPERIENCE PROPRE AUX SERVICES VIDEO Figure II.1. La structure de la QoE [ITU-TG, 08] Figure II.2. Les dimensions de la QoE [MAM, 07] Figure II.3. Le modèle hiérarchique de gestion de performances [TMF917, 04] Figure II.4. Le modèle hiérarchique de service vocal [LZS, 09] Figure II.5. La relation entre la QoE et QoS [FHT, 10] CHAPITRE III: LE ROUTAGE DES REQUETES DANS LES RESEAUX DE DISTRIBUTION DU CONTENU Figure III.1. Un modèle de réseau de distribution de contenu Figure III.2. L architecture générale d un CDN [GCT, 01] Figure III.3. Les mécanismes de redirection de requête Figure III.4. Les mécanismes d insertion du CDN Figure III.5. La redirection DNS dans Akamai xi

12 CHAPITRE IV: UNE ANALYSE STATISTIQUE DU MODELE DE METRIQUES DE LA QoE Figure IV.1. Notre modèle de métriques de la QoE à base de KQI\KPI Figure IV. 2. Une approche générale d expérimentation des modèles à base de KQI/KPI.. 90 Figure IV.3. Impact du taux de perte (IPLR) sur la qualité de vidéo (QoV) Figure IV.4. Les résultats de la régression linéaire entre la QoV et l IPLR Figure IV.5. Impact de la latence (IPTD) sur la qualité de vidéo (QoV) Figure IV.6. Les résultats de la régression multiple entre la QoV et les KPIs Figure IV.7. Impact collectif des KPIs sur la QoV Figure IV.8. Impact collectif des KPIs sur la QoV dans les deux classes Figure IV.9. Impact du taux de perte (IPLR) sur le temps de démarrage (R) Figure IV. 10. Impact de la latence (IPTD) sur le temps de démarrage (R) Figure IV. 11. Les résultats de la régression multiple entre le R et les KPIs Figure IV.12. Impact collectif des KPIs sur la réactivité (R) Figure IV.13. Impact de la QoV sur la QoE Figure IV.14. Impact de la réactivité (R) sur la qualité d expérience (QoE) Figure IV.15. Impact collectif des KQIs (R, QoV) sur la QoE dans la classe C Figure IV.16. Impact collectif des KQIs (R, QoV) sur la QoE dans la classe C Figure IV.17. Impact collectif des KPIs sur la QoE dans la classe C Figure IV.18. Impact collectif des KPIs sur la QoE dans la classe C Figure IV.19. Impact collectif des KPIs sur la QoE dans la classe C CHAPITRE V: CONCEPTION D UN PROTOCOLE DE META- ROUTAGE BASE SUR LA QoE DANS LES CDNS Figure V.1. Les phases de notre protocole de méta-routage Figure V.2. L architecture de notre ensemble d outils de simulation Figure V. 3. Les principales interactions des entités du CDN Figure V.4. Le fonctionnement du serveur DNS-CDN xii

13 LISTE DES TABLEAUX CHAPITRE I: LA VIDEO SUR INTERNET Tableau I.1. Mean Opinion Score (MOS) [ITU-R, 02] Tableau I.2. Les principales solutions au niveau de l application [AHM, 08] CHAPITRE II: LA QUALITE D'EXPERIENCE PROPRE AUX SERVICES VIDEO Tableau II.1. Les KQI\KPI pour les services vidéo [TMF917, 04] Tableau II.2. Les mesures les plus importantes des facteurs la QoE [GYH, 09] CHAPITRE IV: UNE ANALYSE STATISTIQUE DU MODELE DE METRIQUES DE LA QoE Tableau IV.1. Les valeurs, de latence (IPTD) et de taux de perte (IPLR), utilisées pour l expérimentation Tableau IV.2. Transformation des modèles non linéaires aux modèles linéaires Tableau IV.3. Le coefficient de détermination entre la QoV et le taux de perte Tableau IV.4. Le coefficient de détermination entre la QoV et la latence (IPTD) Tableau IV. 5. Les résultats de la RLM dans les deux classes Tableau IV.6. Le coefficient de détermination entre la réactivité et l IPLR Tableau IV.7. Le coefficient de détermination entre le R et la latence (IPTD) Tableau IV.8. Le coefficient de détermination entre la QoE et la QoV Tableau IV. 9. Le coefficient de détermination entre la QoE et le R Tableau IV.10. Le coefficient de détermination entre la QoE et le R dans chaque classe. 104 Tableau IV. 11. Les résultats de la régression multiple entre la QoE et les KQIs Tableau IV. 12. Les résultats de la régression multiple entre la QoE et les KPIs CHAPITRE V: CONCEPTION D UN PROTOCOLE DE META- ROUTAGE BASE SUR LA QoE DANS LES CDNS Tableau V. 1. Correspondance entre les paquets et les champs xiii

14 LISTE DES ABREVIATIONS A : Availability BE : Best Effort CDN : Content Distribution Network DNS : Domain Name System DNS-REQ : DNS REQuest DNS-RES : DNS RESponse DSL: Digital Subscriber Line FTP: File Transfer Protocol HTTP: HyperText Transfer Protocol ICMP: Internet Control Message Protocol IQX: Interdependency between QoE and QoS is exponential IP: Internet Protocol IPLR: IP Packet Loss Ratio IPTD: IP Packet Transfer Delay IPTV: IP TeleVision ITU: International Telecommunication Union ITU-R: ITU Radiocommunication Sector ITU-T: ITU Telecommunication Standardization Sector KPI: Key Performance Indicator KQI: Key Quality Indicator MOS: Mean Opinion Score NetEm: Network Emulator NS-2: Network Simulator 2 NTP: Network Time Protocol OS: Opinion Score PING: Packet INternet Groper PSNR: Peak Signal to Noise Ratio xiv

15 QoE : QoE-REQ : QoE-RES : QoS : QoV : P2P : R : REP-REQ: RR : RTCP: RTSP : RTP : RTP_gs : SC : SCDN : SDC : SRR : TCP : TM : UDP : URL : VCR : VDN : VoD : VoIP : Quality of Experience QoE REQuest QoE RESponse Quality of Service Quality of Video Peer to Peer Reactivity REPlacing REQuest Receiver Report Real-time Transport Control Protocol Real Time Streaming Protocol Real time Transport Protocol RTP group synchronization Système de Comptabilité Streaming Content Delivery Content Système de Distribution du Contenu Système de Routage des Requêtes Transmission Control Protocol Telecommunication Management User Datagram Protocol Uniform Ressource Locator Video Cassette Recording Video Distribution Network Video on Demand Voice over IP xv

16 Introduction Générale INTRODUCTION GENERALE Contexte et Motivation Au cours de ces dernières années, l explosion d Internet a donné naissance à une nouvelle génération de services vidéo comme la télévision sur IP, la vidéoconférence ou encore la vidéo à la demande. Ces services sont devenus courants et constituent aujourd hui un domaine de recherche très actif et un nouveau secteur du marché des télécommunications. A l heure actuelle, plusieurs offres commerciales existent pour la distribution de services vidéo sur des liens haut débit, comme les chaînes numériques de TV sur des liens xdsl, ou sur des réseaux mobiles, comme les services de vidéoconférence sur des téléphones mobiles de troisième génération. L acceptabilité et le succès de ces nouveaux services sont conditionnés par le degré de satisfaction de leurs utilisateurs finaux qui est déterminé par la Qualité d Expérience (Quality of Experience, QoE). En effet, selon [YAT, 04], il existe une corrélation positive entre la volonté de payer et la QoE du flux vidéo offerte à l'utilisateur. L'étude montre clairement que les utilisateurs ont toujours tendance à payer moins cher si on leur offre un flux vidéo avec une QoE faible. Lorsque les utilisateurs estiment surpayer leur service par rapport à la qualité qu'ils attendent, ils réagissent de différentes manières qui aboutissent toutes à une éventuelle diminution de revenus de l opérateur. Les fournisseurs de ces services vidéo sont ainsi appelés à fournir à l utilisateur final une bonne QoE s'ils veulent rester en course. Cependant, l architecture d Internet n a pas été conçue pour supporter ce type de services, et de ce fait, la QoE n est pas aussi bonne que l on souhaiterait. Il est donc nécessaire de développer des architectures et des protocoles réseaux capables de garantir la QoE de ces nouveaux services vidéo. C est dans ce contexte que s inscrit notre problématique. Problématique Pour savoir quels ajustements devraient être apportés et quand les appliquer, il est nécessaire d évaluer la QoE. Or, l évaluation de la QoE requiert la définition d un ensemble de métriques pour mesurer le degré de satisfaction de l utilisateur. En général, l utilisateur perçoit la performance du service en termes plutôt subjectifs que techniques. Par exemple, un utilisateur du service streaming vidéo veut percevoir la vidéo avec une certaine qualité sans pour autant être intéressés par les valeurs des paramètres techniques de la qualité de service (Quality of Service, QoS) du réseau dont: la bande passante, le délai de bout en bout, la gigue ou le taux de perte de données. 16

17 Introduction Générale Par ailleurs, les fournisseurs de services s intéressent, en particulier, à la performance des services en termes de ces paramètres de la QoS. C est pourquoi, il est aussi nécessaire de connaître l impact de la performance du réseau sur la perception de l utilisateur. Malheureusement, il est très difficile d évaluer cet impact en temps réel sur un réseau opérationnel alors que le contrôle des paramètres de la QoS est plus facile et plus habituel [SFC, 09]. La solution idéale pour les fournisseurs de service est d identifier la relation entre les paramètres de QoS et l influence individuelle et collective de ces derniers sur la QoE. La quantification de cette relation revient à définir un modèle de corrélation entre la QoE et la QoS. Dans la littérature, il existe plusieurs types de modèles: linéaire, exponentiel, logarithmique, puissance ou autres. Enfin, à l origine, les services vidéo sur Internet sont exécutés sur l architecture traditionnelle client/serveur où l utilisateur contacte le serveur vidéo et demande le flux vidéo approprié. Cependant, cette architecture centralisée présente plusieurs problèmes notamment le problème de passage à l'échelle face à des milliers d'utilisateurs. Pour remédier à ce problème, plusieurs autres architectures ont été proposées. Parmi celles-ci, nous trouvons l architecture des réseaux de distribution de contenu (Content Distribution Network, CDN) où le contenu vidéo est répliqué du serveur d'origine vers plusieurs autres serveurs, appelés serveurs réplica, situés à proximité de l utilisateur final. Les requêtes de l utilisateur sont ensuite routées vers le meilleur service réplica ayant le contenu désiré. Ce meilleur serveur réplica peut être le serveur le plus proche, le moins chargé et/ou possédant une bonne connexion réseau en termes de paramètres de QoS. Le but principal du routage de requêtes (appelé aussi méta-routage) est de garantir la satisfaction de l utilisateur final, et donc, un excellent critère de sélection serait celui qui prend en considération la perception de l utilisateur (QoE). Objectifs L objectif principal de notre travail consiste à proposer un protocole de méta-routage basé sur la QoE dans les réseaux de distribution de contenus vidéo. Pour atteindre cet objectif, il est nécessaire de définir les principales métriques de la QoE propre aux services vidéo, et ensuite, choisir un modèle générique de corrélation entre la QoE et la QoS. La figure 1 illustre les objectifs que nous nous sommes fixés dans le cadre de ce mémoire. 17

18 Introduction Générale Figure 1. Les objectifs de notre travail. Contributions Partant de là, nos contributions se situent à deux niveaux (Figure 2) : - Au premier niveau, nous avons défini un simple modèle propre aux services vidéo définissant les métriques de la QoE. Ce modèle de métriques se base sur le concept hiérarchique des indicateurs clé de qualité et de performance (Key Quality Indicators/Key Performance Indicators, KQI/KPI) où la QoE est rapportée à trois KQIs, à savoir la disponibilité, la réactivité et la qualité de vidéo, corrélés à deux KPIs du réseau qui sont la latence et le taux de perte des paquets. L expérimentation de ce modèle de métriques a permis ensuite de déduire plusieurs modèles de corrélation de forme exponentielle entre la QoE et plusieurs paramètres de la QoS. - Au deuxième niveau, une première version du protocole de méta-routage a été écrite. Elle permet de rediriger en temps réel, et de manière adaptative, les requêtes de l utilisateur au niveau de la phase de résolution de noms (Domain Name System, DNS) vers le meilleur serveur vidéo offrant la meilleure QoE. Afin de mettre en œuvre cette version du protocole, il a été ensuite nécessaire d introduire une extension sur le simulateur réseau NS-2. Cette extension permet de simuler à la fois la redirection DNS et la transmission de vidéo dans un réseau de distribution de vidéo (Video Distribution Network, VDN). 18

19 Introduction Générale Figure 2. Les principales contributions. Structure du Mémoire Ce présent mémoire est structuré en deux parties présentant respectivement l état de l art et nos contributions : - L état de l art comporte trois chapitres. Le premier chapitre est consacré à la vidéo sur Internet où la notion de la qualité de vidéo est abordée avec un intérêt plus particulier pour les méthodes d évaluation et les mécanismes de gestion. Le deuxième chapitre a pour objectif de donner une vue générale sur les principaux modèles de métriques de la QoE ainsi que les modèles de corrélation QoE-QoS existants. Le troisième chapitre se veut être une synthèse des concepts nécessaires à la bonne compréhension du fonctionnement des réseaux CDN, notamment le fonctionnement de leur Système de Routage des Requêtes (SRR). - La partie contributions comprend deux chapitres. Le quatrième chapitre est consacré nos premières contributions qui consistent en un modèle de métriques de la QoE à base de KQI\KPI ainsi qu un modèle de corrélation exponentiel entre la QoE et plusieurs paramètres de QoS. Dans le cinquième chapitre, nous décrivons notre protocole de méta-routage basé sur la QoE dans les CDNs. En conclusion générale, nous synthétisons les principales parties de notre travail, en faisant ressortir les apports de nos contributions ainsi que les perspectives prévues pour la poursuite de la recherche dans ce domaine. La figure ci-dessous schématise la structure du mémoire. 19

20 Introduction Générale Figure 3. La structure du mémoire. 20

21 PARTIE 1 ETAT DE L ART

22 Chapitre I La Vidéo Sur Internet INTRODUCTION Internet a été conçu au départ pour offrir un service simple (connecter tous les ordinateurs du monde) de la façon la plus économique possible. Il n a pas été conçu pour un type d applications particulier. Cependant, l augmentation rapide des capacités des ordinateurs a fait que ces derniers sont devenus capables au début des années quatrevingt-dix de traiter la vidéo. Il était donc naturel de penser à transmettre ce nouveau type de données sur Internet. Les avantages potentiels sont en effet très nombreux, puisque la transmission de la vidéo permettrait d offrir des services de vidéophonie, de vidéoconférence, de diffusion des chaînes télévisées, voire de jeux distribués. En outre, les avancées technologiques dans le domaine de la compression vidéo (MPEG-4, H.264 AVC, SVC) associées à la numérisation des infrastructures de distribution de contenu (DVB-T, DVB-S, ) et l arrivée rapide du haut débit pour les particuliers (ADSL, WiMax, ) favorisent la convergence de ces services vidéo vers Internet.

23 CHAPITRE I La vidéo sur Internet Ce chapitre est consacré à la vidéo sur Internet. Dans un premier temps, nous donnons un aperçu sur les services vidéo sur Internet. Ensuite, nous explicitons la notion de la qualité de la vidéo (Quality of Video, QoV) en présentant ses méthodes d évaluation ainsi que ses mécanismes de gestion. 23

24 CHAPITRE I La vidéo sur Internet I. APERÇU SUR LES SERVICES VIDEO SUR INTERNET Dans cette première section, nous commençons par expliquer ce que nous entendons dire par un système, une application et un service vidéo. Ensuite, nous présentons les deux principales techniques de livraison de la vidéo sur Internet en se basant sur la technique de streaming. Enfin, nous décrivons les principales architectures ainsi que les protocoles de streaming vidéo. I.1. Du Système au Service Vidéo Dans [SUN, 06], J. San a clarifié la relation entre un système, une application et un service vidéo. Comme illustré dans la figure I.1, un système vidéo typique comprend un codec pour les opérations de codage et de décodage, un réseau de communication pour la transmission et un terminal de l utilisateur final pour l affichage. En ajoutant le contenu vidéo à ce système, une application vidéo est ainsi formée. Un service vidéo est donc un événement de l interaction entre les utilisateurs finaux et l application vidéo sous jacente. Ainsi, un service vidéo comprend, outre le système vidéo, le contenu et l utilisateur final. Figure I.1. La relation entre un système, une application et un service vidéo. I.2. Du Téléchargement au Streaming Vidéo Pour distribuer la vidéo sur Internet, deux solutions sont possibles : le téléchargement et le streaming. La première solution permet la livraison de contenus vidéo à travers un processus de téléchargement qui est réalisé en utilisant des protocoles communs tels que TCP/FTP ou TCP/HTTP. Cette technique du téléchargement présente plusieurs inconvénients relatifs au temps de téléchargement, à l occupation de l espace disque, à la qualité et au type du contenu [AHM, 03] [ATW, 02]. En effet, les vidéos correspondent généralement à de très gros fichiers qui nécessitent généralement de longues périodes de téléchargement et un grand espace de stockage. En outre, la totalité de la vidéo doit être 24

25 CHAPITRE I La vidéo sur Internet téléchargée avant de la visionner demandant ainsi la patience du spectateur (l utilisateur final) et réduisant également la souplesse. En effet, ni la qualité ni le contenu ne peuvent être vérifiés avant la fin du téléchargement. La technique de streaming vidéo, comme une solution alternative, tente de surmonter les problèmes liés au téléchargement vidéo, et fournit également des fonctionnalités supplémentaires comme la transmission directe et l interactivité. En fait, cette technique permet simultanément la livraison et la lecture de la vidéo. Comme montré dans la figure I.2, la lecture commence avant que la totalité de la vidéo ne soit livrée. En général, il y a un court délai entre le début de la livraison et le début de la lecture au niveau de l utilisateur final. Ce délai, appelé le délai de pré-enregistrement ou le temps de démarrage, détermine aussi la taille du tampon pour stocker les paquets reçus. Le streaming vidéo fournit un certain nombre d'avantages, notamment un faible retard avant le commencement du visionnage ainsi qu un faible espace de stockage. En effet, une petite portion de la vidéo est stockée seulement au niveau du client à n'importe quel moment [ATW, 02]. Figure I.2. Comparaison entre le téléchargement et le streaming vidéo. Par ailleurs, le contenu vidéo peut être capturé et encodé en temps réel pour être diffusé en direct (l encodage en temps réel), ou bien pré-encodé et stocké pour une visualisation ultérieure (le pré-encodage) [AHM, 03]. Le téléchargement vidéo utilise évidemment le pré-encodage pour diminuer la taille du fichier vidéo ainsi que le temps de téléchargement. Cependant, le streaming vidéo dépend du type de l encodage où nous distinguons deux catégories principales: le streaming en direct (Live Streaming) utilisant l encodage temps réel et le Streaming progressif (Progressive Streaming) basé sur le préencodage. En parallèle, les services de streaming peuvent être interactifs ou non-interactifs [ATW, 02]. Les services vidéo interactifs, comme la vidéo à la demande, la 25

26 CHAPITRE I La vidéo sur Internet vidéoconférence, la vidéophonie et les jeux vidéo interactifs ont des contraintes très fortes en termes de latence (délai de bout en bout) ; celle-ci est de l'ordre de quelques millisecondes ou quelques secondes. Par contre, les services non-interactifs ont des contraintes de latence beaucoup plus souple (plusieurs secondes voire minutes). Des exemples de services non-interactifs comprennent la diffusion des manifestations populaires, la multidiffusion d'une conférence ou la télévision sur IP. I.2.1. Exemples de Services de Streaming De nombreux services sont basés sur des techniques de streaming vidéo comme la télévision sur IP, la vidéoconférence et la vidéo à la demande. Dans ce qui suit, nous décrivons brièvement ces services: - La Télévision sur IP (Internet Protocol TeleVision, IPTV), est un service de streaming en direct et non interactif qui permet aux utilisateurs de regarder plusieurs chaînes de télévision par Internet. Dans ce service, tous les utilisateurs regardent la même chaîne en même temps, i.e. qu ils auraient leurs heures d'écoute synchronisées. La seule opération que les utilisateurs peuvent effectuer est de commuter entre les différentes chaînes [DON, 08]. - La vidéoconférence ou la visioconférence est un service de streaming en direct et interactif qui permet de faire des réunions à distance en combinant deux techniques : la vidéophonie et la conférence multipoint. La vidéophonie ou la visiophonie permet à l utilisateur de voir et de dialoguer avec son interlocuteur tandis que la conférence multipoint permet d effectuer une réunion avec plus de deux personnes [AHM, 03]. - La vidéo à la demande (Video on Demand, VoD) est un service de streaming progressif et interactif qui permet aux utilisateurs de commencer à regarder la vidéo de leur choix à n importe quel moment, après avoir attendu un petit retard de démarrage, et d'effectuer des opérations de contrôle, exactement comme avec un magnétoscope (Video Cassette Recording, VCR), tels que lire, stop, pause, avancement rapide et revenir en arrière, tout en téléchargeant la vidéo en parallèle [DON, 08]. Dans notre travail, nous nous intéressons particulièrement à ce type de service vidéo. Si le téléchargement de fichiers (qu'ils contiennent ou non des données vidéo) est une opération courante en informatique, le streaming a nécessité en revanche le développement de technologies particulières pour la distribution et la transmission de la vidéo sur Internet. Ces technologies seront développées dans les deux sections suivantes. 26

27 CHAPITRE I La vidéo sur Internet I.3. Les Architectures des Services Streaming Vidéo A l origine, les services vidéo sur Internet sont exécutés sur l architecture traditionnelle client/serveur où le client contacte le serveur streaming et demande le flux vidéo approprié. Cependant, cette architecture centralisée présente plusieurs problèmes notamment: le problème de passage à l'échelle face à des milliers d'utilisateurs. Pour remédier à ce problème, plusieurs autres architectures ont été proposées. Parmi celles-ci, nous trouvons les architectures des réseaux de distribution de contenus (Content Distribution Network, CDN), les architectures des réseaux Pair à Pair (Peer-to-Peer, P2P) et les architectures hybrides (P2P/CDN). I.3.1. Les Architectures des Réseaux de Distribution de Contenu Dans les CDN, tels que Akamai 1, Limelight Networks 2, MirrorImage 3 et EdgeStream 4, le contenu vidéo est répliqué du serveur d'origine vers plusieurs autres serveurs (appelés serveurs réplica) situés à proximité des utilisateurs finaux. Ainsi, les demandes des utilisateurs sont dirigées vers le meilleur serveur réplica ayant le contenu désiré. Le meilleur serveur est défini par le serveur le plus proche, le moins chargé et/ou possédant une bonne connexion réseau avec le client en termes de latence ou de taux de perte [PEN, 08]. Une telle architecture à base de réplication de contenus remplace la communication client/serveur par deux flux de communication: l'un entre le client et le serveur réplica, et l autre entre le serveur réplica et le serveur d'origine [PAV, 06]. Cette distinction en deux flux de communication permet (i) de réduire la consommation de bande passante sur les liaisons réseau, la latence pour les clients et la charge sur les serveurs streaming, et (ii) d augmenter la disponibilité des contenus vidéo [WOZ, 02]. Malgré sa performance, cette architecture souffre néanmoins d un coût prohibitif et d une gestion compliquée inhérentes aux opérations consistant à savoir placer les serveurs réplica, à distribuer des copies du contenu vidéo à des serveurs réplicas et à router les requêtes vers le meilleur

28 CHAPITRE I La vidéo sur Internet serveur réplica. Dans notre travail, le problème de routage des requêtes dans le CDN est abordé dans un objectif de garantir une bonne QoE des services vidéo. I.3.2. Les Architectures des Réseaux Pair-à-Pair Dans les réseaux P2P, tels que CoolStreaming [XLK, 07], PPLive [VGL, 06], BitTorrent 5 et DirectStream [GSK, 08], les utilisateurs s organisent en groupes, en communautés ou comme des utilisateurs simples. Le concept de cette organisation repose sur le fait que chaque participant au réseau P2P peut jouer au même moment le rôle de client et celui de serveur. Les utilisateurs ne sont plus passifs, consommant simplement des flux vidéo en provenance de quelques serveurs streaming répartis sur Internet, mais ils sont actifs dans la mesure où ils participent à la création, à la génération et à la diffusion de contenus vidéo. Les réseaux P2P se présentent comme une réelle alternative au modèle client/serveur, au regard de leur capacité à assurer la montée en charge, et leur déploiement rapide à faible coût. Cependant, le streaming vidéo sur les réseaux P2P présente des problèmes spécifiques, comparé au streaming en mode client/serveur, liés à l organisation des nœuds dans le réseau, à la distribution du contenu entre les nœuds, à la sélection des nœuds, au comportement non déterministe des nœuds et à l hétérogénéité des nœuds [AHM, 08]. I.3.3. Les Architectures Hybrides Afin de regrouper les avantages des architectures CDN et P2P tout en éliminant leurs limitations, certains chercheurs [XKR, 06] [GCZ, 06] ont proposé des architectures hybrides qui combinent les caractéristiques de ces deux façons de faire. Par exemple, PROP (collaborating and coordinating PROxy and its P2P clients) [GCZ, 06] est un système de streaming hybride proxy/p2p pour la VoD où le proxy sert comme site de cache assurant la disponibilité des segments vidéo qui ne peuvent être servis par aucun pair. Bien qu'une telle architecture hybride semble être très prometteuse, certains aspects doivent encore être pris en compte, y compris l'hétérogénéité des utilisateurs et la dynamique des interactions entre les serveurs et les clients [DON, 08]

29 CHAPITRE I La vidéo sur Internet I.4. Les Protocoles Spécifiques au Streaming Vidéo Des protocoles ont été conçus et standardisés pour la communication entre les clients et les serveurs streaming. Selon leurs fonctionnalités, les protocoles de streaming vidéo sur Internet peuvent être classés en trois catégories [WOZ, 02]: - Le protocole de couche réseau qui fournit un support basique de services réseau tels que l'adressage réseau. Le protocole IP (Internet Protocol) est le protocole de couche réseau pour le streaming vidéo sur Internet. - Les protocoles de couche transport qui fournissent les fonctions de transport réseau de bout en bout pour les applications de streaming. Ces protocoles comprennent UDP (User Datagram Protocol) [POS, 80], RTP (Real-time Transport Protocol) [SCF, 03], et RTCP (Real-time Transport Control Protocol) [SCF, 03]. - Le protocole de couche session qui définit les messages et les procédures de contrôle de la livraison des données vidéo durant une session établie. Le protocole RTSP (Real-Time Streaming Protocol) [SRL, 98] est un protocole de contrôle de session. La figure I.3 illustre cette pile de protocoles. En résumé, RTSP initie et dirige la livraison du flux vidéo depuis les serveurs streaming. RTP délivre ces flux vidéo et RTCP contrôle cette livraison. Le multiplexage des paquets RTP/RTCP/RTSP est réalisé par le protocole sous-jacent UDP qui utilise IP pour la transmission sur Internet. Tous ces protocoles (IP, UDP, RTP, RTCP, RTSP) seront décrits succinctement dans le reste de cette section. Figure I.3. La pile de protocoles pour le streaming vidéo sur Internet [WOZ, 02]. 29

30 CHAPITRE I La vidéo sur Internet I.4.1. Le Protocole IP Le protocole IP (Internet Protocol) assure la transmission des datagrammes IP du serveur streaming vers un ou plusieurs utilisateurs finaux. Entre autre, il supporte les trois modes de transmission utilisés pour les services streaming : - La transmission unicast (point à point) qui correspond au concept de la vidéo à la demande (VoD) où chaque requête d un utilisateur correspond à un flux vidéo spécifique délivré par le serveur. Elle permet à l utilisateur de visualiser le contenu de son choix à n importe quel moment et d utiliser toutes formes d interactivité (retour arrière, pause ) - La transmission multicast (point à multipoint) qui convient pour la diffusion en direct et à la vidéoconférence. Dans ce mode de transmission, le serveur ne génère qu un seul flux, qui est ensuite dupliqué si nécessaire au niveau de chacun des nœuds du réseau jusqu aux utilisateurs finaux. Cela permet d optimiser la bande passante du réseau même si des milliers d'utilisateurs sont connectés. Les utilisateurs finaux n ont cependant pas le choix de l heure à laquelle ils visionnent la séquence vidéo puisque le flux est unique et sera de toute façon émis à l'horaire prévu. Cette méthode nécessite que tous les routeurs permettent le multicast, ce qui n'est pas le cas sur Internet [GAS, 06]. - La transmission anycast [PMM, 93] où le flux vidéo généré par le serveur ne sera remis qu'à un seul membre du groupe, à la différence de la transmission multicast où le flux est remis à tous les membres du groupe. Ce paradigme de transmission a été conçu spécialement pour supporter la sélection d un serveur parmi un groupe de serveurs dans lesquels le contenu vidéo est répliqué [BCN, 03]. I.4.2. Le protocole UDP UDP (User Datagram Protocol) [POS, 80] est un protocole simple permettant de transmettre les données vidéo très rapidement (en temps réel). Pour ce faire, il fonctionne en mode non-connecté, sans contrôle d erreurs, sans remise en ordre des paquets à l'arrivée, sans réémission des données perdues et sans procédure d acquittement. Néanmoins, les traitements des erreurs et le ré-ordonnancement peuvent être effectués par d autres protocoles de haut niveau comme RTP, H.264/MPEG- 4 AVC,. I.4.3. Le protocole RTP Le protocole RTP (Real-time Transport Protocol) [SCF, 03] est un protocole de transfert des données (vidéo) de bout en bout. Il permet principalement: 30

31 CHAPITRE I La vidéo sur Internet - d inclure des numéros de séquence à l'information transportée afin de détecter l occurrence des paquets perdus et hors séquence. - d'ajouter des références temporelles (timestamp) qui indiquent l instant exact d émission du paquet à la source permettant ainsi à l arrivée d ordonner les paquets, et de rétablir la régularité temporelle (RTP permet ainsi d assurer une gigue inférieur à 40 ms). - d'identifier le type de contenus (audio, vidéo, etc.) et la nature du codage d information transportée, RTP ne garantit cependant pas une livraison fiable et rapide des données. Pour cela, il est toujours accompagné par le protocole de contrôle RTCP qui gère, entre autres, la qualité de transmission des données. I.4.4. Le protocole RTCP Le protocole RTCP (Real-time Transport Control Protocol) [SCF, 03] est un protocole de contrôle des flux RTP, permettant d envoyer périodiquement des paquets RTCP contenants des informations sur les participants et sur la qualité de transmission des données. Les informations sur la qualité de transmission comprennent essentiellement le taux de perte, la gigue et le délai de bout en bout des paquets RTP. De telles informations de contrôle permettent à l émetteur d ajuster son débit d émission, aux récepteurs de localiser la congestion et aux gestionnaires du réseau d évaluer les performances de celuici. I.4.5. Le protocole RTSP Le protocole RTSP (Real-Time Streaming Protocol) [SRL, 98] est un protocole de contrôle de session pour le streaming média (vidéo/audio) sur Internet. Selon ses développeurs, RTSP fonctionne comme «une commande à distance» du réseau pour les serveurs streaming. A l instar d une télécommande de magnétoscope (VCR), il permet aux utilisateurs de demander spécifiquement des données d un ou de plusieurs serveurs, du type de transfert et d une destination de transmission des données. En outre, il autorise également les utilisateurs de demander des informations sur les données dans un format spécifique, de lancer, d arrêter, de mettre en pause la transmission de données, et d obtenir l accès direct à différents paquets de données. II. LA QUALITE DE VIDEO SUR INTERNET La vidéo sur Internet, comme son nom l indique, utilise Internet comme moyen de diffusion. Or, l architecture du réseau Internet n a pas été conçue pour supporter ces 31

32 CHAPITRE I La vidéo sur Internet types d applications vidéo qui, à la différence des applications traditionnelles de transfert de données, exigent de fortes contraintes en termes de qualité de service (Quality of Service, QoS) : bande passante, délai, gigue et taux de perte des paquets. De ce fait, la qualité de vidéo (Quality of Video, QoV) perçue au niveau de l utilisateur final n est pas aussi bonne que l on souhaiterait. Il a été donc nécessaire de pouvoir évaluer cette QoV pour savoir quels ajustements devraient être apportés. Dans ce contexte, nous passons en revue les méthodes d évaluation et les mécanismes d amélioration de la QoV, après avoir présenté les principaux facteurs impactant celle-ci. II.1. Les Facteurs Impactant la Qualité de Vidéo Dans un service de distribution de paquets vidéo sur Internet, l acquisition et l encodage du contenu original des flux vidéo sont faits par le fournisseur du contenu. Les paquets vidéo sont ensuite distribués et transmis aux utilisateurs finaux par les fournisseurs de service et de réseau. Les équipements terminaux décodent et réparent le flux vidéo avant que le contenu ne soit affiché à l'utilisateur final (Figure I.4). Figure I.4. Un service de distribution de paquet vidéo sur Internet. Ainsi, la QoV dépend de la façon avec laquelle un tel service de distribution est orchestré. En effet, plusieurs facteurs peuvent influencer et/ou altérer la qualité visuelle du contenu original lors, sans toutefois s y limiter, de l acquisition, de l encodage, de la transmission, du décodage et de l affichage. Parmi ceux-ci, nous citons [CHE, 10] [RFW, 06]: - Les artefacts (dégradations) inhérents aux systèmes de capture (les bruits d acquisition et les distorsions optiques) et aux conditions d acquisition (éclairage, nature de la scène, etc.). - Les artefacts de compression (l effet de blocage, l'effet de flou, le bruit, le mouvement irrégulier,.) dus à la compensation du mouvement et aux schémas 32

33 CHAPITRE I La vidéo sur Internet de codage à base de blocs utilisés par la plupart des normes de codage (e.g. G.7xx, H.26x, MPEGx). - Les paramètres de QoS dans les réseaux de transmission : La bande passante. Une vidéo est une succession d'images à une certaine cadence. Les applications vidéo requièrent ainsi une bande passante élevée car d une part, une image représente une grande quantité d informations et d autre part, le nombre d images envoyées par seconde (appelé aussi cadence ou encore frame rate) doit être suffisant pour obtenir une visualisation satisfaisante. Le délai et la gigue qui peuvent introduire, d'abord, un long délai initial avant que la vidéo ne puisse être lue, et puis, des distorsions lors de la visualisation et, éventuellement, la perte de données en raison des paquets vidéo qui ratent la date limite de leur lecture [SIR, 10]. La perte des paquets qui peut causer un effet très destructif sur le trafic vidéo en raison des dépendances qui existent entre les images codées. - Les caractéristiques des dispositifs d affichage, telles que le type d'écran (CRT, LCD, plasma etc.) et ses propriétés (la taille, la résolution, la luminosité, le contraste, la couleur et le temps de réponse). Avec les progrès technologiques dans les domaines de l acquisition et de l affichage de vidéo, les facteurs liés à ces deux processus (les bruits d acquisition, la résolution, la luminosité, ) peuvent être réglés en choisissant les bons paramètres de configuration. Cependant, les facteurs liés au codec et aux réseaux de transport sont difficiles à contrôler et constituent un véritable verrou technologique. C est pour cela, seuls ces facteurs sont généralement pris en compte pour évaluer, contrôler et améliorer la QoV sur Internet comme nous allons l'illustrer dans les prochaines sous-sections. II.2. Les Méthodes d Evaluation D une manière générale, la qualité vidéo (QoV) peut être définie comme étant une fonction d un ensemble de gênes visuelles où la gêne représente une fonction de la perception des dégradations (ou distorsions). La perception des distorsions correspond à la sensation provoquée par la visibilité d erreurs qui est établie en fonction d un seuil appelé seuil de visibilité. Si une erreur est inférieure au seuil de visibilité, elle est invisible, sinon elle est visible [NIN, 09]. L évaluation de cette QoV peut être effectuée de deux manières: subjective ou objective. L évaluation subjective fait appel à des observateurs humains pour évaluer la qualité d une vidéo selon un protocole bien défini. En revanche, l évaluation objective 33

34 CHAPITRE I La vidéo sur Internet fait référence à des métriques mesurées empiriquement par des méthodes appropriées dans le but d automatiser le processus d évaluation. Dans ce qui suit, nous donnons une synthèse sur ces deux types de méthodes d évaluation. II.2.1. Les Méthodes Subjectives Les méthodes subjectives consistent principalement en des expériences de laboratoire, dans lesquelles un certain nombre de personnes sont exposées à des échantillons de vidéo dégradée qu ils doivent ensuite noter. Une telle note doit refléter leur perception, ou opinion, de la qualité de la vidéo. Après un filtrage statistique, la moyenne des opinions (Mean Opinion Score, MOS) est ensuite considérée comme la mesure de la qualité de l échantillon (Tableau I.1). Ces méthodes ont été normalisées dans les recommandations P.910 de l ITU-T [ITU-TP, 08] et BT.500 de l ITU-R [ITU-R, 02]. Tableau I.1. Mean Opinion Score (MOS) [ITU-R, 02]. MOS Qualité Distorsion 5 Excellente Imperceptible 4 Bonne Perceptible sans être gênante 3 Moyenne Légèrement gênante 2 Mauvaise Gênante 1 Très mauvaise Très gênante Pour la vidéo, les méthodes subjectives semblent les plus naturelles. Cependant, elles sont coûteuses en termes de temps et de moyens humains les rendant ainsi difficiles à reconstituer aussi souvent qu'on le souhaite. En effet, elles nécessitent au moins une population de 15 personnes ayant une bonne acuité visuelle pour chaque série de contenus vidéo évalués. Les durées des tests dépendent du nombre d échantillons à évaluer, de leurs durées et de la nature de la tâche assignée aux participants. Ainsi, les méthodes subjectives ne permettent pas de surveiller en temps réel les applications vidéo. De telles difficultés, associées aux méthodes subjectives, ont donnée lieu au développement des méthodes objectives qui, bien que moins performantes, sont beaucoup plus pratiques et moins coûteuses. II.2.2. Les Méthodes Objectives Les méthodes objectives font référence à des formules et des algorithmes établis dans le but d automatiser le processus d évaluation. Elles se basent sur la mesure d une ou plusieurs métriques objectives de la QoV. La validation de ces méthodes se fait par une comparaison de ses notes à celles recueillies lors des tests subjectifs. Cette comparaison est principalement établie à l aide du coefficient de corrélation entre les notes objectives 34

35 CHAPITRE I La vidéo sur Internet et les notes subjectives, appelées MOS (Mean Opinion Score). Ce coefficient de corrélation doit être bien choisi afin de présenter de façon la plus réaliste possible la relation entre les métriques objectives et la perception de l utilisateur. Plusieurs travaux ont été menés dans ce sens, donnant ainsi naissance à une pléthore de méthodes d évaluation de la QoV. Ces méthodes sont classées en trois catégories en fonction de la nature des informations nécessaires pour effectuer l évaluation. Ces catégories sont [NIN, 09]: - Les méthodes avec référence complète, notées FR (Full Reference), qui comparent la version de la vidéo à évaluer avec une version de référence de celle-ci. Pour cette catégorie, la version originale et la version à évaluer doivent être disponibles. - Les méthodes avec référence réduite, notées RR (Reduced Reference), qui comparent une description de la vidéo à évaluer avec une description d une version de référence de celle-ci. Une description est un ensemble de paramètres mesurés sur la vidéo. Pour cette catégorie, la version à évaluer et une description de la version originale doivent être disponibles. - Les méthodes sans référence, notées NR (No Reference), qui caractérisent les distorsions de la vidéo à évaluer uniquement à partir de celle-ci et, éventuellement, à partir de connaissances a priori sur celles-ci. Pour cette catégorie, seule la version à évaluer est requise. Par ailleurs, le type de méthode d évaluation de la QoV dépend de l application visée. Par exemple, les méthodes FR sont plus appropriées pour mesurer la QoV hors ligne comme c'est le cas dans le réglage ou les tests laboratoire du codec. Les conditions peuvent en effet être bien contrôlées et l analyse détaillée et précise de la vidéo est plus importante que les résultats immédiats. Les méthodes NR sont par contre mieux adaptées pour la surveillance des systèmes de distribution vidéo où la mesure en temps réel et le déclenchement d'alarme sous-jacent sont essentiels. Dans notre modèle de métrique de la QoE, nous nous sommes intéressés aux méthodes NR afin de mesurer la QoV en temps réel au niveau de l utilisateur final. II Les Méthodes sans Référence Les méthodes sans référence tentent de déterminer ou de prévoir la QoV en analysant un ou plusieurs types de dégradation (ou d artefact) et/ou en analysant les caractéristiques du système vidéo. Dans le premier modèle (à base d artefact), nous trouvons les méthodes mesurant un seul artefact comme l effet de blocage [WUY, 97] [PLR, 04], l effet de flou [MDW, 02] [MMZ, 02], l effet de netteté [CAG, 02] [NAK, 08] 35

36 CHAPITRE I La vidéo sur Internet et celles mesurant plusieurs artefacts à la fois comme NROQM [CAO, 03], NR-VQM [WOZ, 04] et AVQ [SUR, 07]. Cependant, ces méthodes sont souvent complexes et utilisées uniquement pour un type d artefact particulier. Le deuxième modèle, appelé aussi modèle paramétrique, prédit (ou estime) la qualité de vidéo perçue à partir d un ensemble de paramètres de mesure de performances, principalement liés au codec et au réseau. Dans ce modèle, les méthodes les plus connues sont : - L index de livraison des médias (Media Delivery Index, MDI) [WEC, 06] [INE, 06] [AGI, 08] : il donne une indication de la QoV attendue en se basant sur des mesures au niveau du réseau : le facteur du délai (Delay Factor, DF) et le taux de perte du média (Media Loss Rate, MLR). Il est souvent utilisé pour prévenir des déficiences et des conditions du réseau qui entraînent une livraison de vidéo inacceptable. Cependant, aucun modèle de corrélation entre les composants du MDI (DF et MLR) et la QoV n'a été mis en œuvre. - Une métrique associée à la qualité de déplacement des images (Moving Picture Quality Metrics, MPQM) [WIM, 08] : elle est basée sur le système de vision humain et tient compte de plusieurs paramètres comme la probabilité de taux de perte de paquets, la gigue, la référence d horloge du programme ou encore l entropie de l image. L approche appelée V-Factor est une implémentation du modèle MPQM. Elle permet de fournir le niveau de la QoV et aussi quelques informations supplémentaires nécessaires pour la surveillance et le diagnostic de certains problèmes comme : les indicateurs de performance définis dans la norme ETSI TR [ETSI, 04] et les paramètres de performance définis par les normes ITU Y1540/1541 [ITU-TY, 07] ou IETF RFC 2330 [PAM, 98]. Il est à noter ici que l outil V-Factor est propriétaire de la société Symmetricom 6 et ne permet pas une utilisation gratuite par les académiques. - Le modèle de prédiction développé dans Khan et al. [KSI, 09] pour les applications de streaming vidéo (MPEG-4) sur les réseaux sans fil ou mobiles. Ce modèle est formulé en fonction de paramètres de mesure objectifs associant le débit binaire de l émetteur (Sender BitRate, SBR), la cadence (Frame Rate, FR), le taux d'erreur de paquet (Packet Error Rate, PER) et notamment le type de contenu (Content Type, CT)

37 QoV CHAPITRE I La vidéo sur Internet - Le modèle d opinion défini dans la recommandation G.1070 de l ITU-T [ITU-TG, 07] : celui-ci estime la QoV, par le biais d une formule associant les paramètres collectés à partir du réseau (le taux de perte), du codec utilisé (débit binaire, nombre d image par seconde), de la nature de l équipement terminal (résolution, taille de l écran) et de l environnement (luminance). Tout en étant simple, ce modèle a prouvé son efficacité pour la mesure de la qualité multimédia des applications de vidéophonie sur les réseaux IP. Cependant, son utilisation est soumise au respect de certaines conditions spécifiques (le type du codec, le format de la vidéo, l intervalle d image clé et la taille d'affichage vidéo). Les critères que nous recherchons pour une bonne mesure sans référence de la QoV sont : (i) au moins un des paramètres réseau (le taux de perte, le délai) doit être considéré, (ii) une bonne corrélation des résultats avec la perception humaine, (iii) des calculs rapides et (iv) une implémentation facile. Au début, nous avons pensé que le modèle d opinion répond à toutes les exigences indiquées. Cependant, lorsque nous l avons appliqué en considérant le taux de perte comme la seule variable dans le modèle (le débit binaire et la cadence sont des constantes (420 Kb/s ; 30 fps)), le modèle n a pas fourni une bonne corrélation avec la perception humaine comme le montre la figure I.5. Nous avons donc opté pour une nouvelle démarche consistant à proposer notre propre modèle de corrélation entre les paramètres du réseau (le taux de perte, le délai) et la QoV (Cf. la section III.2.3 du chapitre IV). 5 4,5 4 3,5 3 2,5 2 1,5 1 0, IPLR (%) Perception Humaine Le Modèle d'opinion Figure I.5. La corrélation entre le modèle d opinion et la perception humaine. 37

38 CHAPITRE I La vidéo sur Internet II.3. Les Mécanismes de Gestion Internet est un réseau basé sur la commutation de paquets et sur le protocole IP qui implémente le modèle BE (Best Effort) : tous les paquets de données suivent la même politique et leur acheminement est effectué de proche en proche. Ce modèle ne permet pas de garantir la QoS des flux vidéo et de fournir ainsi une bonne QoV. Il a donc été nécessaire de développer des mécanismes capables de gérer la QoS afin de pouvoir contrôler et d améliorer la QoV. Ces mécanismes peuvent se faire de deux manières : - Les applications ajustent leur comportement en fonction de l état du réseau. - Le réseau s adapte aux demandes des flux applicatifs. Dans ce qui suit, nous présentons brièvement ces mécanismes qui s opèrent soit au niveau de l application soit au niveau du réseau. II.3.1. Au Niveau de l Application Dans cette approche, il s agit de minimiser au niveau applicatif l impact des paramètres du réseau sur la QoV. Ceci est fait, en pratique, par les solutions présentées dans le tableau I.2. Tableau I.2. Les principales solutions au niveau de l application [AHM, 08]. Paramètres du réseau Solutions proposées La bande passante Le taux de perte Le délai et la gigue II Gestion de la Bande Passante Choix du codec Techniques d adaptation Techniques de contrôle Mémoire tampon (Buffer) La bande passante utilisée par un service vidéo peut varier considérablement dans le temps (moment de connexion) et dans l espace (endroit de connexion). La gestion de la bande passante est liée principalement au choix du codec vidéo à utiliser pour un service donné. Ce choix est régi généralement par un compromis entre la taille des unités de données (les échantillons), le délai de compression, le débit à la sortie du codec et la puissance du traitement (i.e. complexité de l algorithme). Il existe actuellement plusieurs normes de codage audiovisuel (Figure I.6). La plus récente est la norme H.264 développée par le groupe JVT (Joint Video Team) qui permet de réduire à moitié les débits utilisés avec MPEG-2 [AHM, 03] [AHM, 08]. 38

39 CHAPITRE I La vidéo sur Internet Figure I.6. Les normes de compression vidéo [AHM, 08]. Choisir un bon codec répondant au besoin de la bande passante d un service vidéo ne suffit pas pour garantir un niveau acceptable de la QoV. Il est aussi nécessaire de gérer la bande passante de manière dynamique en observant l état des ressources disponibles et en agissant sur les différents éléments impliqués dans le service (i.e. par adaptation dynamique). Il existe plusieurs techniques de gestion de la bande passante de bout-enbout qui permettent à la source vidéo de s adapter dynamiquement aux changements des conditions réseau [AHM, 03] [AHM, 08]: simulstore, commutation de flux, transcodage, lissage, etc. II Gestion de Pertes Pour faire face aux effets des pertes sur les flux vidéo décodés, il est nécessaire dans un premier temps de détecter et d isoler la perte, puis dans un second temps d appliquer des techniques de remèdes. La figure I.7 donne un aperçu et une classification des techniques de transport fiables des paquets vidéo. Ces techniques sont classées en deux catégories: (i) les mécanismes au niveau de la source, actives ou passives, pour récupérer les pertes, et (ii) les mécanismes au niveau du destinataire qui dissimule la perte par certaines méthodes. Ces techniques de transport fiables sont détaillées dans [AHM, 03] [AHM, 08]. 39

40 CHAPITRE I La vidéo sur Internet Figure I.7. Techniques de contrôle de pertes [AHM, 08]. II Gestion du Délai et de la Gigue Une solution aux problèmes du délai et de sa variation (gigue) est l utilisation d une mémoire tampon (buffer) dans le décodeur pour la lecture du contenu vidéo. Cette mémoire tampon sert à assembler les paquets de données, éventuellement les réordonner, les décoder et compenser ceux qui sont perdus. Elle agit comme un véritable amortisseur des variations temporelles des paramètres de QoS. Le but de cette configuration est de permettre une lecture fluide du contenu décodé indépendamment de la variation du délai d arrivée des paquets. La longueur de la mémoire tampon est généralement réglée d une façon à couvrir largement la somme du délai de réception des paquets et de sa variation maximale. Il est communément acquis que les paramètres de QoS pour une session vidéo temps-réel peuvent généralement être réduits au délai et à la perte des paquets si une mémoire tampon de taille convenable est utilisée [BOU, 10]. Cependant, l utilisation de la mémoire tampon introduit un délai supplémentaire indésirable (délai de pré-enregistrement) avant que la lecture de la vidéo puisse commencer [AHM, 03]. II.3.2. Au Niveau du Réseau Pour pouvoir mettre en place des garanties de QoS dans les réseaux IP, l IETF (Internet Engineering Task Force) a proposé plusieurs modèles répondant au besoin de la QoS, notamment: les services intégrés (Integrated Services, IntServ) [BCS, 94], les services différenciés (Differentiated Services, DiffServ) [BBC, 98], la commutation de labels multi-protocoles (MultiProtocol Label Switching, MPLS) [RVC, 01] et le routage avec QoS (QoS Routing, QoSR) [CNR, 98]. 40

41 CHAPITRE I La vidéo sur Internet Le modèle IntServ est un modèle orienté flots (ou connexions), dans lequel chaque flot peut faire une demande de QoS spécifique. La garantie de la QoS de chaque flot est alors effectuée par un contrôle d admission et une réservation préalable des ressources (Resource reservation Protocol, RSVP). Il s agit d une gestion préventive de la QoS, effectuée à priori lors de la réservation des ressources. À l opposé, le modèle DiffServ agrège les flux en quelques grandes classes de trafics qui ont chacune ses besoins spécifiques de QoS. La QoS est alors assurée au niveau des nœuds du réseau (les routeurs) par des traitements spécifiques à chaque classe de service. Enfin, le réseau MPLS est orientée «connexion» permettant une ingénierie du trafic (Traffic Engineering, MPLS- TE) de réseaux à commutation de paquets. À ce titre, ils peuvent garantir la bande passante pour divers flots, ce qui constitue la première condition pour fournir une garantie de QoS. Par ailleurs, pour satisfaire les contraintes de délai, de gigue ou de perte imposées par les applications vidéo, MPLS-TE peut être associé à des technologies orientées classes de trafic comme la signalisation RSVP-TE ou comme le modèle DiffServ. Le routage avec QoS consiste à calculer un chemin qui satisfait plusieurs contraintes de QoS simultanément (débit, délai, gigue, fiabilité, etc.). Les protocoles de routage traditionnels ne répondent pas à ces caractéristiques. Il était donc nécessaire de concevoir de nouveaux mécanismes de routage qui prennent en compte l état réel des liens et des routeurs afin d effectuer un routage avec QoS. 41

42 CHAPITRE I La vidéo sur Internet CONCLUSION En conclusion, nous pouvons dire que la vidéo sur Internet n a pas encore acquis ses lettres de noblesse, loin s en faut, mais des progrès significatifs ont été atteints ces dernières années. Des technologies spécifiques ont été développées et aujourd hui ce marché est en pleine explosion même si de nombreux progrès restent encore à faire pour améliorer la QoV. Dans ce premier chapitre, nous avons d abord clarifié la relation entre un système, une application et un service vidéo. Ensuite, nous nous sommes basés sur la technique de streaming vidéo qui a nécessité le développement d architectures et de protocoles particuliers pour la distribution et la transmission de la vidéo sur Internet. Aussi, nous avons décrit quelques services vidéo les plus populaires, notamment la vidéo à la demande (VoD) qui nous intéresse dans notre travail. Nous avons ensuite présenté la notion de la qualité de vidéo (QoV) en citant les facteurs impactant celle-ci, en particulier, les artefacts de compression et les paramètres de la QoS. Ces deux types de facteurs sont pris en compte pour évaluer, contrôler et améliorer la QoV. Nous tenons à spécifier que dans le cadre de notre modèle de métriques de la QoE, nous proposons notre propre modèle de corrélation entre les paramètres du réseau (le taux de perte, le délai) et la QoV afin de mesurer celle-ci en temps réel au niveau de l utilisateur final. La plupart des efforts de la communauté scientifiques se sont concentrés sur la QoV pour déterminer la QoE en ignorant certains aspects importants tels que la disponibilité et la réactivité des services vidéo qui sont également pertinents à l égard de l utilisateur. Le chapitre suivant sera consacré à la QoE des services vidéo. 42

43 Chapitre II La Qualité d Expérience Propre aux Services Vidéo INTRODUCTION L explosion d Internet a donné lieu à une nouvelle génération de services vidéo comme la télévision sur IP, la vidéoconférence ou encore la vidéo à la demande. Les fournisseurs de ces services vidéo sont appelés de plus en plus à fournir à l utilisateur final un certain confort dans l'usage s'ils veulent rester en course. Or, l architecture d Internet n a pas été conçue pour supporter ce type de services, et de ce fait, ce confort n'a pas été pris en compte lors de la conception du réseau Internet sachant que celui-ci fonctionne en «Best Effort». Il s'avère donc nécessaire de développer des mécanismes capables de prendre en compte ce nouvel aspect en charge. Une telle perception est depuis peu connue au sein de la communauté scientifique sous le nom de «Qualité d Expérience» (Quality of Experience, QoE). Dans ce contexte, l état de l art, que nous présentons dans ce chapitre, se veut être une synthèse sur des concepts nécessaires à la bonne compréhension de la QoE propre aux services vidéo sur Internet [ARM, 12]. Tout d abord, nous commençons par définir

44 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo ce que signifie la QoE. Ensuite, nous passons en revue les principaux modèles de métriques de la QoE, et nous discutons dans la foulée la relation possible entre la QoE et la QoS en analysant des modèles génériques de corrélation existants. Enfin, nous abordons brièvement les mécanismes de contrôle de la QoE. 44

45 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo I. DEFINITION DE LA QUALITE D EXPERIENCE La définition la plus répandue de la QoE est donnée par la norme IUT-T [ITU-TGP, 08] qui décrit la QoE comme «l'acceptabilité globale d'une application ou d un service, tel qu'il est perçu subjectivement par l'utilisateur final». Elle inclut les effets complets générés par un système de bout en bout (client, terminal, réseau, infrastructure de services, etc.) et peut être influencée par les attentes, le contexte et le profil des utilisateurs. Martinez-Yelmo et al. [MSG, 10] proposent quant à eux une autre définition pour la QoE appropriée à tout domaine : «il s agit d une mesure subjective de l expérience vécue par l utilisateur». Cette courte définition résume les deux points clés liés au concept de la QoE. Le premier est sous-jacent au fait que la QoE est basée sur des «mesures», ce qui signifie que certains mécanismes sont nécessaires pour définir quelles mesures sont les plus pertinentes et comment peuvent elles être obtenues? Le second correspond au fait que «l expérience est vécue par l utilisateur», signifiant ainsi que ces mesures sont aussi de nature subjective, font appel à un aspect cognitif et dépendent du profil de l'utilisateur, consommateur de ces services. Récemment, une définition plus ample a émergé des discussions faites dans le cadre du séminaire de Dagstuhl (De la Qualité de Service à la Qualité de l'expérience) [WMW, 11] qui détermine la QoE comme «le degré de satisfaction de l utilisateur du service». Dans le cas de services de communication, elle est influencée par le contenu, le réseau, le dispositif, l'application, les attentes et les objectifs de l utilisateur ainsi que le contexte dans lequel ils sont utilisés. Ces définitions montrent clairement que la QoE est aussi composée d'une dimension subjective. Elle détermine le degré de satisfaction de l utilisateur final en prenant en compte tous les facteurs qui influent non seulement sur sa perception mais aussi ses attentes. En effet, la satisfaction reflète le degré de concordance entre l expérience vécue par l utilisateur lors de l usage du service et ses attentes vis-à-vis de cet usage. De plus, c est une notion dépendante des utilisateurs et sa mesure est relative: une expérience peut être jugée satisfaisante par un utilisateur car elle répond favorablement à ses attentes, tout en étant peut être insatisfaisante pour un autre. C'est pourquoi nous retenons comme définition de la QoE dans ce travail celle donnée dans le cadre du séminaire de Dagstuhl [WMW, 11] parce qu'elle nous semble la plus appropriée. 45

46 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo II. LES METRIQUES DE LA QUALITE D EXPERIENCE L évaluation de la QoE requiert la définition d un ensemble de métriques 7 pour mesurer le degré de satisfaction des utilisateurs terminaux. Dans la littérature, plusieurs modèles de métriques ont été proposés correspondant à différents types de services. Dans cette section, nous nous intéressons seulement aux modèles pouvant être appliqués aux services vidéo. Nous commençons par présenter le modèle de l IUT-T [ITU-TG, 08] qui décrit la structure générale de la QoE. Nous présentons ensuite les modèles émanant du DSL Forum [RFW, 06] et décrits dans [MAM, 07] qui se basent sur le caractère multidimensionnel de la QoE. Nous étudions ensuite le modèle du TM Forum [TMF923, 04] qui étend le concept des indicateurs clés en deux nouvelles catégories d'indicateurs : les indicateurs de qualité (Key Quality Indicators, KQI) et les indicateurs de performance (Key Performance Indicators, KPI). Nous terminons enfin avec un modèle proposé par Liu et al [LZS, 09] qui introduit le concept d'index de la QoE. II.1. La Structure de la QoE Selon la norme définie par IUT-T [ITU-TG, 08], la QoE mesure la qualité perçue par les utilisateurs finaux en tenant compte de tous les facteurs qui influent à la fois sur leur perception et leurs attentes. Ces dernières sont fortement influencées par plusieurs facteurs subjectifs. La mesure de la perception intègre par ailleurs de multiples paramètres techniques objectifs. Les mesures objectives proviennent d'indicateurs quantitatifs définissant la qualité de service fournie à l'utilisateur en termes de métriques de performance mesurables au niveau du service (la disponibilité), du réseau (le délai, la gigue et le taux de perte) et de l application client (le codec, la cadence et la résolution d image). La partie subjective définit quant à elle la qualité perçue par l utilisateur en termes d'émotions, de facturation du service et d expérience. La structure de la QoE est illustrée dans la figure II.1. Cette structure de mesure de QoE est difficilement exploitable dans le cas d'un utilisateur ordinaire. Il est en effet difficile d expérimenter et d évaluer chaque paramètre de la qualité de manière exacte. C'est pour cela que d autres concepts plus rationnels ont 7 De manière générale, une métrique est définie comme «un système de mesures connexes qui facilite la quantification d'une certaine caractéristique particulière» [ 46

47 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo été proposés comme les facteurs de mesure, les indicateurs et les index de la QoE décrits ci-dessous. Figure II.1. La structure de la QoE [ITU-TG, 08]. II.2. La multi-dimensionnalité de la QoE La QoE peut être comprise comme une valeur multidimensionnelle qui se compose de différents aspects de la qualité. C'est en se basant sur ce caractère multidimensionnel de la QoE que les modèles DSL Forum [RFW, 06] et celui décrit dans Marez & Moor [MAM, 07] ont été proposés. II.2.1. Le Modèle du DSL Forum A chaque service, le DSL Forum a proposé des facteurs de mesures et des seuils d'acceptabilité (des niveaux prévus) pour la QoE [RFW, 06]. Dans le cas d un service vidéo, cette multi-dimensionnalité inclut les facteurs suivants : la fidélité de l'information (la qualité audio et vidéo), la facilité d utilisation (la manipulation de l'interface de l utilisateur), l instantanéité (temps de réponse faible), la sécurité (l authentification des utilisateurs et la protection des sources vidéo), la fiabilité et la disponibilité. Ces facteurs sont examinés au niveau de trois couches : service, application et réseau. Dans la couche de service, la QoE est mesurée généralement à l aide de l'échelle MOS (Mean Opinion Score) [ITU-R, 02]. Dans les autres couches, la QoE est corrélée aux paramètres liés à l'application vidéo (la résolution d image, le codec vidéo/audio, le débit binaire et la couleur) et à la performance du réseau (le délai, la gigue et le taux de perte de paquets). Ces paramètres sont gérés de manière à atteindre les niveaux prévus de la QoE. Ce modèle se concentre sur l aspect objectif (performances de service) plutôt que sur l aspect subjectif de la qualité. Il ne prend pas en charge les facteurs liés à l'utilisateur 47

48 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo comme les attentes des utilisateurs, leur expérience, le contexte dont ils se trouvent et d autres facteurs. Le modèle proposé dans Marez & Moor [MAM, 07] vient couvrir ces facteurs. II.2.2. Le Modèle de Marez & Moor Dans [MAM, 07], les auteurs ont proposé un modèle conceptuel couvrant les dimensions suivantes (Figure II.2): - La qualité de service qui est une première condition pour parvenir à un service performant. Cette dimension agit sur les performances technologiques à quatre niveaux: application/ service, serveur, réseau et dispositif / appareil. - La facilité d'usage qui est abordée en termes de l'usage comportementale (basé sur la facilité de travail, la convivialité et l'interaction hommemachine) et de l'usage émotionnel (basé sur les émotions et les sentiments de l'utilisateur lors de l'utilisation du dispositif ou de la technologie). - La qualité d efficience qui couvre le caractère subjectif de la QoE. Il apparaît en effet qu'une technologie peut être très performante en termes techniques mais cela peut ne pas être assez efficient pour satisfaire l'utilisateur ou répondre à ses attentes. À cet égard, Jarvenpaa & Lang [JAL, 05] soulignent le fait que «les expériences des utilisateurs avec la technologie sont souvent paradoxale». Pour cette dimension, on distingue trois niveaux: dispositif/appareil, réseau et application/service. - Les attentes qui permettent de mesurer la qualité d efficience de manière adéquate. En effet, ce n'est que lorsqu on a un aperçu des attentes de l'utilisateur qu on peut savoir si une technologie fonctionne bien ou est assez suffisante pour cet utilisateur. Le niveau de satisfaction de ces attentes détermine alors la qualité d efficience. - Le contexte dans lequel se trouve l utilisateur influence directement ses attentes. Cinq types de contexte sont proposés: environnemental, personnel/ social, culturel, technologique et organisationnel. Le modèle proposé a été construit avec l'intention de couvrir non seulement ce que le service fait, mais aussi ce que les personnes peuvent faire avec le service, ce qu ils veulent/pensent à faire avec le service et ce qu ils attendent du service, le contexte dans lequel ils ont l intention de l'utiliser, et jusqu'à quel point il répond à leurs attentes. Bien que ce modèle soit complet, il est assez complexe et peu pratique dans l usage pour mesurer la QoE. Il est en effet difficile de mesurer chaque dimension de manière exacte. 48

49 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo Figure II.2. Les dimensions de la QoE [MAM, 07]. 49

50 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo II.3. Les Indicateurs Clés de Qualité et de Performance Afin de permettre aux fournisseurs d un service de se concentrer sur sa qualité plutôt que sur sa performance, le TM Forum a étendu le concept de l indicateur clé en deux nouvelles catégories d'indicateurs : les indicateurs de qualité (Key Quality Indicators, KQI) et les indicateurs de performance (Key Performance Quality, KPI) [TMF923, 04]. La QoE est rapportée à un certain nombre de KQIs. Ces derniers sont des indicateurs de haut niveau qui mesurent la qualité du service ou de ses composants. Les KPIs sont des mesures quantifiables qui reflètent les facteurs critiques de succès ou d échec d'une ressource ou d un élément de service. D une manière générale, un KQI est défini à partir d'un ensemble de KPIs mesurant la performance du réseau à partir de ses éléments. La correspondance entre les deux types d indicateurs KPI et KQI peut être simple ou complexe, empirique ou formelle. Le modèle hiérarchique de gestion de performances est illustré dans la figure II.3. Figure II.3. Le modèle hiérarchique de gestion de performances [TMF917, 04]. Le concept de KQI\KPI est le plus utilisé pour évaluer le degré de satisfaction des clients (QoE) dans le domaine des télécommunications. En effet, le contrat entre un client et un fournisseur de service (Service Level Agreement, SLA) spécifie entre autres les KQI/KPI des services. Dans [TMF917, 04], le TM Forum a proposé un ensemble générique de KQI/KPI pour un certain nombre de services commerciaux. Le tableau II.1 résume les KQI\KPI pour les services vidéo suivants : la vidéoconférence, la transmission en continu et la diffusion en direct. 50

51 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo Tableau II.1. Les KQI\KPI pour les services vidéo [TMF917, 04]. Indicateurs de qualité (KQI) Indicateurs de performance (KPI) Mean Time Between Failure (MTBF) Disponibilité Mean Time Between Repair (MTBR) Taux de perte de service Mean Opinion Score (MOS) Qualité de Audio\ Vidéo IP Packet Loss Ratio (IPLR) Packet Transfer Delay (IPTD) Packet Delay Variation (IPDV) Temps de Réponse Temps de Réponse Round Trip Time (RTT) One Way Delay (OWD) RTT Délai OWD RTT Gigue IPDV Cell Delay Variation (CDV) Confidentialité Les violations d'accès physique Non-répudiation Les violations d'accès physique Interopérabilité Les complaints d Interopérabilité Temps de Connexion Temps de Connexion II.4. Les Index de la QoE Dans [LZS, 09], les auteurs ont proposé un nouveau concept appelé index de la QoE. Il est défini sur la base des attentes des clients qui sont classées en deux catégories: la fiabilité et le confort. La fiabilité, dans ce contexte, représente l'accessibilité, la réactivité et la persistance du service. Le confort se réfère à la qualité de la session et à l intégrité du service. Chaque index de la QoE peut correspondre à plus d un KQI et chaque KQI peut influencer plus d un index de la QoE. Désignant le degré de satisfaction des clients comme la plus haute couche (la couche cible), les index de la QoE sont choisis pour lier la couche supérieure avec les KQIs. Ce modèle hiérarchique se veut universel et peut être appliqué à tous les services du réseau de nouvelle génération (Next Generation Network, NGN). La figure II.4 ci-dessous représente le cas d un service vocal. 51

52 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo Figure II.4. Le modèle hiérarchique de service vocal [LZS, 09]. Cette étude nous a permis de choisir le modèle TM Forum comme celui qui va nous nous permettre de mesurer au mieux la QoE. Ses deux niveaux d hiérarchie (KQI/KPI) suffisent amplement pour déterminer la QoE. Nous pensons par ailleurs que l ensemble générique des KQI/KPI (Tableau II.1) peut encore être simplifié davantage en éliminant la redondance de certains KQIs (le temps de réponse, le RTT, le délai et le temps de connexion) tout en ignorant les KQI liés à la sécurité (Confidentialité, Non-répudiation, Interopérabilité). En effet, dans le cadre de ce travail, l aspect de sécurité ne sera pas traité. III. LA RELATION ENTRE LA QoE ET LA QoS La perception d'un service donné a toujours été vue différemment entre les fournisseurs de ces services Internet et les utilisateurs de ceux-ci. En effet, les fournisseurs et les utilisateurs utilisent des critères différents pour évaluer la performance. Les premiers font souvent appel aux paramètres spécifiques de la QoS collectés au niveau du réseau de transport comme par exemple le débit, le taux de perte ou encore le délai. En revanche, les utilisateurs perçoivent quant à eux la performance du service dans des termes plutôt subjectifs. Par exemple, les utilisateurs d un service streaming vidéo veulent percevoir la vidéo avec une certaine qualité sans pour autant être intéressés par les valeurs des paramètres techniques du réseau. Or, les deux aspects sont bien évidemment corrélés et il est nécessaire de connaître l impact de la performance du réseau sur le ressenti de l utilisateur. Il est par contre très difficile d évaluer cet impact en temps réel sur un réseau opérationnel, alors que, le contrôle (ou la surveillance) des critères de performance au niveau du réseau est plus facile et plus traditionnel. La solution idéale pour les fournisseurs de services est par conséquent 52

53 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo d identifier la relation entre les paramètres de la QoS et l influence individuelle et collective de ces derniers sur la QoE. En connaissant la QoE de l utilisateur final, le fournisseur peut en effet réguler les paramètres techniques de son réseau afin de répondre au mieux aux attentes de ses clients. Quantifier la relation entre la QoE et la QoS revient donc à définir un modèle de corrélation entre ces deux notions. Plusieurs modèles de corrélation ont été proposés dans la littérature. Nous pouvons distinguer: - Les modèles généraux d évaluation de la QoE où la QoS ne présente qu un facteur parmi d autres (Hamam et al. [HEE, 08] et Gong et al [GYH, 09]). - Les modèles particuliers qui étudient l impact des paramètres de la QoS sur la QoE (rapportée à l un de ses indicateurs de qualité (KQI)). Parmi ces modèles, nous retenons le modèle de Kim et al [KLL, 08], le modèle IQX de Fielder et al [FHT, 10] et le modèle polynomial de Rafai et al [RSM, 11]. III.1. Le Modèle Mathématique Hamam et al. [HEE, 08] ont proposé une classification pour mesurer la QoE des interfaces utilisateurs haptiques (Haptic User Interface, HUI). Cette classification est présentée par un modèle mathématique dans lequel la QoE est calculée comme la combinaison linéaire pondérée de la qualité de service (QoS) et de l'expérience de l utilisateur (User Experience, UE): ( ) (II.1) Où - contrôle le poids relatif attribué au paramètre QoS par rapport au paramètre UE. - La QoS est la moyenne pondérée (II.2) d un ensemble de mesure de la performance du service (S) comme le temps de réponse, la latence/le délai, la bande passante, la gigue, etc. A notre connaissance, le calcul des poids ( ) pour chaque paramètre ( ) n'a pas été précisé dans [HEE, 08]. (II.2) - Le paramètre UE est modélisé comme la somme pondérée de la perception (P), la qualité de rendement ( ) et l aspect physiologique de l utilisateur ( ). De même que la QoS, chaque paramètre (P, R ou Ph) est modélisé comme la moyenne pondérée d un ensemble des mesures qui le définissent. Les principales mesures de la perception sont en effet la facilité 53

54 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo d'utilisation, les préférences, l intuition, les motivations et la satisfaction de l utilisateur. La qualité de rendement est la qualité des trois grandes modalités, à savoir: graphiques, audio et haptiques. Les mesures physiologiques reflètent le comportement de l utilisateur observé comme le stress et la phobie. (II.3) Ce modèle mathématique présente un modèle de corrélation linéaire entre la QoE et la QoS. Cependant, ce modèle signifie que la QoE est presque égale à la QoS, alors que la QoS n est une première condition pour parvenir à un service performant au regard de l utilisateur. Comme discuté dans [MAM, 07], un service peut en effet être très performant en termes de techniques mais cela peut ne pas être assez efficient pour satisfaire l'utilisateur ou répondre à ses attentes. III.2. Le Modèle Pentagramme Dans [GYH, 09], Gong et al. ont proposé un modèle dit de pentagramme pour mesurer la QoE. Ce modèle se compose de cinq facteurs: l'intégralité, la persistance, la disponibilité, l utilité et l'instantanéité. Pour chaque facteur, les auteurs ont déterminé les mesures les plus importantes (Tableau II.2). Les mesures de l intégralité sont celles qui définissent la QoS, notamment le délai, la gigue et le taux de perte de paquets. La QoE est calculée par : ( ) ( ) (II.4) Tableau II.2. Les mesures les plus importantes des facteurs la QoE [GYH, 09]. Les facteurs de la QoE Les mesures les plus importants Symbole L intégralité de Service Délai, Gigue, et taux de perte de parquets. a La persistance de Taux d interruption de service. b Service La disponibilité de Taux de réussite d'accès utilisateur au service. c Service L utilité de Service Utilité de service d La réactivité de Service Temps de réponse de l établissement et de l accès e au service. L intégrité est calculée comme la somme pondérée du taux de consistance du délai ( 1), de la gigue ( 2) et du taux de perte de paquets ( 3) : (II.5) 54

55 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo où PL, JIT et DEL représentent respectivement le poids du délai, de la gigue et du taux de perte de paquets. Le taux de consistance d un paramètre k ( ) est mesuré à partir d un échantillon de taille n comme suit: ( ) La fonction ( ( )) définit le rapport de la valeur maximale du paramètre k ( valeur dans l échantillon numéro i ( ( )): (II.6) ) sur sa ( ) ( ) (II.7) Ce modèle représente de nouvelles façons pour évaluer et mesurer la perception des services voix sur IP (Voice over IP, VoIP). Cependant, il ne peut pas être utilisé en temps réel vu que la QoS est calculée d après un échantillon de mesures collecté périodiquement. III.3. Le Modèle de Kim et al. Kim et al. [KLL, 08] ont proposé un modèle de corrélation QoE-QoS donnée par la formule (II.8) dans laquelle la constante α représente la classe de qualité QoS au niveau du réseau, le paramètre β est déterminé selon la classe de service, et la constante K est le degré de satisfaction de l'utilisation des services. ( ) { ( α α ) ( α α β) } (II.8) La variable utilisée (QoS) est calculée comme la somme des scores normalisés (W) de plusieurs paramètres (II.9) : le délai (D), la gigue (J), le taux de perte (L), le taux d'erreur (E), la bande passante (B), le taux de connexions établies (S), etc. ( ) ( ) ( ) ( ) ( ) ( ) (II.9) Ces scores sont différents selon l utilisation du service. Par exemple, les auteurs ont assigné un score de 10 au délai ( ( ) ) pour des services sensibles au délai (comme la VoIP et la vidéoconférence) et un score de 5 ( ( ) ) pour des services moins sensibles au délai (comme la vidéo à la demande). A notre connaissance, le type de la relation entre la QoE et la QoE permettant de déduire le modèle de corrélation (II.6) n'a pas été précisé dans [KLL, 08]. D autre part, définir les paramètres α, β, K ainsi que les scores (W) de chaque paramètre de la QoS pour tous types de service reste toujours un problème ouvert. 55

56 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo III.4. Le Modèle IQX Dans [FHT, 10], Fielder et al. ont d abord discuté la relation qualitative entre la QoE et la QoS. Ensuite, ils ont quantifié cette relation dans une formule de forme exponentielle, appelée IQX (Interdependency between QoE and QoS is exponential). De manière générale, la relation entre la QoE et la QoS est représentée sous la forme d une courbe (Figure II.5) où les niveaux de la perturbation de QoS sont notés sur l axe des abscisses tandis que les valeurs de la QoE (e.g. MOS) le sont sur celui des ordonnées. Les auteurs ont distingué trois zones séparées par les seuils x1 et x2 : - Zone 1 : La QoE optimale est constante. Une légère croissance de la perturbation de la QoS peut ne pas affecter la QoE. Par exemple, les petits retards (petites gigues) peuvent être éliminés par un tampon de gigue sans que l utilisateur ne remarque le délai supplémentaire. - Zone 2 : La QoE est amortie. Lorsque la perturbation de la QoS dépasse un certain seuil x1, l ex-niveau de la QoE quasi-optimale ne peut pas être maintenu. L augmentation de la perturbation de la QoS cause la diminution de la QoE et par conséquent la diminution de la satisfaction des utilisateurs. - Zone 3 : La QoE est inacceptable. Dès que la perturbation de la QoS atteint un seuil plus élevé, x2, le résultat de la transmission pourrait devenir trop mauvais en qualité. A ce moment, le service peut cesser de fonctionner en raison de contraintes techniques, telles que les délais d'attente, et l utilisateur peut renoncer à l'utilisation du service (Cf. la ligne en pointillée dans la courbe). En se basant sur cette forme générale de la courbe de correspondance entre la QoS et la QoE (Figure II.5), Fiedler et al. ont défini la relation de base du modèle IQX: (II.10) Ce modèle a été validé pour le service streaming VoIP, où la qualité audio en termes de MOS est exprimée en fonction d un seul paramètre de la QoS : le taux de perte ou le taux de ré-ordonnancement. Pour le service de navigation web (web surfing), les auteurs ont montré que le modèle exponentiel donne des approximations de bonne qualité que des approximations originales des modèles logarithmiques proposés dans [SFC, 09] et [RTS, 10]. 56

57 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo III.5. Le Modèle Polynomial Figure II.5. La relation entre la QoE et QoS [FHT, 10]. Récemment, Rifai et al [RSM, 11] ont proposé un modèle de corrélation polynomial entre la QoE et la QoS (II.11) où n présente l'ordre du polynôme. (II.11) Ce modèle permet de s'adapter aux différentes formes de courbes de corrélation: (i) linéaire en développant le modèle (II. 11) au premier ordre (n=1), (ii) logarithmique en utilisant le développement de Taylor pour la fonction logarithmique (II.12) et (iii) Exponentielle en utilisant le développement de Taylor pour la fonction exponentielle (II.13). De plus, les résultats ont montré d une part une bonne approximation entre le modèle logarithmique proposé dans [HEK, 02] et le modèle polynomial (d ordre 5) et d autre part, aucune différence entre le modèle exponentiel de Fielder et al [FHT, 10]. et son approximation polynomiale (d ordre 4). Cependant, le modèle polynomial a été validé pour un seul paramètre de la QoS à la fois. ( ) ( ) ( ) (II.12) ( ) ( ) (II.13) Au regard de sa généricité, nous avons choisi de travailler sur le modèle IQX. Cependant, celui-ci ne prend en compte qu'un seul paramètre de QoS. Ceci nous semble peu pratique puisque les applications vidéo exigent de fortes contraintes au regard de plusieurs paramètres de QoS. Il nous semble donc important d étendre le modèle IQX et de travailler avec plusieurs paramètres de QoS, le problème serait ainsi vu comme un problème d'optimisation à contraintes multiples. Dans [KLL, 08] [GYH, 09] [HEE, 08], la QoS peut être modélisée comme une combinaison pondérée de plusieurs paramètres. Comme, il est difficile de préciser le poids de chaque paramètre de QoS, nous proposons 57

58 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo d identifier l impact individuel de chaque paramètre de QoS sur la QoE et d en déduire ensuite leur impact collectif. Sur la base des outils de statistiques simple comme la régression linéaire multiple, nous développons dans le chapitre IV un modèle global de corrélation de forme exponentiel dans lequel la QoS est calculée comme une somme pondérée de plusieurs paramètres. IV. LES MECANISMES DE CONTROLE DE LA QoE Afin de répondre aux besoins de l utilisateur d un service vidéo, il est nécessaire de concevoir des solutions (architectures et protocoles réseaux) capables de garantir, voire améliorer, sa perception QoE. Parmi celles-ci, nous retrouvons le système de gestion de la QoE pour les services IPTV [GCE, 09], le mécanisme adaptatif de streaming vidéo pour les réseaux de distribution de vidéo [GVK, 09] et le routage adaptatif basé sur la QoE dans les réseaux de distribution de contenus [TMH, 11]. IV.1. Système de Gestion de la QoE pour les Services IPTV Dans [GCE, 09], Garcia et al. ont proposé un système de gestion de la QoE pour les services IPTV. Ce système est basé sur un processus appelé «processus de QoE» situé entre le fournisseur d accès à Internet et l utilisateur. Ce processus calcule la QoE à tout moment puis décide d'effectuer la tâche appropriée. Quand il est nécessaire de procéder à toute amélioration (la QoE dépasse une certaine limite), le système choisit entre changer les paramètres du réseau (la bande passante, le système de gestion de files d'attente,.), se déplacer ou basculer sur un commutateur ou un routeur de secours (si disponible). Nous tenons à spécifier que les auteurs divisent le concept QoE en deux parties: QoE du réseau (QoEN) et QoE de l'utilisateur (QoEU). La QoEN est déterminée à partir des paramètres de la QoS collectée à travers du réseau (délai, gigue et taux de paquets perdus). La QoEU (II.14) dépend, quant à elle de plusieurs paramètres, entre autres la qualité de vidéo ( ), le temps de zapping ( ) et le temps de synchronisation ( ). ( ) (II.14) IV.2. Mécanisme Adaptatif de Streaming Vidéo pour les Réseaux de Distribution de Vidéo Ghareeb et al. [GVK, 09] ont proposé un mécanisme adaptatif de streaming vidéo multi-chemins pour les réseaux de distribution de vidéo (Video Distribution Network, 58

59 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo VDN) afin de maximiser la QoE des utilisateurs finaux. Avec ce mécanisme, quand un client demande une vidéo, le serveur vidéo choisit une stratégie initiale (méthode de fractionnement de la vidéo) et un schéma (chemins utilisés pour transmettre les flux) initial pour démarrer le streaming vidéo. Le choix du chemin entre le client et le serveur vidéo est dynamiquement fait sur la base de l estimation de la bande passante disponible. La QoE au niveau de l utilisateur final est mesurée à l'aide d un outil d évaluation pseudo-subjective de la qualité (Pseudo Subjective Quality Assessment, PSQA). Le retour de la QoE est ensuite envoyé périodiquement dans les paquets RTCP au serveur vidéo qui va décider de conserver ou de modifier sa stratégie et/ou son schéma. Les résultats de simulation ont montré que la méthode proposée peut adapter automatiquement la distribution de charges sur les routes suivies de façon à garantir une meilleure QoE. IV.3. Routage Adaptatif sur la base de la QoE dans les Réseaux de Distribution de Contenus Récemment, Tran et al. [TMS, 11] ont proposé un algorithme de routage adaptatif basé sur la QoE et le Q-Learning, appelé QQAR (QoE Q-learning based Adaptive Routing). Cet algorithme intègre le retour de la QoE des utilisateurs finaux dans un système de routage évolutif afin d'améliorer leur perception en se basant sur l'algorithme de l'apprentissage par renforcement Q-Learning. Pour évaluer la QoE, les auteurs ont utilisé l outil d évaluation pseudo-subjective de qualité (Pseudo Subjective Quality Assessment, PSQA). En se concentrant sur l'architecture du réseau de distribution du contenu (Content Distribution Network, CDN), les auteurs ont ensuite proposé, dans [TMH, 11], une version modifiée de l algorithme QQAR nommée CDA-QQAR (Content Distribution Architecture using modified QQAR). Cet algorithme utilise la QoE comme une métrique pour sélectionner le meilleur serveur réplica et le mécanisme Anycast pour rediriger la requête de l utilisateur vers le serveur sélectionné. Ainsi, il comprend deux processus: (i) le processus d'apprentissage utilisé pour mettre à jour la table de routage dans chaque routeur du réseau basé sur la rétroaction QoE (la fonction de mise à jour est basée sur l'algorithme du Q-learning) et (ii) le processus de sélection utilisé pour déterminer la probabilité de sélection de chaque voisin pour transmettre le paquet de données. Les résultats expérimentaux ont montré que les deux algorithmes de routage proposés (QQAR, CDA-QQAR) donnent des améliorations significatives par rapport aux algorithmes traditionnels. Dans le cadre de ce travail, nous nous intéressons à ce dernier mécanisme de contrôle évolutif (routage adaptatif à base de la QoE dans les réseaux de distribution de contenus) à qui nous proposons dans le chapitre V une adaptation en suivant une nouvelle 59

60 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo approche. Notre protocole de routage de requêtes permettra en effet de rediriger la requête de l utilisateur au niveau de la phase résolution des noms (Domain Name System, DNS) vers le meilleur serveur réplica ayant la meilleure estimation de la QoE. Cette estimation de la QoE est faite, évidemment, par le modèle de corrélation QoE-QoS, que nous allons définir dans chapitre VI. 60

61 CHAPITRE II La Qualité D Expérience Propre aux Services Vidéo CONCLUSION Dans ce chapitre, nous avons fait un tour d horizon sur la notion de la QoE appliquée aux services vidéo. En premier, nous avons défini ce concept comme étant le degré de satisfaction de l utilisateur du service. Ensuite, nous avons passé en revue quatre modèles de métriques de la QoE pouvant être appliqués aux services vidéo. Ces modèles se basent sur la structure, la dimension, l indicateur ou l index de la QoE. Pour sa simplicité et sa popularité, nous avons choisi le modèle développé dans le TM Forum (KQI\KPI) pour définir notre propre modèle de métriques de la QoE. Puis, après avoir analysé les principaux modèles de corrélation entre la QoE et la QoS, nous avons choisi de travailler sur un modèle de corrélation de forme exponentiel considérant plusieurs paramètres de QoS. Enfin, nous avons abordé brièvement trois solutions intégrant la QoE : le système de gestion pour les services IPTV, le mécanisme adaptatif de streaming vidéo pour les réseaux de distribution de vidéo et le routage des requêtes dans les réseaux de distribution de contenus. C est à cette dernière solution que nous nous intéressons dans notre travail. Le chapitre suivant se veut être une synthèse sur les concepts nécessaires à la bonne compréhension du fonctionnement des réseaux de distribution de contenu, notamment le fonctionnement de leur système de routage des requêtes. 61

62 Chapitre III Le Routage des Requêtes dans les Réseaux de Distribution de Contenus INTRODUCTION Les fournisseurs des services vidéo sont appelés à satisfaire leurs clients (utilisateurs finaux) s'ils veulent rester en course. En effet, lorsque les utilisateurs d un service vidéo ne sont pas satisfaits de la qualité offerte, ils peuvent renoncer à l utilisation du service et passer à une autre offre concurrente en augmentant ainsi le taux d attrition (churn) du fournisseur de ces services. Le taux d attrition désigne le taux de perte des utilisateurs lié à l insatisfaction sur l offre ; son augmentation aboutit généralement à une éventuelle diminution de revenus du fournisseur. Par ailleurs, lors de l utilisation des services vidéo, les utilisateurs finaux s intéressent plus particulièrement à la disponibilité, au temps de réponse et à la qualité de vidéo du service. Les fournisseurs de ces services vidéo doivent garantir un niveau acceptable de la QoE, il est donc indispensable d'arriver à offrir des services avec (a) une haute

63 CHAPITRE III Le routage des Requêtes dans Les CDNs disponibilité, (b) un temps de réponse réduit et (c) une bonne qualité des flux vidéo. Du point de vue technique, (a) le serveur vidéo doit être en ligne (live), susceptible d avoir le contenu demandé et capable de le diffuser afin d offrir une haute disponibilité. Cette capacité de diffusion, dépend de la charge du serveur mesurée en termes de CPU, de mémoire, de capacité du disque et d utilisation du réseau. Si le serveur vidéo est seul à fournir ce contenu et qu il se trouve en situation du surcharge, le service sera alors indisponible momentanément. Une solution commune à ce problème est de répliquer le contenu sur plusieurs serveurs à des endroits présélectionnés afin de distribuer la charge entre l ensemble des serveurs et de rediriger ensuite l utilisateur vers le serveur le moins chargé. De plus, (b) comme le transfert de données constitue environ 80% du temps de réponse de la requête [SPV, 03], le contenu demandé doit être entreposé au plus prés de l utilisateur ou arriver à rediriger par un mécanisme adapté la demande de contenu vers le serveur le plus proche. Enfin, (c) et afin d obtenir une bonne qualité des flux vidéo, le serveur doit disposer d une bonne connectivité réseau assurant par exemple un taux de perte faible, une petite latence, une gigue minimale En général, le contenu est routé au travers du chemin le plus optimisé, ce dernier permet de réduire entre autres la latence, le taux de perte et l utilisation totale des ressources du réseau [ATW, 02]. Notons ici que les réseaux de distribution de contenu (Content Delivery Networks, CDN) offrent souvent aux fournisseurs de contenus cette dernière solution, qui permet combiner la réplication du contenu et la redirection des requêtes utilisateurs. Ce chapitre se veut être une synthèse sur les concepts nécessaires à la bonne compréhension du fonctionnement de ce type de réseaux (CDN). Pour cela, nous donnons un aperçu sur les CDNs. Nous nous intéressons ensuite au fonctionnement de leur Système de Routage des Requêtes (SRR) dans les sections II et III. Nous examinons enfin un exemple du SRR réellement déployé par l'entreprise Akamai, leader dans le marché des CDNs. 63

64 CHAPITRE III Le routage des Requêtes dans Les CDNs I. GENERALITES SUR LES RESEAUX DE DISTRIBUTION DE CONTENUS Un réseau de distribution de contenu (Content Distribution Network, CDN), est une collection collaborative des éléments du réseau couvrant le réseau Internet, où le contenu d un serveur d origine est répliqué (ou reproduit) sur plusieurs serveurs, appelés serveurs réplica, qui sont répartis dans le monde entier à proximité des utilisateurs terminaux [PBV, 08]. D après cette définition, le contenu peut se référer à toutes les ressources de données numériques. Il se compose de deux parties principales: les données eux-mêmes (documents, page web, images, audio et vidéo) et les données qui les décrivent (les métadonnées). Ces dernières permettent d'identifier, de trouver et de gérer les données, et facilitent également leur interprétation [PGM, 06]. Le serveur d origine détient la version définitive du contenu. Il est mis à jour par le fournisseur de contenu. Les serveurs réplica, appelés aussi serveurs du bord (edge servers) ou serveurs de remplacement (surrogates), gardent une copie du contenu et agissent comme une référence qui fait autorité pour les réponses au client. Ils peuvent être des serveurs média (vidéo et/ou audio), des serveurs web ou simplement des serveurs cache [PAB, 07]. Les utilisateurs finaux sont les entités qui ont accès au contenu du serveur d origine. La figure III.1. montre un exemple de CDN. Figure III.1. Un modèle de réseau de distribution de contenu. Dans le reste de cette section, nous décrivons l architecture générale d un CDN. Nous abordons ensuite brièvement les principaux problèmes liés à la conception du CDN. Pour illustrer nos propos, un CDN orienté streaming est présenté en fin de cette section. 64

65 CHAPITRE III Le routage des Requêtes dans Les CDNs I.1. L Architecture Générale d un CDN L'architecture générale d'un CDN se compose de six éléments ou composants de base: les clients, les serveurs réplica, le serveur d origine, le Système de Distribution du Contenu (SDC), le Système de Routage des Requêtes (SRR) et le Système de Comptabilité (SC). La figure III.2. présente un schéma très simplifié de cette architecture où les relations entre ses composants peuvent être résumées comme suit [GCT, 01] [KMS, 02] [MRP, 04]: - Le serveur d'origine publie le contenu qui doit être distribué et livré par le SDC dans le CDN et délègue l URL (Uniform Resource Locator) de ce contenu au SRR. - Le Système de Distribution du Contenu (SDC) réplique le contenu du serveur d'origine vers un ou plusieurs serveurs réplica. Il interagit avec le SRR pour l informer de la disponibilité du contenu dans les différents serveurs réplica. De plus, il interagit avec le SC pour l'informer de l'activité de distribution du contenu pour que ce dernier puisse mesurer le volume de distribution de contenu. - Le client effectue une demande de contenu qu'il perçoit comme étant dans le serveur d'origine. Cette demande (ou requête) est interceptée par le SRR. - Le Système de Routage des Requêtes (SRR) redirige la requête du client au serveur réplica approprié dans le CDN. Il interagit ainsi avec le SC pour l informer de la livraison du contenu aux clients. Il arrive aussi qu il interagisse avec le SDC pour l informer de la demande du contenu afin de placer le contenu dans les serveurs réplica. - Le serveur réplica sélectionné fournit alors le contenu demandé au client. Il informe par ailleurs le SC par retour d information (feedback) du contenu transmis. - Le Système de Comptabilité (SC) collecte les données à partir du SRR, du SDC et des serveurs réplica pour les formuler ensuite dans des rapports statistiques. Celles-ci sont utilisées comme une base d informations pour la facturation des biens et d'obligations entre les opérateurs de CDN et les fournisseurs de contenus. Elles servent aussi comme un retour d'informations pour le SRR. 65

66 CHAPITRE III Le routage des Requêtes dans Les CDNs Figure III.2. L architecture générale d un CDN [GCT, 01]. I.2. Les Principaux Problèmes liés à la Conception d un CDN Concevoir une solution complète pour un CDN efficace nécessite d aborder un certain nombre de problèmes techniques, et notamment: le problème de placement des serveurs réplica, les problèmes liés à la distribution du contenu (où et comment distribuer le contenu à travers les serveurs réplica?) et les problèmes liés au routage des requêtes (comment choisir le meilleur serveur réplica et rediriger les requêtes vers celuici?). Dans la littérature, plusieurs travaux de recherche ont été proposés dans le but de résoudre ces problèmes. Dans ce qui suit, nous décrivons brièvement ces problèmes en citant les principaux travaux dans le domaine. I.2.1. Le Problème du Placement des Serveurs Réplica Le problème du placement des serveurs réplica consiste à trouver le meilleur emplacement dans le réseau afin de positionner les serveurs réplica de façon à minimiser la latence, la consommation de bande passante et le nombre de serveurs réplica utilisés [VAP, 06]. Plusieurs algorithmes ont été proposés pour résoudre ce problème, comme l algorithme à base d arbre [LGI, 99], l algorithme de Glouton [RGE, 01] qui positionne progressivement des serveurs réplica et l algorithme Hot Spot [QPV, 01] qui met les serveurs réplica à proximité des clients générant plus de charge. Ces algorithmes spécifient l'emplacement des serveurs réplica afin de réaliser de meilleures performances avec des coûts d'infrastructure faible. L expérimentation a montré que l algorithme de Glouton donne les meilleures performances [QPV, 01]. I.2.2. Les Problèmes du Système de Distribution du Contenu Les principaux problèmes liés à la distribution du contenu se résument dans les problèmes de placement et de délivrance du contenu. Le problème de placement consiste 66

67 CHAPITRE III Le routage des Requêtes dans Les CDNs à choisir le serveur réplica dans lequel le contenu sera stocké de façon à minimiser la charge du serveur réplica et/ou à équilibrer la charge entre l ensemble des serveurs réplica. En général, les algorithmes utilisés pour sélectionner le placement des serveurs peuvent aussi être utilisés pour résoudre ce problème et l algorithme de Glouton reste le meilleur [ZHL, 05]. Pour le problème de délivrance, deux approches existent [KMS, 02]: réactive et proactive. Avec l approche réactive (connue souvent sous le terme anglais pull), le contenu est récupéré du serveur d origine lors de l arrivé d une requête client sur le serveur réplica. C est la technique traditionnelle déployée pour les proxy-cache. Elle permet d économiser la bande passante et d assurer ainsi un niveau élevé de cohérence. Cependant, elle augmente le temps de réponse de la requête du client. C est pourquoi, avec l approche proactive (push), le contenu est délivré à priori en anticipant les requêtes du client tout en évitant de surcharger le serveur d origine. Nous tenons aussi à préciser que le contenu peut être entièrement ou partiellement reproduit dans les serveurs réplica. En effet, il est préférable parfois de partitionner un contenu de grand volume, comme les fichiers multimédia, sur plusieurs serveurs réplica qui sont limités par leurs capacités de stockage et de traitement. Cependant, la gestion de cette dernière approche (connue sous le terme anglais Partial-Site) est plus complexe que la gestion de l approche traditionnelle (Full-Site) où le contenu en entier est répliqué dans les serveurs réplica [PAB, 08]. I.2.3. Les Problèmes du Système de Routage des Requêtes Lors du routage des requêtes dans le CDN, il est nécessaire de sélectionner d abord le meilleur serveur réplica parmi l ensemble des serveurs réplica disponibles, de rediriger ensuite cette requête vers ce meilleur serveur. La sélection prend en compte différents critères : la distance entre le client et le serveur réplica (nombre de saut, la latence, ), la charge des serveurs réplica disponibles, etc. Une fois le meilleur serveur choisi, la requête sera redirigée vers lui par un mécanisme approprié de routage : redirection HTTP, redirection DNS, Anycast,. Ces mécanismes ainsi que les algorithmes de sélection existants sont détaillés dans les sections II et III de ce chapitre. Il est à préciser ici que la conception du système de distribution du contenu (SDC) a un impact direct sur la conception du système de routage des requêtes (SRR). En effet, si le contenu en entier est répliqué sur les serveurs réplica (l approche Full-Site), le SRR dirige directement les requêtes des clients vers le meilleur serveur réplica. Dans le cas contraire (l approche Partial-Site), le SRR est conçu de telle façon qu à la réception de la requête du client, il reçoit, de la part du SDC, la liste contenant toutes les parties du contenu et leurs emplacements dans les serveurs réplica. Le SRR redirige la requête du 67

68 CHAPITRE III Le routage des Requêtes dans Les CDNs client vers plusieurs meilleurs serveurs réplica ayant chacun une partie du contenu [PAB, 08]. En outre, dans le mode Pull, le SRR interagit également avec le SDC pour l informer du résultat de sa sélection afin de placer ou mettre à jour le contenu dans le serveur réplica sélectionné [KMS, 02]. I.3. Les Réseaux de Distribution du Contenu en Streaming Les CDNs ont été originalement conçus pour distribuer des contenus très demandés à partir des serveurs web les plus populaires. Aujourd'hui, la plupart des CDNs supportent le streaming média, i.e. la livraison et la lecture simultanées de contenus média (vidéo/audio). Ces CDNs sont connus sous le nom de SCDNs (Streaming CDNs) pour les réseaux de distribution de contenu en streaming. Certains SCDNs sont explicitement conçus pour offrir le média en streaming tels que PRISM [CGK, 01], VCDN [CAS, 03], MarconiNet [DSY, 99] ou EdgeStream 8. D autres SCDNs à usage général supportent tout type de contenu, y compris le contenu média comme Akamai 9, Limelight Networks 10 ou MirrorImage 11. Comparativement aux CDNs traditionnels (supportant seulement la livraison des pages web), les SCDNs imposent plus de contraintes [ATW, 02]: - Une page web est un élément relativement léger, de l'ordre de 10 kilooctets. Elle peut donc être répliquée dans son intégralité sur chaque serveur choisi. Par contre, les contenus de type média (comme les films) ont une longue durée et nécessitent une quantité importante de stockage, de l'ordre de quelques mégaoctets à quelques giga-octets. Il n'est donc pas pratique ou souhaitable de répliquer un flux média en entier sur chaque serveur choisi. Le contenu média est alors partitionné en plusieurs parties ou segments, et seulement une portion du média est mise sur un serveur. - Le transfert des flux streaming sur le réseau Internet imposent des contraintes très fortes en termes de QoS. Par exemple, si la congestion et la perte de paquets conduisent à un délai de quelques secondes dans la livraison d'une page web (ce qui est souvent acceptable), leur effet par

69 CHAPITRE III Le routage des Requêtes dans Les CDNs contre sur une session de streaming des médias peut poser problème (interruptions et plusieurs artefacts). - L interaction client-serveur pour un SCDN implique une session RTP/UDP très longue à l opposée du CDN conventionnel qui implique une (ou plusieurs) session (s) HTTP / TCP plus courte (s) (de l ordre d une fraction de seconde). Il est donc parfois nécessaire d'effectuer une opération de transfert intercellulaire en plein milieu d une session RTP (midstream handoff). Cela consiste à solliciter un autre serveur sans interruption de service afin d équilibrer la charge entre les serveurs streaming. II. LA SELECTION DU MEILLEUR SERVEUR REPLICA Le fonctionnement du Système de Routage des Requêtes (SRR) consiste d abord à sélectionner le meilleur serveur réplica qui pourra satisfaire la demande du client, et ensuite, à réorienter cette demande vers ce meilleur serveur par un mécanisme de redirection comme la redirection HTTP, la redirection DNS, etc. Dans cette section, nous nous intéressons seulement au principe de sélection du meilleur serveur réplica. La section III est consacrée aux mécanismes de routage. Les algorithmes de sélection du serveur réplica permettent de sélectionner le serveur vers lequel un client donné doit être redirigé [SPV, 03]. La sélection peut être aléatoire [DEL, 99] ou faite en fonction de plusieurs métriques liées à la performance du CDN. Ces métriques peuvent être classées en deux catégories : celles caractérisant l état du réseau entre le client et le serveur réplica comme le nombre de sauts (la proximité topologique), les informations de routage BGP (la proximité géographique), la latence, le taux de perte (la fiabilité), la bande passante disponible, et celle caractérisant l état de charge du serveur réplica qui peut être calculée en fonction de la charge CPU, de la charge d'interface réseau, du nombre de connexions actives ou encore la charge des entrées sorties de stockage [BCT, 04]. Notre approche consiste à utiliser, non pas une seule métrique, mais la combinaison de plusieurs de ces métriques : la latence, le taux de perte et la charge du serveur réplica. Notre algorithme de sélection prendra en compte ces trois métriques à travers le modèle de corrélation entre la QoS et la QoE que nous allons définir dans le chapitre IV. II.1. Les Techniques d Acquisition des Critères de Sélection Les métriques considérées pour une bonne analyse de la QoE/QoS proviennent des CDNs à partir de différentes statistiques relevées par le biais d'un certain nombre de 69

70 CHAPITRE III Le routage des Requêtes dans Les CDNs techniques comme: l enquête active, la surveillance passive et la rétroaction des serveurs réplica. Ces techniques sont présentées dans les paragraphes suivants. II.1.1. Enquête Active du Réseau La technique appelée «enquête active du réseau» [BCT, 04] est une technique de mesure où des enquêtes ou des interrogations (probing) sont envoyées périodiquement aux ou à partir des serveurs réplicas afin de relever leurs performances. Un exemple typique de ces enquêtes est un message d écho ICMP envoyé périodiquement du serveur réplica au client désirant le contenu dans l objectif de mesurer une performance liée au chemin suivi par les flots au travers du réseau. Nous noterons ici que l avantage principal de cette technique est celle de ne nécessiter aucune modification coté serveur. Cependant, elle introduit une latence supplémentaire qui pourra être importante si les enquêtes sont effectuées fréquemment. De plus, enquêter peut parfois conduire à une métrique inexacte comme par exemple celle inhérente au trafic ICMP qui peut être ignoré ou serait moins prioritaire en raison des choix du client, d'où un temps erroné. II.1.2. Surveillance Passive du Réseau La surveillance passive du trafic [BCT, 04] est une technique de mesure dans laquelle le trafic entre le client et le serveur réplica est surveillé en continu pour avoir en retour des mesures de performances réelles. Une fois le client connecté, la performance du transfert est mesurée (bande passante, délai, taux de perte, ). Ces données sont ensuite réinjectées dans le système de routage des requêtes. Un exemple d application de cette technique est le mode Server Push [FBZ, 98] où le serveur réplica est modifié de telle sorte qu il permette d envoyer les performances du transfert seulement lorsque des changements intéressants sont observés. Les principaux avantages de cette technique sont l'évolutivité et la précision des mesures du serveur, tandis que, la modification des serveurs et l'absence de mesure de la route en constituent les principaux inconvénients. II.1.3. Rétroaction des Serveurs Réplica La rétroaction (Feedback) des serveurs réplica [BCT, 04] peut être obtenue en effectuant des enquêtes actives du réseau sur les serveurs réplica par l'émission de requêtes spécifiques destinées aux applications. Elle peut être obtenue également auprès des agents de monitoring déployés dans les serveurs réplica amenés à communiquer un rapport de rétroaction. Celui-ci contient une variété de métriques liées à la performance du réseau et des serveurs. La rétroaction a été souvent utilisée pour surveiller la charge des serveurs réplica [BCN, 03]. 70

71 CHAPITRE III Le routage des Requêtes dans Les CDNs Nous pensons que la rétroaction des serveurs réplica constitue une bonne technique d acquisition des métriques de sélection du meilleur serveur ainsi qu un bon moyen pour surveiller l état du CDN, y compris les serveurs réplica. En effet, elle peut combiner les deux techniques (l enquête active et la surveillance passive) de manière complémentaire afin d obtenir des mesures plus précises. De plus, le rapport de rétroaction contenant plusieurs mesures de métriques de performance, peut être envoyé à des intervalles réguliers (périodiques) ou irréguliers (lorsque des changements intéressants sont observés) selon le besoin. Notre protocole de méta-routage est basé sur la rétroaction de la QoE estimée qui contient plusieurs métriques (la latence, le taux de perte et la charge de serveur). Ce rapport de rétroaction est envoyé initialement pour aider à sélectionner le meilleur serveur réplica, il est ensuite envoyé au travers des feedbacks du RTCP pour permettre de s adapter à l état actuel du CDN. II.2. Classification des Algorithmes de Sélection Les algorithmes de sélection peuvent être adaptatifs ou non adaptatifs [PAB, 08]. Ceux de la première catégorie considèrent l'état actuel du CDN pour sélectionner un serveur réplica. L'état actuel du CDN est obtenu par l'estimation de certaines mesures comme la charge des serveurs réplica ou la congestion des liaisons du réseau sélectionné. Par ailleurs, les algorithmes adaptatifs ont la capacité de changer leurs comportements pour faire face à une situation durable, ce qui les rendent plus complexes que les algorithmes non-adaptatifs. Ces derniers utilisent des heuristiques pour sélectionner un serveur réplica plutôt que de considérer l'état du système actuel. Ils sont faciles à mettre en œuvre et fonctionnent efficacement lorsque les hypothèses faites par les heuristiques sont remplies. Au regard de sa simplicité, l algorithme non-adaptatif le plus connu est celui fonctionnant avec la technique du round-robin. Cet algorithme distribue toutes les requêtes des clients vers les serveurs réplica du CDN et tente d'équilibrer la charge entre eux [SZY, 02]. Il suppose que tous les serveurs réplica ont la même capacité de traitement et que l'un d'eux peut servir tout type de demande du client. Cet algorithme est efficace pour les clusters, où tous les serveurs réplica sont situés au même endroit [PAB, 98]. Cependant, il est inefficace dans le cas où les serveurs réplica sont situés à des endroits éloignés. En effet, il ne considère pas la distance entre les serveurs réplica et les clients et il peut ainsi rediriger un client vers un serveur réplica plus éloigné entraînant ainsi des performances médiocres perçues par les clients terminaux. De plus, l'équilibrage de charge entre les serveurs réplica n'est pas pleinement atteint, le traitement des 71

72 CHAPITRE III Le routage des Requêtes dans Les CDNs différentes demandes peut en effet impliquer significativement différents coûts de calcul [PAB, 08]. DistribuedDirector [DEL, 99] est une solution propriétaire Cisco qui met en œuvre différents types d algorithmes de sélection adaptatifs et non adaptatifs. Parmi les algorithmes non-adaptatifs, on trouve celui qui considère le pourcentage des requêtes des clients que chaque serveur réplica reçoit. Un serveur recevant davantage de requêtes est supposé être plus puissant. Par conséquent, les demandes des clients sont dirigées vers les serveurs les plus puissants pour atteindre une meilleure utilisation des ressources. Cependant, les serveurs les plus puissants ne sont pas forcément situés dans des endroits proches des utilisateurs. Un autre algorithme non-adaptatif considère la proximité géographique du client pour rediriger les requêtes vers le serveur réplica le plus proche. Cet algorithme souffre du fait que les demandes des clients peuvent être affectées à des serveurs réplica surchargés pouvant ainsi dégrader les performances perçues par le client. La technique DistributedDirector utilise aussi un algorithme de sélection adaptatif qui prend en compte une combinaison pondérée de trois indicateurs, à savoir la distance inter-as (le nombre des systèmes autonomes (Autonomous System, AS) traversés), la distance intra-as (le nombre de sauts traversés), et la latence de bout en bout. Bien que cet algorithme soit souple du fait qu il permet l'utilisation des trois métriques, le déploiement d'un agent dans chaque serveur réplica pour mesurer ces métriques le rend complexe et coûteux. De plus, les techniques actives utilisées par cet algorithme pour mesurer la latence introduisent un trafic supplémentaire [PAB, 08]. Dans [AFN, 01] et [ASS, 02], les auteurs ont proposé des algorithmes de sélection adaptatifs basés sur la latence client-serveur. Cette latence mesurée passivement au niveau de serveur, est utilisée pour sélectionner le serveur réplica ayant la plus petite latence récemment signalée. Toutefois, ces algorithmes exigent le maintien d une base de données centrale contenant les différentes mesures de la latence limitant ainsi l'évolutivité des systèmes sur lesquels ces algorithmes sont déployés [SSP, 04]. La tendance actuelle s oriente de plus en plus vers les algorithmes adaptatifs qui modifient leurs comportements en fonction de l état du CDN pour faire face à une situation durable. Dans notre protocole de méta-routage, nous proposons un algorithme de sélection adaptatif basé sur la QoE afin de maintenir un bon niveau de performances perçues au niveau du client. 72

73 CHAPITRE III Le routage des Requêtes dans Les CDNs III. LES MECANISMES DE REDIRECTION DES REQUETES Les mécanismes de redirection ou de routage informent le client du résultat de la sélection en indiquant le serveur réplica choisi amené à satisfaire sa requête. Plusieurs mécanismes de redirection de requête existent. Ils peuvent être classés selon plusieurs critères. Dans ce travail, nous avons choisi volontairement de les classer selon la couche TCP\IP où ils opèrent. Cette classification est simple à utiliser et facile à développer. Comme la montre la figure III.3, nous trouvons des mécanismes qui opèrent au niveau de la couche application, de la couche transport ou encore de la couche réseau. Chacun de ces mécanismes, voire une combinaison de ceux-ci, peuvent être utilisés dans un seul CDN. Par la suite, nous décrivons les mécanismes de redirection de requêtes en présentant leurs avantages et leurs limites. Figure III.3. Les mécanismes de redirection de requête. III.1. Les Mécanismes Opérant au niveau de la Couche Application Plusieurs mécanismes de redirection de requêtes opèrent au niveau de la couche d application. Certains utilisent un protocole spécifié comme HTTP ou DNS et d autres sont utilisés avec tout protocole comme la réécriture URL et la technique dite anycast. III.1.1. La Redirection HTTP La redirection HTTP propage l information sur les ensembles des serveurs réplica dans les en-têtes HTTP [PAB, 08]. Les protocoles HTTP permettent à un serveur web de répondre à une demande du client avec un message spécial qui indique au client de soumettre à nouveau sa demande à un autre serveur. La redirection HTTP peut être utilisé à la fois pour la distribution de contenus en Full-Site et en Partial-Site. Elle peut aussi être utilisée pour construire un serveur web spécial, qui accepte les demandes des clients, choisit les serveurs réplica et redirige les clients vers ces serveurs. Le principal avantage de ce mécanisme est sa flexibilité et sa simplicité du fait qu il utilise le protocole HTTP. En outre, la réplication peut être gérée avec une granularité fine, chaque page web peut en effet être considérée comme un granule [PEN, 08]. 73

74 CHAPITRE III Le routage des Requêtes dans Les CDNs Néanmoins, l'inconvénient le plus important de la redirection HTTP est le manque de transparence. En effet, du fait qu elle fait une redirection visible pour les clients, ces derniers considèrent ce procédé comme indésirable [SPV, 03]. Par ailleurs, la surcharge générée par cette approche est importante, elle introduit en effet un message aller-retour supplémentaire dans le traitement des requêtes ainsi que sur le protocole HTTP [PAB, 08]. III.1.2. La Réécriture URL La réécriture URL, appelée aussi la modification du contenu, est principalement utilisée dans le cas où le contenu est partiellement répliqué sur les serveurs réplica (approche dite Partial-Site) [BCN, 03]. Ainsi, le serveur d'origine redirige les clients vers différents serveurs réplica par la réécriture des liens URL dans les pages générées dynamiquement. Par exemple, avec une page web contenant un fichier HTML et des objets incorporés, le serveur web peut modifier les références des objets incorporés afin que le client puisse les récupérer à partir des meilleurs serveurs réplica. Pour automatiser ce processus, des scripts spéciaux analysent de manière transparente le contenu des pages web et remplacent les URL incorporées [KWZ, 01]. La réécriture URL peut être proactive ou réactive [PAB, 08]. Dans la réécriture URL proactive, les URL pour les objets incorporés de la page HTML principale sont formulées avant que le contenu ne soit chargé dans le serveur d'origine. L'approche réactive consiste à réécrire l'url des objets incorporés lorsque la demande du client atteint le serveur d'origine. Comme les URL réécrites contiennent des noms des meilleurs serveurs réplica, le principal avantage de cette technique réside dans le fait que les clients sont liés à plusieurs serveurs réplica et non pas un seul serveur réplica comme dans les autres mécanismes de redirections. De plus, le niveau de granularité peut être atteint étant donné que les objets incorporés peuvent être considérés comme des granules. Cependant, la réécriture URL peut surcharger le serveur d origine et ainsi causer du retard lors de redirection des requêtes [PAB, 08]. III.1.3. La Redirection DNS La redirection DNS consiste à utiliser un serveur DNS local personnalisé (modifié) pour répondre aux requêtes de résolution de noms avec l'adresse IP du meilleur serveur réplica plutôt qu'avec celle du serveur d'origine [SPV, 03]. En effet, lorsque l utilisateur envoie une requête DNS au serveur DNS local, ce dernier la transmet au SRR du CDN (qui peut être un autre serveur DNS) au lieu de déclencher la résolution DNS comme cela se fait habituellement. Ensuite, le SRR interroge chaque serveur réplica, en leur demandant d'examiner la performance de leur chemin avec le serveur DNS local. Chaque 74

75 CHAPITRE III Le routage des Requêtes dans Les CDNs serveur réplica reporte les résultats des mesures effectuées à son niveau permettant ainsi au SRR de sélectionner le serveur réplica le plus approprié. Enfin, le SRR envoie une réponse DNS, contenant l adresse IP du serveur réplica choisi, au serveur DNS local qui la transmet ensuite à l'utilisateur [VAP, 06]. Ce mécanisme fonctionne bien lorsque le contenu en entier est répliqué dans les serveurs réplica (approche Full-Site). En revanche, avec l approche Partial-Site, la redirection DNS est souvent combinée avec la réécriture URL de telle manière que le serveur DNS local dirige d abord la requête vers le serveur d origine, ensuite, vers les meilleurs serveurs réplica contenant les objets incorporés. La redirection DNS est simple, transparente et évolutive. En raison de ces avantages, une majorité de réseaux CDN l utilise comme un mécanisme de routage des requêtes [SPV, 03]. Cependant, cette version basique de la redirection DNS possède plusieurs limites [PAB, 08] [BCN, 03]. D une part, elle augmente la latence du réseau en raison de l'augmentation du temps de résolution DNS. Pour résoudre ce problème, les administrateurs du CDN divisent leur DNS en deux niveaux (DNS de bas niveau et DNS de haut niveau) pour répartir la charge [KWZ, 01]. D autre part, la sélection du meilleur serveur réplica se base sur la proximité des serveurs réplica du serveur DNS local plutôt que sur leur proximité géographique du client terminal. Ainsi, lorsque le client et le serveur DNS local ne se trouvent pas à proximité, la redirection DNS peut rediriger le client vers le serveur réplica plus éloigné entraînant ainsi des performances médiocres perçues par ce client terminal. Par ailleurs, le DNS local peut ne pas être invoqué pour contrôler toutes les requêtes entrantes en raison de la mise en cache de données DNS à la fois au niveau du fournisseur d'accès internet et du client. En effet, le serveur DNS local peut avoir le contrôle sur 5% des demandes dans de nombreux cas [CCC, 02].En dernier, au regard du fait que les clients n'ont pas accès aux noms de domaine réel qui servent leurs demandes, cela peut conduire à l'absence de tout autre serveur pour répondre aux demandes du client en cas de panne du serveur réplica cible. Ainsi, afin de continuer de répondre aux conditions changeantes du réseau ou du serveur, la redirection DNS doit éviter le cache ou les décisions au niveau du client [PAB, 08]. III.1.4. La Technique de l Anycast La technique dite Anycast est un service réseau du protocole IP applicable aux situations dans lesquelles un utilisateur souhaite localiser un hôte (un serveur) qui prend en charge un service particulier et que ce service est répliqué sur plusieurs serveurs [PMM, 93]. Comme nous allons voir dans la sous-section III.3, la technique Anycast IP possède plusieurs lacunes notamment lorsqu elle route les datagrammes vers le serveur réplica le plus proche sur la base de métriques de routage comme le nombre de sauts. 75

76 CHAPITRE III Le routage des Requêtes dans Les CDNs Pour pallier à cela, des chercheurs ont proposé d opérer le concept Anycast à un plus haut niveau (couche application) afin de pouvoir manipuler d autres métriques de sélection comme la charge du serveur [PEN, 08]. Dans ce contexte, Fei et al. [FBZ, 98] ont proposé un mécanisme Anycast au niveau de la couche application dans lequel le service est composé d'un ensemble de résolveurs Anycast. Ces résolveurs font la correspondance entre un nom de domaine Anycast (Anycast Domain Name, ADN) et une ou plusieurs adresses IP. En effet, un ADN identifie de manière unique une collection des adresses IP (potentiellement dynamique) qui constitue un groupe Anycast. Les clients interagissent avec les résolveurs Anycast en générant une requête Anycast. Une base de métriques, associée à chaque résolveur Anycast, contient les mesures de performance (la charge et la capacité de traitement des requêtes) des serveurs réplica. Ces données de performance peuvent être utilisées pour sélectionner le meilleur serveur réplica en se basant sur des critères de sélection spécifiées par l'utilisateur. Ce mécanisme de routage donne une meilleure flexibilité. Par contre, il nécessite des modifications au niveau des serveurs réplica ainsi qu au niveau des clients. Compte tenu du nombre potentiellement important de serveurs et de clients, il peut par conséquent conduire à l'augmentation des coûts. D autres mécanismes Anycast au niveau de la couche application se trouvent dans [PEN, 08]. III.2. Les Mécanismes Opérant au niveau de la Couche Transport Dans ces mécanismes [BCN, 03], le premier paquet de demande du client sera envoyé au serveur d origine qui le retransmet au SRR. Celui-ci inspecte ensuite les informations disponibles dans ce premier paquet (l'adresse IP du client, le numéro du port et le protocole de la couche transport) pour sélectionner le serveur réplica approprié. Toutefois, les mécanismes de routage de la couche transport sont généralement combinés aux mécanismes à base de DNS de telle sorte que le premier paquet de demande du client sera d abord envoyé au serveur réplica initialement choisi par le DNS. Le SRR décide ensuite s il raffinera son choix en relançant le processus de sélection avec plus de précision. Ils sont mieux adaptés aux longues sessions comme les sessions FTP et RTSP. A contrario, ils pourraient également rediriger le client vers des serveurs réplica surchargés. III.3. Les Mécanismes Opérant au niveau de la Couche Réseau Le seul mécanisme utilisé opérant au niveau IP est celui basé sur la technique dite Anycast IP proposé par Partridge et al [PMM, 93]. Avec ce mécanisme, une adresse IP (appelée adresse Anycast) est attribuée à un ensemble de serveurs réplica et chaque 76

77 CHAPITRE III Le routage des Requêtes dans Les CDNs routeur IP détient un chemin dans sa table de routage pour le serveur réplica le plus proche de ce routeur. Lors de l envoi de la requête du client, les datagrammes sont routés vers un seul serveur réplica, généralement le plus proche, selon la politique de routage. Ainsi, la sélection du serveur réplica se fait implicitement (de manière transparente) au sein des routeurs et l efficacité du critère de sélection dépend de l'efficience des métriques de routage. La technique Anycast IP vise la réplication à l échelle du réseau des serveurs réplica sur des plates-formes potentiellement hétérogènes [PAB, 08]. Cependant, il possède certains inconvénients notamment [BCN, 03]: - des parties de l'espace d'adresses IP sont allouées aux adresses Anycast. - typiquement, les protocoles de routage ne sont pas sensibles à la charge du réseau. Ainsi, le serveur réplica le plus proche peut-être celui avec une longue latence réseau. - la charge du serveur n'est pas considérée durant le routage de la requête. III.4. Discussion Chaque mécanisme de redirection des requêtes possède des avantages et des inconvénients. Pour y retrouver, nous avons analysé nos exigences et procédé par élimination comme suit: - Le contenu doit être un contenu média, particulièrement une vidéo. Ainsi, la redirection HTTP pourra être écartée de nos choix. - Si nous supposons que le contenu (la vidéo) en entier est répliqué dans les serveurs vidéo, alors nous n aurons pas besoin de la réécriture URL. - La transmission des paquets vidéo impose des contraintes très fortes en termes de QoS réseau : la bande passante, la latence, le taux de perte, etc. Comme la technique Anycast IP offre généralement un service BE (Best Effort) où tous les paquets suivent la même politique et leur acheminement est effectué de proche en proche, cette technique sera aussi écartée. - Comparant la technique Anycast au niveau de la couche application avec la redirection DNS, les deux mécanismes se basent sur des résolveurs des noms pour rediriger les clients vers le meilleur serveur réplica. La technique Anycast exige des modifications au niveau des serveurs réplica et des clients afin de traiter les requêtes des résolveurs Anycast. En contrepartie, la résolution DNS se fait de manière transparente et automatique au niveau des clients. De plus, elle est plus simple et 77

78 CHAPITRE III Le routage des Requêtes dans Les CDNs évolutive. Pour cela, nous optons pour la redirection DNS afin d orienter l utilisateur final vers le serveur réplica sélectionné. Nous avons par ailleurs choisi un autre mécanisme d insertion de DNS. En fait, comme le montre la figure III.4, il existe deux façons d insérer le serveur DNS [BEL, 01] : soit en déléguant le DNS Local (la plus utilisée), soit en interceptant la requête en périphérie. Avec la délégation du DNS Local, ce dernier retransmet la requête de résolution de nom au SRR qui n est qu un autre serveur DNS appelé le serveur DNS- CDN. Par ailleurs, avec le deuxième mécanisme d insertion, la requête de résolution de nom est interceptée d abord par le serveur DNS-CDN qui vérifie que le contenu demandé est disponible dans au moins un serveur réplica du CDN. Si ce n est pas le cas, il retransmet cette requête au serveur DNS local. Nous avons penché pour ce deuxième mécanisme d insertion, qui a été utilisé dans [MSD, 06], afin de surmonter quelques limites de la version basique du mécanisme DNS. En effet, il permet d éviter le cache du DNS local et de prendre en compte la proximité du client de serveurs réplica lors de la sélection du meilleur serveur réplica. De plus, ce mécanisme est facile à implémenter et ne nécessite pas de modifier le fonctionnement habituel du DNS local. Figure III.4. Les mécanismes d insertion du CDN. IV. UN EXEMPLE D UN SYSTEME DE ROUTAGE DE REQUETE: AKAMAI Après avoir présenté les principes de base des algorithmes de sélection du meilleur serveur réplica ainsi qu un panorama des mécanismes de redirection des requêtes, il sera intéressant d examiner une implémentation réelle d un SRR dans un CDN donné. Pour ce faire, nous avons choisi le leader des CDNs : Akamai. 78

79 CHAPITRE III Le routage des Requêtes dans Les CDNs Akamai est l un des CDNs commerciaux les plus réussis, qui met à la disposition de ses clients une plate-forme de serveurs distribués mondialement. En 2008, cette plateforme était constituée de 36,000 serveurs, contrôlés par des logiciels propriétaires et répartis dans 950 réseaux individuels à travers 70 pays 12. Ces serveurs réplica délivrent tout type de contenu : statique 13 (e.g des pages HTML, des images incorporés, des contenus exécutables et des documents PDF), dynamique 14 (e.g. des animations, des scripts et pages DHTML), et média (audio/vidéo) en streaming. Akamai propose deux types de livraison de services [PJL, 03]: livraison de site (Full- Site) et livraison d objets (Partial-Site). Avec la livraison de site, les serveurs Akamai répliquent a priori le contenu complet (relativement statique) des sites originaux : c est l approche Full-Site en mode Push. D autre part, avec la livraison des objets, les serveurs Akamai répliquent à la demande des objets de sites originaux ; c est l approche Partial- Site en mode Pull. Ce mode de livraison est conçu pour offrir un contenu très dynamique de telle sorte que les fournisseurs du contenu utilisent le logiciel propriétaire Akamai, nommé Akamaizer, pour réécrire l'url dans leurs sites web. Ensuite, les serveurs d'akamai récupèrent et cachent des objets incorporés, tels que des icônes, des images, des photos et des clips audio/vidéo, pour les livrer directement aux utilisateurs. Si un objet demandé est manquant dans un serveur réplica, une nouvelle demande est générée à partir du serveur désigné pour le serveur d'origine, ou à d'autres serveurs Akamai dans la hiérarchie. IV.1. La Redirection DNS [PEN, 08] Autre que le mécanisme de réécriture URL, Akamai utilise son propre système DNS implémenté comme une hiérarchie à deux niveaux de serveurs DNS: en 2000, 50 serveurs DNS de haut niveau (High-Level DNS, HLDNS) et 2000 serveurs DNS de bas niveau (Low-Level DNS, LLDNS). Comme le montre la figure III.5, lorsqu'un navigateur effectue une requête de résolution de nom (par exemple a7.g.akamai.net), (1) il contacte Le contenu statique ne change pas au fil du temps comme les images et les fichiers PDF. 14 Le contenu dynamique est généré dynamiquement en fonction de l'emplacement de l'utilisateur, l historique ou la nature de la demande elle-même dont le but de personnaliser l'expérience de navigation (site web) des utilisateurs. 79

80 CHAPITRE III Le routage des Requêtes dans Les CDNs d abord son serveur DNS local, en lui demandant de résoudre le nom du serveur. En absence d'une réponse en cache, le serveur DNS local résout le nom du serveur en utilisant des requêtes DNS itératives. (2) Il contacte donc le serveur racine (.net), qui (3) répond avec une liste de serveurs HLDNS d Akamai (akamai.net). Ensuite, (4) le serveur DNS local contacte un de ces serveurs HLDNS et (5) il reçoit une liste de serveurs LLDNS (g.akamai.net) qui sont proches de lui. Puis, (6) il contacte l'un des serveurs LLDNS, qui (7) renvoie les adresses IP du meilleur serveur réplica pour cette demande. Enfin, (8) le serveur DNS local retourne l adresse IP au navigateur requérant, qui (9) récupère le contenu du serveur. En plus de ce mécanisme de redirection DNS, la figure III.5 montre aussi le temps de vie (Time To Live, TTL) du cache de chacun des serveurs DNS. En effet, le système DNS d Akamai permet la mise en cache des réponses DNS, tout comme dans la résolution de nom DNS conventionnel, afin d'éviter que chaque demande prenne le délai de trois niveaux de requêtes DNS. Le TTL des réponses DNS a été fixé de telle façon à équilibrer les avantages de la mise en cache et à garder la correspondance clientserveur à jour avec l état actuel du réseau ainsi que l état des serveurs réplica. Figure III.5. La redirection DNS dans Akamai. IV.2. L Algorithme de Sélection [DMP, 02] Dans la terminologie Akamai, le meilleur serveur réplica doit être (i) actif (en marche), (ii) susceptible d avoir le contenu demandé, (iii) disponible en fonction de sa charge et de la bande passante du réseau et (iv) le plus proche du serveur DNS local en termes de la topologie du réseau (les informations BGP) et des caractéristiques de liaison dynamique (la latence, le taux de perte,..). 80

81 CHAPITRE III Le routage des Requêtes dans Les CDNs Akamai utilise un algorithme de routage des requêtes adaptatif aux pics de charge soudains (flash crowds) des serveurs, où une centaine d utilisateurs se sont connectés en même temps sur un serveur donné. En fait, chacun des serveurs réplica rapportent fréquemment leur charge au système de surveillance Akamai, qui agrège et publie ces rapports de charge pour le serveur DNS local. Si la charge d'un serveur dépasse un certain seuil, le serveur DNS assigne simultanément une partie du contenu du serveur alloué à des serveurs réplica supplémentaires. Si la charge dépasse un autre seuil, l'adresse IP du serveur n'est plus disponible pour le client. Aussi, l'infrastructure d'akamai gère les pics de charge soudains en allouant plus de serveurs réplica sur les sites connaissant une charge élevée, tout en servant tous les clients de serveurs à proximité. Par ailleurs, Akamai utilise des agents qui simulent le comportement des utilisateurs finaux en téléchargeant les objets web et en mesurant leur taux de défaillance et les temps de téléchargement. Akamai utilise cette information pour surveiller la performance globale du système et pour détecter et suspendre automatiquement les serveurs déficients. A notre connaissance, la QoE des services multimédia (vidéo/audio) n est pas intégrée dans l approche Akamai. 81

82 CHAPITRE III Le routage des Requêtes dans Les CDNs CONCLUSION Dans ce troisième chapitre, nous avons présenté un état de l art sur les CDNs. Après avoir donné une définition générale des CDNs, nous avons expliqué les relations existantes entre ses principaux composants : les clients, les serveurs réplica, le serveur d origine, le Système de Distribution du Contenu (SDC), le Système de Routage de Requêtes (SRR) et le Système de Comptabilité (SC). Ensuite, nous nous sommes intéressés particulièrement au fonctionnement du SRR qui consiste à sélectionner le meilleur serveur réplica pouvant satisfaire la demande du client, et par la suite, à rediriger cette demande vers ce meilleur serveur par un mécanisme de redirection. Enfin, nous avons décrit le SRR déployé par le CDN Akamai. En résumé, les CDNs semblent être une solution prometteuse pour garantir la QoE des services vidéo. Avec leur SRR, la requête de l utilisateur peut être redirigée vers le meilleur serveur réplica ayant la meilleure estimation de la QoE. La deuxième partie de notre travail consiste à proposer un protocole de méta-routage adaptatif associée à la perception de l'usager. La conception de ce protocole a été argumentée au travers de cet état de l art, notamment concernant les points suivants : le choix du critère de sélection, la technique d acquisition des métriques et le mécanisme de routage utilisé. Notre algorithme de sélection prendra en compte la combinaison de plusieurs métriques comme la latence, le taux de perte et la charge du serveur réplica. Ces métriques sont mesurées grâce à la rétroaction des serveurs réplica. En procédant par élimination, nous avons choisi la redirection DNS comme un mécanisme de routage. Nous avons ensuite apporté des modifications sur la version basique de ce mécanisme afin de surmonter ses limites. C est pourquoi, nous avons adopté l insertion du DNS en périphérie. Dans le prochain chapitre, nous allons introduire notre première contribution qui nous permet de mesurer la QoE sur laquelle se base notre protocole de méta-routage. 82

83 PARTIE 2 CONTRIBUTIONS

84 Chapitre IV Une Analyse Statistique pour un Modèle de Métriques de la QoE INTRODUCTION Dans ce chapitre, nous présentons nos contributions qui consistent en un modèle de métriques de la QoE à base de KQI\KPI ainsi qu un modèle de corrélation exponentiel entre la QoE et plusieurs paramètres de QoS. Après avoir expliqué notre approche expérimentale, nous discutons ensuite les résultats de notre expérimentation.

85 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE I. PRESENTATION GENERALE DU MODELE DE METRIQUES PROPOSE Comme nous l avons mis en avant dans le chapitre II (section II), le modèle présenté par le TM Forum relatif au concept KQI/KPI permet de mesurer au mieux la QoE. Dans ce modèle, la QoE (IV. 1) est rapportée à plusieurs indicateurs de qualité (KQIs), où chaque KQI (IV. 2) est supporté par un ensemble d indicateurs de performance (KPIs). ( ) (IV. 1) ( ) (IV. 2) Nous proposons de simplifier encore davantage l ensemble générique des KQI/KPI, donné par le tableau II.1: (i) en regroupant dans une seule classe, que nous appelons la réactivité, ces indicateurs de qualité: le temps de réponse, le RTT, le délai et le temps de connexion, (ii) en omettant volontairement les KQIs liés à la sécurité (confidentialité, nonrépudiation, interopérabilité). En effet, il nous apparaît que lors de l utilisation d un service vidéo, par exemple la vidéo à la demande (VoD), les utilisateurs finaux s intéressent plus particulièrement à des indicateurs de qualité comme la disponibilité (Availability, A), la réactivité (Reactivity, R) et la qualité de vidéo (Quality of Video, QoV). Dans notre contexte, le service est disponible lorsqu il est opérationnel et accessible à l appel de l utilisateur. Il est réactif lorsqu il répond rapidement aux requêtes de l utilisateur. De plus, le service fournit une bonne QoV lorsque l utilisateur final ne perçoit aucune dégradation dans la vidéo reçue. D autre part, et pour étayer notre démarche, nous nous sommes focalisés dans ce mémoire uniquement aux deux KPIs collectés à partir du réseau de transport : la latence ou le délai de transfert de paquets (IP Packet Transfer Delay, IPTD) et le taux de perte de paquets (IP Packet Loss Ratio, IPLR). Notre réflexion a porté sur la manière de mesurer ces KQIs et trouver une correspondance entre les KPIs (IPTD et IPLR) et les KQIs (A, R et QoV) choisis. Les trois prochaines sous-sections proposent des éléments de réponse à ces deux questions. I.1. La Disponibilité La disponibilité est une mesure relative au fait que le service est opérationnel et accessible lorsqu'on y fait appel [TOA, 04]. Elle dépend de la disponibilité de tous les composants des systèmes de distribution de vidéo (le terminal de l utilisateur final, le réseau du transport, l infrastructure de services comme par exemple les serveurs CDN, etc.). Dans le cadre de ce travail, étant donné que nous nous intéressons à l infrastructure du CDN, nous considérons seulement la disponibilité de ses serveurs réplica. Ainsi, la disponibilité sera considérée dans notre modèle comme une simple variable booléenne (0 85

86 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE ou 1) indiquant si le serveur est connecté (en marche) ou non. Cet indicateur de qualité sera par conséquent indépendant de tout autre KPI au niveau du réseau. De plus, si le serveur est connecté ( ), la QoE dépendra alors des deux autres paramètres KQIs ( ( )). Dans le cas contraire ( ), la QoE est évidemment nulle. De cette façon, nous exprimons la QoE comme suit : ( ) ( ) (IV. 3) I.2. La Réactivité La réactivité est la capacité d'un service à répondre rapidement (instantanément) aux requêtes de ses utilisateurs. Elle dépend évidemment du temps de réponse aux requêtes. Un service est dit réactif si et seulement si son temps de réponse est réduit au minimum. Le temps de réponse indique le temps écoulé, en unités de temps, entre l envoi d une commande ou d une requête 15 et l arrivée de la réponse. Dans notre expérimentation, nous nous intéressons au temps de réponse aux premières paquets envoyées par le client demandant le contenu vidéo. Nous parlons ici du temps de démarrage (Start-up Time) ou du temps de connexion (Connection Time) qui indique le temps d attente relevé chez l utilisateur à partir de l'instant où il clique sur un lien vidéo ou sur le bouton «Lecteur» du lecteur vidéo jusqu à ce que la vidéo soit reproduite sur son écran. Quant au temps de démarrage, il dépend bien évidemment de la latence (IPTD), mais aussi du taux de perte (IPLR). Le lecteur vidéo attend en effet que sa mémoire tampon (buffer) se remplit avant le commencement de la lecture. S'il arrive que les premiers paquets soient perdus, le temps de démarrage va croître. Effectivement, le dimensionnement de cette mémoire tampon représente un réel challenge pour le déploiement des services streaming. L utilisation d une mémoire tampon trop grande rallonge le temps de démarrage. D autre part, l utilisation d une mémoire tampon trop petite ne permet pas d absorber la variation du délai en augmentant ainsi le taux de pertes des paquets (les paquets rejets à l arrivé). Plusieurs travaux de recherche existent pour définir des modèles adaptatifs et analytiques afin de déterminer la taille optimale du buffer. Plus de détails sur ces travaux se trouve dans [AHM, 08].. 15 Cette commande peut être un clic sur un lien vidéo ou sur l une des fonctions de contrôle de lecteur vidéo : lecture, pause, stop, retour et avance rapide. 86

87 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE I.3. La Qualité de Vidéo Comme discuté dans le chapitre I (section II.2), la qualité de vidéo (QoV) est définie comme une fonction d un ensemble de dégradations visuelles. Elle peut être évaluée automatiquement en utilisant une ou plusieurs méthodes objectives. Ces dernières sont de différents types: avec référence complète, avec référence réduite ou sans référence. Dans le cadre de notre modèle de métriques, nous avons besoin des méthodes sans référence afin d évaluer la QoV en temps réel au niveau de l utilisateur. Ce type des méthodes permet en effet de prévoir la QoV à partir d un ensemble de paramètres de mesure de performances, principalement liés au codec et au réseau. Cependant, aucune méthode sans référence existante dans la littérature n a pu répondre à nos exigences résumées ainsi : (i) au moins un des paramètres du réseau de transport (IPTD, IPLR) doit être considéré, (ii) une bonne corrélation des résultats avec la perception humaine, (iii) des calculs rapides et (iv) une implémentation facile. Il s avère donc nécessaire de proposer notre propre modèle de corrélation entre la QoV et les deux paramètres du réseau (IPTD et IPLR). I.4. Synthèse En résumé, notre modèle de métriques de la QoE est illustré dans la figure IV.1. Dans ce modèle, la QoE est rapportée à trois KQIs: la disponibilité (A), la réactivité (R) et la qualité de vidéo (QoV). Ces deux derniers KQIs (R et QoV) sont supportés par deux KPIs : la latence (IPTD) et le taux de perte (IPLR). Dans la section III, nous définissons la fonction de l équation (IV. 3) ainsi que la correspondance entre les KQIs et les KPIs (IV. 4) (IV. 5). ( ) (IV. 4) ( ) (IV. 5) 87

88 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE Figure IV.1. Notre modèle de métriques de la QoE à base de KQI\KPI II. DESCRIPTION DU MODELE DE CORRELATION PROPOSE [ABM, 12] Afin de définir la correspondance entre les KQIs et les KPIs sélectionnés, une analyse des principaux modèles de corrélation entre la QoE (rapportée à l un de ses KQIs) et la QoS a été effectuée (Cf. la section III du chapitre II). Cette étude nous a permis de choisir le modèle IQX [FHT, 10] comme celui qui va nous permettre de quantifier la relation entre la QoE et la QoS. Cependant, ce modèle exponentiel ne prend en compte qu'un seul paramètre de la QoS. Dans cette section, nous présentons un modèle global de corrélation de forme exponentielle considérant plusieurs paramètres de QoS comme dans [KLL, 08] [GYH, 09] [HEE, 08]. Au niveau du modèle IQX ( ), la constante gamma (γ) permet de s adapter à l échelle de mesure de la QoE. Traditionnellement, la QoE est exprimée en termes de MOS (Mean Opinion Score) défini dans la norme [ITU-R, 02]. La note moyenne d opinion (MOS) consiste en une échelle comprise entre les valeurs entières 5 (excellente) et 1 (très mauvaise). La constante s approche ainsi de 1 pour exprimer une très mauvaise QoE quand la perturbation de la QoS devient très grande ( ). Dans [SFC, 09], les auteurs ont introduit une nouvelle échelle de mesure de la QoE appelée OS (Opinion Score) qui prolonge l échelle du MOS par la valeur 0. En utilisant cette échelle discrète d OS, les auteurs ont éliminé la constante ( ) dans tous les modèles exponentiels proposés dans leurs travaux de [SFC, 09]. Dans notre approche, nous assumons que la constante est nulle et que la QoE est exprimée sur une échelle continue d OS. Cette dernière couvre l'intervalle ] ]et l'utilisateur peut donc choisir une valeur appartenant à un intervalle continu afin d'exprimer sa perception de la qualité du service 88

89 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE vidéo. Ainsi, la qualité sera notée comme très mauvaise dans l'intervalle ] ] (respectivement mauvaise dans ] ], moyenne dans ] ], bonne dans ] ] et excellente dans] ]). Notre objectif principal est de quantifier la relation entre la QoE et plusieurs paramètres de QoS notés. Si la QoE et chaque paramètre sont liés par un modèle exponentiel, nous obtenons alors le système d équations suivant : (IV. 6) { où les paramètres et sont positifs. En termes de régression simple, l impact individuel de chaque paramètre sur la QoE est réputé exponentiel. Ce modèle de régression non linéaire peut se ramener à un modèle de régression linéaire avec un changement de variables [SMY, 02]. En appliquant la transformation logarithmique sur chaque équation du système (IV. 6), nous obtenons le système (IV. 7) où chaque paramètre a un impact linéaire sur la nouvelle variable «( )». ( ) ( ) ( ) ( ) (IV. 7) { ( ) ( ) Ainsi, l impact collectif des paramètres de QoS sur la variable ( ) est linéaire. Nous pouvons appliquer ensuite la méthode de Régression Linéaire Multiple (RLM). Il s'agit d'une méthode utilisée pour modéliser la relation linéaire entre une variable endogène (expliquée) et plusieurs variables exogènes (explicatives) [MEK, 11]. Son équation de prédiction exprime la valeur de la variable endogène ( ) comme une fonction linéaire de plusieurs variables exogènes ( ) : ( ) (IV. 8) où les constantes sont estimées par la méthode des moindres carrés. La transformation exponentielle appliquée à l équation (IV.8) permet d'obtenir notre modèle de corrélation exponentiel : (IV. 9) Par identification avec le modèle IQX ( ), notre modèle de corrélation peut être vu comme une extension de ce modèle comme illustré dans (IV.10). Notre contribution principale est l utilisation d une combinaison de plusieurs paramètres lors de la définition de la perturbation de QoS. Cette dernière peut en effet être modélisée 89

90 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE comme une somme pondérée de plusieurs paramètres où le poids de chaque paramètre est estimé par une analyse de la régression linéaire multiple. { ( ) (IV. 10) III. EXPERIMENTATION Après avoir établi notre propre modèle de métriques de la QoE, il a été nécessaire de définir la fonction de l équation (IV. 3) ainsi que la correspondance entre les KQIs (R et QoV) et les KPIs (IPTD et IPLR). Pour ce faire et afin de prouver le concept proposé, une expérimentation en trois étapes a été nécessaire (Figure IV.2) : - Etape 1 : Une série d expériences a été effectué sur un échantillon de personnes afin de construire notre base expérimentale au regard des paramètres objet de notre étude (IPTD, IPLR, R, QoV, QoE). - Etape 2 : Une étude analytique de l impact des KPIs (IPTD, IPLR) sur les KQIs (R, QoV) a été menée pour définir la correspondance entre les deux types d indicateurs (IV. 4) (IV. 5). - Etape 3 : Une analyse de l impact des KQIs (R, QoV) sur la QoE a été faite pour définir la fonction de l équation (IV. 3). Figure IV. 2. Une approche générale d expérimentation des modèles à base de KQI/KPI. III.1. Etape 1 : Collecte des Données Cette première étape consiste principalement en des expériences de laboratoire: un certain nombre de personnes sont amenés à utiliser un service de Vidéo à la Demande (VoD). Ils leur sont demandés ensuite de donner une note mesurant leur niveau de 90

91 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE satisfaction concernant l'utilisation du service (QoE) sur la base de deux KQIs (la réactivité et la qualité de vidéo). Ces expériences ont été menées avec des valeurs fixes de KPIs. Le tableau IV.1. présente les valeurs de la latence (IPTD) et du taux de perte (IPLR), utilisées pour notre expérimentation. Dans la cadre de cette expérimentation, nous avons collecté un échantillon de 900 couples (IPTD, IPLR, R, QoV, QoE) en effectuant un tirage de scénarios (entre 5 et 55) sur un nombre important de personnes (54). Le tirage consiste en effet à choisir aléatoirement une configuration des paramètres de QoS (IPTD, IPLR) à exécuter sur le réseau. Ensuite, un utilisateur se sert d un service VoD comme suit : (i) il commence par demander un flux vidéo 16, (ii) une fois ce flux vidéo apparu sur son écran, il le visionne durant deux minutes et (iii) il note enfin la QoV et la QoE en utilisant l échelle continue d OS. Notons ici que le temps du démarrage est calculé automatiquement à partir de l'instant où l utilisateur demande le flux vidéo jusqu à ce que ce dernier soit reproduit sur son écran. Pour plus de détails sur la plateforme utilisée dans notre phase d'expérimentation, le lecteur peut se référer à l annexe A. Tableau IV.1. Les valeurs, de latence (IPTD) et de taux de perte (IPLR), utilisées pour l expérimentation. Le Délai de Transfert des Paquets (IPTD) [ms] Le Taux de Perte des Paquets (IPLR) [%] 0, 50, 100, 150, 200, 250, 300, 350, 400, 450, 500, 550, 600, 650, 700, 750, 800, 850, 900, 950, 1000, 1500, 2000, 2500, 3000, 4000, 5000, 6500, 8000, , 0.125, 0.25, 0.5, 0.625, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 2.75, 3, 3.5, 4, 4.5, 5, 5.5, 6, 7, 8, 10, 15, 20, 30, 50, 75, 100. III.2. Etape 2 : Impact des KPIs sur les KQIs Pour étudier l impact des KPIs (IPLR et IPTD) sur les KQIs (QoV et R), nous étudions dans un premier temps l impact individuel de chaque KPI sur un KQI. Ensuite, nous étudions leur impact collectif sur un KQI. De fait, l étude de l impact individuel revient à étudier la régression simple alors que l étude de l impact collectif concerne la régression multiple. 16 La vidéo est de résolution 432x320, du débit 25 images par seconde et de codec MPEG-4 (XVID). Cette vidéo a été choisie car elle alterne les mouvements lents et rapides. 91

92 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE III.2.1. Impact du Taux de Perte sur la Qualité de Vidéo Dans cette section, nous expliquons en détail la démarche d analyse de données qui a été suivie afin d étudier l impact individuel d une variable X sur une variable Y tout au long de notre expérimentation. Nous présentons dans un premier temps la variable Y en fonction de la variable X. La figure IV.3 présente les variations du paramètre QoV en fonction du taux de perte (IPLR) pour chaque valeur de latence (IPTD). Ce graphique permet d estimer la nature du modèle de corrélation adéquat. Comme dans [SFC, 09], nous nous intéressons seulement aux types de corrélation suivants : linéaire, logarithmique, exponentiel et puissance. Nous avons ensuite choisi de transformer le modèle de corrélation non linéaire en un modèle linéaire ( ) comme l'indique le tableau IV.2. Ainsi, quatre modèles linéaires ont été appliqués. Figure IV.3. Impact du taux de perte (IPLR) sur la qualité de vidéo (QoV). Tableau IV.2. Transformation des modèles non linéaires aux modèles linéaires. Modèles non linéaires Type de transformation Modèles linéaires correspondant Logarithmique ( ) ( ) ( ) ( ) ( ) ( ) Aucun ( ) 92

93 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE Pour effectuer la régression linéaire, la commande lm (linear model) disponible dans l outil d analyse statistique de données «logiciel R» 17 a été utilisée. Pour chaque valeur de l IPTD, nous avons effectué la régression de ces quatre modèles : (i) linéaire ( ), (ii) logarithme ( ( )), (iii) exponentiel ( ( ) ) et (iv) puissance ( ( ) ( )). Les résultats de cette régression sont ensuite affichés et analysés. La figure IV.4 montre une partie des résultats où la régression linéaire entreprise est ( ). Sur ces résultats, nous nous intéressons particulièrement à [COM, 11]: - l'estimation des paramètres du modèle (a et b) qui se trouvent dans la colonne Estimate. - les valeurs observées de la statistique de test d hypothèse «H0» permettant de vérifier si la relation entre Y (= QoV) et X (= IPLR) est significative, i.e., si la variable Y dépend bien de X. En général, l hypothèse H0 est rejetée pour des erreurs supérieures ou égales à Dans le cas où l hypothèse H0 est rejetée pour la variable X alors il faut conserver la variable X, sinon on peut supprimer la variable X. - les coefficients de corrélation. Le logiciel R donne le carré de coefficient de corrélation (Multiple R-squared) appelé coefficient de détermination ( ). En termes de régression, le modèle de corrélation entre Y (= QoV) et X (= IPLR) est de bonne qualité si le coefficient de corrélation ( ) (ou le coefficient de détermination ( )) est proche de 1. A noter que le coefficient de corrélation ( ) exprime le pourcentage des variations du paramètre QoV expliqué par le modèle. Nous choisissons en dernier le modèle qui dispose du coefficient de corrélation le plus élevé (proche de 1) dans la majorité des cas. Comme le montre le tableau IV.3, l impact de l IPLR sur la QoV a été validé comme étant de forme exponentielle. L'analyse (Cf. figure IV.3) a en effet démontré qu au début, une légère croissance du taux de perte n affecte pas la QoV. Cependant, dés que le taux de perte (IPLR) dépasse 1%, les distorsions de la vidéo deviennent visibles et gênantes. Ainsi, la QoV commence à diminuer jusqu à devenir très mauvaise ( ). 17 R est un logiciel libre multiplateforme (Linux, Windows, Mac OS) qui possède une large collection d outils statistiques et graphiques. Il est aussi un langage de programmation interactif interprété et orienté objet qui inclue de nombreuses facilités. Les versions compilées de R, les différentes bibliothèques ainsi qu une large documentation sont disponible sur 93

94 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE Figure IV.4. Les résultats de la régression linéaire entre la QoV et l IPLR. Tableau IV.3. Le coefficient de détermination entre la QoV et le taux de perte. Modèle Linéaire Logarithme Exponentiel Puissance Modèle Linéaire Logarithme Exponentiel Puissance IPTD (ms) IPTD (ms) III.2.2. Impact de la Latence sur la Qualité de la Vidéo La figure IV.5 représente la corrélation entre la latence (IPTD) et la QoV pour chaque valeur du taux de perte (IPLR). Sur la base de la démarche explicitée dans la section précédente, l impact de la latence sur la QoV a été validé comme étant de forme exponentielle (Tableau IV.4). L'analyse a en effet démontré que la QoV commence à se dégrader à un taux constant à partir de. Ce phénomène est dû aux distorsions 94

95 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE visuelles (effet de blocage) introduites par la latence ainsi qu'à la perte des paquets vidéo qui dépassent leur date d échéance (date limite d arrivée). En général, un paquet arrivant au-delà de sa date d échéance ne fournit aucune information utile à une application temps-réel (comme le transfert de la vidéo), il est ainsi considéré comme perdu [MAN, 05]. Figure IV.5. Impact de la latence (IPTD) sur la qualité de vidéo (QoV). Tableau IV.4. Le coefficient de détermination entre la QoV et la latence (IPTD). Modèle Linéaire Logarithme Exponentiel Puissance Modèle Linéaire Logarithme Exponentiel Puissance IPLR (%) IPLR (%) III.2.3. Impact Collectif des KPIs sur la Qualité de la Vidéo Nous avons vu dans la section précédente que la QoV et chacun des KPIs (IPTD et IPLR) sont liés par une forme de nature exponentielle. Il est donc possible d'appliquer notre modèle de corrélation proposé dans la section II. Dans ce modèle, la QoE est rapportée à la qualité de la vidéo (QoV) tandis que à la QoS est basée sur les deux paramètres (IPTD et IPLR). Notre expérimentation (Figure IV.6) a démontré que ce 95

96 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE modèle est de bonne qualité ( ), i.e % des variations de la QoV sont expliquées par le modèle suivant: ( ) ( ) (IV. 11) Call: lm(formula = log(qov) ~ IPTD + IPLR) Residuals: Min 1Q Median 3Q Max Coefficients: Estimate Std. Error t value Pr(> t ) (Intercept) 1.038e e <2e-16 *** IPTD e e <2e-16 *** IPLR e e <2e-16 *** --- Signif. codes: 0 *** ** 0.01 * Residual standard error: on 897 degrees of freedom Multiple R-squared: , Adjusted R-squared: F-statistic: 2335 on 2 and 897 DF, p-value: < 2.2e-16 Figure IV.6. Les résultats de la régression multiple entre la QoV et les KPIs. Comme illustré dans la figure IV.7 (b), la QoV a une valeur moyenne au démarrage de l'expérimentation ( ( ) ). Elle se dégrade ensuite à un taux constant pour approcher de la valeur zéro dès que le taux de perte (IPLR) dépasse 30%. Cela confirme que le modèle obtenu (IV.7 (b)) est bien ajusté que pour une partie ou une classe de l échantillon ( ). Une explication pourrait être corrélée au nombre élevé de données dans cette classe. L'analyse fine des résultats obtenus montre en effet que la majorité des couples de données de l'échantillon (environ 750/900) sont situés dans cette classe ( ), ce qui représente un biais non négligeable dans les résultats. Pour remédier à ce problème, deux solutions existent: - diviser notre échantillon en deux classes. Pour chaque classe, il faudra trouver le type d impact collectif des KPIs sur la QoV correspondant. Dans ce cas, le modèle de corrélation s'écrit sous la forme d'une fonction composite (définie par plusieurs fonctions). - Enrichir l'échantillon en rajoutant de nouvelles données dans l'objectif d'avoir une seule classe homogène et ainsi un modèle de corrélation décrit par une fonction simple. 96

97 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE Figure IV.7. Impact collectif des KPIs sur la QoV. Au regard des difficultés rencontrées lors de la collecte de notre échantillon de données en termes de temps et de moyens humains, nous avons choisi de suivre la première solution, qui est la plus simple et la plus pratique, tout au long de cette expérimentation. La deuxième solution nécessite en effet la collecte des autres données et l aboutissement d une seule classe homogène n est pas garanti. En suivant la première solution, nous avons donc divisé notre échantillon en deux classes selon les valeurs de la QoV : { ( ) ] ] et { ( ) ] ]. Ensuite, pour chaque classe, une analyse basée sur la Régression Linéaire Multiple (RLM) entre le ( ) et les paramètres de QoS (IPTD et IPLR) a été appliquée (Cf. tableau IV.5). Nous constatons ainsi que le modèle obtenu dans la classe C1 est presque égal à celui de l ancien modèle donné par l équation (IV. 11). Par ailleurs, le modèle obtenu dans la classe C2 dispose un bon coefficient de corrélation ( ). Comme le montre la figure IV. 8 (Classe 2), une croissance légère d IPLR n'affecte pas la QoV. Par contre, les distorsions de la vidéo deviennent perceptibles sans être gênantes au regard de la croissance du paramètre IPTD. 97

98 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE Tableau IV. 5. Les résultats de la RLM dans les deux classes. Classe 1 (C1) [ ] Classe 2 (C2) ] ] Call: lm(formula = log(qov) ~ IPTD + IPLR) Residuals: Min 1Q Median 3Q Max Coefficients: Estimate Std. Error t value Pr(> t ) (Intercept) 9.568e e <2e-16 *** IPTD e e <2e-16 *** IPLR e e <2e-16 *** --- Signif. codes: 0 *** ** 0.01 * Residual standard error: on 785 degrees of freedom Multiple R-squared: , Adjusted R-squared: F-statistic: 2048 on 2 and 785 DF, p-value: < 2.2e-16 Call: lm(formula = log(qov) ~ IPTD + IPLR) Residuals: Min 1Q Median 3Q Max Coefficients: Estimate Std. Error t value Pr(> t ) (Intercept) 1.476e e < 2e-16 *** IPTD e e e-12 *** IPLR e e < 2e-16 *** --- Signif. codes: 0 *** ** 0.01 * Residual standard error: on 109 degrees of freedom Multiple R-squared: , Adjusted R-squared: F-statistic: on 2 and 109 DF, p-value: < 2.2e-16 Figure IV.8. Impact collectif des KPIs sur la QoV dans les deux classes. 98

99 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE En conclusion, nous avons obtenu un modèle de corrélation défini par deux fonctions propres à chaque classe, chacune d'entre elles exprime la relation entre la QoV et les deux paramètres de QoS (IPTD et IPLR) dans chaque classe. La QoV (IV.5) peut alors s exprimer avec le modèle exponentiel composite donné par (IV.12). Ce modèle valide l hypothèse exponentielle pour les services VoD où la QoV est exprimée comme une fonction de deux paramètres de QoS (délai et taux de perte). La QoV se dégrade en effet à un taux constant d excellente jusqu à très mauvaise : une croissance légère de la perturbation de (IV.13) n affecte pas le trafic vidéo. Dés que IPTD dépasse 1000ms ( ), les distorsions de la vidéo deviennent visibles sans être gênantes. Ensuite, la QoV se dégrade de bonne jusuqu à moyenne quand IPLR augmente ( ). Enfin, la croissance de la perturbation de cause des effets très destructifs sur le trafic vidéo et la QoV devient ainsi très mauvaise. { ( ) ( ) ( ) ( ) ( ) ( ) (IV. 12) { ( ) ( ) ( ) ( ) (IV. 13) III.2.4. Impact du Taux de Perte sur la Réactivité Comme précisé dans la section I.2, la réactivité se résume dans notre expérimentation au temps de démarrage, celui-ci dépendant du taux de perte. D après le tableau IV.6, cette dépendance peut être exprimée par un modèle exponentiel, i.e. l augmentation du taux de perte cause l augmentation du temps de démarrage à un taux constant (Cf. figure IV.9). Tableau IV.6. Le coefficient de détermination entre la réactivité et l IPLR. Modèle Linéaire Logarithme Exponentiel Puissance Modèle Linéaire Logarithme Exponentiel Puissance IPTD (ms) IPTD (ms)

100 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE Figure IV.9. Impact du taux de perte (IPLR) sur le temps de démarrage (R). III.2.5. Impact de la Latence sur la Réactivité Le temps de démarrage inclut, outre la latence, d autres délais comme ceux induits par le codec, le buffer ou le temps de traitement de serveur. Par contre, la latence reste le facteur le plus influant car elle constitue environ 80% du temps de réponse de la requête [SPV, 03]. Le temps de démarrage (R) croît ainsi sensiblement avec la latence. Comme le prouve le tableau IV.7, l impact de la latence sur le temps de démarrage est de forme exponentiel. La figure IV.10 représente en effet une croissance exponentielle du temps de démarrage (R) avec la latence (IPTD) pour les différentes valeurs du taux de perte (IPLR). Tableau IV.7. Le coefficient de détermination entre le R et la latence (IPTD). Modèle Linéaire Logarithme Exponentiel Puissance Modèle Linéaire Logarithme Exponentiel Puissance IPLR(%) IPLR(%)

101 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE Figure IV. 10. Impact de la latence (IPTD) sur le temps de démarrage (R). III.2.6. L Impact Collectif des KPIs sur la Réactivité Comme les deux KPIs ont le même type d impact exponentiel sur la réactivité, nous pouvons nous ramener à une étude de la RLM en opérant un changement de variables. Ainsi, en appliquant la RLM entre le ( ) et les KPIs (Figure IV.11), le modèle de corrélation est jugé de bonne qualité ( ), i.e. 83.7% des variations de la réactivité sont expliquées par le modèle donné par (IV. 14). En outre, d après la figure IV.12, le modèle estimé ajuste bien notre échantillon de données pour les valeurs IPLR inférieures à 50%. Cependant, il perd un peu en précision pour les valeurs supérieures qui sont rarement atteintes dans les réseaux réellement déployés. ( ) ( ) (IV. 14) Call: lm(formula = log(r) ~ IPTD + IPLR) Residuals: Min 1Q Median 3Q Max Coefficients: Estimate Std. Error t value Pr(> t ) (Intercept) 2.445e e <2e-16 *** IPTD 6.973e e <2e-16 *** IPLR 1.373e e <2e-16 *** --- Signif. codes: 0 *** ** 0.01 * Residual standard error: on 897 degrees of freedom Multiple R-squared: , Adjusted R-squared: F-statistic: 1049 on 2 and 897 DF, p-value: < 2.2e-16 Figure IV. 11. Les résultats de la régression multiple entre le R et les KPIs. 101

102 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE Figure IV.12. Impact collectif des KPIs sur la réactivité (R). III.3. Etape 3 : Impact des KQIs sur la Qualité d Expérience De même que l étape 2, nous commençons par étudier l impact individuel des KQIs (QoV et R) sur la QoE afin d en déduire leur impact collectif sur la QoE. III.3.1. Impact de la Qualité de Vidéo sur la Qualité d Expérience Selon le coefficient de détermination (Tableau IV.8) le plus élevé, l impact de la QoV sur la QoE est linéaire. Cependant, une relation linéaire entre la QoE et la QoV signifie que la QoE est presque égale à la QoV. En réalité, la QoE couvre d'autres aspects importants tels que la réactivité qui est également pertinente à l égard de l utilisateur. Pour cela, nous nous sommes dirigés vers le modèle puissance qui possède un coefficient de corrélation assez proche du modèle linéaire. De plus, ce modèle exprime la présence d un taux de décroissance proportionnel entre la QoV et la QoE (Figure IV.13). Tableau IV.8. Le coefficient de détermination entre la QoE et la QoV. Modèle Linéaire Logarithmique Exponentiel Puissance Coefficient de Détermination (r 2 )

103 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE Figure IV.13. Impact de la QoV sur la QoE. III.3.2. Impact de la Réactivité sur la Qualité d Expérience Comme indiqué dans le tableau IV.9, l impact de la réactivité (le temps de démarrage) sur la QoE suit une fonction de type puissance. La QoE diminue lorsque le temps de démarrage augmente. En effet, l utilisateur juge négativement une longue attente avant affichage sur son écran de la vidéo demandée. Le modèle obtenu (Figure IV.18 (a)) est ajusté seulement pour une classe de valeurs ( ). De même que l étude d impact collectif des KPIs sur la QoV, nous avons opté pour une distribution différente de notre échantillon selon les valeurs de la QoE : { ( ) ] ] et { ( ) ] ]. Tableau IV. 9. Le coefficient de détermination entre la QoE et le R. Modèle Linéaire Logarithmique Exponentiel Puissance Le Coefficient de Détermination Le tableau IV.10 montre le coefficient de détermination entre la QoE et le temps de démarrage (R) pour les quatre modèles dans chacune des classes ( et ). Ainsi, l impact du temps de démarrage (R) reste toujours donné sur une fonction de forme puissance dans la classe, (Figure IV.14 (b)). Par contre, dans la classe (Figure IV.14 (c)), il n'a pas été possible de déterminer la nature de cette dépendance. Cela est dû à un autre type d impact non considéré dans le cadre de cette expérimentation. 103

104 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE Tableau IV.10. Le coefficient de détermination entre la QoE et le R dans chaque classe. Classe Modèle Linéaire Logarithmique Exponentiel Puissance Classe 3 (C3) Classe 4 (C4) Figure IV.14. Impact de la réactivité (R) sur la qualité d expérience (QoE). 104

105 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE III.3.3. Impact Collectif des KQIs sur la Qualité d Expérience Dans la classe C3, les deux KQIs ont un impact de forme puissance sur la QoE. Ainsi, après avoir appliqué la RLM entre les valeurs ( ) et les logarithmes des KQIs (Cf. Tableau IV.11), nous avons obtenu un modèle que nous pouvons qualifier de bonne qualité ( ). Cependant, l hypothèse est acceptée pour la constante et la réactivité (R). Si nous choisissons de conserver la constante (respectivement la réactivité) alors nous prenons un risque supérieur de 10% (respectivement égale à 100%). Ainsi, la QoE ne dépend que de la QoV dans la classe C3 (Cf. la formule IV.15). Par ailleurs, dans la classe C4, même si nous n ayons pas pu déterminer l impact de la réactivité sur la QoE (Cf. Tableau IV.10), nous avons assumé que les deux KQIs ont le même impact sur la QoE afin de pouvoir appliquer la RLM entre ces deux KQIs. Nous avons ainsi obtenu un bon modèle ( ) dans lequel la relation entre la réactivité (R) et la QoE est significative (un risque inférieur à 0.1%). Enfin, l équation (IV. 3) peut s exprimer avec le modèle de corrélation composite suivant: { ( ) ( ) ( ) ( ) ( ) (IV. 15) Une représentation graphique des modèles obtenus est donnée dans les figures IV. 15 et IV. 16. Figure IV.15. Impact collectif des KQIs (R, QoV) sur la QoE dans la classe C3. 105

106 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE Figure IV.16. Impact collectif des KQIs (R, QoV) sur la QoE dans la classe C4. Tableau IV. 11. Les résultats de la régression multiple entre la QoE et les KQIs. Classe 3 ] ] Classe 4 ] ] Call: lm(formula = log(qoe) ~ log(r) + log(qov)) Residuals: Min 1Q Median 3Q Max Coefficients: Estimate Std. Error t value Pr(> t ) (Intercept) log(r) log(qov) <2e-16 *** --- Signif. codes: 0 *** ** 0.01 * Residual standard error: on 576 degrees of freedom Multiple R-squared: , Adjusted R-squared: F-statistic: 2163 on 2 and 576 DF, p-value: < 2.2e-16 Call: lm(formula = log(qoe) ~ log(r) + log(qov)) Residuals: Min 1Q Median 3Q Max Coefficients: Estimate Std. Error t value Pr(> t ) (Intercept) <2e-16 *** log(r) <2e-16 *** log(qov) <2e-16 *** --- Signif. codes: 0 *** ** 0.01 * Residual standard error: on 318 degrees of freedom Multiple R-squared: , Adjusted R-squared: F-statistic: on 2 and 318 DF, p-value: < 2.2e

107 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE III.3.4. Le Modèle de Corrélation proposé entre la QoE et la QoS Le modèle composite, de forme exponentielle, entre la QoE et les paramètres de QoS (IPTD et IPLR) donné par (IV.16) s'obtient par le remplacement dans l équation (IV. 15) de la QoV par l équation (IV.12) et de la réactivité (R) par l équation (IV.14). Au niveau de ce modèle, et au regard de notre base d'échantillon, nous distinguons seulement trois classes (la classe 3 ( ] ]) est quant à elle incluse dans la classe 1 ( ] ])). ( ) ( ) ( ) { ( ) ( ) ( ) ( ) ( ) ( ) (IV. 16) Afin de valider le modèle obtenu, nous l avons comparé avec les résultats de la RLM entre la QoE et les KPIs (IPTD et IPLR) dans la classe globale contenant tout l échantillon de données (900 couples) ainsi que dans les classes introduites dans la formule ci-dessus (C3, C5 et C6). Comme synthétisé dans le tableau IV.12, nous avons obtenu un modèle de corrélation de bonne qualité ( ) dans la classe globale. Néanmoins, le modèle obtenu reste ajuster pour les valeurs de QoE inférieurs à expliquant ainsi les bons résultats obtenus dans la classe 3. En revanche, pour les autres classes (C5 et C6), le coefficient de corrélation reste faible compte tenu de l impact inconnu de la réactivité sur la QoE dans la classe C4. Pour chaque classe étudiée (C3, C5 et C6), les figures IV.17, IV.18 et IV.19 illustrent graphiquement le modèle donné par (IV.15) (en rouge) et le modèle obtenu après l'application de la méthode RLM entre ( ) et les KPIs (en bleu) donné par la formule IV.17. Ce dernier ajuste d'une meilleure façon l échantillon de données dans la classe C3 comparativement aux autres classes et ce contrairement au modèle donné par (IV.16). ( ) ( ) ( ) { ( ) ( ) ( ) ( ) ( ) ( ) (IV. 17) 107

108 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE Tableau IV. 12. Les résultats de la régression multiple entre la QoE et les KPIs. Global (tout l échantillon de données) Classe 3 (C3) Classe 5 (C5) Classe 6 (C6) Call: lm(formula = log(qoe) ~ IPTD + IPLR) Residuals: Min 1Q Median 3Q Max Coefficients: Estimate Std. Error t value Pr(> t ) (Intercept) 1.064e e <2e-16 *** IPTD e e <2e-16 *** IPLR e e <2e-16 *** --- Signif. codes: 0 *** ** 0.01 * Residual standard error: on 897 degrees of freedom Multiple R-squared: , Adjusted R-squared: F-statistic: 2512 on 2 and 897 DF, p-value: < 2.2e-16 Call: lm(formula = log(qoe) ~ IPTD + IPLR) Residuals: Min 1Q Median 3Q Max Coefficients: Estimate Std. Error t value Pr(> t ) (Intercept) 8.736e e <2e-16 *** IPTD e e <2e-16 *** IPLR e e <2e-16 *** --- Signif. codes: 0 *** ** 0.01 * Residual standard error: on 576 degrees of freedom Multiple R-squared: , Adjusted R-squared: F-statistic: 1404 on 2 and 576 DF, p-value: < 2.2e-16 Call: lm(formula = log(qoe) ~ IPTD + IPLR) Residuals: Min 1Q Median 3Q Max Coefficients: Estimate Std. Error t value Pr(> t ) (Intercept) 1.099e e < 2e-16 *** IPTD e e e-08 *** IPLR e e e-15 *** --- Signif. codes: 0 *** ** 0.01 * Residual standard error: on 206 degrees of freedom Multiple R-squared: , Adjusted R-squared: F-statistic: on 2 and 206 DF, p-value: 2.534e-15 Call: lm(formula = log(qoe) ~ IPTD + IPLR) Residuals: Min 1Q Median 3Q Max Coefficients: Estimate Std. Error t value Pr(> t ) (Intercept) 1.442e e < 2e-16 *** IPTD e e e-13 *** IPLR e e e-06 *** --- Signif. codes: 0 *** ** 0.01 * Residual standard error: on 110 degrees of freedom Multiple R-squared: , Adjusted R-squared: F-statistic: on 2 and 110 DF, p-value: 1.011e

109 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE Figure IV.17. Impact collectif des KPIs sur la QoE dans la classe C3. Figure IV.18. Impact collectif des KPIs sur la QoE dans la classe C5. 109

110 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE Figure IV.19. Impact collectif des KPIs sur la QoE dans la classe C6. 110

111 CHAPITRE IV Une Analyse Statistiques pour un Modèle de Métriques de la QoE CONCLUSION Dans ce chapitre, nous avons présenté notre première contribution qui consiste en un modèle de métriques de la QoE sur la base des indicateurs de qualité et de performance (KQI/KPI). Au niveau de ce modèle, la QoE est rapportée à trois KQIs (la disponibilité, la réactivité et la qualité de vidéo) supportés par deux KPIs (la latence et le taux de perte). Au travers de cette contribution, nous avons introduit une approche générale pour expérimenter tout type de modèle basé sur le concept KQI\KPI. Cette approche empirique passe par trois étapes : (i) collecter l échantillon de données, (ii) trouver la correspondance entre les KPIs et les KQIs et (iii) analyser la correspondance entre les KQIs et la QoE. Notre approche reste valable dans le cas d une extension du modèle (ajout de KQIs et/ou de KPIs). Par ailleurs, la correspondance entre les KPIs, les KQIs et la QoE a été déterminée en fonction des deux types de régression: simple et multiple. Ces correspondances ont permis de déduire quatre modèles de corrélation exponentiels. Sur la base d'une étude utilisant la régression linéaire multiple, un modèle de corrélation exponentiel global a été proposé. Dans ce modèle, la QoS est modélisée comme une somme pondérée de plusieurs paramètres (taux de perte, latence, ). Le modèle proposé peut être vu comme une extension du modèle exponentiel défini dans [FHT, 10]. D autre part, le modèle de corrélation QoV-QoS nous a permis de définir une méthode sans référence et paramétrique afin d évaluer la QoV. Il serait donc intéressant de comparer notre méthode d évaluation de la QoV avec d autres méthodes existantes (avec référence complète ou avec référence réduite). Ceci reste comme perspective pour notre travail. Enfin, le modèle proposé de métriques nous a permis de déduire un modèle exponentiel de corrélation entre la QoE et la QoS. Ce modèle de corrélation sera testé dans le protocole de méta-routage que nous proposons dans le chapitre suivant. 111

112 Chapitre V Conception d un Protocole de Méta-Routage basé sur la QoE dans les CDNs INTRODUCTION Dans ce chapitre, nous abordons les prémices d'une solution dédiée aux réseaux de distribution de contenus de type vidéo basée sur la QoE. Elle consiste en un protocole de méta-routage, agissant au niveau de la résolution de noms (Domain Name System, DNS), et permettant de rediriger en temps réel, et de manière adaptative, les requêtes de l utilisateur vers le meilleur serveur vidéo offrant la meilleure QoE. Pour mettre en œuvre le protocole proposé, nous présentons, sur la base du simulateur réseau NS-2, l'extension proposée capable de simuler à la fois la redirection DNS et la transmission vidéo dans un CDN. 112

113 CHAPITRE V Conception d un protocole de Méta-Routage basé sur la QoE I. PRESENTATION GENERALE DU PROTOCOLE PROPOSE Dans cette première version du protocole, nous nous intéressons seulement au Système de Routage des Requêtes (SRR) dans un CDN. Pour la distribution de contenus vidéo, nous assumons que la vidéo est répliquée en entier (mode Full-Site) et a priori (mode Push) dans les serveurs réplica. L architecture de notre CDN ne comporte ainsi que trois entités: - Les clients qui effectuent des requêtes (demandes) de contenus vidéo et reçoivent les flux vidéo en provenance des serveurs réplica. - Les serveurs réplica qui envoient les flux vidéo aux clients. Ils fonctionnent sous le contrôle du serveur redirecteur à qui ils envoient parfois des demandes de remplacement. - Le serveur DNS-CDN (parfois appelé serveur redirecteur) qui désigne le meilleur serveur réplica pouvant répondre à la demande du client. Pour ce faire, il maintient trois tables différentes : La table des contenus disponibles qui contient la liste de tous les contenus vidéo disponibles dans le CDN avec leurs emplacements. Une vidéo est éventuellement présente sur plusieurs serveurs réplica. La table des serveurs réplica connectés qui permet de tenir à jour la liste de tous les serveurs réplica actifs (en marche) dans le CDN. Notons ici que lorsqu un serveur réplica se connecte ou se déconnecte dans le CDN, il en informe le serveur redirecteur afin de mettre à jour cette table ainsi que la table des contenus disponibles. La table des demandes en cours de traitement qui maintient à jour les données mesurées au niveau du serveur réplica traitant la demande. Comme illustré dans la figure V.1, le fonctionnement de notre protocole de métaroutage, basé sur une boucle de rétroaction de la QoE, passe par cinq phases: initiation, sélection, connexion, rétroaction et adaptation. Ces phases sont décrites dans les soussections suivantes. 113

114 CHAPITRE V Conception d un protocole de Méta-Routage basé sur la QoE I. 1. La Phase d Initiation Figure V.1. Les phases de notre protocole de méta-routage. Lorsqu un client initie une demande de vidéo, une requête de résolution de nom est envoyée de manière transparente au serveur DNS-CDN. A partir de la table des contenus disponibles, le serveur DNS-CDN vérifie que le contenu demandé est disponible dans au moins un serveur réplica du CDN. Dans le cas contraire, la demande sera retransmise au serveur DNS local. Sinon, le processus de sélection est déclenché. I. 2. La Phase de Sélection Le processus de sélection du meilleur serveur réplica se déroule comme suit : a. Le serveur DNS-CDN diffuse une requête à tous les serveurs réplica ayant le contenu demandé en leur demandant d envoyer leur estimation de la QoE. A cette fin, la requête contient : l adresse IP du client cible afin de permettre aux serveurs réplica de mesurer la performance du réseau entre eux et le client. le nom du contenu afin de le mettre en cache et/ou le mettre à jour selon la politique du serveur. le délai d expiration (timeout) de la requête au bout de laquelle le serveur réplica doit répondre. b. Chaque serveur réplica mesure la performance du réseau, en termes de latence et taux de perte, entre lui et le client afin d estimer la QoE à partir de l un des 114

115 CHAPITRE V Conception d un protocole de Méta-Routage basé sur la QoE modèles de corrélation QoE-QoS trouvés dans la section III.3.4 du chapitre V. Cette estimation de la QoE est ensuite envoyée au serveur DNS-CDN avant que l expiration du timeout. c. Une fois le timeout expiré, le serveur DNS-CDN désigne le serveur réplica ayant la meilleure estimation de la QoE. I. 3. La Phase de Connexion Une fois le Meilleur Serveur Réplica (MSR) est sélectionné, le serveur DNS-CDN répond à la requête de résolution du nom du client en communiquant l adresse IP de ce serveur (MSR). Une session RTP/RTCP est ensuite établie entre le MSR et le client. La transmission de la vidéo sur le réseau utilise en effet les protocoles RTP/RTCP [SCF, 03] (Cf. section I.4 du chapitre I). Ces protocoles utilisent des ports différents. Le protocole RTP utilise un numéro de port pair, et le protocole RTCP le numéro de port impair qui suit directement. Lorsqu une session RTP est ouverte, une session RTCP est aussi ouverte de manière implicite. Les numéros de port utilisés par les protocoles RTP/RTCP sont compris entre 1025 et Les ports RTP et RTCP par défaut sont respectivement 5004 et I. 4. La Phase de Rétroaction Le protocole RTCP est basé sur des transmissions périodiques des rapports de rétroaction entre le client (récepteur) et le serveur réplica (émetteur). Parmi ces rapports, le rapport RR (Receiver Report) contient des informations statistiques de la qualité de la livraison des paquets RTP reçus au niveau du client. Ces informations permettent de calculer, entre autres, la latence et le taux de perte de paquets (Cf. section II.1.1) qui sont ensuite utilisées pour estimer la QoE à partir de notre modèle de corrélation QoE-QoS. Le serveur réplica décide ensuite d envoyer une demande de remplacement au serveur DNS- CDN dans le cas où la QoE atteint un seuil critique durant un intervalle donné. I. 5. La Phase d Adaptation L adaptation de notre protocole est basée essentiellement sur les demandes de remplacement envoyées au serveur DNS-CDN. Elle consiste en effet à rediriger le client vers un autre serveur réplica meilleur que le serveur courant sans interruption du service 115

116 CHAPITRE V Conception d un protocole de Méta-Routage basé sur la QoE dans l objectif de maintenir une un bon niveau de performance perçue durant toute la session du transfert. Cette opération, connue sous le terme anglais «midstream handoff» 18, doit se faire de manière transparente au client. Nous tenons aussi à préciser que dans le cas où le serveur DNS-CDN ne reçoit aucune demande de remplacement durant un certain intervalle assez long (qu'il faudra paramétrer), le serveur DNS-CDN lance le processus d équilibrage de charges entre les serveurs réplicas. II. UNE EXTENSION SUR NS-2 POUR LA VALIDATION DE LA REDIRECTION DNS DANS LES RESEAUX DE DISTRIBUTION DE VIDEO En général, la mise en place d un nouveau protocole nécessite sa validation par l un des processus suivants : la simulation au moyen d outils spécifiques ou l expérimentation sur une plate-forme réelle. Ne disposant pas d une véritable plate-forme CDN de tests, nous avons opté pour la simulation afin de valider notre protocole de méta-routage. Pour ce faire, il est nécessaire de pouvoir simuler la redirection DNS ainsi que la transmission vidéo dans un réseau de distribution de contenus de type vidéo, appelé aussi réseau de distribution de vidéo (Video Distribution Network, VDN). A notre connaissance, il n existe aucun simulateur offrant cette possibilité. Cependant, des solutions partielles ont été proposées. Parmi ces solutions, nous distinguons principalement le simulateur CDN CDNSim [SPV, 10] et des extensions sur le simulateur réseau NS-2 permettant de simuler la redirection DNS dans un CDN comme dans [SHZ, 03], [CFO, 10] et [BHM, 11] ou de simuler la transmission vidéo à travers le protocole RTP/RTCP comme dans [BGK, 08], [ZHJ, 08], [FRI, 09] et [BMV, 10]. Comme discuté dans l annexe B, après avoir passé en revue ces principales solutions, nous avons opté pour une nouvelle extension sur NS-2 combinant à la fois la solution de Shen et Zhao [SHZ, 03] avec celle de Boronat et al. [BMV, 10] pour simuler respectivement la redirection DNS et la transmission vidéo. La figure V.2 présente l architecture de l ensemble des outils de simulation nécessaires à la validation de notre protocole de méta-routage. Cette architecture passe par deux étapes : la génération du fichier de trace du trafic vidéo et la simulation du réseau avec NS- 2. En effet, les modèles du trafic dans NS-2 (CBR, VBR, ) ne permettent pas de 18 En français, la traduction correspondante est «un transfert intercellulaire en plein milieu de session du transfert». Pour le reste de document, nous allons retenir l appellation «midstream handoff». 116

117 CHAPITRE V Conception d un protocole de Méta-Routage basé sur la QoE représenter le modèle de trafic vidéo, il faut donc générer un fichier de trace du trafic vidéo compatible avec NS-2 afin de rendre la simulation plus réaliste. Pour ce faire, il faut configurer un serveur VLC pour qu'il diffuse, en local et via un stream RTP/MPEG, un fichier vidéo encodé. En parallèle, l'outil rtpdump est lancé en écoute sur le même port afin d'enregistrer les informations des paquets RTP dans un fichier de sortie. Ce dernier fichier sera ensuite converti en un fichier de trace de trafic compatible avec NS-2 contenant des informations utiles telles que le numéro de séquence, la taille et le temps d'émission pour chaque paquet RTP. Dans la deuxième étape, nous introduisons notre propre extension sur NS-2 afin de valider la redirection DNS dans les VDNs. Dans cette extension, nous utilisons (i) une version modifiée de RTP_gs [BMV, 10], que nous appelons RTP-CDN, permettant d inclure les fonctionnalités supplémentaires caractérisant les clients et les serveurs réplica du CDN, (ii) un nouvel agent DNS-CDN permettant de rediriger les requêtes du client au niveau du DNS vers le serveur réplica ayant la meilleure estimation de la QoE, et (iii) des nouveaux paquets permettant de communiquer entre les clients, les serveurs réplica et le serveur DNS-CDN. Figure V.2. L architecture de notre ensemble d outils de simulation. 117

118 CHAPITRE V Conception d un protocole de Méta-Routage basé sur la QoE II.1. Le Protocole RTP-CDN Comme décrit dans l annexe B, plusieurs implémentations du protocole RTP/RTCP [BMV, 10] [BGK, 08] [ZHJ, 08] [FRI, 09] ont été proposées afin de remédier aux lacunes de l implémentation native de ce protocole dans NS-2. Parmi ces implémentations, l implémentation du Boronat et al. [BMV, 10] (nommée RTP_gs pour RTP group synchronization) est la seule conforme aux spécifications RFC 3550 [SCF, 03]. Elle inclut en effet plusieurs améliorations, notamment : (i) la définition de tous les types de paquets RTCP (SR, RR, SDES, APP et BYE) avec leur format exact; (ii) la surveillance, la notification et l enregistrement des métriques QoS au cours de la simulation; (iii) la capacité de traiter tout modèle de trafic d application; et (iv) la compatibilité avec le code NS-2 existant. Au regard de ces améliorations, nous avons choisi de travailler sur l implémentation du RTP_gs afin d inclure les fonctionnalités supplémentaires caractérisant les clients et les serveurs réplica du CDN. Etant donné que le protocole RTP s inscrit dans un modèle client/serveur, nous avons choisi de créer un nouvel agent «RTP-CDN» héritant de la classe «RTP_gs» et jouant à la fois le rôle du client CDN et du serveur réplica. Le client RTP-CDN envoie ainsi une demande de résolution de nom (DNS REQuest, DNS-REQ) au serveur DNS-CDN. Ensuite, dés qu il reçoit la réponse du serveur DNS-CDN (DNS RESponse, DNS-RES) contenant l adresse IP du meilleur serveur réplica, il établit une session RTP\RTCP avec ce serveur. Le serveur RTP-CDN sera donc amené à exécuter une des actions suivantes : - recevoir une demande d estimation de la QoE (QoE REQuest, QoE-REQ) à laquelle il doit répondre par un rapport de rétroaction (QoE RESponse, QoE-RES) contenant une estimation de la QoE. Cette réponse est prise en compte dans la sélection du meilleur serveur réplica ou lors du processus d équilibrage de charges. - envoyer une demande de remplacement (REPlacing REQuest, REP-REQ) si la QoE se détériore afin d être remplacé par un autre meilleur serveur réplica, - recevoir une commande «MIDSTREAM» pour effectuer le «midstream handoff» qui redirige le client RTP-CDN vers un autre meilleur serveur réplica (soit le serveur Z). Pour ce faire, il envoie un message «REDIRECT» au client pour l informer de la fermeture de leur session courante et le rediriger vers le nouveau serveur Z. Ce dernier est aussi informé de ce transfert, à l aide du message «INFORM», afin d accepter l ouverture d une nouvelle session RTP/RTCP avec le client. 118

119 CHAPITRE V Conception d un protocole de Méta-Routage basé sur la QoE La figure V.3 présente les principales interactions entre les entités du CDN à l aide d un diagramme de séquence. 119

120 CHAPITRE V Conception d un protocole de Méta-Routage basé sur la QoE dans les CDN Figure V. 3. Les principales interactions des entités du CDN. 120

121 CHAPITRE V Conception d un protocole de Méta-Routage basé sur la QoE II.1.1. Mesure de Performance du Réseau A la réception d une demande d estimation de la QoE (QoE REQuest, QoE-REQ), le serveur RTP-CDN doit mesurer la performance du réseau en termes de latence (IPTD) et taux de perte (IPLR) entre lui et le client cible RTP-CDN. Cette mesure peut se faire d une manière explicite ou implicite : - Avant l établissement d une session RTP/RTCP entre le serveur et le client cible, le calcul de performance du réseau se fait explicitement par le biais de l utilitaire PING (Packet INternet Groper) qui s'appuie sur le protocole ICMP (Internet Control Message Protocol) [POS, 81]. Le serveur envoie ainsi un certain nombre des requêtes «ECHO» au client cible qui répond avec des paquets «ECHO_REPLY». La différence entre le nombre des paquets ECHO envoyés et le nombre des paquets ECHO_REPLY reçus présente le nombre des paquets «ECHO_REPLY» perdus. Elle permet ainsi de déduire le taux de perte de paquets (V.1). La latence de chaque paquet ECHO_REPLY est calculée comme étant la différence entre l instant de réception ( ) 19 et l instant d envoi ( ). Elle permet ainsi de déduire la latence moyenne (V.2). [ ] (V.1) [ ] ( ) ( ) (V.2) - Au cours d une session RTP/RTCP ouverte entre le serveur et le client cible, le calcul de performance du réseau se fait implicitement par le biais de rapport RR (Receiver Report) du RTCP. En effet, le calcul du taux de perte (IPLR) est basé sur le champ «Fraction lost» du RR qui indique la fraction de perte des paquets RTP depuis le dernier rapport émis. Cette fraction (V.3) représente le rapport entre le nombre de paquets perdus et le nombre de paquets attendus déduit à partir du numéro de séquence de chaque paquet RTP reçu. Par ailleurs, plusieurs solutions peuvent être envisagées pour estimer la latence (ou le temps émetteur récepteur) au niveau du serveur [CHA, 00]. La solution la plus simple est basée sur le champ «NTP timestamp 20» du RR. Elle calcule la différence entre l instant de réception 19 Les paquets ICMP (ECHO et ECHO_REPLY) sont des simples paquets NS-2 incluant le champ timestamp (32 bits) qui représente l horodatage (en millisecondes) du paquet. 20 Le champ NTP timestamp indique l instant d émission (en secondes) du paquet RTCP SR. Il utilise le protocole NTP (Network Time Protocol) pour présenter la date (64 bits). 121

122 CHAPITRE V Conception d un protocole de Méta-Routage basé sur la QoE ( ) et l instant d envoi ( ) du paquet RR comme indiqué dans (V.4). Notons ici que le serveur estime la QoE perçue au niveau du client à chaque fois qu il reçoit un paquet RR. A la réception de la requête QoE-REQ, le serveur répond ainsi avec sa dernière mesure de la QoE. D autre part, dés que la valeur de la QoE calculée atteint un seuil critique durant un intervalle donné T, il envoie une demande de remplacement (REP-REQ) au serveur DNS-CDN contenant la moyenne de la QoE (que nous appelons QoE-seuil) durant l intervalle T. [ ] (V.3) [ ] ( ) (V.4) II.2. Agent DNS-CDN Comme le montre le digramme d activité ci-dessous (Figure V.4), les principales fonctionnalités de l agent DNS-CDN peuvent se résumer comme suit : - A la réception d une demande de résolution de noms (DNS-REQ), l agent DNS- CDN vérifie que le contenu demandé est disponible dans le CDN avant de déclencher/lancer le processus de sélection (Cf. section I. 2). Une fois le meilleur serveur réplica (par exemple serveur Y) sélectionné, il envoie une réponse (DNS- RES) à la requête DNS-REQ contenant l adresse IP du serveur Y. - A la réception d une demande de remplacement (REP-REQ) de la part d un serveur réplica (par exemple le serveur X), l agent DNS-CDN relance le processus de sélection avec une contrainte supplémentaire : le meilleur serveur réplica (que nous appelons le serveur Y) doit fournir une QoE supérieure à la valeur de la QoE indiquée (QoE-seuil) dans la demande de remplacement. Si le processus de sélection ne trouve aucun serveur meilleur alors la demande du serveur X n est pas prise en considération et sa connexion avec le client cible est maintenue. Sinon, l agent DNS-CDN envoie une commande «MIDSTREAM» au serveur X afin de rediriger le client cible vers le nouveau serveur Y en effectuant le «midstream handoff» comme décrit dans la section précédente. - Enfin, si le serveur DNS-CDN ne reçoit aucune demande de remplacement de la part du serveur X durant un certain intervalle assez long, il déclenche le processus d équilibrage de charges qui consiste à rechercher un serveur réplica meilleur que le serveur X. Si ce serveur existe, alors le client sera redirigé vers lui en effectuant le «midstream handoff». Ces fonctionnalités seront implémentées dans les méthodes «command» et «recv» de la superclasse «agent.cc». 122

123 CHAPITRE V Conception d un protocole de Méta-Routage basé sur la QoE dans les CDN Figure V.4. Le fonctionnement du serveur DNS-CDN. 123

124 CHAPITRE V Conception d un protocole de Méta-Routage basé sur la QoE II.3. Nouveaux Paquets En correspondance avec ces deux nouveaux agents créés (DNS-CDN et RTP-CDN), nous avons également introduit plusieurs nouveaux paquets: DNS-REQ, DNS-RES, QoE- REQ, QoE-RES, ECHO, ECHO_REPLY, REP-REQ, MIDSTREAM, REDIRECT et INFORM. Les deux paquets de l utilitaire PING (ECHO, ECHO_REPLY) correspondent à des simples paquets NS-2. Par ailleurs, les autres paquets correspondent à des nouveaux entêtes de paquets héritant tous de la superclasse PacketHeaderClass. Nous ajoutons en effet quelques champs nécessaires pour l'entête de paquets par défaut dans les nouveaux entêtes de paquets créés. Ces champs sont (tableau V.1): - «Content_name» qui indique le nom de contenu. Il est nécessaire dans tous les nouveaux paquets. - «Client_adr» qui peut indiquer une des trois variantes suivantes: l adresse IP du client cible demandant le contenu (QoE-REQ), l adresse IP du client cible avec lequel est connecté le serveur réplica demandant le remplacement (REP-REQ) ou l adresse IP du client cible avec lequel le serveur va établir une session RTP (INFORM). - «Serveur_adr» qui présente l adresse IP du serveur réplica vers lequel sera redirigé le client. - «QoE» qui contient la valeur de la QoE estimée au niveau du serveur réplica. - «Timeout» qui indique le délai d expiration de la requête QoE-REQ avant lequel le serveur réplica doit répondre. Tableau V. 1. Correspondance entre les paquets et les champs Champs Content_name Client_adr Server_adr QoE Timeout Paquets DNS-REQ x 21 DNS-RES x x QoE-REQ x x x QoE-RES x x x x REP-REQ x x x MIDSTREAM X x x REDIRECT X x INFORM X x 21 x signifie que le champ A est nécessaire dans le paquet B. 124

125 CHAPITRE V Conception d un protocole de Méta-Routage basé sur la QoE CONCLUSION Dans ce dernier chapitre, nous avons décrit notre protocole adaptatif de méta-routage basé sur la QoE dans les CDNs. Dans un premier temps, nous avons décrit le fonctionnement de ce protocole qui passe par cinq phases: (i) la phase d initiation où le client envoie une requête de résolution de nom au serveur DNS-CDN, (ii) la phase de sélection du serveur réplica approprié ayant la meilleure estimation de la QoE, (iii) la phase de connexion où une session RTP/RTCP entre le client et le serveur réplica désigné est établie, (iv) la phase de rétroaction de la QoE et (v) la phase d adaptation où le «midstream handoff» est effectué afin de maintenir un bon niveau de la QoE. Comme il n existe aucun simulateur réseau capable de simuler la redirection DNS dans les VDNs, nous avons ensuite conçu notre propre solution afin de faciliter nos travaux futurs devant mettre en ouvre le protocole proposé. Cette solution combine celle de Shen et Zhao [SHZ, 03] (la simulation de la redirection DNS) avec celle proposée par Boronat et al. [BMV, 10] (simulation de la transmission vidéo à travers le protocole RTP_gs). Nous avons ainsi introduit dans notre extension sur NS-2 une version modifiée de RTP_gs [BMV, 10], un nouvel agent DNS-CDN et des nouveaux paquets de communication. 125

126 Conclusion Générale & Perspectives CONCLUSION GENERALE & PERSPECTIVES L objectif de notre travail fut de proposer un protocole de méta-routage basé sur la QoE dans les CDN. Pour ce faire, il a été nécessaire, dans un premier temps, de définir les principales métriques permettant d évaluer le degré de satisfaction des utilisateurs des services vidéo. Dans cette étude, nous nous sommes limités volontairement sur le concept KQI\KPI pour définir un simple modèle de métriques de la QoE. Au niveau de ce modèle, la QoE est rapportée à trois KQIs, à savoir : la disponibilité, la réactivité et la qualité de vidéo, supportés par deux KPIs qui sont la latence et le taux de perte. Par ailleurs, la correspondance entre les KPIs, les KQIs et la QoE a été déterminée en fonction des deux types de régression: simple et multiple. En fait, sur la base d'une étude utilisant la régression linéaire multiple, nous avons proposé, dans un deuxième temps, un modèle de corrélation exponentiel global dans lequel la QoS est modélisée comme une somme pondérée de plusieurs paramètres (taux de perte, latence, ). L expérimentation de notre modèle de métriques a permis de déduire plusieurs modèles de corrélation QoE-QoS de bonne qualité. Nous avons ensuite décrit une première version de protocole de méta-routage permettant de rediriger en temps réel, et de manière adaptative, les requêtes de l utilisateur dans la phase de résolution des noms (DNS) vers le meilleur serveur réplica offrant la meilleure QoE. Afin de faciliter dans le futur la mise en œuvre du protocole proposé, nous avons introduit une extension sur le simulateur réseau NS-2 capable de simuler à la fois la redirection DNS et la transmission vidéo dans un réseau de distribution de vidéo (VDN). Comme perspectives de recherche et de travaux futurs, nous pouvons envisager les points suivants : - Concernant notre modèle de métriques de la QoE, plusieurs améliorations peuvent être apportées. L échantillon de données peut être enrichi par d autres mesures dans le but d'avoir une seule classe homogène lors de la régression, et ainsi obtenir de bons modèles de corrélation simple (non composite) correspondant à l ensemble de l échantillon et non pas à des parties (ou classes) de l échantillon. Ensuite, au lieu de prendre la disponibilité comme une variable booléenne (0 ou 1) indiquant si le serveur est connecté ou non, il serait intéressant qu elle caractérise l état de charge du serveur vidéo qui peut être calculée en fonction de la charge CPU, de la charge d'interface réseau, du nombre de connexions actives et/ou de la charge des entrées-sorties de stockage. Il serait également avantageux de mesurer la réactivité 126

127 Conclusion Générale & Perspectives en termes d OS plutôt qu en termes de temps de démarrage. Ainsi, l utilisateur aura la possibilité de cliquer sur toutes les fonctions de contrôle du lecteur vidéo (lecture, pause, stop, retour et avance rapide) afin de pouvoir évaluer la réactivité du service. Enfin, il serait important de connaître l impact des autres paramètres de QoS (la bande passante et la gigue) sur les KQIs ainsi que sur la QoE. - Concernant nos modèles de corrélation entre la QoE et la QoS, plusieurs tests doivent être effectués. D une part, le modèle de corrélation QoV-QoS nous a permis de définir une méthode sans référence et paramétrique afin d évaluer la QoV. Il serait donc intéressant de comparer cette approche d évaluation de la QoV avec d autres méthodes. Nous pensons à développer une plateforme d évaluation de la QoV en ajoutant une troisième étape à notre extension sur NS-2. Celle-ci permettra de reconstruire les flux vidéo reçus en vue d évaluer sa qualité en utilisant plusieurs méthodes objectives avec référence complète, avec référence réduite et sans référence. D autre part, les modèles de corrélation QoE-QoS proposés devront être testés dans une configuration expérimentale afin de montrer leur efficacité. Cela pourra être fait une fois que nous mettrons en ouvre notre protocole de méta-routage. - Après la validation de cette première version du protocole de méta-routage, il serait intéressant d introduire d autres versions permettant de prendre en compte : Le mode Pull où le contenu vidéo est récupéré du serveur d origine lors de l arrivée d une requête client sur le serveur. Dans ce cas, le serveur DNS-CDN interagit également avec le serveur d origine pour l informer du résultat de sa sélection afin de placer le contenu dans le serveur réplica sélectionné. Le mode Partial-Site où le contenu est partiellement répliqué sur les serveurs réplica. Dans ce cas, la redirection DNS est combinée avec la réécriture URL de telle manière que le serveur DNS-CDN redirige le client vers plusieurs meilleurs serveurs réplicas ayant chacun une partie du contenu. - Enfin, une fois la notion de QoE des services vidéo bien maîtrisée, nous envisageons de nous orienter vers les services multimédia où la synchronisation entre la vidéo et l audio pose un grand défi. 127

128 ANNEXES 128

129 ANNEXE A LA PLATEFORME D EXPERIENCE INTRODUCTION La plateforme utilisée dans notre phase d'expérimentation (Cf. Section III.1 du Chapitre IV) est composée des éléments suivants (Figure A.1): - Une architecture client-serveur avec un client vidéo de type VLC et un serveur streaming vidéo VLC. - Un émulateur réseau (Network Emulator, NetEm) pour produire un réseau réel dans un environnement laboratoire. - Une interface de test pour calculer le temps de démarrage (la réactivité) et recueillir les retours QoV et QoE des observateurs. Dans ce qui suit, nous donnons une brève description des outils utilisés dans notre plateforme d expérience.

130 Annexe A La Plateforme d Expérience Figure A.1. La plateforme de l expérience. I. Lecteur Multimédia VLC VLC 22 est un lecteur multimédia libre, gratuit et multiplateforme (Windows, GNU/Linux, BSD, Mac OS X, Pocket PC). Il supporte les codecs nécessaires à la lecture de la plupart des formats audio et vidéo. Il permet aussi de diffuser un contenu multimédia (vidéo, audio) à travers un réseau local ou le réseau Internet. Après avoir configuré le serveur VLC pour une diffusion d'un fichier multimédia, les clients peuvent ensuite accéder à ce contenu en ouvrant un flux réseau. Plus de détails sur le streaming VLC est fourni dans [LBD, 05]. II. Emulateur Réseau NetEm Le rôle d un émulateur réseau est d imiter les fonctions d'un réseau étendu dans le cadre d'une expérimentation laboratoire. Les émulateurs de réseau les plus populaires sont dummynet 23, le NIST net 24, NetEm 25 et ALTQ 26. [GUR, 09] a présenté une étude comparative entre ces quatre émulateurs. NetEm a été sélectionné comme étant l'émulateur le plus approprié

131 Annexe A La Plateforme d Expérience NetEm [HEM, 05] émule un réseau étendu en donnant la possibilité de réguler soi même les paramètres de ce réseau comme le délai, la perte de paquets, la duplication de paquets, la corruption de paquets, le re-ordonnancement de paquets et le contrôle de débit. Par ailleurs, il permet aussi de spécifier l interface réseau à travers laquelle le trafic sera filtré en entrée et/ou en sortie. La figure A.2 présente l'exemple d'une instruction NetEm permettant de générer 1% de perte avec 100 ms de latence sur les paquets émis par l'interface eth0. La figure A.3 décrit un ensemble d instructions NetEm permettant de générer les mêmes perturbations réseau (1% de perte avec 100 ms de latence) mais sur les paquets entrants de l'interface eth0. # tc qdisc add dev eth0 root netem delay 100ms loss 1% # modprobe ifb # ip link set dev ifb0 up # tc qdisc add dev eth0 ingress Figure A.2. L exemple 1 du NetEm. # tc filter add dev eth0 parent ffff: protocol ip u32 match u flowid 1:1 action mirred egress redirect dev ifb0 # tc qdisc add dev ifb0 root netem delay 100ms loss 1% Figure A.3. L exemple 2 du NetEm. III. Interface de Test Afin de faciliter nos tests, nous avons développé une interface graphique Qt 27 regroupant plusieurs fenêtres, notamment: - «Lecteur Video» pour créer un client VLC, - «Configuration» pour émuler un réseau étendu, - «Chronomètre» pour calculer le temps de démarrage, - «Interface OS» pour recueillir le retour des observateurs. 27 Qt est un framework orienté objet développé en C++ par Qt Development Frameworks, filiale de Nokia. C est une bibliothèque multiplateforme (Linux, Windows, Mac OS) offrant des composants d'interface graphique (widgets), d'accès aux données, de connexions réseaux, de gestion des fils d'exécution, d'analyse XML, etc. Le kit de développement logiciel Qt ainsi que sa documentation officielle sont disponible sur 131

132 Annexe A La Plateforme d Expérience La figure A.4 illustre le processus du déroulement d une seule expérience. (1) Le développeur choisit au démarrage de l'expérience une configuration réseau (IPTD, IPLR) et l exécute à partir de la fenêtre «Configuration». Ensuite, (2) l utilisateur demande un flux vidéo 28 en cliquant sur le bouton «OK» de la fenêtre «Lecture vidéo». (3) La fenêtre «Chronomètre» s affiche pour calculer le temps de démarrage. (4) A l'apparition de la vidéo, l utilisateur arrête le chronomètre en cliquant sur le bouton «stop». Après deux minutes, la fenêtre VLC se ferme et (5) l interface OS s ouvre afin de recueillir le retour de l utilisateur concernant la QoV et la QoE exprimé sur une échelle continue d OS. 28 La vidéo est de résolution 432x320, du débit 25 images par seconde et de codec MPEG-4 (XVID). Cette vidéo a été choisie car elle alterne les mouvements lents et rapides. 132

133 Annexe A La Plateforme d Expérience Figure A.4. Le processus du déroulement d une seule expérience. 133

134 ANNEXE B LE CHOIX DES OUTILS DE SIMULATION INTRODUCTION Afin de mettre en ouvre le protocole de méta-routage proposé (Cf. section I du chapitre V), nous avons besoin de simuler à la fois la redirection DNS et la transmission vidéo dans un réseau de distribution de vidéo (VDN). A notre connaissance, il n existe aucun simulateur offrant cette possibilité. Cependant, des solutions partielles ont été proposées. Parmi ces solutions, nous distinguons principalement le simulateur CDN CDNSim [SPV, 10] et des extensions sur le simulateur réseau NS-2 permettant soit de simuler la redirection DNS dans un CDN comme dans [SHZ, 03], [CFO, 10] et [BHM, 11] soit de simuler la transmission vidéo à travers le protocole RTP/RTCP comme dans [BGK, 08], [ZHJ, 08], [FRI, 09] et [BMV, 10]. Avant de discuter notre choix d outils de simulation nécessaires pour la mise en œuvre de notre protocole, nous passons en revu les principales solutions.

135 Annexe B Le Choix des Outils de Simulation I. SIMULATEUR CDN CDNSim Le simulateur CDN (CDN Simulator, CDNSim) [SPV, 10] est un logiciel libre permettant de simuler les principales caractéristiques du CDN (Cf. Tableau B.1). De plus, il utilise le simulateur réseau OMNET++/INET 29 pour les opérations basiques des réseaux comme la transmission TCP/IP et l ordonnancement à événement discret. La topologie du réseau de CDNsim se compose d'un ensemble de nœuds génériques interconnectés par des liens du réseau et des nœuds routeur. Ces nœuds génériques sont: (i) le nœud «client» pour générer les requêtes (ii) le nœud «serveur réplica» pour servir les requêtes des clients, (ii) le nœud «serveur d'origine» pour distribuer le contenu aux serveurs réplica et (iv) le nœud «redirecteur DNS» pour rediriger la requête du client au serveur réplica le plus proche en termes de distance réseau. A notre connaissance, dans [SPV, 10], les auteurs ne spécifient pas à quoi correspond cette distance réseau (nombre de sauts ou un calcul plus complexe), et ils n indiquent pas comment faire étendre ce critère de sélection pour inclure d autres métriques. En outre, malgré que CDNSim supporte tout type du contenu (pages web statique et médias en streaming), le trafic média n est pas traité comme un trafic temps réel (UDP ou RTP) mais comme un simple trafic TCP. Le code source de CDNsim est disponible sur le lien Tableau B. 1. Les principales caractéristiques du CDNSim [SPV, 10]. Topologie du CDN Types de Serveurs Type de Relation Types de Contenu Serveurs d origine et Serveurs Réplica Client Serveurs Réplica Serveur Origine Web statique, Média en streaming Système de Distribution du Contenu Placement des serveurs réplica Placement du contenu Livraison du contenu N importe quelle politique N importe quelle politique Pull/Push ; Partial-Site/Full-Site Système de Routage de Requêtes Mécanisme de routage des requêtes Routage de requête à base de DNS

136 Annexe B Le Choix des Outils de Simulation II. SIMULATEUR RESEAU NS-2 NS-2 (Network Simulator 2) 30 est un simulateur réseau orienté objet, à événements discrets, écrit en C++ et OTcl. Il couvre un très grand nombre d'applications (web, ftp, telnet), de protocoles (TCP, UDP, RTP, SRM), des types de réseaux (filaires, sans fil et satellite), d éléments de réseau (Nodes, Link et Queuing), et de modèles de trafic (CBR, VBR, Exponential, etc.). De plus, NS-2 est un logiciel libre permettant ainsi d apporter des modifications à son code source afin d ajouter des nouveaux protocoles et de nouvelles fonctionnalités. C est pourquoi, il est le plus populaire au sein de la communauté scientifique. Par la suite, nous présentons des extensions sur NS-2 permettant soit de simuler la redirection DNS dans un CDN soit de simuler la transmission vidéo à travers le protocole RTP/RTCP. II.1. Redirection DNS Dans la littérature, nous avons trouvé trois extensions sur NS-2 permettant de simuler la redirection DNS dans un CDN. En premier, dans le but de simuler l équilibrage de charge entre les serveurs réplica, Shen et Zhao [SHZ, 03] ont proposé de créer quatre nouveaux agents 31 : (i) «cdn_client» pour envoyer la requête de résolution du nom au «cdn_dns» et traiter sa réponse en envoyant la requête de données au «cdn_server» approprié, (ii) «cdn_dns» pour rediriger l agent «cdn_client» au «cdn_server» approprié en utilisant la table de hachage qui maintient ses informations de routage (adresse source, adresse destination et type de contenu), (iii) «cdn_server» pour envoyer les données demandées au «cdn_client» et une notification au «cdn_router», et (iv) «cdn_router» pour exécuter l algorithme de l équilibrage de charge local basé sur le critère du nombre de connexions. Le code source est disponible sur le lien Ensuite, afin d évaluer certains algorithmes typiques d équilibrage de charge (Random, Least Loaded, 2 Random Choices), Cece et al. [CFO, 10] ont proposé une autre extension Généralement, les protocoles dans NS-2 sont implémentés comme des agents qui présentent des extrémités du réseau où les paquets sont construits ou consommés. La classe «agent.cc» est utilisée comme une superclasse pour la mise en œuvre des nouveaux protocoles. 136

137 Annexe B Le Choix des Outils de Simulation sur NS-2 permettant de simuler l infrastructure des réseaux de distribution de contenus HTTP. Cette extension introduit plusieurs classes C++ notamment: (i) «CdnData» pour les messages de données, (ii) «CdnAgent» pour envoyer et recevoir les messages, (iii) «CdnClient» pour générer les requêtes HTTP et traiter les messages de redirection et (iv) «CdnServer» pour traiter les requêtes HTTP entrantes, exécuter les algorithmes de l équilibrage de charge et envoyer les messages de redirection aux clients. Récemment, Bhardwaj et Malhotra [BHM, 11] ont proposé une simple implémentation de la redirection DNS dans le but de comparer entre certaines techniques de hachage (Modulo Hashing, Consistent Hashing et Highest Random Weight). Cette implémentation introduit seulement trois agents dans NS-2: (i) «CDN_CLIENT» pour envoyer la requête de résolution du nom au «CDN_DNS» et recevoir le contenu demandé à partir du «CDN_SERVER», (ii) «CDN_DNS» pour rediriger la requête du «CDN_CLIENT» au «CDN_SERVER» approprié après avoir exécuté une technique de hachage donnée et (iii) «CDN_SERVER» pour servir le «CDN_CLIENT» avec le contenu demandé en se basant sur les informations reçues de la part de «CDN_DNS». II.2. Transmission de la Vidéo à travers RTP/RTCP Comme nous l avons précisé dans la section I.4 du chapitre I, la transmission de la vidéo en temps réel utilise une pile des protocoles sur le réseau Internet notamment le protocole de transport de données RTP et son compagnon le protocole de contrôle RTCP [SCF, 03]. Ce dernier est basé sur des transmissions périodiques des rapports de rétroactions entre les serveurs (sources) et les clients (puits) des médias. Il existe en effet cinq types différents de paquets: (i) la description de la source (Source Description, SDES) permettant d identifier les participants à une session et de fournir des informations sur ces participants, (ii) le rapport de l émetteur (Sender Report, SR) contenant des statistiques de transmission et de réception pour les émetteurs, (iii) le rapport de récepteur (Receiver Report, RR) contenant des informations statistiques de la qualité de la livraison des paquets RTP perçu au niveau des récepteurs, (iv) le message BYE envoyé si un récepteur quitte une session RTP et (v) les messages d application (Application, APP) utilisés pour ajouter de nouveaux messages aux paquets RTCP contenant des informations spécifiques à l application. Dans NS-2, les protocoles RTP et RTCP sont mis en œuvre en utilisant respectivement la classe «rtp.cc» et la classe «rtcp.cc». La classe «rtp.cc» implémente les fonctionnalités d envoi et de réception des paquets RTP, tandis que la classe «rtcp.cc» implémente seulement la transmission et la réception des paquets SR. La classe «session-rtp.cc» traite principalement la création des rapports de rétroaction et le maintien des tables 137

138 Annexe B Le Choix des Outils de Simulation d'information des participants à travers les paquets de contrôle reçus auprès de ses agents. Cette classe est appelée par la classe OTcl «session-rtp.tcl» qui définit les procédures d'initialisation de la session, le calcul des intervalles de rétroaction (et sa valeur initiale), le réglage de la taille et le taux de transmission de paquets RTP, l attribution des identificateurs des flux, l association des nouvelles sessions RTP avec les nœuds, l'arrêt des transmissions des flux RTP, la libération des ressources de la session, etc. Tous ces fichiers C++ utilisent «rtp.h» en tant que fichier d'en-tête. Ses emplacements dans l architecture NS sont illustrés dans la figure B.1. Figure B.1. L architecture du NS. Cependant, cette implémentation native des protocoles RTP et RTCP dans NS-2 est imprécise et incomplète [BMV, 10]: (i) seul le paquet RTCP SR est défini (ii) le format de ce paquet SR n est pas conforme aux spécifications RFC 3550 [SCF, 03], (iii) vu que les messages RR ne sont pas définies, alors la surveillance et le contrôle des métriques QoS ne sont pas fournis, (iv) le même entête de paquet est utilisé dans la construction des deux paquets RTP et RTCP, (v) Les champs d'entête de paquet ne sont pas conformes aux spécifications RFC 3550 en ce qui concerne leur type et leur taille, (vi) l'agent RTP est capable de générer seulement le trafic CBR (Constant Bit Rate), etc. Pour remédier à ces lacunes, des extensions de cette implémentation native du RTP/RTCP ont été proposées. Dans [BGK, 08], Bouras et al. ont étendu les fonctionnalités du code RTP/RTCP sous NS-2 afin de fournir les fonctionnalité définies dans RFC 3350 [SCF, 03] et employer le comportement de partage de la bande passante du TCP-Friendly pour la transmission multicast de données multimédia d un serveur à un certain nombre de récepteurs. Le code source, nommé RTPUP (RTP University of Patras), sa documentation et un exemple de simulation, sont disponibles sur: 138

139 Annexe B Le Choix des Outils de Simulation Zhou et Jang [ZHJ, 08] ont proposé un système nommé VSS (Vidéo Streaming Simulation) pour simuler la transmission vidéo MPEG-4. L'architecture de ce système comprend principalement trois étapes. Le but de la première étape est de générer le fichier de trace vidéo en utilisant un encodeur MPEG-4 et un générateur de fichier de trace vidéo. La deuxième étape consiste à simuler la transmission vidéo sur NS-2 en se basant sur une version modifiée de RTPUP permettant de: - employer le comportement du contrôle de congestion du TRFC (TCP Friendly Rate Control) pour tester sa performance et la comparer avec les autres contrôleurs de congestion. - supporter une classe de fichier de trace pour l'interface entre la première étape et la deuxième étape. - générer le fichier de trace de l émetteur et le fichier de trace du récepteur pour enregistrer les détails de la transmission. Dans la troisième étape, la vidéo reçue est régénérée en utilisant le fichier de trace généré lors de la simulation et les vidéos encodées dans la première étape. Cette vidéo est ensuite évaluée en utilisant la méthode avec référence complète PSNR (Peak Signal to Noise Ratio pour le rapport signal/bruit maximal) 32. [FRI, 09] a proposé de créer de nouveaux agents RTP et RTCP (nommés respectivement RTP_v2 et RTCP_v2) avec des fonctionnalités supplémentaires afin de fournir le contrôle de la perte et de la gigue dans le streaming vidéo MPEG-2 sur les réseaux sans fil (802.11e). Pour ce faire, l auteur a défini de nouvelles structures de données pour générer les paquets RTP et RTCP. Cependant, la taille des champs de ces structures de données n'est pas correcte et certains champs ne sont pas spécifiés dans la RFC 3550 [BMV, 10]. En outre, l'auteur a développé deux autres applications pour la distribution vidéo sous NS-2: (i) un générateur de fichier de trace (appelé mpg2trace) et (ii) une application émetteur/récepteur MPEG-2 capable d agir virtuellement comme un serveur/client de service streaming vidéo. Enfin, l'auteur évalue la performance en utilisant la méthode PSNR. Le code source, le générateur mpg2trace, l application émetteur/récepteur MPEG-2 ainsi que le guide d'installation sont disponible sur: 32 C est une mesure de la qualité de reconstruction de l'image reçue par rapport à l'image originale. 139

140 Annexe B Le Choix des Outils de Simulation Boronat et al. [BMV, 10] ont récemment proposé un cadre de simulation précis pour évaluer la QoV en streaming. Ils ont combiné : (i) NS-2 y compris une nouvelle implémentation du protocole RTP/RTCP (nommé RTP group synchronization, RTP_gs), (ii) une version modifiée de MyEvalvid-RTP [YKC, 08] contenant les outils RTP (RTPdump, RTPplay) 33, le lecteur média VLC, le logiciel ffmpeg 34 pour le codage et le décodage MPEG-4 et d'autres programmes pour les mesures de la QoV comme l afficheur YUV 35 et l outil VQMT 36. Comme le montre la figure B.2, l utilisateur doit suivre trois phases différentes, à savoir la phase de prétraitement, la phase de simulation et la phase de post-traitement pour évaluer la QoV. La première phase a pour objectif de générer un fichier de trace du trafic vidéo compatible avec NS-2 contenant des informations utiles, telles que le numéro de séquence, la taille et le temps d émission pour chaque paquet RTP. Dans la deuxième phase, les auteurs ont utilisé leur extension du module RTP/RTCP qui inclut les améliorations suivantes: (i) la définition de tous les types de paquets RTCP (SR, RR, SDES, APP et BYE) avec leur format exact; (ii) la surveillance, la notification et l enregistrement des métriques QoS au cours de la simulation; (iii) la capacité de traiter n'importe quel modèle de trafic d application; (iv) le support des flux multicast multiple sur le même nœud, v) la compatibilité avec le code NS-2 existant, et (vi) l inclusion d une fonctionnalité optionnelle avec l'approche de la synchronisation des groupes dans [MOB, 10]. Enfin, la dernière phase a pour objectif de reconstruire le flux vidéo reçu en vue d évaluer sa qualité en utilisant par exemple l outil VQMT. Le code source, le guide d'installation ainsi qu un exemple de simulation sont disponibles sur

141 Annexe B Le Choix des Outils de Simulation Figure B.2. L ensemble d outils pour évaluer la QoV [BMV, 10]. III. DISCUSSION Toutes les solutions permettant de simuler la redirection DNS dans un CDN supportent le fonctionnement des trois entités principales de notre architecture CDN (Cf. section I du chapitre V): le client, le serveur réplica et le serveur redirecteur. Cependant, la solution qui convient le mieux au fonctionnement du notre protocole de méta-routage est celle implémentée dans Shen et Zhao [SHZ, 03]. Les autres solutions ont été en effet écartées de notre choix pour les raisons suivantes : - Notre algorithme de sélection prend en compte une combinaison de métriques à travers le modèle de corrélation QoE-QoS proposé dans le chapitre IV. Dans le 141