Contrôle d'encombrement avec TCP

Statut du présent mémoire

Le présent document spécifie un protocole en cours de normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright

Copyright (C) The Internet Society (1999). Tous droits réservés.

Résumé

Le présent document définit les quatre algorithmes entrelacés de TCP pour le contrôle d'encombrement : démarrage lent, évitement d'encombrement, retransmission rapide, et récupération rapide. De plus, le document spécifie comment TCP devrait commencer la transmission après une période de repos relativement longue, ainsi qu'une discussion sur les diverses méthodes de génération d'accusé de réception.

1.   Introduction

Le présent document spécifie quatre algorithmes TCP [RFC0793] de contrôle d'encombrement : démarrage lent, évitement d'encombrement, retransmission rapide et récupération rapide. Ces algorithmes ont été imaginés dans [Jac88] et [Jac90]. Leur utilisation avec TCP est normalisée dans la [RFC1122].

Le présent document est une mise à jour de la [RFC2001]. En plus de la spécification des algorithmes de contrôle de l'encombrement, le présent document spécifie ce que les connexions TCP devraient faire après une période relativement longue d'inactivité, et il spécifie et précise aussi certaines des questions qui relèvent de la génération des ACK TCP.

Noter que [Ste94] donne des exemples de ces algorithmes en action et que [WS95] donne une explication du code source pour la mise en œuvre en BSD de ces algorithmes.

Le présent document est organisé comme suit. La Section 2 donne diverses définitions qui sont utilisées dans le document. La Section 3 donne une spécification des algorithmes de contrôle d'encombrement. La Section 4 traite des problèmes qui se rapportent aux algorithmes de contrôle d'encombrement et finalement, la Section 5 traite des considérations pour la sécurité.

Les mots clé "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119].

2.   Définitions

La présente section donne les définitions de plusieurs termes qui seront utilisés dans la suite de ce document.

Segment : Un segment est TOUT paquet de données ou d'accusé de réception TCP/IP (ou les deux).

Taille maximum de segment d'envoi (SMSS, Sender Maximum Segment Size) : La SMSS est la taille du plus grand segment que peut transmettre l'envoyeur. Cette valeur peut être fondée sur l'unité maximum de transmission (MTU) du réseau, sur l'algorithme de découverte de la MTU du chemin [RFC1191], sur la RMSS (voir l'élément suivant), ou sur d'autres facteurs. La taille n'inclut pas les en-têtes TCP/IP ni les options.

Taille maximum de segment de réception (RMSS, Receiver Maximum Segment Size) : La RMSS est la taille du plus grand segment que le receveur veut accepter. C'est la valeur spécifiée dans l'option MSS envoyée par le receveur durant le démarrage de la connexion. Ou, si l'option MSS n'est pas utilisée, 536 octets [RFC1122]. La taille n'inclut pas les en-têtes TCP/IP ni les options.

Segment complet (Full-Sized Segment) : Un segment qui contient le nombre maximum d'octets de données permis (c'est-à-dire, un segment qui contient SMSS octets de données).

Fenêtre de receveur (rwnd, receiver window) : La dernière fenêtre de receveur annoncée.

Fenêtre d'encombrement (cwnd, congestion window) : Une variable d'état TCP qui limite la quantité de données qu'une connexion TCP peut envoyer. À tout moment, une connexion TCP NE DOIT PAS envoyer de données avec un numéro de séquence supérieur à la somme du plus haut numéro de séquence acquitté et du minimum de cwnd et rwnd.

Fenêtre initiale (IW, Initial Window) : La fenêtre initiale est la taille de la fenêtre d'encombrement de l'envoyeur après l'achèvement de la prise de contact ternaire (three-way handshake).

Fenêtre de perte (LW, Loss Window) : C'est la taille de la fenêtre d'encombrement après qu'un envoyeur TCP a détecté une perte en utilisant son temporisateur de retransmission.

Fenêtre de redémarrage (RW, Restart Window) : C'est la taille de la fenêtre d'encombrement après qu'une connexion TCP a redémarré la transmission après une période de repos (si l'algorithme de démarrage lent est utilisé, voir au paragraphe 4.1).

