Memoire Online - Amélioration de la performance de TCP dans les réseaux mobiles ad hoc.

La QdS regroupe un ensemble de technologies mises en oeuvre pour assurer des débits suffisants et constants sur les réseaux en général et Internet en particulier. Dans les réseaux filaires, le protocole TCP est considéré parmi les moyens les plus efficaces pour garantir une bonne transmission de données à cause de sa fiabilité ainsi que ses mécanismes de contrôle de congestion, de multiplexage qui favorisent le type de données par rapport à un autre type afin de garantir un bon fonctionnement du service. Cependant dans les réseaux sans fil et dans certaines conditions, au lieu d'améliorer la QdS, les mécanismes du protocole TCP font que la QdS se dégrade.

Les graphes 17 et 18 comparent les performances et la qualité de service fourni par le protocole TCP en matière de débit, afin de montrer l'impact du protocole TCP sur la qualité de service des réseaux sans fils sous les contraintes de mobilité et des interférences.

Dans ces figures nous constatons deux faits : quand il n'y a ni mobilité ni interférence, le débit est assez bon avec presque les mêmes valeurs pour les cas filaire et sans-fil. Cependant, dès que les noeuds de la topologie commence à être mobile ou subissent des effets d'interférences, leurs débit se dégradent d'une façon importante dans le réseau sans fil, ce qui impacte négativement la qualité de service du réseau. Par contre sur le réseau filaire ceci n'aura presque aucun impact sur la qualité de service du réseau (impact négligé).

Figure 17 : Comparaison des valeurs du débit filaire et sans fils avec déplacement

Figure 18 : Comparaison des valeurs du débit filaire et sans fils sous l'effet des

6.5. Etude comparative des travaux existants

Dans le cadre des améliorations du protocole TCP dans les réseaux sans fils en général et les réseaux ad hoc en particulier, plusieurs approches ont été proposées. La plupart de ces approches visent à trouver une solution qui permet au protocole TCP de faire la différence entre une perte de paquet due à une congestion du lien et une perte de paquet qui est due aux erreurs du lien.

Les solutions proposées jusqu'à présent peuvent être classé en deux catégories, les solutions inter-couches et les solutions basées sur la couche de transport. Ces approches sont résumées dans la figure 19.

6.5.1. Les solutions inter-couches

TCP-F est une approche basée sur une réponse de retour (rétroaction) afin d'éviter les erreurs de chemin dans les réseaux MANET. Cette approche permet à l'expéditeur TCP de faire la distinction entre les pertes dues à la congestion du réseau et celles dues à d'autres facteurs. Ainsi, lorsque l'agent de routage d'un noeud détecte l'interruption d'une route, il envoie explicitement un paquet de notification d'erreur de route (RFN) à la source du paquet. En recevant le RFN, la source passe dans un état de sommeil (snooze state). L'expéditeur TCP qui est en état de sommeil arrête l'envoi de paquets et sauvegarde les valeurs de toute variable comme le délai et la taille de la fenêtre de congestion. L'expéditeur TCP reste dans cet état de sommeil jusqu'à ce qu'il reçoit un paquet notification de la restauration de la route (RRN). En recevant le RRN, l'expéditeur TCP va

sortir de l'état de sommeil et va reprendre la transmission en se basant sur les valeurs déjà sauvegardées de la fenêtre de congestion et du délai.

Figure 19 : Classification des solutions pour l'amélioration de TCP dans les réseaux

Afin d'éviter les scénarios de blocage dans un état de somnolence sur la réception d'une notification RFN, l'expéditeur TCP déclenche une horloge d'échec de route. Lorsque ce délai expire l'algorithme de contrôle de congestion est exécuté normalement.

Dans [18], les auteurs rapportent une amélioration en utilisant TCP-F sur TCP. Le scénario de simulation est basique et ne repose pas sur un réseau ad hoc. Au lieu de cela, ils imitent le comportement d'un réseau ad hoc au niveau de la couche transport.

La technique de notification d'erreur de lien explicite ou ELFN-based technique est similaire à TCP-F. Cependant, contrairement à celle-ci, l'évaluation de la proposition est basée sur une interaction réelle entre TCP et le protocole de routage. Cette interaction vise à informer TCP sur les échecs de la route quand ils se produisent. Les auteurs utilisent un message ELFN, qui est envoyé par le protocole de routage à l'expéditeur. Le message

