Modélisation du transport

Rappelons brièvement le principe de base des algorithmes de congestion slow start

et congestion avoidance dont les principes sont définis dans le RFC 2581 [StAP99]. Concernant le contrôle de congestion, il s’agit d’adapter le taux d’envoi des segments en fonction du taux d’arrivée des acquittements (ACKs). L’objectif est d’arriver à un ni- veau d’autosynchronisation où la cadence d’émission (réglée par la taille de la fenêtre) est égale à la cadence où les paquets quittent le réseau (réception de ACK). Les ACK reçus sont utilisés pour augmenter la taille de la fenêtre de congestion (congestion window : CWND), et donc le débit d’émission, de façon à exploiter au mieux la bande passante disponible. L’algorithme slow start augmente de façon exponentielle la taille de la fenêtre pour, à l’initialisation, remplir rapidement le réseau de paquets en transit, alors que l’ac- croissement devient ensuite linéaire, en phase de congestion avoidance, pour s’adapter à la cadence de sortie de réseau des paquets. Lorsqu’une congestion est détectée, la taille de la fenêtre est diminuée.

La valeur de la fenêtre, sa fonction de croissance avec les seuils pour passer d’un ac- croissement exponentiel à un accroissement linéaire, font l’objet de plusieurs variantes de TCP. Les différences entre les versions de TCP viennent également des algorithmes ap- pliqués par TCP pour assurer la fiabilité du transfert. Deux modes de recouvrement sont spécifiés dans les standards :

– Le fast retransmit : lorsque l’émetteur progresse dans sa transmission de données, mais qu’il n’y a pas de progression dans les acquittements qu’il reçoit, il suppose qu’il y a eu un problème et déclenche la retransmission d’un segment, l’idée étant de ne pas attendre que le temporisateur de retransmission expire pour retransmettre. Le segment qui semble manquer est réémis dès réception de trois ACKs dupliqués

(DUPACKs).

– Le fast recovery consiste à essayer de continuer à transmettre des segments grâce à une diminution adéquate de la fenêtre (afin de ne pas interrompre l’horloge des ACKs qui la font glisser), puis à passer en congestion avoidance.

Les différentes versions de TCP proposent des algorithmes spécifiques pour augmenter la taille de la fenêtre et gérer les retransmissions. L’évolution de la fenêtre en cas de perte de donnée est illustrée sur la Figure1.3. Nous allons nous intéresser aux versions du protocole TCP NewReno, TCP Sack et TCP Westwood qui d’après leurs caractéristiques sont adaptées à un environnement sans fil. Les premières permettent de gérer des pertes multiples, la dernière d’adapter le débit au plus près de celui de la liaison. Nous évaluerons par simulation l’intérêt d’utiliser ces options en les comparant avec la version de base TCP Reno.

FIG. 1.3 – Évolution de la fenêtre de congestion avec retransmission rapide

1.4.1.1 TCP Reno/NewReno

La version de TCP dite Reno, proposée par Jacobson dans [Jaco88] et [Jaco90], a introduit le fast retransmit (dans la version historique, dite Tahoe [Jaco88], ce n’était qu’après l’expiration du timer que la perte était détectée). La perte de paquet, signe d’une congestion, déclenche la retransmission des paquets perdus. La retransmission s’effectue avec une fenêtre de congestion réduite à un segment, même si la perte s’est produite avec une taille de fenêtre importante. Ceci n’est pas efficace puisque la congestion s’est produite pour une valeur de fenêtre qui était supérieure à un, il n’est pas utile de la réduire autant. La proposition de Jacobson est de diminuer la valeur de la fenêtre non pas à un mais à la moitié de la valeur courante qu’avait celle-ci lors de la perte et ensuite d’augmenter sa taille de façon linéaire, pour transmettre de nouvelles données (algorithme de fast recovery).