Taille en cours (Flight Size) : Quantité de données envoyées non encore acquittées.

3.   Algorithmes de contrôle d'encombrement

La présente Section définit les quatre algorithmes de contrôle d'encombrement : démarrage lent, évitement d'encombrement, retransmission rapide et récupération rapide, développés dans [Jac88] et [Jac90]. Dans certaines situations il peut être avantageux pour l'envoyeur TCP d'être plus conservateur que ce que permettent les algorithmes, cependant une connexion TCP NE DOIT PAS être plus agressive que ce que permettent les algorithmes suivants (c'est-à-dire qu'elle NE DOIT PAS envoyer de données lorsque la valeur de cwnd calculée par les algorithmes suivants ne permettrait pas que les données soient envoyées).

3.1   Démarrage lent et évitement d'encombrement

Les algorithmes de démarrage lent et d'évitement d'encombrement DOIVENT être utilisés par un envoyeur TCP pour contrôler la quantité de données qu'il est en train d'injecter dans le réseau. Pour mettre en œuvre ces algorithmes, deux variables sont ajoutées à l'état TCP par connexion. La fenêtre d'encombrement (cwnd) est une limite côté envoyeur sur la quantité de données que l'envoyeur peut émettre dans le réseau avant de recevoir un accusé de réception (ACK), alors que la fenêtre de receveur (rwnd) annoncée est une limite côté receveur sur la quantité de données en instance. Le minimum de cwnd et de rwnd gouverne la transmission des données.

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

Commencer la transmission dans un réseau dont on ne connaît pas les conditions exige de TCP qu'il sonde lentement le réseau pour déterminer la capacité disponible, afin d'éviter d'encombrer le réseau avec une salve de données d'une taille inappropriée. L'algorithme de démarrage lent est utilisé à cette fin au début d'un transfert, ou après réparation d'une perte détectée par le temporisateur de retransmission.

IW, la valeur initiale de cwnd, DOIT être inférieure ou égale à 2*SMSS octets et NE DOIT PAS être supérieure à deux segments.

On note qu'une extension expérimentale TCP non standard [RFC2414] admet qu'une connexion TCP PEUT utiliser une fenêtre initial (IW) plus grande, comme défini dans l'équation 1 :

   IW = min (4*SMSS, max (2*SMSS, 4380 bytes))   (1)

Avec cette extension, un envoyeur TCP PEUT utiliser une fenêtre initiale de 3 ou 4 segments, pourvu que la taille combinée des segments n'excède pas 4380 octets. Nous NE PERMETTONS PAS ce changement au titre de la norme définie par le présent document. Cependant, nous incluons la discussion de (1) dans le reste de ce document comme ligne directrice pour ceux qui font l'expérience de ce changement, plutôt que de se conformer à la présent norme pour le contrôle d'encombrement dans TCP.

La valeur initiale de ssthresh PEUT être arbitrairement élevée (par exemple, certaines mises en œuvre utilisent la taille de la fenêtre annoncée) mais elle peut être réduite en réponse à de l'encombrement. L'algorithme de démarrage lent est utilisé lorsque cwnd < ssthresh, alors que l'algorithme d'évitement d'encombrement est utilisé lorsque cwnd > ssthresh. Lorsque cwnd = ssthresh, l'envoyeur peut utiliser l'un ou l'autre algorithme.

Durant le démarrage lent, une connexion TCP incrémente cwnd d'au plus SMSS octets pour chaque ACK reçu qui accuse réception de nouvelles données. Le démarrage rapide se termine lorsque cwnd excède ssthresh (ou, facultativement, lorsque il atteint sa valeur, comme noté ci-dessus) ou lorsque on observe de l'encombrement.

Durant l'évitement d'encombrement, cwnd est incrémenté de un segment complet par délai d'aller-retour (RTT). L'évitement d'encombrement se poursuit jusqu'à détection d'encombrement. Une formule communément utilisée pour mettre à jour cwnd durant l'évitement d'encombrement est donnée dans l'équation 2 :

   cwnd += SMSS*SMSS/cwnd   (2)

