4.3. TCP New Reno
L'algorithme New Reno n'est qu'une modification
légère mais significative apportée à l'algorithme
Reno. En effet, cette modification, permet à TCP New Reno
d'éviter de devoir attendre pour qu'un déclenchement de
retransmission se produise lorsque plusieurs paquets sont perdus au sein d'une
même fenêtre de congestion.
Le changement s'opère au niveau de la phase de
recouvrement rapide (Fast recovery) : Tant que l'émetteur n'a pas
reçu les ACK de tous les paquets perdus (réception d'un
acquittement partiel pour seulement une partie des segments perdus), TCP New
Reno reste dans cette phase. Un accusé partiel permet donc de se rendre
compte que parmi les paquets retransmis une première fois, certains ont
à nouveau été perdus. Dès lors, cette version
n'attend pas un Time Out pour retransmettre ces paquets perdus. TCP New Reno ne
quitte pas l'algorithme de Fast Recovery contrairement à Reno qui sort
de ce mode dès la réception d'un ACK non dupliqué.
La version TCP New Reno apporte des réponses aux pertes
successives, cependant elle souffre du fait qu'elle utilise un RTT pour
détecter chaque perte de paquet. Néanmoins elle est parmi les
versions les plus utilisées de TCP actuellement.
4.4. TCP Vegas
Plutôt que d'attendre une perte de paquet, TCP Vegas
prend en compte le temps de réponse du destinataire (le RTT) afin d'en
déduire le ratio auquel envoyer les paquets. En fonction du temps de
réponse, on est capable de supposer l'état des buffers des
routeurs intermédiaires. Vegas modifie pour cela plusieurs algorithmes
vus jusqu'ici (slow-start, Congestion Avoidance, Fast Retransmit). Grâce
à cette technique, Vegas à de meilleurs débits et moins de
pertes de paquets que Reno. Cet algorithme permet d'atteindre un partage
équitable des ressources. De même, il y a assez peu de pertes avec
Vegas puisqu'à l'état stable, le débit correspond de
près à la capacité du lien [33].
TCP Vegas permet de s'adapter plus rapidement aux changements
de disponibilité des liens. Cependant, les performances se
dégradent lorsqu'il est utilisé avec d'autres protocoles qui ne
prennent pas en compte l'état des liens avant une perte de paquet. Son
inconvénient est qu'il nécessite une modification de la pile TCP
au niveau de l'émetteur et du récepteur.
27
Chapitre I: Concepts de base
4.5. TCP Westwood+
TCP Westwood est une variante modifiée
côté émetteur de l'algorithme de TCP New Reno. Cette
modification a pour but d'apporter une meilleure gestion des LFN (long fat
network). TCP Westwood modifie les valeurs de ssthresh et de cwnd en fonction
des estimations qu'il fait sur la bande passante disponible. La première
version faisant de mauvaises estimations, elle a été
corrigée par la suite, d'où le nom Westwood+. Ces estimations se
basent, comme pour Vegas sur le temps de réponse du destinataire (RTT),
sauf que ces estimations sont utilisées différemment.
TCP Westwood possède un mécanisme qui
détecte qu'il n'y a pas de congestion (Persistent Non Congestion
Detection, PNCD), ce qui lui permet de rapidement utiliser la bande passante
disponible. Il modifie le slow-start (devient moins agressif) en y ajoutant une
phase : « Agile Probing ». Cette modification lui permet (avec les
estimations via le RTT) d'avoir une phase d'accroissement de cwnd [34] quasi
exponentielle puis de se stabiliser, d'accroître, puis de se stabiliser,
etc...
L'algorithme gagne beaucoup en efficacité, mais perd en
équité puisqu'en cas de pertes de paquets il ne s'adapte pas
directement en divisant la fenêtre cwnd par deux.
| 