ELFN est comme un message «hôte inaccessible » du protocole ICMP, qui contient les adresses et les ports de l'expéditeur et du récepteur, ainsi que le numéro de séquence de paquets TCP. Sur la réception du message ELFN, la source répond en désactivant son horloge de retransmission et entre dans un mode "veille". Pendant la période d'attente, l'expéditeur TCP sonde le réseau pour vérifier si la route est rétablie, si l'accusé de réception du paquet de sonde est reçu, l'expéditeur TCP quitte le mode veille, reprend son horloge de retransmission et continue les opérations normales.

Cette technique a apporté des améliorations significatives sur le TCP standard, mais d'autres évaluations sont encore nécessaires. En cas de forte charge le protocole ELFN donne de plus mauvais résultats que le TCP standard, ceci est dû au fait que le protocole ELFN est basée sur le sondage régulier du réseau afin de détecter les rétablissements de routes.

ATCP or TCP ad hoc utilise lui aussi une réponse de retour de la couche réseau. En plus des échecs de route, ATCP a pour but de régler le problème des taux d'erreur élevés de bits (BER). L'expéditeur TCP peut être mis dans plusieurs états, en état de conservation, en état de contrôle de congestion ou en état de retransmission. Sur les noeuds source de TCP, une couche appelée ATCP est inséré entre les couches TCP et IP. ATCP, écoute les informations d'état de réseau fourni par les messages ECN (Explicit Congestion Notification) et par le protocole ICMP "Destination inaccessible", puis ATCP met l'agent de TCP dans l'état approprié selon la réponse reçue. Sur réception d'un message "Destination inaccessible", l'agent TCP entre dans un état de conservation ; lors de cet état l'agent TCP est gelé et aucun paquet n'est envoyé jusqu'à ce qu'une nouvelle route soit trouvée durant le sondage du réseau. Le message ECN est utilisé comme un mécanisme de notification qui indique à l'expéditeur les éventuelles congestions du réseau sur la route utilisée. Lors de la réception du message ECN, le mécanisme de contrôle de congestion du TCP est invoqué normalement sans attente. Pour détecter les pertes de paquets dues aux erreurs de route, ATCP surveille les accusés de réception reçus. Lorsque ATCP reçois trois ACK dupliqués, il ne transmet pas la troisième ACK en double, mais met TCP dans l'état de conservation et retransmet rapidement le paquet perdu de la mémoire tampon TCP. Après avoir reçu le prochain ACK, ATCP permet à TCP de se mettre dans un état normal.

ATCP a été implémenté, testé et évalué selon différents scénarios, tels que la congestion et les liens perdus. Dans tous les cas, le transfert d'un fichier donné en utilisant ATCP donne de meilleures performances que le TCP standard. Toutefois, le scénario utilisé est un peu spécial, puisque ni les liaisons sans fil, ni les protocoles de routage ad hoc n'ont été considérés, les auteurs ont utilisé un banc d'essai expérimental composé de cinq ordinateurs équipés de cartes Ethernet. Avec ces ordinateurs, les auteurs ont formé un réseau de quatre sauts.

TCP-Bus utilise les capacités du TCP standard, la mémoire tampon et le numéro de séquence. D'un autre côté, tout comme les approches précédentes TCP-bus se basent aussi sur une réponse de retour ; il utilise les évaluations du réseau pour détecter les échecs de la route afin de réagir convenablement à cet événement. L'apport que propose cette approche est le fait d'introduire la capacité du `tampon mémoire' dans les noeuds mobiles. Les auteurs sélectionnent un protocole de routage de type initialisation-à-la-demande-de-la-source ou ABR (Routage basé associativité) [22] initié à la demande. Les améliorations suivantes sont proposées :

? La notification explicite : deux messages de contrôle sont utilisés pour

informer la source de l'échec de la route et du rétablissement de route. Ces messages sont appelés la Notification-de-Déconnection-Explicite-de-Route (NDER) et la Notification-Réussie-Explicite-de-Route (NRER). A la réception de la (NDER) de la part du noeud qui a détecté l'échec de route, ce noeud est appelé Noeud-Pivotant (NP), la source cesse d'envoyer des paquets. De même après le rétablissement de route par le PN en utilisant une requête localisée (RL), le PN transmettra le NRER à la source. A la réception de la NRER, la source reprend la transmission de données.

? Extension des valeurs du timeout : pendant la phase de la reconstruction de

