Comparaison de performances entre TCP et SCTP

Dans l’article [KuJa04], les performances de TCP apparaissent meilleures que celles de SCTP dans les MANETs. Ceci provient des versions comparées, en particulier, de l’utili- sation d’une option SACK pour SCTP, coûteuse en overhead, et d’une option ACK pour TCP. Dans cette section, nous montrons l’intérêt d’avoir des paramètres similaires pour SCTP et TCP et déterminons les valeurs de ceux-ci.

Nous utilisons un modèle très simple, comprenant une source et un destinataire (voir la Figure2.12) et définissons trois scénarios de simulation sans perte pour tester l’implan- tation NS.

FIG. 2.12 – Scénario entre une source et une destination

Scénario 1 : TCP et SCTP utilisent les paramètres par défaut du simulateur

NS2. SCTP

– MTU = 1500 octets.

– Taille des données = 1468 octets. – Taille de l’en-tête = 32 octets.

– Taille de la file d’attente de réception = 65536 octets.

TCP

– MTU = 1040 octets.

– Taille des données = 1000 octets. – Taille de l’en-tête = 40 octets. – Taille de la fenêtre = 30 paquets.

La taille de la file d’attente de réception de TCP est obtenue par l’émetteur dans la limite de la taille de fenêtre. Pour SCTP, la taille de fenêtre est la taille de la file d’attente de réception / la taille de MTU.

Dans la première simulation nous cherchons à découvrir l’impact de la taille de la MTU sur les performances des protocoles TCP et SCTP. A cet effet, nous gardons les carac- téristiques normales de transmission de données qui incluent une taille de MTU de 1500 octets dans SCTP et une taille de MTU de 1040 octets avec TCP. Les résultats observés sont indiqués sur la Figure2.13 qui représente l’évolution de la taille de la fenêtre avec le temps de simulation. Nous avons utilisé un temps de simulation de 100 secondes.

FIG. 2.13 – Scénario 1 : utilisation des valeurs par défaut

Résultat :

Nous pouvons voir que la taille de fenêtre de SCTP atteint un seuil plus important que celle de TCP avant que celle-ci ne passe en progression linéaire. De plus, alors que TCP continue à augmenter sa fenêtre, SCTP reste avec une fenêtre constante car il est limité par la fenêtre de réception (65536 octets).

Dans le deuxième scénario nous modifions les paramètres par défaut : la taille de la MTU est équivalente pour les deux protocoles, la taille de la fenêtre de TCP est choisie pour obtenir un seuil de basculement (progression exponentielle / progression linéaire) entre SCTP et TCP équivalent. D’après le scénario 1 cette valeur est de 44 paquets.

Scénario 2 : Nous changeons le MTU et la taille de la fenêtre de TCP.

SCTP

– MTU = 1500 octets.

– Taille des données = 1468 octets. – Taille de l’en-tête = 32 octets.

TCP

– MTU = 1500 octets.

– Taille des données = 1460 octets. – Taille de l’en-tête = 40 octets. – Taille de la fenêtre = 44 paquets.

FIG. 2.14 – Scénario 2 : Changement des paramètres MTU et taille de fenêtre TCP

Résultat :

Les résulats illustrés dans la Figure 2.14, montrent un comportement d’émission en phase d’initialisation similaire. L’évolution des fenêtres des deux protocoles, quoique pas tout à fait identiques sont plus proches que précédemment. L’étape suivante est de modifier les paramètres de SCTP pour obtenir un accroissement linéaire équivalent à celui de TCP.

Scénario 3 : Nous changeons la taille de la file d’attente de réception de

SCTP. SCTP

– MTU = 1500 octets.

– Taille de l’en-tête = 32 octets.

– Taille de la file d’attente de réception = 65536 x 2 = 131072 octets.

TCP

– MTU = 1500 octets.

– Taille des données = 1460 octets. – Taille de l’en-tête = 40 octets. – Taille de la fenêtre = 44 paquets.

FIG. 2.15 – Scénario 3 : Changement du paramètre taille de la file d’attente de réception SCTP

Résultat :

Dans ce dernier scénario nous obtenons un comportement similaire de SCTP,

et de TCP (voir la Figure 2.15). Notons que si la taille de la queue de réception du récepteur est suffisamment grande pour garder les paquets pendant le temps qu’un paquet perdu soit retransmis, la performance est alors améliorée.

2.4

Conclusion

Dans ce chapitre nous avons synthétisé les éléments de base des optimisations pour améliorer les performances du transport en réseaux ad hoc. Nous nous sommes intéressés à la méthode, au protocole et, aux paramètres permettant d’obtenir des évaluations cohé- rentes.

La méthode cross layer, s’appuie sur des échanges d’informations entre des couches qui ne sont pas forcément adjacentes, la performance globale est optimisée en adaptant chaque niveau en fonction de l’information disponible. Les architectures protocolaires, pour mettre en oeuvre les mécanismes d’adaptation, s’inspirent de trois modèles : com- munication directe entre couches, interactions vers une entité intermédiaire et nouvelles abstractions. Dans les chapitres suivants, nous utilisons le modèle d’interactions vers une entité intermédiaire. Celui-ci sera géré à la source dans le chapitre 3 et de façon répartie dans le chapitre 4. Le modèle choisi simplifie les évolutions d’architectures, par rapport à un modèle de communication directe entre couches, tout en préservant le découpage fonctionnel de l’architecture standard qui est remis en cause dans le modèle par compo- sants. En nous référant à la classification des optimisations que nous avons effectuée, nos propositions se situent au niveau transport, sur des événements optimisés inter-couches, et des algorithmes optimisés.

Le protocole de transport sur lequel nous travaillons est SCTP en raison de sa capacité à gérer le multihoming. Quoique très proche de SCTP nous avons relevé des différences, en particulier sur les paramètres de congestion. Nous avons déterminé leurs valeurs pour obtenir des évaluations de performances pertinentes.

3

Optimisation de SCTP par communication inter-couches `a l’initiative du

noeud source

Sommaire

3.1 Fonctionnement de SCTP . . . . 60

3.1.1 Chunk Bundling : Format de Messages SCTP . . . 61