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

La conception des techniques d'adaptation de réseau pour la transmission de la vidéo sur Internet pose de nombreux défis. Dans cette section, nous présentons des solutions basées sur la couche de transport. En particulier, nous résumons les travaux de recherche existants en les classant selon leurs types.

Trois catégories de contrôle de débit existent : Contrôle basé sur la source, contrôle basé sur le récepteur et contrôle hybride. Nous terminons cette section en résumant, évaluant et comparant ces techniques.

7.5.1. Contrôle de débit basé source

Dans cette approche, la source (expéditeur) est chargée d'adapter le débit de transmission vidéo. Des mécanismes de contrôle de débit basées sur la source fournissent des informations sur l'état du réseau pour l'expéditeur afin qu'il puisse régler et adapter le débit du flux vidéo. Le contrôle du débit basé sur la source peut être implicite pour les deux approches unicast et multicast.

En ce qui concerne la transmission unicast, elle concerne deux approches existantes, l'une basée sur le sondage et l'autre basée sur équation. La première approche est basée sur le sondage d'expériences. Le débit d'envoi est régulé par les stratégies d'augmentation additive et de diminution multiplicative (AIMD) ou par l'augmentation multiplicative et la diminution multiplicative (MIMD). L'augmentation ou la diminution du débit dépend du

seuil du taux de perte de paquets. Sur l'approche basée équation, le débit d'émission est calculé par une équation de débit qui prend en considération l'état de la route de transmission dans le réseau.

En ce qui concerne la transmission multicast, l'expéditeur utilise un seul canal multidiffusion où seul le contrôle de débit en fonction de sonde peut être utilisé. La multidiffusion monocanal est efficace puisque tous les récepteurs partagent le même et seul canal. Si la vidéo multicast devait être livrée par le biais des flux unicast individuelles, l'efficacité de la bande passante serait faible, mais les services pourraient être différenciés puisque chaque récepteur peut négocier avec la source les paramètres des services.

Le mécanisme de contrôle de congestion TCP est en lui-même l'approche de contrôle de débit basé-sondage la plus répandue.

7.5.1.2. Contrôle de débit avec le protocole de transport multimédia (MTP) [2]

Le protocole de transport MTP est une modification du protocole TCP. C'est une solution basée-sondage qui désactive gracieusement les retransmissions tout en préservant les horloges de transmission ainsi que les caractéristiques du mécanisme de congestion du TCP. Tout comme le protocole TCP, MTP effectue le démarrage lent, l'évitement de congestion, la retransmission rapide et le recouvrement rapide. Il offre cependant une API transparente UDP-like qui permet aux applications média streaming de prendre des décisions de mise à l'échelle des médias informés et fournit une sémantique de livraison de paquets UDP. En outre MTP n'offre pas une garantie de livraison des paquets dans le bon ordre.

A la base, le protocole MTP conserve les mêmes mécanismes de détection de perte de paquets et de recouvrement de pertes que ceux du protocole TCP, mais réduit les caractéristiques de grand délais et gigue. Quand l'émetteur MTP reçoit des accusés de réception dupliqués, il lance le mécanisme d'évitement de congestion, de retransmission rapide et de recouvrement rapide de la même façon que le protocole TCP, et donne un mouvement de la fenêtre de congestion ainsi qu'une horloge de transmission de paquets identiques à ceux du protocole TCP. A la réception d'un troisième accusé de réception ACK dupliqué, au lieu d'entrer en phase de retransmission, le protocole MTP active l'expéditeur MTP qui augmente sa fenêtre de transmission et envoie un nouveau paquet. Quand il reçoit un accusé de réception pour ce nouveau paquet, il diminue sa fenêtre de transmission. Ceci est fait afin de ne pas considérer le remplacement/retransmission de paquets en tant que nouvelle transmission au moment de la prochaine décision de transmission de paquets, tout en conservant le même comportement de transmission que celui de TCP au niveau de la couche réseau.

Dans le cas d'un timeout de transmission, l'expéditeur MTP réagit de la même manière qu'un expéditeur TCP en effectuant un démarrage lent sauf que, contrairement à TCP qui redémarre la transmission depuis le dernier numéro de séquence de paquet ACK reçu, MTP redémarre en transmettant un nouveau paquet directement.

Les résultats de la simulation en [2], ont montré que les flux vidéo MTP héritent des bonnes caractéristiques du flux TCP et UDP. Les résultats montrent aussi que les flux MTP ressemblent également aux flux de TCP-Friendly en plus du fait qu'ils peuvent adapter le débit de TCP-Friendly.