Route (PRR), tout au long de la route (de la source à la NP) les paquets sont insérés dans la mémoire tampon. Pour éviter les timeout durant la phase PRR, l'horloge de retransmission de paquet est sauvegardée sur le tampon mémoire puis doublée par la suite.

retransmission est doublée, les paquets perdus le long de la route depuis la source vers NP, ne seront pas retransmis jusqu'à l'expiration de l'horloge de retransmission ajustée. Pour résoudre ce problème, une indication est faite à la source de manière à pouvoir retransmettre les paquets perdus d'une manière sélective.

la route est rétablie, la destination informe la source des paquets perdus le long de la route (de la NP à la destination). A la réception de cette notification, la source retransmet simplement ces paquets perdus. Le problème est que les paquets mis en mémoire tampon le long du trajet depuis la source vers l'unité de raccordement peuvent arriver à destination plutôt que les paquets retransmis, ainsi la destination répondra par des ACK dupliqués, et les paquets de requêtes inutiles pour la retransmission rapide sont mis à l'écart.

exactitude le bon fonctionnement de TCP-bus, les auteurs proposent de transmettre de manière fiable les messages de contrôle de routage NDER et NRER. La transmission se fait d'une manière fiable en restant à l'écoute sur le canal après avoir transmis les messages de contrôle. Si un noeud a envoyé un message de contrôle et que ce dernier n'a

pas reçu ce message relayé pendant un timeout, il conclut que le message de commande est perdu, donc il retransmet ce message.

Cette approche (TCP-Bus) offre de nombreuses nouvelles techniques pour l'amélioration de TCP. Les nouvelles contributions de cet article sont les techniques de mise en mémoire tampon et la transmission fiable de messages de contrôle. Dans leur évaluation, les auteurs ont constaté que le protocole TCP-Bus surpasse le TCP standard et le TCP-F dans des conditions différentes. L'évaluation est basée uniquement sur le protocole de routage ABR, d'autres protocoles de routage doivent être pris en compte. Aussi, TCP-Bus n'a pas tenu compte du fait que le pivotement de noeud peut empêcher le calcul d'un nouvel itinéraire partiel à la destination.

Les connexions TCP avec un grand nombre de sauts souffrent de défaillances de routes fréquentes en raison de la mobilité. Pour améliorer le débit de ces connexions et régler le problème de partage de débit, le régime de Split TCP a été introduit pour diviser les longues connexions TCP en segments plus courts localisées (Cf. figure 20). Le noeud interface entre deux segments localisés est appelé un proxy. L'agent de routage décide s'il attribue le rôle de proxy à son noeud selon le paramètre de distance inter-proxy. Le proxy intercepte les paquets TCP, les insère dans la mémoire tampon, et accuse leur réception à la source (ou au proxy précédent) en envoyant un acquittement local (LACK). En outre, un proxy est chargé de délivrer les paquets, à un taux approprié, au prochain segment local. Lors de la réception d'un LACK (de la part du prochain proxy ou de la destination finale), le proxy vide sa mémoire tampon des paquets. Afin d'assurer la fiabilité de la source à la destination, un ACK est envoyé par la destination à la source de manière similaire au protocole TCP standard.

Ce schéma divise les fonctionnalités de la couche Transport sur le contrôle de bout-en-bout ainsi que sur le contrôle de congestion. Cela se fait à l'aide de deux fenêtres de transmission à la source, la fenêtre de congestion et la fenêtre de bout-en-bout. La fenêtre de congestion est une sous-fenêtre de la fenêtre de bout en bout. Bien que le changement de la taille de la fenêtre de congestion se fasse en fonction du taux d'arrivée des paquets LACK de la part du prochain proxy, la taille de la fenêtre de bout-en-bout va changer en fonction du débit d'arrivée de bout-en-bout des accusés de réception ACK de la destination. A chaque proxy, il y aura une fenêtre de congestion qui gère le taux d'envoi entre les proxys.

Les résultats des simulations indiquent qu'une distance inter-proxy entre 3 et 5 a un bon impact à la fois sur le débit et la répartition. Les auteurs rapportent qu'une amélioration allant jusqu'à 30% peut être obtenue dans le débit total à l'aide de Split TCP. Les inconvénients sont des grands tampons et une surcharge du réseau. En outre, cette proposition rend le rôle de noeuds proxy plus complexes car ils ont à contrôler la livraison des paquets des proxys suivants pour chaque session TCP.

