3.1. Démarrage Lent et Évitement de Congestion

Les algorithmes de démarrage lent et d'évitement de congestion DOIVENT (MUST) être utilisés par un expéditeur TCP pour contrôler la quantité de données en attente injectées dans le réseau.

Variables d'État

Pour implémenter ces algorithmes, deux variables sont ajoutées à l'état par connexion TCP:

1. Fenêtre de Congestion (cwnd): Une limite côté expéditeur sur la quantité de données que l'expéditeur peut transmettre dans le réseau avant de recevoir un accusé de réception (ACK)
2. Fenêtre Annoncée par le Récepteur (rwnd): Une limite côté récepteur sur la quantité de données en attente

Le minimum de cwnd et rwnd régit la transmission de données.

Une autre variable d'état, le seuil de démarrage lent (ssthresh), est utilisée pour déterminer si l'algorithme de démarrage lent ou d'évitement de congestion est utilisé pour contrôler la transmission de données, comme discuté ci-dessous.

Objectif du Démarrage Lent

Commencer la transmission dans un réseau avec des conditions inconnues nécessite que TCP sonde lentement le réseau pour déterminer la capacité disponible, afin d'éviter de congestionner le réseau avec une rafale de données inappropriément grande. L'algorithme de démarrage lent est utilisé à cet effet:

• Au début d'un transfert
• Après la réparation d'une perte détectée par le temporisateur de retransmission

Le démarrage lent sert également à démarrer "l'horloge ACK" utilisée par l'expéditeur TCP pour libérer des données dans le réseau dans les algorithmes de démarrage lent, d'évitement de congestion et de récupération de perte.

Fenêtre Initiale (IW)

IW, la valeur initiale de cwnd, DOIT (MUST) être définie en utilisant les directives suivantes comme limite supérieure:

Si SMSS > 2190 octets:
    IW = 2 * SMSS octets et NE DOIT PAS être plus de 2 segments

Si (SMSS > 1095 octets) et (SMSS <= 2190 octets):
    IW = 3 * SMSS octets et NE DOIT PAS être plus de 3 segments

Si SMSS <= 1095 octets:
    IW = 4 * SMSS octets et NE DOIT PAS être plus de 4 segments

Comme spécifié dans [RFC3390], le SYN/ACK et l'accusé de réception du SYN/ACK NE DOIVENT PAS (MUST NOT) augmenter la taille de la fenêtre de congestion. De plus, si le SYN ou SYN/ACK est perdu, la fenêtre initiale utilisée par un expéditeur après un SYN correctement transmis DOIT (MUST) être un segment contenant au plus SMSS octets.

Une justification détaillée et une discussion du réglage IW sont fournies dans [RFC3390].

Considérations sur la Découverte du MTU du Chemin

Lorsque des fenêtres de congestion initiales de plus d'un segment sont implémentées conjointement avec la Découverte du MTU du Chemin (Path MTU Discovery) [RFC1191], et que la MSS utilisée s'avère trop grande, la fenêtre de congestion cwnd DEVRAIT (SHOULD) être réduite pour éviter de grandes rafales de segments plus petits. Plus précisément, cwnd DEVRAIT (SHOULD) être réduite du rapport de l'ancienne taille de segment à la nouvelle taille de segment.

Valeur Initiale de ssthresh

La valeur initiale de ssthresh DEVRAIT (SHOULD) être définie arbitrairement élevée (par exemple, à la taille de la plus grande fenêtre annoncée possible), mais ssthresh DOIT (MUST) être réduit en réponse à la congestion.

Définir ssthresh aussi haut que possible permet aux conditions du réseau, plutôt qu'à une limite d'hôte arbitraire, de dicter le taux d'envoi.

Sélection d'Algorithme

• L'algorithme de démarrage lent est utilisé quand cwnd < ssthresh
• L'algorithme d'évitement de congestion est utilisé quand cwnd > ssthresh
• Quand cwnd et ssthresh sont égaux, l'expéditeur peut utiliser soit le démarrage lent soit l'évitement de congestion

Algorithme de Démarrage Lent

Pendant le démarrage lent, un TCP incrémente cwnd d'au plus SMSS octets pour chaque ACK reçu qui acquitte cumulativement de nouvelles données. Le démarrage lent se termine lorsque:

• cwnd dépasse ssthresh (ou, optionnellement, lorsqu'il l'atteint, comme noté ci-dessus), ou
• Lorsque la congestion est observée

Augmentation Recommandée de cwnd

Bien que traditionnellement les implémentations TCP aient augmenté cwnd de précisément SMSS octets lors de la réception d'un ACK couvrant de nouvelles données, nous RECOMMANDONS (RECOMMEND) que les implémentations TCP augmentent cwnd, selon:

cwnd += min (N, SMSS)    (équation 2)

où N est le nombre d'octets précédemment non acquittés acquittés dans l'ACK entrant.