Cet ajustement est exécuté sur tout ACK entrant non dupliqué. L'équation (2) donne une approximation acceptable du principe sous-jacent d'augmenter cwnd d'un segment complet par RTT. (Noter que pour une connexion dans laquelle le receveur accuse réception de chaque segment de données, (2) se révèle légèrement plus agressive que un segment par RTT, et pour un receveur qui accuse réception tous les autres paquets, (2) est moins agressive.)

   Note de mise en œuvre : Comme une arithmétique d'entiers est généralement utilisée dans les mises en œuvre de TCP, la formule donnée dans l'équation 2 peut échouer à augmenter cwnd lorsque la fenêtre d'encombrement est très large (supérieure à SMSS*SMSS). Si la formule ci-dessus donne 0, le résultat DEVRAIT être arrondi à 1 octet.

   Note de mise en œuvre : Les mises en œuvre plus anciennes ont une constante additive supplémentaire sur la partie droite de l'équation (2). Ceci est incorrect et peut en fait conduire à diminuer les performances [RFC2525].

Une autre façon acceptable d'augmenter cwnd durant l'évitement d'encombrement est de compter le nombre d'octets qui ont été acquittés par des ACK pour les nouvelles données. (Un inconvénient de cette mise en œuvre et qu'elle exige l'entretien d'une variable d'état supplémentaire.) Lorsque le nombre d'octets acquittés atteint cwnd, cwnd peut alors être incrémenté jusqu'à SMSS octets. Noter que durant l'évitement d'encombrement, cwnd NE DOIT PAS être augmenté de plus que le plus grand de un segment complet par RTT ou la valeur calculée en utilisant l'équation 2.

   Note de mise en œuvre : certaine mises en œuvre entretiennent cwnd en octets, alors que d'autres le font en segments complets. Cette dernière façon rend l'équation (2) difficile à utiliser et on peut préférer utiliser l'approche de comptage exposée au paragraphe précédent.

Lorsque un envoyeur TCP détecte une perte de segment en utilisant le temporisateur de retransmission, la valeur de ssthresh DOIT être réglée inférieure ou égale à la valeur données dans l'équation 3 :

   ssthresh = max (TailleEnCours/2, 2*SMSS)   (3)

Comme exposé plus haut, TailleEnCours est la quantité de données en instance dans le réseau.

   Note de mise en œuvre : une erreur facile à commettre est d'utiliser simplement cwnd, plutôt que TailleEnCours, ce qui dans certaines mises en œuvre peut à l'occasion augmenter bien au delà de rwnd.

De plus, sur une fin de temporisation cwnd DOIT être réglé à une valeur inférieure ou égale à la fenêtre de perte, LW, qui est égale à un segment complet (sans considération de la valeur de IW). Donc, après la retransmission du segment abandonné, l'envoyeur TCP utilise l'algorithme de redémarrage lent pour augmenter la fenêtre de un segment complet jusqu'à la nouvelle valeur de ssthresh, point auquel l'évitement d'encombrement va à nouveau prendre la préséance.

3.2   Retransmission rapide/Récupération rapide