Dans cet algorithme chaque noeud conserve un enregistrement des puissances de signaux reçus de noeuds voisins 1-hop. En utilisant ces enregistrements, le protocole de routage prédit immédiatement les échecs de route ; cette prédiction est appelé Proactive Link Management. Lors de la détection de cet événement, l'agent de routage de la source est averti par un message Going-Down (cf. Figure 21) à la réception de ce message de l'agent de routage de la source arrête d'envoyer des paquets et initie une procédure de recherche de route. La nouveauté de cette proposition est le mécanisme réactif du Link Management. Ce mécanisme augmente la puissance de transmission recherchant de nouvelles routes à chaque fois qu'une route subit des erreurs de route. Les mécanismes de gestion de liens réactifs et proactifs peuvent être couplés de la manière suivante : Suite à la prévision sur la panne du lien, l'agent de routage du noeud informe la source pour arrêter l'envoi, ce noeud augmente sa puissance d'émission pour gérer les paquets en transit qui utilisent ce lien.

Les auteurs utilisent des simulations sur des scénarios de réseaux faiblement chargés. Les résultats montrent que leur approche donne 45% d'amélioration sur les performances du protocole TCP.

L'approche COntention-based PAth Selection aborde le problème de baisse de la performance de TCP en raison des concurrences d'accès sur un canal sans fil. Elle met en oeuvre deux techniques : la première est la transmission disjointe et la deuxième est la route retour, qui consiste à choisir des itinéraires disjoints pour les données TCP et les paquets TCP ACK. Le second est l'équilibrage-contentieux dynamique, qui consiste à mettre à jour dynamiquement les itinéraires disjoints. Une fois la contention d'une route dépasse un certain seuil, appelé seuil de temporisation, une nouvelle route moins contentieuse est choisie pour remplacer la route contentieuse.

Dans cette proposition, la contention sur le canal sans fil est mesurée en fonction du nombre de fois qu'un noeud a reculé au cours de chaque intervalle de temps. Aussi à tout moment une route peut être brisée, en plus de lancer une procédure de rétablissement d'itinéraire, COPAS redirige les paquets TCP en utilisant le deuxième itinéraire alternatif. En comparant COPAS et DSR, les auteurs ont constaté que COPAS surpasse DSR en termes de débit TCP et des frais généraux de routage (ressources). L'amélioration du débit TCP peut atteindre jusqu'à 90%. Cependant, l'utilisation de COPAS, tel que rapportée par les auteurs, est limitée aux réseaux statiques ou des réseaux à faible mobilité. Quand les noeuds se déplacent plus rapidement en utilisant une transmission disjointe et des routes retours, ceci augmente la probabilité de défaillance de route rencontrée par les connexions TCP.

6.5.2. Les solutions basées sur la couche Transport 6.5.2.1. Fixed RTO [23]

Cette technique est une technique basée expéditeur, elle ne se base pas sur les réponses retour d'état du réseau. Les auteurs utilisent une heuristique afin de faire la différence entre les échecs de route et la congestion du réseau. Lorsque deux timeouts qui se suivent, ce qui correspond à la situation dans laquelle l'ACK manquant n'est pas reçu avant l'expiration du deuxième RTO, l'expéditeur conclut qu'un échec de route s'est produit. Le paquet de données est retransmis à nouveau mais sans doublé la valeur du RTO (reste la même valeur que celle de l'envoi précèdent). Cette approche fonctionne avec le protocole TCP standard, où un algorithme de réduction de puissance «exponentielle» est utilisé. Le RTO reste fixe jusqu'à ce que la route soit rétablie et que la réception du paquet retransmis est accusée.

Les auteurs ont évalué cette proposition en utilisant différents protocoles de routage ainsi que différents scenarios TCP sélectifs et l'accusé de réception retardé. Ils signalent que des améliorations significatives ont été obtenues lors de l'utilisation fixe-RTO avec les protocoles de routage à la demande. Néanmoins, comme indiqué par les auteurs eux-mêmes, cette proposition est limitée à des réseaux sans fil uniquement, une limitation sérieuse depuis l'interopérabilité avec les réseaux câblés est nécessaire. En outre, la

supposition que deux timeout consécutifs sont les résultats exclusifs de défaillances d'itinéraire a besoin de plus de l'analyse, en particulier en cas de congestion.