Le protocole de transport VTP est basé sur le sondage qui offre un nouveau mécanisme de contrôle de débit de bout en bout. Ce mécanisme a été conçu spécifiquement pour le streaming en temps réel dans les réseaux sans fil. Son premier but était de bien fonctionner dans l'Internet par câble, d'être robuste aux erreurs aléatoires, afin de fournir une bonne convivialité avec le protocole TCP ainsi que d'être déployé avec succès sur les liaisons sans fil.

VTP combine l'estimation du taux avec des techniques de discrimination de perte. Il se compose de deux éléments importants, à savoir le taux d'estimation atteint (AR) et l'algorithme de discrimination de perte (LDA). Le taux AR est le débit avec lequel l'expéditeur a envoyé ces paquets avec succès à travers le goulot d'étranglement. Plus spécifiquement, c'est le débit que le récepteur peut mesurer, ajouté à la fraction correspondante à la perte de paquets à la sortie du goulot d'étranglement dû aux erreurs aléatoires. Le LDA permet au protocole VTP de distinguer les pertes de congestion des pertes d'erreurs de route. Le protocole VTP mesure l'AR et adapte son débit d'émission lorsqu'une congestion est détectée par le LDA.

Le contrôle de débit avec VTP est basé sur l'analyse du débit d'envoi instantanée du protocole TCP. Comme TCP, VTP augmente linéairement la bande passante disponible jusqu'à ce qu'une congestion soit détectée. Au cours d'une phase de congestion et en imitant le comportement de TCP sans impliquer une décroissance multiplicative, l'expéditeur VTP réduit son débit d'envoi et le taux d'encodage vidéo jusqu'à ce que la congestion s'arrête. Cela permet au protocole VTP de transmettre une plus grande partie de flux vidéo.

Le protocole VTP est un protocole de bout-en-bout qui fonctionne bien dans l'environnement sans fil sans le soutien des couches inférieures ainsi que les mécanismes AQM (analyse quantifié de la marche) [3]. Il vise à être adaptable et flexible en faisant des hypothèses minimales sur le réseau et en utilisant des évaluations de réseau comme un indicateur approximatif. Ces caractéristiques sont les facteurs de motivation de la conception du protocole VTP.

Dans les algorithmes SAMM qui ont été proposés pour la transmission multicast de vidéos, la source ajuste les paramètres de codage, en incluant le nombre de vidéos et leurs débits respectifs dans une réponse retour (feedback) de congestion sur un flux continu de la part des récepteurs. Les algorithmes SAMM peuvent être basés sur le concept de bout-en-bout ou basé-réseau. Sur les algorithmes basés-réseau, la congestion est surveillée et détectée par les noeuds intermédiaires de réseau. D'autre part, sur les algorithmes de bout-en-bout, le contrôle de congestion se fait exclusivement chez la source et chez les récepteurs.

Afin de renforcer les algorithmes SAMM, une architecture de réseau doit être définie. Quatre éléments de base sont nécessaires pour la mise en oeuvre d'un algorithme vidéo SAMM qui sont : une source vidéo adaptative de plusieurs niveaux, des récepteurs vidéo de plusieurs niveaux, des routeurs multicast et des noeuds avec la capacité de renvoyer des réponses retours (feedback). La source vidéo adaptative a la capacité de générer des données vidéo de plusieurs niveaux de qualité. Le récepteur fait référence à la qualité qu'il veut recevoir. Les routeurs multicast doivent être capables d'effectuer le transfert multicast, le routage, la diminution de priorité, l'isolation de flux et le contrôle de congestion. Pour éviter l'implosion, une agrégation des réponses retour est faite par la fusion et l'organisation des réponses retour distribuées dans le réseau superposé. Après la réception d'un nombre donné de paquets vidéo, le récepteur envoie une réponse retour au noeud de fusion le plus proche. Celui-ci transmettra à la source la liste de débits demandés par les récepteurs.

Tous les protocoles et les algorithmes ci-dessus se réfèrent à la couche Transport, à part Real Time Protocol (RTP) qui est un protocole Internet standard se trouvant sur la couche Application. Il est utilisé pour le transport des données en temps réel de bout en bout, y compris l'audio et la vidéo. Il peut aussi être utilisé pour les services de média à la demande ainsi que les services interactifs comme la téléphonie sur Internet et les communications unicast.

Le protocole RTP fonctionne habituellement sur le dessus du protocole UDP afin de faire usage de ses fonctions de multiplexage et de contrôle. RTP ne garantit pas une livraison rapide de paquets et ne fournit pas les paquets dans leur ordre. Le protocole RTP donne la responsabilité de récupérer les segments perdus et le séquençage des paquets à la couche Application. Par conséquent, il ne propose aucune formule de fiabilité ou de contrôle de débit/congestion. Il offre un service d'horodatage ainsi que des numéros de séquence pour assurer la fiabilité et le contrôle débit/congestion, mais leur mise en oeuvre est totalement attribuée à l'application.