Cet ajustement fait partie du comptage d'octets approprié (Appropriate Byte Counting) [RFC3465] et fournit une robustesse contre les récepteurs mal comportés qui peuvent tenter d'inciter un expéditeur à gonfler artificiellement cwnd en utilisant un mécanisme connu sous le nom de "division d'ACK" [SCWA99].

Algorithme d'Évitement de Congestion

Pendant l'évitement de congestion, cwnd est incrémenté d'environ 1 segment de taille complète par temps d'aller-retour (RTT). L'évitement de congestion continue jusqu'à ce que la congestion soit détectée.

Directives pour l'Incrémentation de cwnd

Les directives de base pour incrémenter cwnd pendant l'évitement de congestion sont:

• PEUT (MAY) incrémenter cwnd de SMSS octets
• DEVRAIT (SHOULD) incrémenter cwnd selon l'équation (2) une fois par RTT
• NE DOIT PAS (MUST NOT) incrémenter cwnd de plus de SMSS octets

Implémentation Recommandée

La méthode RECOMMANDÉE (RECOMMENDED) pour augmenter cwnd pendant l'évitement de congestion est de compter le nombre d'octets qui ont été acquittés par des ACK pour de nouvelles données. Lorsque le nombre d'octets acquittés atteint cwnd, alors cwnd peut être incrémenté jusqu'à SMSS octets.

Notez que pendant l'évitement de congestion, cwnd NE DOIT PAS (MUST NOT) être augmenté de plus de SMSS octets par RTT.

Formule Alternative

Une autre formule courante qu'un TCP PEUT (MAY) utiliser pour mettre à jour cwnd pendant l'évitement de congestion est donnée dans l'équation (3):

cwnd += SMSS*SMSS/cwnd    (équation 3)

Cet ajustement est exécuté à chaque ACK entrant qui acquitte de nouvelles données. L'équation (3) fournit une approximation acceptable du principe sous-jacent consistant à augmenter cwnd d'un segment de taille complète par RTT. (Notez que pour une connexion où le récepteur acquitte un paquet sur deux, (3) est moins agressive que permis — augmentant cwnd approximativement tous les deux RTT.)

Notes d'Implémentation pour l'Équation (3)

Note 1 : Comme l'arithmétique entière est généralement utilisée dans les implémentations TCP, la formule de l'équation (3) peut ne pas augmenter cwnd lorsque la fenêtre de congestion est plus grande que SMSS*SMSS. Si la formule ci-dessus donne 0, le résultat DEVRAIT (SHOULD) être arrondi à 1 octet.

Note 2 : Les anciennes implémentations ont une constante additive supplémentaire du côté droit de l'équation (3). Cela est incorrect et peut en fait conduire à des performances diminuées [RFC2525].

Note 3 : Certaines implémentations maintiennent cwnd en unités d'octets, tandis que d'autres en unités de segments de taille complète. Ces dernières trouveront l'équation (3) difficile à utiliser, et peuvent préférer utiliser l'approche par comptage discutée au paragraphe précédent.

Réponse à la Perte

Lorsqu'un expéditeur TCP détecte une perte de segment en utilisant le temporisateur de retransmission et que le segment donné n'a pas encore été renvoyé par le temporisateur de retransmission, la valeur de ssthresh DOIT (MUST) être définie à pas plus que la valeur donnée dans l'équation (4):

ssthresh = max (FlightSize / 2, 2*SMSS)    (équation 4)

où, comme discuté ci-dessus, FlightSize est la quantité de données en attente dans le réseau.

En revanche, lorsqu'un expéditeur TCP détecte une perte de segment en utilisant le temporisateur de retransmission et que le segment donné a déjà été retransmis au moins une fois par le temporisateur de retransmission, la valeur de ssthresh est maintenue constante.

Note d'Implémentation sur FlightSize

Une erreur facile à commettre est d'utiliser simplement cwnd, plutôt que FlightSize, ce qui dans certaines implémentations peut augmenter bien au-delà de rwnd.

Réglage de cwnd après Timeout

En outre, lors d'un timeout (comme spécifié dans [RFC2988]) cwnd DOIT (MUST) être défini à pas plus que la fenêtre de perte, LW, qui est égale à 1 segment de taille complète (indépendamment de la valeur d'IW).

Par conséquent, après avoir retransmis le segment abandonné, l'expéditeur TCP utilise l'algorithme de démarrage lent pour augmenter la fenêtre de 1 segment de taille complète à la nouvelle valeur de ssthresh, à ce moment l'évitement de congestion reprend.

Retransmissions Spurious

Comme le montrent [FF96] et [RFC3782], la récupération de perte basée sur le démarrage lent après un timeout peut provoquer des retransmissions spurious qui déclenchent des accusés de réception en double. La réaction à l'arrivée de ces ACK en double dans les implémentations TCP varie considérablement. Ce document ne spécifie pas comment traiter de tels accusés, mais note cela comme un domaine qui pourrait bénéficier d'une attention, d'expérimentations et d'une spécification supplémentaires.