Un receveur TCP DEVRAIT envoyer un ACK dupliqué immédiat lorsque arrive un segment décalé. L'objet de cet ACK est d'informer l'envoyeur qu'un segment a été reçu décalé et du numéro de séquence qui est attendu. Du point de vue de l'envoyeur, les ACK dupliqués peut être causés par un certain nombre de problèmes réseau. D'abord, ils peuvent être causés par des segments abandonnées. Dans ce cas, tous les segments après le segment abandonné vont déclancher des ACK dupliqués. Ensuite, les ACK dupliqués peuvent être causés par la réorganisation des segments de données par le réseau (ce n'est pas un événement rare le long de certains chemins du réseau [Pax97]). Enfin, des ACK dupliqués peuvent être causés par la réplication des ACK ou des segments de données par le réseau. De plus, un receveur TCP DEVRAIT envoyer un ACK immédiat lorsque le segment entrant bouche entièrement ou en partie un trou dans l'espace de séquence. Cela va générer des informations plus appropriées pour un envoyeur qui récupère d'une perte à travers une fin de temporisation de retransmission, une retransmission rapide, ou un algorithme expérimental de récupération de perte, tel que NewReno [RFC2582].

L'envoyeur TCP DEVRAIT utiliser l'algorithme "retransmission rapide" pour détecter et réparer les pertes, sur la base des ACK dupliqués entrants. L'algorithme "retransmission rapide" utilise l'arrivée de 3 ACK dupliqués (4 ACK identiques sans l'arrivée d'aucun autre paquet entre temps) comme indication de la perte d'un segment. Après réception de 3 ACK dupliqués, TCP effectue la retransmission de ce qui apparaît comme le segment manquant, sans attendre l'arrivée à expiration du temporisateur de retransmission.

Après que l'algorithme de retransmission rapide a envoyé ce qui paraît être le segment manquant, l'algorithme "récupération rapide" pilote la transmission des nouvelles données jusqu'à ce qu'arrive un ACK non dupliqué. La raison pour ne pas effectuer le démarrage lent est que la réception des ACK dupliqués indique non seulement qu'un segment a été perdu, mais aussi que des segments quittent très vraisemblablement le réseau (bien qu'une duplication massive de segments par le réseau puisse invalider cette conclusion). En d'autres termes, comme le receveur peut seulement générer un ACK dupliqué lors de l'arrivée d'un segment, ce segment a quitté le réseau et est dans la mémoire tampon du receveur, de sorte qu'on sait qu'il n'est plus en train de consommer les ressources du réseau. De plus, comme "l'horloge" ACK [Jac88] est préservée, l'envoyeur TCP peut continuer à transmettre de nouveaux segments (bien que la transmission doive continuer en utilisant un cwnd réduit).

Les algorithmes retransmission rapide et récupération rapide sont normalement mis en œuvre ensemble comme suit :

1.   Lorsque le troisième ACK dupliqué est reçu, régler ssthresh à une valeur inférieure ou égale à celle données dans l'équation 3.

2.   Retransmettre le segment perdu et régler cwnd à ssthresh plus 3*SMSS. Cela "gonfle" artificiellement la fenêtre d'encombrement du nombre de segments (trois) qui ont quitté le réseau et que le receveur a mis en mémoire tampon.

3.   Pour chaque ACK dupliqué supplémentaire reçu, incrémenter cwnd de SMSS. Cela gonfle artificiellement la fenêtre d'encombrement afin de refléter le segment supplémentaire qui a quitté le réseau.

4.   Transmettre un segment, si c'est permis par la nouvelle valeur de cwnd et la fenêtre annoncée du receveur.