Si plusieurs études, telle celle de floyd [FaFl96], ont montré que TCP Reno offre de meilleures performances par rapport à Tahoe, en cas de perte d’un seul paquet dans une fenêtre de congestion, en revanche, en cas de pertes multiples, les performances de TCP Reno se dégradent car il ne peut pas éviter les expirations à répétition de timers. La version TCP NewReno spécifiée dans le RFC 3782 [FlHG04] modifie légèrement le fast recovery pour prendre en compte les pertes multiples. Dans TCP Reno le premier acquittement

partiel stoppe la phase de recouvrement rapide alors que pour NewReno l’acquittement partiel est compris comme une indication de perte : l’émetteur retransmet le premier paquet non acquitté.

1.4.1.2 TCP Sack

Le mécanisme des acquittements sélectifs (Sack), RFC 2883 [FMMP00], permet égale- ment d’améliorer la retransmission des données en cas d’erreurs multiples. L’idée de Sack est de permettre au TCP récepteur de confirmer non seulement la dernière donnée reçue en séquence, mais également des données reçues hors séquence ; le TCP émetteur peut ainsi en déduire quelles sont les données manquantes, et donc optimiser (c’est-à-dire anti- ciper) la retransmission de celles-ci. Sack se base sur l’utilisation de deux options de TCP :

1. Sack-permitted

Un TCP mettant en oeuvre Sack et voulant employer ce mécanisme devra inclure cette option dans son segment SYN (synchroniser), d’ouverture de connexion. De cette façon, il annonce à l’autre extrémité de la connexion qu’il supporte cette mé- thode d’acquittement. Sack ne sera utilisé pour la connexion que si les deux extré- mités incluent cette option dans leur SYN.

FIG. 1.4 – Format de l’option SACK 2. Sack

Cette option (Figure 1.4), qui peut être vue comme un ensemble de champs sup- plémentaires au champ numéro d’acquittement, permet au récepteur d’indiquer à l’émetteur quels sont les blocs de données contigus reçus correctement mais hors séquence. Du fait des limitations de la taille des options dans l’en-tête TCP, le ré- cepteur peut annoncer un maximum de quatre blocs de données hors séquence (trois blocs, dans le cas où l’option de l’estampillage temporel, ou timestamps, est utilisée).

1.4.1.3 TCP Westwood

TCP Westwood (TCP-W) n’est pas standardisé, et des travaux le concernant seront trouvés en [MCGL00], [ZPGS01], [GrMa04], [MGFC04]. Il a été spécifié pour des grands réseaux avec des débits élevés, des variations de charges importantes, des pertes d’in- formations dues à la congestion mais également à des erreurs de transmission. Il utilise l’algorithme de fast recovery en s’appuyant sur une estimation de la bande passante pour régler les mouvements de la fenêtre de congestion, et pour adapter les seuils des algorithmes de traitement de congestion (voir Figure1.5).

FIG. 1.5 – TCP Westwood

Pour évaluer la bande passante disponible, TCP-W mesure le taux de réception des ac- cusés de réception. Pour cela, l’émetteur doit déduire le nombre de données envoyées vers le récepteur en fonction du temps. Lorsqu’un ACK parvient à la source, cela exprime qu’une certaine quantité d’informations est arrivée à destination. En effectuant une moyenne du nombre de données envoyées en fonction du temps, et s’il n’y a pas de pertes, on obtient une estimation de la bande passante utilisée par la source. Si les paquets transmis par la source sont de tailles variables, et qu’une perte survient et que celle-ci est annoncée par la présence de duplicate ACKs (DUPACKs), il n’est pas possible de savoir quel paquet s’est perdu. Il est alors utile d’effectuer des échantillonnages de mesures de taille de paquets pour pouvoir évaluer la quantité d’information perdue. Plus de précisions sur la mise à jour des variables (“Slow Start threshold (SSthresh)” et “Congestion Avoidance”) et les procédures de mesures seront trouvées en [WVSG02].