Cette approche est la solution de bout en bout qui ne nécessite pas la coopération de noeuds intermédiaires ; elle est basée sur des événements Out-Of-Order (OOO). Les événements (OOO) sont interprétés comme une indication d'échec de route. La détection d'un événement OOO est effectuée soit par un mécanisme basée sur expéditeur ou bien d'un mécanisme basé sur le récepteur. Le mécanisme basé expéditeur utilise la propriété de fonction croissante du numéro de séquence ACK pour détecter les événements OOO. Dans le cas de paquets ACK dupliqués, ces ACKs auront le même numéro de séquence, mais l'émetteur a besoin d'informations supplémentaires pour détecter les cas d'OOO. Cette information est une option d'un octet ajouté aux ACKs appelé ACK de duplication de numéro de séquence (ADSN). L'ADSN est incrémenté et transmis avec chaque ACK dupliqué. Cependant, le mécanisme basé sur le récepteur a besoin d'une option TCP supplémentaire sur deux octets pour détecter les événements OOO, appelé TCP Packet-Sequence-Number (TPSN). Le TPSN est incrémenté et transmis avec chaque paquet TCP y compris les paquets retransmis. Si le récepteur détecte un événement OOO, il devrait en informer l'expéditeur en fixant un bit d'option spécifique, appelé bit de OOO, dans l'en-tête de paquet ACK.

Une fois que l'expéditeur TCP détecte un événement OOO, il prend les deux mesures d'actions suivantes : désactiver temporairement le contrôle de congestion et le recouvrement rapide lors de l'évitement de congestion. Dans le premier cas, l'expéditeur TCP désactive l'algorithme de congestion pour une période de temps spécifique (T1), la prochaine action est la suivante : si l'algorithme de contrôle de congestion a été invoqué au cours de la période de temps passé (T2), l'expéditeur TCP doit revenir immédiatement à l'état d'avant l'invocation du contrôle de congestion. Les auteurs font des périodes T1 et T2 comme fonction du RTT (round trip time).

Durant la simulation de cette approche, différents scénarios ont été envisagés en combinant tous les mécanismes et les actions mentionnées ci-dessus. Leurs résultats montrent que les mécanismes basés expéditeur/récepteur se comportent de façon similaire. Ainsi, ils recommandent l'utilisation du mécanisme de détection de l'expéditeur car il ne nécessite pas de notification de la part de l'expéditeur pour le destinataire. En ce qui concerne les actions, ils ont comme rôle de désactiver temporairement le contrôle de congestion et le recouvrement rapide lors de l'évitement de congestion et le fait qu'ils sont utilisés dans la détection d'événement OOO, ils ont constaté que les deux actions conduisent à une amélioration significative. En général, le protocole TCP-DOOR améliore le rendement de 50%. Néanmoins, la supposition que les événements OOO sont forcément les résultats de l'échec de route, mérite beaucoup plus d'analyse. Les protocoles de routage

multi-route tels que TORA peuvent produire des événements OOO qui ne sont pas liés à des défaillances de route.

Le tableau suivant récapitule les approches vues en mentionnant une comparaison entre ces approches.

Approches	Type de solution	Dégrée de complexité	Débit	Type de réseau	Nombre de connexions	Evaluation
TCP-F	Inter- couches	Moyenne	Faible	Mobile aléatoire	Une seule	Simulation
ELFN	Inter- couches	Moyenne	Faible	Mobile aléatoire	Une seule	Simulation
ATCP	Inter- couches	Haute	Faible	Mobile aléatoire	Une seule	Emulation
TCP-Bus	Inter- couches	Haute	Moyen	Mobile aléatoire	Multiple	Simulation
Split-TCP	Inter- couches	Moyenne	Moyen	Mobile aléatoire	Une seule	Simulation
TCP avec puissance de signal	Inter- couches	Haute	Faible	Mobile aléatoire	Deux	Simulation
COPAS	Couches réseau	Moyenne	Haut	Statique	Multiple	Simulation
Fixed- RTO	Couches TCP	Faible	Faible	Mobile aléatoire	Une seule	Simulation
TCP DOOR	Couches TCP	Faible	Moyen	Mobile aléatoire	Une seule	Simulation

Amélioration de la performance de TCP dans les réseaux mobiles ad hoc.

6.4. TCP et la qualité de service dans les réseaux sans fil

6.5. Etude comparative des travaux existants

6.5.1. Les solutions inter-couches