1. Introduction
1. Introduction
Le protocole TCP [Postel81] a été conçu pour fonctionner de manière fiable sur presque n'importe quel support de transmission, indépendamment du taux de transmission, du délai, de la corruption, de la duplication ou de la réorganisation des segments. Les implémentations TCP de production s'adaptent actuellement à des taux de transfert allant de 100 bps à 10**7 bps et à des délais aller-retour allant de 1 ms à 100 secondes. Des travaux récents sur les performances TCP ont montré que TCP peut bien fonctionner sur une variété de chemins Internet, allant des canaux I/O de 800 Mbit/sec aux modems à composition à 300 bit/sec [Jacobson88a].
L'introduction de la fibre optique entraîne des vitesses de transmission toujours plus élevées, et les chemins les plus rapides sortent du domaine pour lequel TCP a été initialement conçu. Ce mémo définit un ensemble d'extensions modestes à TCP pour étendre le domaine de son application afin de correspondre à cette capacité réseau croissante. Il est basé sur et rend obsolètes les RFC-1072 [Jacobson88b] et RFC-1185 [Jacobson90b].
Il n'y a pas de réponse en une ligne à la question: "Quelle vitesse TCP peut-il atteindre?". Il existe deux types de problèmes distincts, les performances et la fiabilité, et chacun dépend de paramètres différents. Nous discutons de chacun à tour de rôle.
1.1 TCP Performance (Performances TCP)
Les performances TCP ne dépendent pas du taux de transfert lui-même, mais plutôt du produit du taux de transfert et du délai aller-retour. Ce "bandwidthdelay product (produit bande passantedélai)" mesure la quantité de données qui "remplirait le tuyau"; c'est l'espace tampon requis à l'émetteur et au récepteur pour obtenir un débit maximal sur la connexion TCP sur le chemin, c'est-à-dire la quantité de données non acquittées que TCP doit gérer afin de garder le pipeline plein. Les problèmes de performances TCP surviennent lorsque le bandwidth*delay product est grand. Nous désignons un chemin Internet fonctionnant dans cette région comme un "long, fat pipe (long tuyau gros)", et un réseau contenant ce chemin comme un "LFN" (prononcé "elephan(t)").
Les canaux satellite de paquets à haute capacité (par exemple, le Wideband Net de DARPA) sont des LFN. Par exemple, un canal satellite à vitesse DS1 a un bandwidth*delay product de 106 bits ou plus; cela correspond à 100 segments TCP en attente de 1200 octets chacun. Les chemins à fibre optique terrestre tomberont également dans la classe LFN; par exemple, un délai transcontinental de 30 ms à une bande passante DS3 (45Mbps) dépasse également 106 bits.
Il existe trois problèmes de performances fondamentaux avec le TCP actuel sur les chemins LFN:
(1) Window Size Limit (Limite de taille de fenêtre)
L'en-tête TCP utilise un champ de 16 bits pour signaler la taille de la fenêtre de réception à l'émetteur. Par conséquent, la plus grande fenêtre qui peut être utilisée est 2**16 = 65K octets.
Pour contourner ce problème, la section 2 de ce mémo définit une nouvelle option TCP, "Window Scale (Échelle de fenêtre)", pour permettre des fenêtres plus grandes que 2**16. Cette option définit un facteur d'échelle implicite, qui est utilisé pour multiplier la valeur de taille de fenêtre trouvée dans un en-tête TCP pour obtenir la vraie taille de fenêtre.
(2) Recovery from Losses (Récupération après pertes)
Les pertes de paquets dans un LFN peuvent avoir un effet catastrophique sur le débit. Jusqu'à récemment, les implémentations TCP fonctionnant correctement provoqueraient le drainage du pipeline de données à chaque perte de paquet, et nécessiteraient une action de démarrage lent pour récupérer. Récemment, les algorithmes Fast Retransmit et Fast Recovery [Jacobson90c] ont été introduits. Leur effet combiné est de récupérer d'une perte de paquet par fenêtre, sans drainer le pipeline. Cependant, plus d'une perte de paquet par fenêtre entraîne généralement un délai de retransmission et le drainage de pipeline et le démarrage lent qui en résultent.
L'expansion de la taille de la fenêtre pour correspondre à la capacité d'un LFN entraîne une augmentation correspondante de la probabilité que plus d'un paquet par fenêtre soit abandonné. Cela pourrait avoir un effet dévastateur sur le débit de TCP sur un LFN. De plus, si un mécanisme de contrôle de congestion basé sur une forme d'abandon aléatoire était introduit dans les passerelles, les abandons de paquets espacés aléatoirement deviendraient courants, augmentant éventuellement la probabilité d'abandonner plus d'un paquet par fenêtre.
Pour généraliser le mécanisme Fast Retransmit/Fast Recovery afin de gérer plusieurs paquets abandonnés par fenêtre, des accusés de réception sélectifs sont nécessaires. Contrairement aux accusés de réception cumulatifs normaux de TCP, les accusés de réception sélectifs donnent à l'émetteur une image complète des segments qui sont mis en file d'attente au récepteur et de ceux qui ne sont pas encore arrivés. Certaines preuves en faveur des accusés de réception sélectifs ont été publiées [NBS85], et les accusés de réception sélectifs ont été inclus dans un certain nombre de protocoles Internet expérimentaux -- VMTP [Cheriton88], NETBLT [Clark87], et RDP [Velten84], et proposés pour OSI TP4 [NBS85]. Cependant, dans le régime non-LFN, les accusés de réception sélectifs réduisent le nombre de paquets retransmis mais n'améliorent pas autrement les performances, rendant leur complexité de valeur discutable. Cependant, les accusés de réception sélectifs devraient devenir beaucoup plus importants dans le régime LFN.
RFC-1072 a défini une nouvelle option TCP "SACK" pour envoyer un accusé de réception sélectif. Cependant, il existe des problèmes techniques importants à résoudre concernant à la fois le format et la sémantique de l'option SACK. Par conséquent, SACK a été omis de ce paquet d'extensions. On espère que SACK pourra "rattraper" pendant le processus de normalisation.
(3) Round-Trip Measurement (Mesure du temps d'aller-retour)
TCP implémente la livraison de données fiable en retransmettant les segments qui ne sont pas acquittés dans un intervalle de délai de retransmission (RTO, Retransmission Timeout). La détermination dynamique précise d'un RTO approprié est essentielle aux performances TCP. Le RTO est déterminé en estimant la moyenne et la variance du temps d'aller-retour mesuré (RTT, Round-Trip Time), c'est-à-dire l'intervalle de temps entre l'envoi d'un segment et la réception d'un accusé de réception pour celui-ci [Jacobson88a].
La section 4 introduit une nouvelle option TCP, "Timestamps (Horodatages)", puis définit un mécanisme utilisant cette option qui permet de chronométrer presque chaque segment, y compris les retransmissions, à un coût de calcul négligeable. Nous utilisons le mnémonique RTTM (Round Trip Time Measurement, Mesure du temps d'aller-retour) pour ce mécanisme, afin de le distinguer des autres utilisations de l'option Timestamps.
1.2 TCP Reliability (Fiabilité TCP)
Maintenant, nous passons des performances à la fiabilité. Le taux de transfert élevé entre dans les performances TCP par le bandwidth*delay product. Cependant, un taux de transfert élevé seul peut menacer la fiabilité TCP en violant les hypothèses derrière le mécanisme TCP pour la détection de duplicata et le séquençage.
Un type d'erreur particulièrement grave peut résulter d'une réutilisation accidentelle des numéros de séquence TCP dans les segments de données. Supposons qu'un "old duplicate segment (ancien segment dupliqué)", par exemple, un segment de données dupliqué qui a été retardé dans les files d'attente Internet, soit livré au récepteur au mauvais moment, de sorte que ses numéros de séquence tombent quelque part dans la fenêtre actuelle. Il n'y aurait pas d'échec de somme de contrôle pour avertir de l'erreur, et le résultat pourrait être une corruption non détectée des données. La réception d'un ancien segment ACK dupliqué à l'émetteur pourrait être seulement légèrement moins grave: il est susceptible de bloquer la connexion de sorte qu'aucun progrès supplémentaire ne puisse être fait, forçant un RST sur la connexion.
La fiabilité TCP dépend de l'existence d'une limite sur la durée de vie d'un segment: le "Maximum Segment Lifetime (Durée de vie maximale du segment)" ou MSL. Un MSL est généralement requis par tout protocole de transport fiable, car chaque champ de numéro de séquence doit être fini, et donc tout numéro de séquence peut éventuellement être réutilisé. Dans la suite de protocoles Internet, la limite MSL est appliquée par un mécanisme de couche IP, le champ "Time-to-Live (Durée de vie)" ou TTL.
La duplication des numéros de séquence peut se produire de deux manières:
(1) Sequence number wrap-around on the current connection (Rebouclage du numéro de séquence sur la connexion actuelle)
Un numéro de séquence TCP contient 32 bits. À un taux de transfert suffisamment élevé, l'espace de séquence de 32 bits peut être "rebouclé" (cyclé) dans le temps qu'un segment est retardé dans les files d'attente.
(2) Earlier incarnation of the connection (Incarnation antérieure de la connexion)
Supposons qu'une connexion se termine, soit par une séquence de fermeture appropriée, soit en raison d'un crash d'hôte, et que la même connexion (c'est-à-dire, utilisant la même paire de sockets) soit immédiatement rouverte. Un segment retardé de la connexion terminée pourrait tomber dans la fenêtre actuelle pour la nouvelle incarnation et être accepté comme valide.
Les duplicata d'incarnations antérieures, cas (2), sont évités en appliquant le MSL fixe actuel de la spécification TCP, comme expliqué dans la section 5.3 et l'annexe B. Cependant, le cas (1), éviter la réutilisation des numéros de séquence dans la même connexion, nécessite une limite MSL qui dépend du taux de transfert, et à des taux suffisamment élevés, un nouveau mécanisme est requis.
Plus précisément, si la bande passante effective maximale à laquelle TCP est capable de transmettre sur un chemin particulier est B octets par seconde, alors la contrainte suivante doit être satisfaite pour un fonctionnement sans erreur:
2**31 / B > MSL (secs) [1]
Le tableau suivant montre la valeur pour Twrap = 2**31/B en secondes, pour certaines valeurs importantes de la bande passante B:
| Network | B*8 bits/sec | B bytes/sec | Twrap secs |
|---|---|---|---|
| ARPANET | 56kbps | 7KBps | 3*10**5 (~3.6 days) |
| DS1 | 1.5Mbps | 190KBps | 10**4 (~3 hours) |
| Ethernet | 10Mbps | 1.25MBps | 1700 (~30 mins) |
| DS3 | 45Mbps | 5.6MBps | 380 |
| FDDI | 100Mbps | 12.5MBps | 170 |
| Gigabit | 1Gbps | 125MBps | 17 |
Il est clair que le rebouclage de l'espace de séquence n'est pas un problème pour la commutation de paquets à 56kbps ou même les Ethernets à 10Mbps. D'autre part, aux vitesses DS3 et FDDI, Twrap est comparable au MSL de 2 minutes supposé par la spécification TCP [Postel81]. En se dirigeant vers les vitesses gigabit, Twrap devient trop petit pour une application fiable par le mécanisme TTL d'Internet.
Le champ de fenêtre de 16 bits de TCP limite la bande passante effective B à 2**16/RTT, où RTT est le temps d'aller-retour en secondes [McKenzie89]. Si le RTT est suffisamment grand, cela limite B à une valeur qui satisfait la contrainte [1] pour une grande valeur MSL. Par exemple, considérons un backbone transcontinental avec un RTT de 60ms (fixé par les lois de la physique). Avec le bandwidth*delay product limité à 64KB par la taille de fenêtre TCP, B est alors limité à 1.1MBps, peu importe à quel point le taux de transfert théorique du chemin est élevé. Cela correspond au cycle de l'espace de numéro de séquence dans Twrap= 2000 secs, ce qui est sûr dans l'Internet d'aujourd'hui.
Il est important de comprendre que le coupable n'est pas la fenêtre plus grande mais plutôt la bande passante élevée. Par exemple, considérons un LAN FDDI (très grand) avec un diamètre de 10km. En utilisant la vitesse de la lumière, nous pouvons calculer le RTT à travers l'anneau comme (210**4)/(310**8) = 67 microsecondes, et le delay*bandwidth product est alors de 833 octets. Une connexion TCP à travers ce LAN utilisant une fenêtre de seulement 833 octets fonctionnera à la pleine vitesse de 100mbps et peut reboucler l'espace de séquence en environ 3 minutes, très proche du MSL de TCP. Ainsi, la haute vitesse seule peut causer un problème de fiabilité avec le rebouclage du numéro de séquence, même sans fenêtres étendues.
Le protocole Delta-T de Watson [Watson81] inclut des mécanismes de couche réseau pour l'application précise d'un MSL. En revanche, le mécanisme IP pour l'application MSL est défini de manière lâche et encore plus lâchement implémenté dans Internet. Par conséquent, il est imprudent de dépendre de l'application active du MSL pour les connexions TCP, et il n'est pas réaliste d'imaginer définir des MSL plus petits que les valeurs actuelles (par exemple, 120 secondes spécifiées pour TCP).
Une solution possible au problème du cycle de l'espace de séquence serait d'augmenter la taille du champ de numéro de séquence TCP. Par exemple, le champ de numéro de séquence (et aussi le champ d'accusé de réception) pourrait être étendu à 64 bits. Cela pourrait être fait soit en changeant l'en-tête TCP, soit au moyen d'une option supplémentaire.
La section 5 présente un mécanisme différent, que nous appelons PAWS (Protect Against Wrapped Sequence numbers, Protection contre les numéros de séquence rebouclés), pour étendre la fiabilité TCP à des taux de transfert bien au-delà de la limite supérieure prévisible des bandes passantes réseau. PAWS utilise l'option TCP Timestamps définie dans la section 4 pour se protéger contre les anciens duplicata de la même connexion.
1.3 Using TCP options (Utilisation des options TCP)
Les extensions définies dans ce mémo utilisent toutes de nouvelles options TCP. Nous devons aborder deux problèmes possibles concernant l'utilisation des options TCP: (1) la compatibilité et (2) la surcharge.
Nous devons porter une attention particulière à la compatibilité, c'est-à-dire à l'interopération avec les implémentations existantes. La seule option TCP définie précédemment, MSS, ne peut apparaître que sur un segment SYN. Chaque implémentation devrait (et nous nous attendons à ce que la plupart le fassent) ignorer les options inconnues sur les segments SYN. Cependant, certaines implémentations TCP boguées pourraient planter lors de la première apparition d'une option sur un segment non-SYN. Par conséquent, pour chacune des extensions définies ci-dessous, les options TCP ne seront envoyées sur les segments non-SYN que lorsqu'un échange d'options sur les segments SYN a indiqué que les deux côtés comprennent l'extension. De plus, une option d'extension ne sera envoyée dans un segment <SYN,ACK> que si l'option correspondante a été reçue dans le segment <SYN> initial.
Une question peut être soulevée concernant la surcharge de bande passante et de traitement pour les options TCP. Ces options qui se produisent sur les segments SYN ne sont pas susceptibles de causer une préoccupation de performance. L'ouverture d'une connexion TCP nécessite l'exécution de code de cas spécial significatif, et le traitement des options est peu susceptible d'augmenter ce coût de manière significative.
D'autre part, une option Timestamps peut apparaître dans n'importe quel segment de données ou ACK, ajoutant 12 octets à l'en-tête TCP de 20 octets. Nous croyons que la bande passante économisée en réduisant les retransmissions inutiles compensera largement la bande passante d'en-tête supplémentaire.
Il existe également un problème concernant la surcharge de traitement pour l'analyse du format aligné sur octet variable des options, en particulier avec un CPU d'architecture RISC. Pour répondre à cette préoccupation, l'annexe A contient une disposition recommandée des options dans les en-têtes TCP pour obtenir un alignement raisonnable du champ de données. Dans l'esprit de Header Prediction, un TCP peut rapidement tester cette disposition et si elle est vérifiée, utiliser un chemin rapide. Les hôtes qui utilisent cette disposition canonique utiliseront effectivement les options comme un ensemble de champs de format fixe ajoutés à l'en-tête TCP. Cependant, pour conserver le cadre philosophique et protocolaire des options TCP, un TCP doit être préparé à analyser un champ d'options arbitraire, bien qu'avec moins d'efficacité.
Enfin, nous observons que la plupart des mécanismes définis dans ce mémo sont importants pour les LFN et/ou les réseaux très haute vitesse. Pour les réseaux à faible vitesse, il pourrait s'agir d'une optimisation de performance de NE PAS utiliser ces mécanismes. Un fournisseur TCP préoccupé par les performances optimales sur les chemins à faible vitesse pourrait envisager de désactiver ces extensions pour les chemins à faible vitesse, ou permettre à un utilisateur ou à un gestionnaire d'installation de les désactiver.