Nous avons procédé à un ensemble de tests qui ont permis davoir une caractérisation du lien satellite sur la voie aller et retour, mais aussi de soulever certains problèmes relatifs à des tests réels et de comportements applicatifs dans une campagne de tests sur un vrai lien satellite.
Nous avons soulevé le problème de fausses détections de pertes, puisque TCP gère la congestion avec des pertes à l'aide de certains timers à savoir le RTO. Pendant nos tests, nous avons remarqué que le RTT peut atteindre des valeurs très grandes jusqu'à 15 secondes dans certains cas, ou avoir de très petites valeurs, ceci est dû à la manière avec laquelle les RTOs sont calculés (en fonction du délai qui lui aussi est grand). Ceci pénalise les communications sur le lien satellite.
83
5 Conclusion
L'analyse du système réel offre la possibilité de caractériser le lien satellite. Avoir les caractéristiques du système réel aide à une éventuelle configuration d'un système émulé et s'avère le meilleur moyen pour bien paramétrer ce dernier. L'émulation par la suite se rapprochera au plus du système réel. Dans d'autres cas, le rejeu des profils de flux capturés sur le lien réel est un complément à l'analyse et permet d'effectuer des comparaisons émulées, en conditions réelles.
L'analyse du comportement des timers de retransmission, RTO pour une transmission TCP, révèle une anomalie (très grande valeur de RTO qui peut atteindre les 15 secondes dans certains cas). Ce genre d'anomalies est causé par le grand délai de bout en bout (le RTO est calculé en fonction du RTT), cela peut s'avérer problématique pour les liaisons satellites. Le grand délai de bout en bout, dû au remplissage des buffers, génère de plus en plus de pertes qui ne sont pas forcément liées à des congestions du réseau mais plutôt à la bufferisation (délai de propagation, queuing).
Les méthodes de calcul des timers TCP sont conçues pour les réseaux terrestres mais s'avèrent incompatible pour les réseaux satellite. Actuellement, dans le réseau Internet, les versions les plus utilisées sont CUBIC et NEWRENO. Cependant, TCP n'a pas été conçu pour opérer dans les réseaux à grand délai.
Les tests réalisés donnent des résultats parfois divergents qui rendent une extrapolation d'un modèle mathématique difficile. Certains modèles proposés dans la littérature et basés sur la simulation NS2 sont en contradiction avec nos résultats sur le système réel d'OURSES, le premier de son genre. Ce problème résulte vraisemblablement de l'absence de références disponibles lors de la conception de ces modèles.
En effet, la modélisation dépend essentiellement de la configuration du système pour une architecture donnée. La configuration d'une architecture dite militaire diffère d'une architecture type catastrophe naturelle ou dun simple accès d'une zone rurale. Les types de données échangées, le débit de transfert ou la priorité de flux changent en fonction de la configuration. La direction de circulation de flux (voie aller ou retour) a de l'importance dans chacune des configurations.
Enfin, l'utilisation de l'adaptation de codage et modulation ACM ne pose pas de difficulté à TCP, qui peut exploiter le surplus de la bande passante en cas d'amélioration du lien, et résiste bien à la réduction de la bande passante en cas de fading.
Devant la complexité des systèmes satellites, la plupart des modèles proposés dans la littérature simplifie le système réel pour mettre en avant certains paramètres qui pourront être utilisés pour configurer le système en fonction de l'application visée. Les résultats obtenus sur le système réel contredisent certains des résultats obtenus à l'aide des modèles.
Pour éviter ces inconvénients, la méthodologie de mesure utilisée sur le système réel nous permet de disposer des informations pertinentes pour la conception d'émulateur ou simulateur et également de valeurs de références pour pouvoir vérifier la pertinence des résultats issus de nos travaux basés sur l'émulation ou la simulation d'un système satellite et ce à différents niveaux d'architecture réseau.
85
Chapitre 3 : Impact des réseaux
satellite sur la couche transport
TCP
1 Introduction
Les réseaux satellite ont été introduits pour compléter l'accès aux réseaux terrestres, dans les zones rurales ou zones appelées blanches. Leur utilisation s'est étendue aux diffusions de la télévision, les communications téléphoniques ainsi qu'aux échanges de données. Ces derniers sont assurés généralement par le protocole TCP, qui est le protocole le plus utilisé dans l'Internet d'aujourd'hui. Cependant, TCP rencontre de nombreux problèmes sur les réseaux satellite à cause des caractéristiques de ces derniers (long délai, limitation de la bande passante, données en burst etc.).
Durant les dernières années, des solutions pour adapter TCP aux réseaux satellite ont été proposées tel que les optimiseurs de performances (Performance Enhancing Proxy PEP) [74]. Bien que les PEPs rapportent des améliorations aux performances applicatives, ils présentent quelques inconvénients. L'utilisation de PEP n'est pas recommandée à cause de la division de la connexion TCP du segment satellite. En effet, cette division va à l'encontre de la sémantique de bout en bout d'une connexion TCP. D'un autre côté, certaines connexions TCP cryptées ne supportent pas les PEPs pour les mêmes raisons.
De nombreuses améliorations de TCP ont été proposées comme l'utilisation de certaines options ou mécanismes d'adaptation aux satellites. De plus, de nouvelles versions de bout en bout ont été introduites. Ces nouvelles versions permettent non seulement d'adapter TCP aux réseaux satellite, d'éviter d'utiliser des solutions d'améliorations dédiées comme les PEPs et d'avoir de bonnes performances applicatives. C'est à ce titre que nous justifions dans ce chapitre de revisiter l'amélioration de TCP sur satellite par les nouvelles versions de TCP qui changent radicalement d'approche.
Ce chapitre est divisé en trois parties. Nous allons tout d'abord présenter les caractéristiques des réseaux satellite Géostationnaires (GEO). Nous présentons par la suite les options, les mécanismes d'amélioration et les nouvelles versions de TCP utilisés. Après une étude comparative des différentes solutions de transport sur les réseaux par satellite, notre objectif et de proposer une solution de transport universelle adaptée tant pour les réseaux satellite que terrestres évitant la mise en uvre d'équipements ou de logiciels spécifiques sur le segment satellite.