Le Real Time Control Protocol (RTCP) accompagne le protocole RTP. Il sert à faire des statistiques sur les connexions et les informations multimédias telles que le nombre d'octets envoyés, le nombre de paquets envoyés, le nombre de paquets perdus, la gigue et les délais aller-retour. Les expéditeurs, les récepteurs et les moniteurs tiers peuvent utiliser ces informations pour juger la qualité de leurs connexions afin de procéder aux ajustements nécessaires telles que le passage d'un faible codec de compression à un codec de compression plus élevé. Les gestionnaires de réseau peuvent utiliser des informations contenues dans les paquets RTCP pour évaluer la performance de leurs réseaux dans la diffusion multicast. RTCP est utilisé pour les conférences en temps réel (grands groupes) utilisant le réseau Internet, y compris l'identification de la source, le soutien pour les passerelles et les traducteurs multicast-à-unicast. Il propose également des évaluations de qualité de service à partir de récepteurs au groupe de multi diffusion. Aussi il sert comme un support pour la synchronisation des différents flux de médias. Les données RTP / RTCP peuvent être cryptées afin d'améliorer la sécurité.

Le protocole RTP / RTCP n'est pas responsable des tâches de niveau supérieur comme l'assemblage ou la synchronisation qui doivent être fait dans la couche Application. Il fournit des mécanismes et des fonctionnalités de contrôle nécessaires à l'acheminement du contenu en temps réel. RTP est un framework de protocole qui n'est délibérément pas complet. Il est ouvert pour être utilisé sur de nouveaux formats de données ainsi que pour de nouveaux logiciels multimédia. En ajoutant de nouveaux profils et de nouvelles spécifications de formats de données, on peut adapter le protocole RTP à de nouveaux formats de données et à de nouvelles applications.

Le mécanisme de contrôle de débit de TCP friendly est l'un des algorithmes de streaming de bout-en-bout basés équation les plus répandus et souvent utilisé comme référence. TFRC a pour rôle de servir comme `framework' de contrôle de congestion pour toutes les applications qui ne nécessitent pas le fonctionnement à 100% du mécanisme de fiabilité du protocole TCP et qui profitent de la faible variation du débit d'émission.

Dans le protocole TFRC, l'émetteur envoie un flux de paquets de données vers le récepteur avec une vitesse contrôlée par la formule suivante :

2.7

* v2*??*??

3 (??_ ???? * (3 * v3*??*??

8 ) * ?? * (1 32 * ??²)))

Où X est le débit de transmission en octets / seconde, s est la taille du paquet en octets, R est le temps d'aller-retour (RTT) en secondes, p est la probabilité de perte de paquets (entre 0 et 1), t_RTO est la valeur du retransmission timeout de TCP en secondes et b est le nombre de paquets notifiés par un seul accusé de réception TCP.

Quand un paquet feedback est reçu par le récepteur, l'expéditeur change son taux d'envoi sur la base des informations contenues dans la réponse retour. Si l'expéditeur ne reçoit pas de feedback durant deux temps aller-retour (RTT), il abaisse son taux d'envoi de moitié. Ce résultat est obtenu au moyen d'une minuterie qui est appelé la minuterie de non-feedback. Quand un paquet feedback est reçu, les actions suivantes doivent être effectuées : calculer un nouvel échantillon du temps d'aller-retour, mettre à jour la valeur estimée du temps aller-retour, mettre à jour l'intervalle de temporisation, mettre à jour le débit d'émission et réinitialiser la minuterie de non-feedback.

Le récepteur envoie périodiquement des messages de réponse retour à l'expéditeur. Les paquets feedback devraient normalement être envoyés au moins une fois par RTT. Ils devraient également être envoyés à chaque fois qu'un nouvel événement de perte est détecté sans attendre la fin d'un RTT, et à chaque fois qu'un paquet out-of-order qui supprime un événement de perte de l'historique des pertes est reçu. Si l'expéditeur transmet de nombreux paquets par RTT, il peut y avoir certains avantages si l'envoi de messages feedback se feront plus d'une fois par RTT car cela permet d'avoir une réponse plus rapide qui servira à l'évolution des mesures de RTT. Cependant, l'envoi d'un grand nombre de paquets feedback par RTT pourra surcharger le réseau.

Le protocole TFRC a été conçu pour répondre à un événement de perte paquet. Cependant, avec la popularité croissante de terminaux Internet sans fil et la grande demande qui concerne le flux streaming vidéo par les utilisateurs mobiles, il est important pour les protocoles de streaming de travailler d'une façon efficace sur les liens sans fil en supportant les erreurs aléatoires élevées du sans fil.

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

7.5. Technique d'adaptation du réseau

7.5.1. Contrôle de débit basé source