sur satellite
5. EVALUATION DE L’ARCHITECTURE HYBRIDE
5.4.3. Accès Internet évolué
5.4.3.3. Des optimisations au niveau liaison
Le niveau MAC offre aussi des solutions à ce problème. En effet l’engorgement du buffer d’émission est la raison physique de la baisse du débit d’émission des acquittements sur le lien, entraînant implacablement la chute du débit en download. Pour palier cela, nous avons envisagé trois solutions : régler la taille du buffer d’émission, appliquer une politique de service en fonction des flux, ou limiter le MTU sur le lien1.
5.4.3.3.1. L’INFLUENCE DE LA TAILLE DES BUFFERS D’ÉMISSION
L’influence de la taille des buffers sur les deux communications est le premier point traité ici. Nous proposons de faire varier la taille de ces buffers et d’observer les résultats donnés par simulation. Dans un premier temps, observons ces résultats pour des buffers d’émission 50 KB, et de 100 KB. Pour donner une idée de l’influence du modèle de pertes choisi, nous présentons les résultats sans et avec pertes (Figure 5.19).
Cette figure souligne deux points. Tout d’abord cette optimisation a bien une influence similaire sur un modèle avec et sans perte. Pour un buffer plus petit, les paquets de 1500 octets sur la voie retour ont une plus grande chance d’être éliminés que les acquittements de 40 octets. Les mécanismes de TCP détectent alors de la congestion dans le système, et diminuent le débit d’émission sur le lien retour, laissant alors champ libre aux acquittements. La seconde conclusion que l’on peut tirer de cette étude est la plus délicate stabilité du système dans ce cas, qui donne des résultats moins performants que la solution applicative précédente. Enfin on peut noter que la présence d’erreur n’a pas toujours un impact négatif sur le système, puisqu’il peut permettre de diminuer le débit en upload, et ainsi augmenter le débit sur le lien retour. Toutefois on ne peut s’appuyer vraiment sur cette constatation pour optimiser le système.
Pour constater à quel point cette influence est sensible, nous avons fait varier la taille des buffers de 3 KB à 200 KB pour une simulation de 5000 s. La figure suivante (Figure 5.20) représente alors l’évolution du débit moyen obtenu pour le transfert aller et le transfert retour en fonction de la taille du buffer d’émission aller et retour (nous affectons la même taille aux deux buffers pour la simulation).
Figure 5.19 Évolution du débit applicatif observé sur le lien aller et retour en fonction du temps avec un buffer d’émission de 50 KB et de 100 KB
On peut observer ici l’influence réelle de la taille des buffers d’émission sur le débit moyen aller et retour. Cet impact est bien plus important sur le flux à destination, que celui en partance. En effet la variation peut aller jusqu’à près de 700 % sur le lien aller, alors que pour le flux en upload, on observe une variation de moins de 100 % (au maximum). La taille optimale pour la voie aller semble être de 41 KB, avec un débit aller moyen de 338.65 B, contre un débit retour de 85.6 KB.
Cette variation surprenante est essentiellement due à la régulation des échanges TCP. Dans un échange bidirectionnel comme celui là, aucun état stationnaire n’est vraiment possible, il s’agit alors plutôt d’un cycle de remplissage des buffers. Ainsi lorsque le buffer d’émission du client arrive à saturation, les paquets à émettre, acquittements comme données, sont rejetés. Toutefois, les données étant plus volumineuses que les acquittements, elles ont plus de chance d’être supprimées. Le flux upload TCP s’autorégule alors, baissant son débit, et laissant la voie libre aux acquittements de la voie descendante. On arrive alors dans un état cyclique de remplissage du buffer. Un état optimal peut alors être trouvé.
Plus la taille du buffer d’émission du serveur augmente, plus celui-ci peut émettre efficacement vers le client, entraînant une augmentation du débit aller.
Plus la taille du buffer d’émission du client augmente, plus il est possible d’émettre de paquets en upload, augmentant le temps d’attente des acquittements dans la file d’attente, et dégradant ainsi le débit de la voie aller.
Puisque cette courbe représente l’évolution en simultanée des deux buffers, il est normal d’observer cette double évolution. Les oscillations sont dues en grande partie à ce phénomène, cumulé à l’impact des variations de la taille du buffer, qui entraîne la perte ou non d’acquittements, et donc une dégradation potentielle du débit du lien aller.
Figure 5.20 Évolution du débit moyen applicatif sur 5000 s en fonction de la taille des buffers
d’émission
On peut enfin noter un seuil qui correspond à une taille décisive de la file d’attente, au-delà de laquelle le RTO de TCP se déclenchera dans tous les cas. Aucun paquet n’est perdu par des files d’attente supérieures à 87 KB, mais c’est TCP qui s’autorégule alors, entraînant une baisse du débit, et donc une diminution de la taille de la file d’attente. Ce qui explique que lors d’une telle communication, le buffer d’émission ne pourra jamais dépasser une certaine taille (ici 87 KB), et donc le comportement de TCP sera identique au-delà de cette valeur.
5.4.3.3.2. L’INFLUENCE DE LA POLITIQUE DE SERVICE DES BUFFERS D’ÉMISSION
Une autre méthode consiste à gérer le buffer d’émission au niveau de l’interface IP, ou MAC. Ainsi il est possible d’implanter ici une politique différente du FIFO, permettant de donner une priorité équivalente voire plus grande aux acquittements. La politique de service sur la file peut ainsi être changée, mais d’autres files peuvent aussi être introduites, une pour les trafics prioritaires, de type temps réel par exemple, et une autre pour les autres.
Nous proposons ici d’observer l’amélioration apportée par ces techniques sur le débit applicatif du système. Les figures suivantes présentent respectivement la mise en oeuvre d’une politique de diminution du nombre de paquet en attente dans la file pour un type de flux donné (cette politique est introduite en NS sous de nom de Deficient Round Robin) (Figure 5.21), et du Fair Queueing (Figure 5.22) reposant sur un Round Robin prenant en compte la taille des données.
Figure 5.21 Évolution du débit applicatif observé sur le lien aller et retour en fonction du temps avec une politique de DeficientRound Robin sur le buffer d’émission de 150 KB
Figure 5.22 Évolution du débit applicatif observé sur le lien aller et retour en fonction du temps avec une politique de Fair Queueing sur le buffer d’émission de 150 KB
Sur ces deux courbes, on peut constater l’amélioration très nette apportée par une gestion de la file d’émission du client. On pourra noter une meilleure performance du Fair Queueing pour le débit applicatif aller. En effet, son utilisation fondée sur la distribution d’étiquette en fonction du trafic transmis, permet d’assurer aux acquittements un passage rapide en tête de la file, n’ayant qu’à attendre tout au plus l’émission du datagramme en cours du flux d’upload (le mode préemptif étant rarement conseillé). De plus, l’attribution des étiquettes se fonde sur la taille des données, permettant pour des paquets de MTU 1500 B, d’envoyer entre 37 et 38 acquittements pour un datagramme d’upload. Dans le cas du Deficient Round Robin, l’amélioration est notable, mais le flux des acquittements àa encore à souffrir de grandes variations, ce qui explique de moins bonnes expériences (Figure 5.23).
Figure 5.23 Aperçu de l’évolution de la file d’attente d’émission dans le cas DRR et FQ 5.4.3.3.3. L’INFLUENCE DE LA MTU
Une dernière solution proposée ici est la diminution de la MTU sur le lien retour. Ce type de problème a déjà été rencontré sur les réseaux terrestres qui, pour permettre une meilleure réactivité, fixent la MTU sur le lien retour à 576 B (valeur plus communément utilisée sur Internet), soit une MSS de 536 B.
L’avantage de ce type de solution est étudié ici, montrant l’influence d’un découpage en plus petits paquets sur la voie retour. Il faut noter qu’il n’est pas tout à fait dans l’intérêt de la voie retour d’utiliser une MTU plus petite que 1500 B, puisque cela générerait un grand nombre d’acquittements supplémentaires sur la voie retour, ainsi qu’une diminution du trafic TCP dans la période de slow start et de congestion avoidance (période très sensible sur le satellite).
Figure 5.24 Évolution du débit applicatif observé sur le lien aller et retour en fonction du temps et de la MSS du lien retour.
Les figures ci-dessus proposent d’observer l’évolution du débit moyen en fonction du temps. Nous avons fait cette étude pour différentes valeurs de la MSS, et nous proposons ici les
courbes obtenues pour des MSS de 88, 216, et 536 et 1460 B. Le cas 1460 B est présenté précédemment dans cette partie (Figure 5.16), les autres sont tracés dans la figure ci-dessus.
On observe dans ces courbes une très nette corrélation entre l’augmentation du débit aller et la diminution du débit retour. Ainsi pour le passage d’une MSS de 216 B à 88 B, on observe une diminution de plus de 50 % pour le débit applicatif retour, contre à peine une augmentation de 10 % sur la voie aller.
Cependant si l’on compare les résultats obtenus pour une MSS de 1460 B et ceux pour 536 B, on a une baisse sur le lien retour de quelques pourcents pour une augmentation entre 100% et 150 % pour le débit applicatif retour. On peut donc conclure que cette méthode peut apporter un gain réel de performance à condition de garder une MSS de l’ordre de 500 B sur la voie retour, pour ne pas dégrader le débit en upload.
5.4.3.3.4. CONCLUSION SUR CES OPTIMISATIONS
Nous pouvons noter dans cette partie qu’un grand nombre de ces optimisations permettent d’améliorer le débit aller au détriment plus ou moins important de la voie retour. Toutefois, la majeure partie de ces solutions permet de gagner plus que l’on ne perd. Une solution comme l’application d’une politique de service du buffer d’émission permet d’offrir de très bons résultats, sans une baisse trop importante du débit applicatif sur la voie retour.
Ces améliorations nous semblent très utiles pour obtenir un service performant, et doivent donc être prises en compte dans le système hybride, d’autant plus que des modifications au niveau liaison restent transparentes pour l’utilisateur final.