Soutenance mémoire
Depuis l’avènement de l’informatique moderne mais plus particulièrement depuis l’avènement de l’informatique grand public dans les années 80, les ordinateurs ont été utilisés pour afficher du contenu multimédia. Au début ces contenus étaient relativement simples puis, au fil du temps, les ordinateurs sont devenus capables d’afficher des contenus de plus en plus complexes. Puis, avec l’arrivée d’Internet, l’idée de transmettre ces vidéos en temps-réel d’une machine à une autre est née. Il restait cependant de nombreux défis à relever. En effet, transmettre des vidéos en temps-réel nécessite des processeurs assez puissants pour supporter le décodage de la vidéo ainsi qu’une bande passante assez élevée pour le transmettre. Cependant, le débit disponible était très limité et la seule solution viable était de télécharger le média pour le visionner ultérieurement.
A partir de 2000, le développement d’Internet s’est accéléré. Le débit disponible est devenu beaucoup plus important avec la popularisation de l’accès à Internet haut-débit. Dans le même temps le nombre de personnes connectées a explosé. De nombreux services de streaming ont alors vu le jour. Pourtant, le streaming est resté limité aux formats d’encodage bas débit. Les formats d’encodages qui nécessitaient une plus grande bande passante, comme le HD (High Definition), n’étaient pas encore utilisés. Durant cette période de popularité croissante d’Internet, les utilisateurs se connectaient à Internet par des liaisons filaires, ce qui limitait leur mobilité. Des solutions ont été développées, notamment la technologie Wi-Fi qui permet à un dispositif (par exemple un ordinateur, une console de jeux, un smartphone) compatible de se connecter à Internet par le moyen d’un point d’accès sans avoir besoin d’y être relié par un câble (connexion dite sans-fil). Le Wi-Fi permet donc une très grande liberté de mouvement par rapport à une connexion filaire. Mais cette liberté est limitée car la portée du signal entre le mobile et le point d’accès est de l’ordre d’une dizaine ou d’une centaine de mètres. D’autres solutions s’appuyant sur les technologies de communication mobile comme par exemple la 3G ont fait leur apparition afin de pallier à cette limitation de portée et offrir aux utilisateurs une liberté de mouvement supérieure. Ainsi, un utilisateur connecté en 3G a la possibilité d’accéder au contenu d’Internet et d’être joignable n’importe où. Avec cette évolution vers une plus grande liberté de mouvement/mobilité, presque toute personne a la possibilité d’être connectée à Internet par le biais d’une de ces technologies.
Contrôle de congestion
L’effondrement congestif est une situation qu’un réseau informatique peut atteindre, quand peu ou pas de communications aboutissent à cause de la congestion. La congestion se produit généralement dans les goulots d’étranglement du réseau, où le débit des données entrantes dépasse le débit disponible sortant. Lorsqu’un réseau est dans cet état, la demande de trafic est élevé, mais peu de débit utile est disponible. Des niveaux élevés de retard sont constatés et des pertes de paquets sont causées par les routeurs qui les rejettent parce que leurs files d’attente sont pleines. La qualité générale du service est donc extrêmement mauvaise. Réduire la congestion a été identifié comme un problème dès 1984 (RFC 896 [Nag84]). Les premières tentatives de réduire la congestion sont apparues avec la mise en œuvre du mécanisme de contrôle de congestion Van Jacobson entre 1987 et 1988. Le contrôle de congestion est donc un mécanisme qui permet d’adapter le débit d’un ou de plusieurs flux au débit disponible dans un réseau. La plupart des mécanismes de contrôle de congestion utilisent des méthodes dites de bouten-bout afin d’estimer le débit disponible. Le protocole le plus utilisé actuellement est TCP. Il existe de nombreuses versions de TCP dont la plus utilisé est TCP NewReno. TCP est connu pour ne pas être bien adapté aux transmissions des données multimédia. C’est pourquoi d’autres protocoles spécifiques à ce genre de transmissions existent tels que UDP et DCCP. Le point commun entre ces deux protocoles est la non retransmission des paquets perdus sachant qu’elles ne sont pas toujours utiles.
Principe d’ECN
ECN (Explicit Congestion Notification) est une extension d’IP (Internet Protocol) définie dans la RFC3168 [RFB01]. ECN nécessite pour son fonctionnement un gestionnaire actif de file d’attente (Active Queue Management (AQM)) comme par exemple RED (décrit dans la section suivante), et supporte une notification de congestion de bout en bout sans perte de paquets. Son utilisation est facultative et elle n’est utilisée que lorsque les deux extrémités d’une même connexion souhaitent le faire. ECN utilise les deux bits les moins importants (plus à droite) bits du champ DiffServ dans l’en-tête IP. Cela donne la possibilité d’avoir quatre valeurs qui sont :
– 00 : non ECN-Capable
– 10 et 01 : ECN Capable – ECT
– 11 : congestion rencontrés – CE
Les flux voulant utiliser ECN modifient l’en-tête de la couche transport DCCP au début de la transmission afin de négocier leurs volontés de l’utiliser. Si la source et la destination acceptent son utilisation, les paquets envoyés entre elles seront marqués ECN capable (ECT 01 ou 10) dans l’en-tête IP. Quand un routeur compatible ECN entre en congestion, il met à jour les deux bits à 11 dans l’en-tête IP du paquet, que cela soit un paquet de donnée ou un accusé de réception, pour indiquer une congestion imminente. En réponse à ce signal ECN, le destinataire du paquet acquitte le paquet en indiquant les paquets marqués. En détectant la présence d’ECN dans l’acquittement, la source réagit, à son tour, en réduisant son débit comme si c’était un paquet perdu. Si l’acquittement en revanche est marqué lui aussi la source renégocie avec la destination le taux avec lequel les accusé de réception seront envoyés en diminuant ce taux.
Gestion active de la file d’attente : RED
De nos jours, les routeurs implémentant une stratégie active de gestion des files d’attente comme RED (Random Early Detection) sont nombreux. L’utilisation de RED conduit à un meilleur partage entre les différents flux passant par un routeur. Il permet également de gérer la congestion sur le réseau en fournissant des informations de retour négatives « feed-back » aux émetteurs par le rejet aléatoire des paquets de sa file d’attente lors d’une congestion imminente. La RFC3168 [RFB01] propose de marquer ces paquets au lieu de les rejeter. Ainsi, si l’utilisation d’ECN est activée dans le routeur et que le flux est compatible avec ECN, RED marque ces paquets au lieu de les rejeter. Pour ce faire, RED utilise nombreuses valeurs : la taille de la file d’attente ql ; la moyenne de la file d’attente qave ; le seuil minimum de la file d’attente qth_min et le seuil maximum de la file d’attente qth_max. Le traitement du paquet dépend de qavg :
– Si qave < qth_min, tous les paquets passent sans rejet ou marquage ECN.
– Si qth_min < qave < qth_max, les paquets sont marqués ou rejetés avec une probabilité qui augmente avec l’augmentation de qave.
– Finalement, quand qave > qth_max tous les paquets sont rejetés .
Simulateur de réseau : ns2
Le simulateur de réseaux ns2 [Net] fournit au monde de la recherche un support pour simuler un réseau avec différents protocoles de transport, protocoles de routage, gestions de files d’attente et d’autres applications sur les réseaux filaire et sans-fil. ns2 a été conçu de sorte que le code offre ré-utilisabilité et modularité. L’utilisation du simulateur ns2 est simple et flexible. De plus, les résultats des simulations sont reproductibles, ce qui permet de bien décrire des événements apparus pendant la simulation et d’en tirer des conclusions. Cela offre également la possibilité de vérifier très facilement l’influence d’un changement du code sur les résultats. ns2 est un simulateur à événements discret écrit en C++ avec le langage orienté objet Tcl (OTcl) pour configurer les objets. Ces objets sont des nœuds, des liaisons, des agents ou des applications. Les nœuds et les liaisons définissent la topologie du réseau. Les agents représentent les points finaux, tandis que les applications sont des sources de trafic qui envoient et reçoivent les données.
|
Table des matières
I Introduction générale
1 Introduction
2 Pré-requis
2.1 Contrôle de congestion
2.2 Principe d’ECN
2.3 Gestion active de la file d’attente : RED
2.4 Simulateur de réseau : ns2
2.5 Réseaux sans-fil
2.6 Utilisation du contrôle de trafic sur Linux
2.7 Modèles de propagation existants
II Amélioration des protocoles de transport sur les réseaux sans-fil par la différenciation de pertes
3 Introduction
4 État de l’art des méthodes de différenciation de pertes
4.1 Protocoles de transport pour les réseaux sans-fil
4.1.1 TCP Westwood et Westwood+
4.2 Méthodes explicites de différenciation de pertes
4.2.1 Snoop
4.2.2 ELN
4.2.3 TCP-Aware Link-Layer Retransmission
4.2.4 I-TCP
4.2.5 ECN
4.3 Méthodes implicites de différentiation de pertes
4.3.1 Méthodes basées sur le RTT
4.3.2 Méthodes basées sur le ROTT
4.3.3 Méthodes basées sur l’IAT
4.4 Discussion
4.5 Conclusion
5 Différenciation de pertes en utilisant le RTT et ECN
5.1 Étude analytique sur l’utilité de la différenciation de pertes
5.2 Influence des pertes sur le RTT
5.2.1 Influence des pertes sur le RTT en théorie
5.2.2 Influence des pertes sur le RTT par la simulation
5.2.3 Choix du seuil du RTT pour différencier les pertes
5.3 RELD (RTT ECN Loss Differentiation)
5.3.1 Détails et le fonctionnement de RELD
5.4 Conclusion
6 Évaluation des performances par la simulation
6.1 Environnement de simulation
6.1.1 Modifications apportées aux sources de ns2
6.1.2 Modèles de pertes et de propagation
6.1.3 Topologie du réseau de simulation
6.1.4 Configuration du modèle de propagation
6.1.5 Scénarios de simulation
6.2 Résultats des simulations
6.2.1 RELD : vérification du seuil du RTT choisi
6.2.2 RELD : évaluation de la viabilité de classification
6.2.3 RELD vs TCPlike
6.2.4 RELD vs TCP-Eaglet
6.3 Conclusion
III Conclusion générale
Télécharger le rapport complet
