sur satellite
3.5.1. TCP standard et les limites de son utilisation sur satellite
La raison fondamentale de la mauvaise interaction entre TCP et les systèmes satellites vient de la nature même de ce type de lien : le fonctionnement global de TCP, qui n’est pas rappelé ici1,
n’est pas prévu pour différentes caractéristiques de lien. Or les liens GEO cumulent un certain nombre de ces points :
• un délai de propagation élevé,
• une asymétrie souvent importante entre la voie aller et retour, • une méthode d’accès dynamique délicate,
• des erreurs physiques.
Chacune de ses raisons ne sont pas véritablement dissociées des autres, mais pour pouvoir clarifier notre approche, nous avons préféré aborder cette partie en les dissociant dans des sections distinctes.
3.5.1.1.
Le délai de propagation
Un long RTT a pour premier effet de diminuer le débit maximum qu’une connexion TCP peut atteindre sur un lien. En effet, au maximum, on ne peut émettre que la fenêtre maximale du récepteur (avertized window) avant de recevoir le premier acquittement de cette fenêtre émise. Or la taille maximale de celle-ci est fixée à 65535 B [64]. De plus il s’agit d’une taille maximale qui n’est pas toujours utilisée (par exemple le FTP d’Unix utilise une maximum de 24 KB). On peut alors obtenir un majorant du débit avec la formule suivante (6)
(6) Max _
Avertized Window D
RTT =
Avec un RTT de 500 ms, on obtient alors un débit maximal d’environ 1043 Kb/s contre un débit de 393 Kb/s dans le cas d’une fenêtre maximale de 24 KB.
Le RTT influence aussi notablement la longueur de la phase de slow start comme celle de congestion avoidance, entraînant sur le lien satellite un débit limité pour une durée non négligeable.
Un dernier problème, typiquement lié au délai, est le calcul du RTT par TCP. En effet, le protocole de transport TCP se base sur l’évaluation du RTT pour calculer le RTO (Retransmission Time Out) [64]. Or l’estimation de ce RTT est effectuée à chaque émission de nouvelle fenêtre, ce qui peut poser un certain problème lorsque la taille de cette dernière est importante, surtout si le RTT fluctue beaucoup.
3.5.1.2.
L’asymétrie
L’asymétrie du lien pose un problème important, comme nous aurons l’occasion de le constater à plusieurs reprises par la suite. Différentes études [42] [65] montrent l’influence du ratio d’asymétrie. En effet si l’on note T1 et T2, respectivement le temps d’émission d’un datagramme
(de taille data) sur le lien aller, et le temps d’émission d’un acquitement (de taille ack) sur le lien retour. Notons Dd et Du les débits respectif de la voie aller (source vers terminal en passant par une gateway) et de la voie retour. On alors engorgement des acquittements dès que T2 est supérieur à T1, soit, en fonction du débit du lien et de la taille de la donnée :
(7) 1 2
u
d u d
D
data ack ack
T T
D D data D
< ⇔ < ⇔ >
Or pour un débit aller Dd de 512 Kb/s, des acquittements de 40 B et une MSS de 1460 B, on obtient une valeur limite d’environ 13.7 Kb/s pour Du. En deçà de ce seuil, il y a congestion
des acquittements, et le trafic aller est ralenti par le faible débit retour des acquittements.
Un autre problème intimement lié est la notion d’autorégulation du flux TCP. En effet le temps d’arrivée des acquittements va être déterminant pour le flot de donnée aller. Aussi, en phase stationnaire de la communication TCP, on ne peut émettre qu’un paquet pour un acquittement reçu. Le nombre d’acquittements à la seconde est alors une borne supérieure sur le nombre de datagrammes émis à la seconde. Soit une borne sur le débit maximal de :
(8) 2 . u MAX data D data D T ack = =
L’application numérique donne la courbe suivante en fonction du débit de la voie retour (Figure 3.26). Il semble alors délicat de pouvoir profiter d’un débit important aller pour une connexion TCP, si le lien retour a un débit faible.
Figure 3.26 Borne supérieure sur le débit aller en fonction du débit de la voie retour
3.5.1.3.
La méthode d’accès
La méthode d’accès satellite n’a une influence que dans le cadre d’un retour satellite. En effet, dans ce cas et par soucis de rentabilité de l’accès satellite, la réservation de capacité sur le lien retour est le plus souvent dynamique pour permettre des prix abordables. Ce type de méthode entraîne alors la mise en place d’un temps supplémentaire et variable pour avoir accès au média. D’une part le RTT est augmenté, influençant de manière négative la capacité de réactivité du système, et diminuant le débit maximal calculé précédemment (8). D’autre part, le RTT devient variable, entraînant des difficultés pour le calcul du RTO.
3.5.1.4.
Les erreurs physiques
Un dernier obstacle à la bonne adéquation du satellite à TCP est son taux d’erreur plus important que sur les réseaux terrestres, d’autant plus que les pertes sur satellite suivent difficilement un quelconque modèle1. Pour TCP, une perte de paquet correspond à une
congestion dans le réseau, or avec un média très bruité tel que le satellite, il n’en est pas forcément le cas. TCP va alors passer en congestion avoidance après l’écoulement du RTO. Cependant, si la perte est due au lien satellite, d’une part le débit va être diminué pour rien, et d’autre part, il peut y avoir réémission de segments inutiles. Dans le cadre d’une communication quasi point à point la congestion avoidance n’a pas lieu d’être, et la réaction de TCP aux erreurs satellites entraîne un fonctionnement bien en dessous des capacités du système.
Dans ce cadre, l’utilisation du fast retransmit/fast recovery va permettre d’améliorer la détection de pertes dues au bruit, grâce à la réception de duplicata des acquittements : Au troisième acquittement dupliqué, la source émet les paquets sans attendre le time out, entrant alors en phase de fast recovery, à la place du slow start. Ces mécanismes sont implantés notamment dans la version Reno [66] et NewReno [67] de TCP, et permettent de diminuer moins drastiquement le débit TCP.
Toutefois du fait du long délai du média satellite, et des erreurs multiples sur une même fenêtre, ce mécanisme n’est pas toujours suffisant pour éviter le déclenchement du RTO, entraînant un impact déplorable sur le débit du système. Le problème des erreurs sur satellite est donc essentiellement couplé à celui du RTT élevé et incompressible.