5.   Lorsque arrive le nouvel ACK qui accuse réception de nouvelles données, régler cwnd à ssthresh (la valeur établie à l'étape 1). C'est ce qu'on appelle "dégonfler" la fenêtre.

Cet ACK devrait être l'accusé de réception obtenu de la retransmission de l'étape 1, un RTT après la retransmission (bien qu'il puisse arriver plus tôt en présence de livraison de segments de données significativement décalés chez le receveur). De plus, cet ACK devrait accuser réception de tous les segments intermédiaires envoyés entre le segment perdu et la réception du troisième ACK dupliqué, si l'un d'entre eux a été perdu.

Note : Il est connu que cet algorithme ne récupère généralement pas très efficacement de pertes multiples dans une même salve de paquets [FF96]. Des propositions de modification pour régler ce problème se trouvent dans la [RFC2582].

4.   Considérations supplémentaires

4.1   Redémarrage des connexions inactives

Un problème connu avec les algorithmes TCP de contrôle d'encombrement décrits ci-dessus est qu'ils permettent l'émission potentiellement inappropriée de salves de trafic après qu'une connexion TCP a été inactive pendant une période relativement longue. Après une période d'inactivité, TCP ne peut pas utiliser l'horloge des ACK pour injecter de nouveaux segments dans le réseau, car tous les ACK ont quitté le réseau. Donc, comme précisé plus haut, TCP peut envoyer une salve d'un taux de ligne d'une taille de cwnd dans le réseau après une période d'inactivité.

[Jac88] recommande qu'une connexion TCP utilise le démarrage lent pour redémarrer la transmission après une période d'inactivité relativement longue. Le démarrage lent sert à redémarrer l'horloge des ACK, tout comme il le fait au début d'un transfert. Ce mécanisme a été largement déployé de la manière suivante. Lorsque TCP n'a pas reçu de segment pendant plus d'une temporisation de retransmission, cwnd est réduit à la valeur de la fenêtre de redémarrage (RW) avant le début de la transmission.

Pour les besoins de la présente norme, on définit RW = IW.

On note que l'extension expérimentale non standard à TCP définie dans la [RFC2414] définit RW = min(IW, cwnd), avec la définition de IW ajustée selon l'équation (1) ci-dessus.

L'utilisation de la dernière réception d'un segment pour détermine s'il faut ou non diminuer cwnd ne permet pas de dégonfler cwnd dans le cas courant de connexions HTTP persistantes [HTH98]. Dans ce cas, un serveur de la Toile reçoit une demande avant de transmettre les données au navigateur de la Toile. La réception de la demande fait échouer l'essai pour une connexion inactive, et permet à TCP de commencer la transmission avec un cwnd d'une taille éventuellement inappropriée.

Donc, une connexion TCP DEVRAIT régler cwnd à pas plus que RW avant de commencer la transmission si elle n'a pas envoyé de données dans un intervalle excédant la temporisation de retransmission.

4.2   Génération des accusés de réception

L'algorithme de retard d'accusé de réception spécifié dans la [RFC1122] DEVRAIT être utilisé par un receveur TCP. Lorsque il est utilisé, un receveur TCP NE DOIT PAS retarder à l'excès les accusés de réception. En particulier, un ACK DEVRAIT être généré pour au moins chaque second segment complet, et DOIT être généré dans les 500 ms de l'arrivée du premier paquet non acquitté.

L'exigence que un ACK "DEVRAIT" être généré au moins tous les seconds segments complets figure dans la [RFC1122] comme DEVRAIT à un endroit et comme DOIT dans un autre. Nous la déclarons sans ambiguïté ici comme DEVRAIT. Nous soulignons aussi que c'est un DEVRAIT, ce qui signifie qu'une mise en œuvre ne devrait dévier de cette exigence qu'après un examen attentif de ses implications. Voir la discussion de "Extension de violation d'ACK" dans la [RFC2525] et les références qu'elle contient pour une discussion des problèmes de performances possibles si on génère les ACK moins fréquemment que tous les seconds segments complets.

Dans certains cas, envoyeur et receveur peuvent n'être pas d'accord sur ce qui constitue un segment complet. Une mise en œuvre est réputée se conformer à cette exigence si elle envoie au moins un accusé de réception chaque fois qu'elle reçoit 2*RMSS octets de nouvelles données de l'envoyeur, où RMSS est la taille maximum de segment spécifiée par le receveur à l'envoyeur (ou la valeur par défaut de 536 octets, selon la [RFC1122], si le receveur ne spécifie pas une option MSS durant l'établissement de la connexion). L'envoyeur peut être forcé d'utiliser une taille de segment inférieure à RMSS du fait de l'unité de transmission maximum (MTU), de l'algorithme de découverte de la MTU du chemin, ou pour d'autres facteurs. Par exemple, considérons le cas où le receveur annonce une RMSS de X octets mais où l'envoyeur finit par utiliser une taille de segment de Y octets (Y < X) du fait de la découverte de la MTU du chemin (ou de la taille de MTU de l'envoyeur). Le receveur va générer des ACK étendus si il attend que 2*X octets soient arrivés avant qu'un ACK soit envoyé. Cela va clairement prendre plus de 2 segments de taille Y octets. Donc, alors qu'il n'est pas défini d'algorithme spécifique, il est souhaitable que les receveurs essayent d'empêcher cette situation, par exemple en faisant un accusé de réception au moins tous les seconds segments, sans considération de la taille. Finalement, nous répétons qu'un ACK NE DOIT PAS être retardé pendant plus de 500 ms en attendant l'arrivée d'un second segment complet.

Les segments de données déclassés DEVRAIENT être acquittés immédiatement, afin d'accélérer la récupération de perte. Pour déclancher l'algorithme de retransmission rapide, le receveur DEVRAIT envoyer immédiatement un ACK dupliqué lorsque il reçoit un segment de données sur un trou dans l'espace de séquence. Pour donner un retour d'informations aux envoyeurs qui récupèrent de pertes, le receveur DEVRAIT envoyer immédiatement un ACK lorsque il reçoit un segment de données qui remplit tout ou partie d'un trou dans l'espace de séquence.

Un receveur TCP NE DOIT PAS générer plus d'un ACK pour chaque segment entrant, sauf pour la mise à jour de la fenêtre offerte lorsque l'application receveuse consomme les nouvelles données [page 42, RFC0793][RFC0813].

4.3   Mécanismes de récupération de perte

Un certain nombre d'algorithmes de récupération de perte qui s'ajoutent à la retransmission rapide et à la récupération rapide ont été suggérés par les chercheurs. Bien que certains de ces algorithmes soient fondés sur l'option d'accusé de réception sélectif de TCP (SACK) [RFC2018], tels que [FF96,MM96a,MM96b], d'autres n'exigent pas de SACK [Hoe96,FF96,RFC2582]. Les algorithmes sans SACK utilisent "l'accusé de réception partiel" (ACK qui couvrent les nouvelles données, mais pas toutes les données en instance lorsque la perte a été détectée) pour déclancher les retransmissions. Bien que le présent document ne normalise aucun des algorithmes spécifiques qui peuvent améliorer la retransmission rapide/récupération rapide, ces algorithmes améliorés sont implicitement admis, pour autant qu'ils suivent les principes généraux des quatre algorithmes de base décrits plus haut.

Donc, lorsque est détectée la première perte dans une fenêtre de données, ssthresh DOIT être réglé à pas plus que la valeur donnée par l'équation (3). Ensuite, jusqu'à ce que tous les segments perdus de la fenêtre de données en question soient réparés, le nombre de segments transmis dans chaque RTT DOIT n'être pas supérieur à la moitié du nombre de segments en instance lorsque la perte a été détectée. Enfin, après que toute perte de segments dans la fenêtre donnée a été retransmise avec succès, cwnd DOIT être réglé à pas plus que ssthresh et évitement d'encombrement DOIT être utilisé pour encore augmenter cwnd. Les pertes dans deux fenêtre de données successives, ou la perte d'une retransmission, devraient être prises comme deux indications d'encombrement, et donc, cwnd (et ssthresh) DOIT être baissé deux fois dans ce cas.

Les algorithmes mentionnés dans [Hoe96,FF96,MM96a,MM6b] suivent les principes des quatre algorithmes de contrôle d'encombrement mentionnés dans le présent document.

5.   Considérations pour la sécurité

Le présent document exige d'une connexion TCP qu'elle diminue son taux d'envoi en présence de fins de temporisation de retransmission et de l'arrivée d'accusés de réception dupliqués. Un attaquant peut donc dégrader les performances d'une connexion TCP soit en causant la perte de paquets de données ou de leurs accusés de réception, soit en fabricant un excès de duplications d'accusés de réception. Causer deux événements de contrôle d'encombrement dos à dos va souvent ramener ssthresh à sa valeur minimum de 2*SMSS, causant l'entrée immédiate de la connexion dans la phase d'évitement d'encombrement à fonctionnement plus lent.

L'Internet repose dans une mesure considérable sur la mise en œuvre correcte de ces algorithmes afin de préserver la stabilité du réseau et éviter un collapsus d'encombrement. Un attaquant pourrait amener les points d'extrémité TCP à répondre de façon plus agressive en face d'un encombrement en fabricant un excès d'accusés de réception dupliqués ou un excès d'accusés de réception pour les nouvelles données. On peut concevoir qu'une telle attaque puisse plonger une portion du réseau dans un collapsus d'encombrement.

6.   Changements par rapport à la RFC 2001

Le présent document a été entièrement remanié et il n'est pas possible de faire la liste des éléments de changement entre les deux documents. L'intention du présent document n'est pas de changer les recommandations données dans la RFC 2001, mais de mieux préciser les cas qui n'étaient pas exposés en détail dans la RFC2001. Précisément, le présent document suggère ce que les connexions TCP devraient faire après une période relativement longue de repos, et spécifie et précise quelques unes des questions relevant de la génération d'un ACK TCP. Enfin, la limite supérieure admissible pour la fenêtre d'encombrement initiale a aussi été relevée de un à deux segments.

Remerciements

Les quatre algorithmes décrits ici ont été développés par Van Jacobson.

Une partie du texte de ce document est tirée de "TCP/IP Illustrated, Volume 1: The Protocols" de W. Richard Stevens (Addison-Wesley, 1994) et de "TCP/IP Illustrated, Volume 2: The Implementation" de Gary R. Wright et W. Richard Stevens (Addison-Wesley, 1995). Ces matériaux sont utilisés avec la permission de Addison-Wesley.

Neal Cardwell, Sally Floyd, Craig Partridge et Joe Touch ont contribué par de nombreuses suggestions utiles.

Références

[RFC0793]   J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", (STD 7), septembre 1981.

[RFC0813]   D. Clark, "Fenêtre et stratégie d'accusé de réception dans TCP", juillet 1982.

[RFC1122]   R. Braden, "Exigences pour les hôtes Internet – couches de communication", STD 3, octobre 1989.

[RFC1191]   J. Mogul et S. Deering, "Découverte de la MTU de chemin", novembre 1990.

[RFC2001]   W. Stevens, "Algorithmes de démarrage lent, d'évitement d'encombrement, de retransmission rapide et de récupération rapide dans TCP", janvier 1997. (Obsolète, voirRFC2581) (P.S.)

[RFC2018]   M. Mathis et autres, "Options d'accusé de réception sélectif sur TCP", octobre 1996. (P.S.)

[RFC2119]   S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2414]   M. Allman, S. Floyd, C. Partridge, "Accroissement de la fenêtre initiale de TCP", septembre 1998. (Obsolète, voirRFC3390) (Expérimentale)

[RFC2525]   V. Paxson et autres, "Problèmes connus de mise en œuvre de TCP", mars 1999. (Information)

[RFC2582]   S. Floyd, T. Henderson, "Modification NewReno à l'algorithme de récupération rapide de TCP", avril 1999. (Obsolète, voirRFC3782) (Expérimentale)

[FF96]   Fall, K. and S. Floyd, "Simulation-based Comparisons of Tahoe, Reno and SACK TCP", Computer Communication Review, juillet 1996. ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.

[Flo94]   Floyd, S., "TCP and Successive Fast Retransmits", Rapport technique, octobre 1994. ftp://ftp.ee.lbl.gov/papers/fastretrans.ps.

[Hoe96]   Hoe, J., "Improving the Start-up Behavior of a Congestion Control Scheme for TCP", In ACM SIGCOMM, août 996.

[HTH98]   A. Hughes, J. Touch et J. Heidemann, "Issues in TCP Slow-Start Restart After Idle", Travail en cours.

[Jac88]   Jacobson, V., "Congestion Avoidance and Control", Computer Communication Review, vol. 18, n° 4, pp. 314-329, août 1988. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.

[Jac90]   Jacobson, V., "Modified TCP Congestion Avoidance Algorithm", liste de diffusion end2end-interest, 30 avril 1990. ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail.

[MM96a]   Mathis, M. and J. Mahdavi, "Forward Acknowledgment: Refining TCP Congestion Control", Compte-rendu du SIGCOMM'96, août 1996, Stanford, CA. Disponible à http://www.psc.edu/networking/papers/papers.html

[MM96b]   Mathis, M. and J. Mahdavi, "TCP Rate-Halving with Bounding Parameters", Rapport technique. Disponible à http://www.psc.edu/networking/papers/FACKnotes/current.

[Pax97]   Paxson, V., "End-to-End Internet Packet Dynamics", Compte-rendu du SIGCOMM '97, Cannes, France, septembre 1997.

[Ste94]   Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.

[WS95]   Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: The Implementation", Addison-Wesley, 1995.

Adresse des auteurs

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (1999). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.