4. PAWS -- Protect Against Wrapped Sequence Numbers (PAWS -- Protection contre le bouclage des numéros de séquence)

4. PAWS: Protect Against Wrapped Sequence Numbers (PAWS: Protection contre le bouclage des numéros de séquence)

4.1 Introduction

Section 4.2 describes a simple mechanism to reject old duplicate segments that might corrupt an open TCP connection; we call this mechanism PAWS (Protect Against Wrapped Sequence numbers). PAWS operates within a single TCP connection, using state that is saved in the connection control block. Section 4.3 and Appendix C discuss the implications of the PAWS mechanism for avoiding old duplicates from previous incarnations of the same connection.

La section 4.2 décrit un mécanisme simple pour rejeter les anciens segments dupliqués qui pourraient corrompre une connexion TCP ouverte; nous appelons ce mécanisme PAWS (Protect Against Wrapped Sequence numbers, protection contre le bouclage des numéros de séquence). PAWS fonctionne au sein d'une seule connexion TCP, en utilisant un état qui est enregistré dans le bloc de contrôle de connexion. La section 4.3 et l'Annexe C discutent des implications du mécanisme PAWS pour éviter les anciens duplicata des incarnations précédentes de la même connexion.

4.2 The PAWS Mechanism (Le mécanisme PAWS)

PAWS uses the same TCP Timestamps option as the RTTM mechanism described earlier, and assumes that every received TCP segment (including data and ACK segments) contains a timestamp SEG.TSval whose values are monotone non-decreasing in time. The basic idea is that a segment can be discarded as an old duplicate if it is received with a timestamp SEG.TSval less than some timestamp recently received on this connection.

PAWS utilise la même option TCP Timestamps que le mécanisme RTTM décrit précédemment, et suppose que chaque segment TCP reçu (y compris les segments de données et ACK) contient un horodatage SEG.TSval dont les valeurs sont monotones non décroissantes dans le temps. L'idée de base est qu'un segment peut être rejeté comme un ancien duplicata s'il est reçu avec un horodatage SEG.TSval inférieur à un certain horodatage récemment reçu sur cette connexion.

In both the PAWS and the RTTM mechanism, the "timestamps" are 32-bit unsigned integers in a modular 32-bit space. Thus, "less than" is defined the same way it is for TCP sequence numbers, and the same implementation techniques apply. If s and t are timestamp values, s < t if 0 < (t - s) < 2**31, computed in unsigned 32-bit arithmetic.

Dans les mécanismes PAWS et RTTM, les "horodatages (timestamps)" sont des entiers non signés de 32 bits dans un espace modulaire de 32 bits. Ainsi, "inférieur à (less than)" est défini de la même manière que pour les numéros de séquence TCP, et les mêmes techniques d'implémentation s'appliquent. Si s et t sont des valeurs d'horodatage, s < t si 0 < (t - s) < 2**31, calculé en arithmétique non signée de 32 bits.

The choice of incoming timestamps to be saved for this comparison must guarantee a value that is monotone increasing. For example, we might save the timestamp from the segment that last advanced the left edge of the receive window, i.e., the most recent in-sequence segment. Instead, we choose the value TS.Recent introduced in Section 3.4 for the RTTM mechanism, since using a common value for both PAWS and RTTM simplifies the implementation of both. As Section 3.4 explained, TS.Recent differs from the timestamp from the last in-sequence segment only in the case of delayed ACKs, and therefore by less than one window. Either choice will therefore protect against sequence number wrap-around.

Le choix des horodatages entrants à enregistrer pour cette comparaison doit garantir une valeur qui est monotone croissante. Par exemple, nous pourrions enregistrer l'horodatage du segment qui a avancé en dernier le bord gauche de la fenêtre de réception, c'est-à-dire le segment en séquence le plus récent. Au lieu de cela, nous choisissons la valeur TS.Recent introduite dans la Section 3.4 pour le mécanisme RTTM, car l'utilisation d'une valeur commune pour PAWS et RTTM simplifie l'implémentation des deux. Comme la Section 3.4 l'a expliqué, TS.Recent diffère de l'horodatage du dernier segment en séquence uniquement dans le cas des ACKs différés, et donc de moins d'une fenêtre. L'un ou l'autre choix protégera donc contre le bouclage des numéros de séquence.

RTTM was specified in a symmetrical manner, so that TSval timestamps are carried in both data and ACK segments and are echoed in TSecr fields carried in returning ACK or data segments. PAWS submits all incoming segments to the same test, and therefore protects against duplicate ACK segments as well as data segments. (An alternative un-symmetric algorithm would protect against old duplicate ACKs: the sender of data would reject incoming ACK segments whose TSecr values were less than the TSecr saved from the last segment whose ACK field advanced the left edge of the send window. This algorithm was deemed to lack economy of mechanism and symmetry.)

RTTM a été spécifié de manière symétrique, de sorte que les horodatages TSval sont transportés dans les segments de données et ACK et sont reflétés dans les champs TSecr transportés dans les segments ACK ou de données de retour. PAWS soumet tous les segments entrants au même test, et protège donc contre les segments ACK dupliqués ainsi que les segments de données. (Un algorithme asymétrique alternatif protégerait contre les anciens ACKs dupliqués: l'émetteur de données rejetterait les segments ACK entrants dont les valeurs TSecr étaient inférieures au TSecr enregistré du dernier segment dont le champ ACK a avancé le bord gauche de la fenêtre d'envoi. Cet algorithme a été jugé manquer d'économie de mécanisme et de symétrie.)

TSval timestamps sent on {SYN} and {SYN,ACK} segments are used to initialize PAWS. PAWS protects against old duplicate non-SYN segments, and duplicate SYN segments received while there is a synchronized connection. Duplicate {SYN} and {SYN,ACK} segments received when there is no connection will be discarded by the normal 3-way handshake and sequence number checks of TCP.

Les horodatages TSval envoyés sur les segments {SYN} et {SYN,ACK} sont utilisés pour initialiser PAWS. PAWS protège contre les anciens segments non-SYN dupliqués, et les segments SYN dupliqués reçus alors qu'il existe une connexion synchronisée. Les segments {SYN} et {SYN,ACK} dupliqués reçus lorsqu'il n'y a pas de connexion seront rejetés par la poignée de main à 3 voies normale et les vérifications de numéro de séquence de TCP.

It is recommended that RST segments NOT carry timestamps, and that RST segments be acceptable regardless of their timestamp. Old duplicate RST segments should be exceedingly unlikely, and their cleanup function should take precedence over timestamps.

Il est recommandé que les segments RST ne transportent PAS d'horodatages, et que les segments RST soient acceptables quel que soit leur horodatage. Les anciens segments RST dupliqués devraient être extrêmement improbables, et leur fonction de nettoyage devrait avoir la priorité sur les horodatages.

4.2.1 Basic PAWS Algorithm (Algorithme PAWS de base)

The PAWS algorithm requires the following processing to be performed on all incoming segments for a synchronized connection:

L'algorithme PAWS nécessite que le traitement suivant soit effectué sur tous les segments entrants pour une connexion synchronisée:

R1) If there is a Timestamps option in the arriving segment and SEG.TSval < TS.Recent and if TS.Recent is valid (see later discussion), then treat the arriving segment as not acceptable:

S'il existe une option Timestamps dans le segment arrivant et SEG.TSval < TS.Recent et si TS.Recent est valide (voir la discussion ultérieure), alors traiter le segment arrivant comme non acceptable:

Send an acknowledgement in reply as specified in RFC-793 page 69 and drop the segment.

Envoyer un accusé de réception en réponse comme spécifié dans RFC-793 page 69 et rejeter le segment.

Note: it is necessary to send an ACK segment in order to retain TCP's mechanisms for detecting and recovering from half-open connections. For example, see Figure 10 of RFC-793.

Note: il est nécessaire d'envoyer un segment ACK afin de conserver les mécanismes de TCP pour détecter et récupérer des connexions semi-ouvertes. Par exemple, voir la Figure 10 de RFC-793.

R2) If the segment is outside the window, reject it (normal TCP processing)

Si le segment est en dehors de la fenêtre, le rejeter (traitement TCP normal)

R3) If an arriving segment satisfies: SEG.SEQ <= Last.ACK.sent (see Section 3.4), then record its timestamp in TS.Recent.

Si un segment arrivant satisfait: SEG.SEQ <= Last.ACK.sent (voir Section 3.4), alors enregistrer son horodatage dans TS.Recent.

R4) If an arriving segment is in-sequence (i.e., at the left window edge), then accept it normally.

Si un segment arrivant est en séquence (c'est-à-dire, au bord gauche de la fenêtre), alors l'accepter normalement.

R5) Otherwise, treat the segment as a normal in-window, out-of-sequence TCP segment (e.g., queue it for later delivery to the user).

Sinon, traiter le segment comme un segment TCP normal dans la fenêtre, hors séquence (par exemple, le mettre en file d'attente pour une livraison ultérieure à l'utilisateur).

Steps R2, R4, and R5 are the normal TCP processing steps specified by RFC-793.

Les étapes R2, R4 et R5 sont les étapes de traitement TCP normales spécifiées par RFC-793.

It is important to note that the timestamp is checked only when a segment first arrives at the receiver, regardless of whether it is in-sequence or it must be queued for later delivery. Consider the following example.

Il est important de noter que l'horodatage n'est vérifié que lorsqu'un segment arrive pour la première fois au récepteur, qu'il soit en séquence ou qu'il doive être mis en file d'attente pour une livraison ultérieure. Considérez l'exemple suivant.

Suppose the segment sequence: A.1, B.1, C.1, ..., Z.1 has been sent, where the letter indicates the sequence number and the digit represents the timestamp. Suppose also that segment B.1 has been lost. The timestamp in TS.TStamp is 1 (from A.1), so C.1, ..., Z.1 are considered acceptable and are queued. When B is retransmitted as segment B.2 (using the latest timestamp), it fills the hole and causes all the segments through Z to be acknowledged and passed to the user. The timestamps of the queued segments are not inspected again at this time, since they have already been accepted. When B.2 is accepted, TS.Stamp is set to 2.

Supposons que la séquence de segments: A.1, B.1, C.1, ..., Z.1 ait été envoyée, où la lettre indique le numéro de séquence et le chiffre représente l'horodatage. Supposons également que le segment B.1 ait été perdu. L'horodatage dans TS.TStamp est 1 (de A.1), donc C.1, ..., Z.1 sont considérés comme acceptables et sont mis en file d'attente. Lorsque B est retransmis en tant que segment B.2 (utilisant le dernier horodatage), il comble le trou et fait en sorte que tous les segments jusqu'à Z soient accusés de réception et transmis à l'utilisateur. Les horodatages des segments en file d'attente ne sont pas inspectés à nouveau à ce moment, car ils ont déjà été acceptés. Lorsque B.2 est accepté, TS.Stamp est défini sur 2.

This rule allows reasonable performance under loss. A full window of data is in transit at all times, and after a loss a full window less one packet will show up out-of-sequence to be queued at the receiver (e.g., up to ~2**30 bytes of data); the timestamp option must not result in discarding this data.

Cette règle permet des performances raisonnables en cas de perte. Une fenêtre complète de données est en transit à tout moment, et après une perte, une fenêtre complète moins un paquet apparaîtra hors séquence pour être mise en file d'attente au récepteur (par exemple, jusqu'à ~2**30 octets de données); l'option d'horodatage ne doit pas entraîner le rejet de ces données.

In certain unlikely circumstances, the algorithm of rules R1-R4 could lead to discarding some segments unnecessarily, as shown in the following example:

Dans certaines circonstances improbables, l'algorithme des règles R1-R4 pourrait entraîner le rejet inutile de certains segments, comme le montre l'exemple suivant:

Suppose again that segments: A.1, B.1, C.1, ..., Z.1 have been sent in sequence and that segment B.1 has been lost. Furthermore, suppose delivery of some of C.1, ... Z.1 is delayed until AFTER the retransmission B.2 arrives at the receiver. These delayed segments will be discarded unnecessarily when they do arrive, since their timestamps are now out of date.

Supposons à nouveau que les segments: A.1, B.1, C.1, ..., Z.1 aient été envoyés en séquence et que le segment B.1 ait été perdu. De plus, supposons que la livraison de certains des C.1, ... Z.1 soit retardée jusqu'à APRÈS que la retransmission B.2 arrive au récepteur. Ces segments retardés seront rejetés inutilement lorsqu'ils arriveront, car leurs horodatages sont maintenant obsolètes.

This case is very unlikely to occur. If the retransmission was triggered by a timeout, some of the segments C.1, ... Z.1 must have been delayed longer than the RTO time. This is presumably an unlikely event, or there would be many spurious timeouts and retransmissions. If B's retransmission was triggered by the "fast retransmit" algorithm, i.e., by duplicate ACKs, then the queued segments that caused these ACKs must have been received already.

Ce cas est très improbable. Si la retransmission a été déclenchée par un timeout, certains des segments C.1, ... Z.1 doivent avoir été retardés plus longtemps que le temps RTO. C'est probablement un événement improbable, sinon il y aurait de nombreux timeouts parasites et retransmissions. Si la retransmission de B a été déclenchée par l'algorithme de "retransmission rapide (fast retransmit)", c'est-à-dire par des ACKs dupliqués, alors les segments en file d'attente qui ont causé ces ACKs doivent avoir déjà été reçus.

Even if a segment were delayed past the RTO, the Fast Retransmit mechanism [Jacobson90c] will cause the delayed packets to be retransmitted at the same time as B.2, avoiding an extra RTT and therefore causing a very small performance penalty.

Même si un segment était retardé au-delà du RTO, le mécanisme de retransmission rapide [Jacobson90c] provoquera la retransmission des paquets retardés en même temps que B.2, évitant un RTT supplémentaire et causant donc une très petite pénalité de performance.

We know of no case with a significant probability of occurrence in which timestamps will cause performance degradation by unnecessarily discarding segments.

Nous ne connaissons aucun cas avec une probabilité d'occurrence significative dans lequel les horodatages causeront une dégradation des performances en rejetant inutilement des segments.

4.2.2 Timestamp Clock (Horloge d'horodatage)

It is important to understand that the PAWS algorithm does not require clock synchronization between sender and receiver. The sender's timestamp clock is used to stamp the segments, and the sender uses the echoed timestamp to measure RTT's. However, the receiver treats the timestamp as simply a monotone-increasing serial number, without any necessary connection to its clock. From the receiver's viewpoint, the timestamp is acting as a logical extension of the high-order bits of the sequence number.

Il est important de comprendre que l'algorithme PAWS ne nécessite pas de synchronisation d'horloge entre l'émetteur et le récepteur. L'horloge d'horodatage de l'émetteur est utilisée pour horodater les segments, et l'émetteur utilise l'horodatage reflété pour mesurer les RTT. Cependant, le récepteur traite l'horodatage simplement comme un numéro de série monotone croissant, sans aucune connexion nécessaire à son horloge. Du point de vue du récepteur, l'horodatage agit comme une extension logique des bits de poids fort du numéro de séquence.

The receiver algorithm does place some requirements on the frequency of the timestamp clock.

L'algorithme du récepteur impose certaines exigences sur la fréquence de l'horloge d'horodatage.

(a) The timestamp clock must not be "too slow".

L'horloge d'horodatage ne doit pas être "trop lente".

It must tick at least once for each 231 bytes sent. In fact, in order to be useful to the sender for round trip timing, the clock should tick at least once per window's worth of data, and even with the RFC-1072 window extension, 231 bytes must be at least two windows.

Elle doit tic-taquer au moins une fois pour chaque 231 octets envoyés. En fait, pour être utile à l'émetteur pour le chronométrage aller-retour, l'horloge devrait tic-taquer au moins une fois par fenêtre de données, et même avec l'extension de fenêtre RFC-1072, 231 octets doivent être au moins deux fenêtres.

To make this more quantitative, any clock faster than 1 tick/sec will reject old duplicate segments for link speeds of ~8 Gbps. A 1ms timestamp clock will work at link speeds up to 8 Tbps (8*10**12) bps!

Pour rendre cela plus quantitatif, toute horloge plus rapide que 1 tic/sec rejettera les anciens segments dupliqués pour des vitesses de liaison de ~8 Gbps. Une horloge d'horodatage de 1ms fonctionnera à des vitesses de liaison allant jusqu'à 8 Tbps (8*10**12) bps!

(b) The timestamp clock must not be "too fast".

L'horloge d'horodatage ne doit pas être "trop rapide".

Its recycling time must be greater than MSL seconds. Since the clock (timestamp) is 32 bits and the worst-case MSL is 255 seconds, the maximum acceptable clock frequency is one tick every 59 ns.

Son temps de recyclage doit être supérieur à MSL secondes. Étant donné que l'horloge (horodatage) est de 32 bits et que le MSL dans le pire des cas est de 255 secondes, la fréquence d'horloge maximale acceptable est d'un tic toutes les 59 ns.

However, it is desirable to establish a much longer recycle period, in order to handle outdated timestamps on idle connections (see Section 4.2.3), and to relax the MSL requirement for preventing sequence number wrap-around. With a 1 ms timestamp clock, the 32-bit timestamp will wrap its sign bit in 24.8 days. Thus, it will reject old duplicates on the same connection if MSL is 24.8 days or less. This appears to be a very safe figure; an MSL of 24.8 days or longer can probably be assumed by the gateway system without requiring precise MSL enforcement by the TTL value in the IP layer.

Cependant, il est souhaitable d'établir une période de recyclage beaucoup plus longue, afin de gérer les horodatages obsolètes sur les connexions inactives (voir Section 4.2.3), et de relâcher l'exigence MSL pour empêcher le bouclage des numéros de séquence. Avec une horloge d'horodatage de 1 ms, l'horodatage de 32 bits bouclera son bit de signe en 24,8 jours. Ainsi, il rejettera les anciens duplicata sur la même connexion si MSL est de 24,8 jours ou moins. Cela semble être un chiffre très sûr; un MSL de 24,8 jours ou plus peut probablement être supposé par le système de passerelle sans nécessiter une application précise du MSL par la valeur TTL dans la couche IP.

Based upon these considerations, we choose a timestamp clock frequency in the range 1 ms to 1 sec per tick. This range also matches the requirements of the RTTM mechanism, which does not need much more resolution than the granularity of the retransmit timer, e.g., tens or hundreds of milliseconds.

Sur la base de ces considérations, nous choisissons une fréquence d'horloge d'horodatage dans la plage de 1 ms à 1 sec par tic. Cette plage correspond également aux exigences du mécanisme RTTM, qui n'a pas besoin de beaucoup plus de résolution que la granularité du temporisateur de retransmission, par exemple, des dizaines ou des centaines de millisecondes.

The PAWS mechanism also puts a strong monotonicity requirement on the sender's timestamp clock. The method of implementation of the timestamp clock to meet this requirement depends upon the system hardware and software.

Le mécanisme PAWS impose également une forte exigence de monotonicité sur l'horloge d'horodatage de l'émetteur. La méthode d'implémentation de l'horloge d'horodatage pour satisfaire cette exigence dépend du matériel et du logiciel du système.

• Some hosts have a hardware clock that is guaranteed to be monotonic between hardware resets.

  Certains hôtes ont une horloge matérielle qui est garantie d'être monotone entre les réinitialisations matérielles.

• A clock interrupt may be used to simply increment a binary integer by 1 periodically.

  Une interruption d'horloge peut être utilisée pour simplement incrémenter un entier binaire de 1 périodiquement.

• The timestamp clock may be derived from a system clock that is subject to being abruptly changed, by adding a variable offset value. This offset is initialized to zero. When a new timestamp clock value is needed, the offset can be adjusted as necessary to make the new value equal to or larger than the previous value (which was saved for this purpose).

  L'horloge d'horodatage peut être dérivée d'une horloge système qui est susceptible d'être modifiée brusquement, en ajoutant une valeur de décalage variable. Ce décalage est initialisé à zéro. Lorsqu'une nouvelle valeur d'horloge d'horodatage est nécessaire, le décalage peut être ajusté si nécessaire pour rendre la nouvelle valeur égale ou supérieure à la valeur précédente (qui a été enregistrée à cette fin).

4.2.3 Outdated Timestamps (Horodatages obsolètes)

If a connection remains idle long enough for the timestamp clock of the other TCP to wrap its sign bit, then the value saved in TS.Recent will become too old; as a result, the PAWS mechanism will cause all subsequent segments to be rejected, freezing the connection (until the timestamp clock wraps its sign bit again).

Si une connexion reste inactive assez longtemps pour que l'horloge d'horodatage de l'autre TCP boucle son bit de signe, alors la valeur enregistrée dans TS.Recent deviendra trop ancienne; en conséquence, le mécanisme PAWS provoquera le rejet de tous les segments ultérieurs, gelant la connexion (jusqu'à ce que l'horloge d'horodatage boucle à nouveau son bit de signe).

With the chosen range of timestamp clock frequencies (1 sec to 1 ms), the time to wrap the sign bit will be between 24.8 days and 24800 days. A TCP connection that is idle for more than 24 days and then comes to life is exceedingly unusual. However, it is undesirable in principle to place any limitation on TCP connection lifetimes.

Avec la plage choisie de fréquences d'horloge d'horodatage (1 sec à 1 ms), le temps pour boucler le bit de signe sera entre 24,8 jours et 24800 jours. Une connexion TCP qui est inactive pendant plus de 24 jours puis revient à la vie est extrêmement inhabituelle. Cependant, il est indésirable en principe de placer une quelconque limitation sur les durées de vie des connexions TCP.

We therefore require that an implementation of PAWS include a mechanism to "invalidate" the TS.Recent value when a connection is idle for more than 24 days. (An alternative solution to the problem of outdated timestamps would be to send keepalive segments at a very low rate, but still more often than the wrap-around time for timestamps, e.g., once a day. This would impose negligible overhead. However, the TCP specification has never included keepalives, so the solution based upon invalidation was chosen.)

Nous exigeons donc qu'une implémentation de PAWS inclue un mécanisme pour "invalider" la valeur TS.Recent lorsqu'une connexion est inactive pendant plus de 24 jours. (Une solution alternative au problème des horodatages obsolètes serait d'envoyer des segments de maintien en vie à un taux très faible, mais toujours plus souvent que le temps de bouclage pour les horodatages, par exemple, une fois par jour. Cela imposerait une surcharge négligeable. Cependant, la spécification TCP n'a jamais inclus les maintiens en vie, donc la solution basée sur l'invalidation a été choisie.)

Note that a TCP does not know the frequency, and therefore, the wraparound time, of the other TCP, so it must assume the worst. The validity of TS.Recent needs to be checked only if the basic PAWS timestamp check fails, i.e., only if SEG.TSval < TS.Recent. If TS.Recent is found to be invalid, then the segment is accepted, regardless of the failure of the timestamp check, and rule R3 updates TS.Recent with the TSval from the new segment.

Notez qu'un TCP ne connaît pas la fréquence, et donc, le temps de bouclage, de l'autre TCP, il doit donc supposer le pire. La validité de TS.Recent ne doit être vérifiée que si la vérification d'horodatage PAWS de base échoue, c'est-à-dire, seulement si SEG.TSval < TS.Recent. Si TS.Recent s'avère invalide, alors le segment est accepté, indépendamment de l'échec de la vérification d'horodatage, et la règle R3 met à jour TS.Recent avec le TSval du nouveau segment.

To detect how long the connection has been idle, the TCP may update a clock or timestamp value associated with the connection whenever TS.Recent is updated, for example. The details will be implementation-dependent.

Pour détecter combien de temps la connexion a été inactive, le TCP peut mettre à jour une horloge ou une valeur d'horodatage associée à la connexion chaque fois que TS.Recent est mis à jour, par exemple. Les détails seront dépendants de l'implémentation.

4.2.4 Header Prediction (Prédiction d'en-tête)

"Header prediction" [Jacobson90a] is a high-performance transport protocol implementation technique that is most important for high-speed links. This technique optimizes the code for the most common case, receiving a segment correctly and in order. Using header prediction, the receiver asks the question, "Is this segment the next in sequence?" This question can be answered in fewer machine instructions than the question, "Is this segment within the window?"

La "prédiction d'en-tête (Header prediction)" [Jacobson90a] est une technique d'implémentation de protocole de transport à haute performance qui est la plus importante pour les liaisons à haute vitesse. Cette technique optimise le code pour le cas le plus courant, recevoir un segment correctement et dans l'ordre. En utilisant la prédiction d'en-tête, le récepteur pose la question, "Ce segment est-il le suivant dans la séquence?" Cette question peut être répondue en moins d'instructions machine que la question, "Ce segment est-il dans la fenêtre?"

Adding header prediction to our timestamp procedure leads to the following recommended sequence for processing an arriving TCP segment:

L'ajout de la prédiction d'en-tête à notre procédure d'horodatage conduit à la séquence recommandée suivante pour le traitement d'un segment TCP arrivant:

H1) Check timestamp (same as step R1 above)

Vérifier l'horodatage (même que l'étape R1 ci-dessus)

H2) Do header prediction: if segment is next in sequence and if there are no special conditions requiring additional processing, accept the segment, record its timestamp, and skip H3.

Faire la prédiction d'en-tête: si le segment est le suivant dans la séquence et s'il n'y a pas de conditions spéciales nécessitant un traitement supplémentaire, accepter le segment, enregistrer son horodatage, et sauter H3.

H3) Process the segment normally, as specified in RFC-793. This includes dropping segments that are outside the window and possibly sending acknowledgments, and queueing in-window, out-of-sequence segments.

Traiter le segment normalement, comme spécifié dans RFC-793. Cela inclut le rejet des segments qui sont en dehors de la fenêtre et éventuellement l'envoi d'accusés de réception, et la mise en file d'attente des segments dans la fenêtre, hors séquence.

Another possibility would be to interchange steps H1 and H2, i.e., to perform the header prediction step H2 FIRST, and perform H1 and H3 only when header prediction fails. This could be a performance improvement, since the timestamp check in step H1 is very unlikely to fail, and it requires interval arithmetic on a finite field, a relatively expensive operation. To perform this check on every single segment is contrary to the philosophy of header prediction. We believe that this change might reduce CPU time for TCP protocol processing by up to 5-10% on high-speed networks.

Une autre possibilité serait d'échanger les étapes H1 et H2, c'est-à-dire, d'effectuer l'étape de prédiction d'en-tête H2 EN PREMIER, et d'effectuer H1 et H3 uniquement lorsque la prédiction d'en-tête échoue. Cela pourrait être une amélioration des performances, car la vérification d'horodatage à l'étape H1 est très peu susceptible d'échouer, et elle nécessite une arithmétique d'intervalle sur un champ fini, une opération relativement coûteuse. Effectuer cette vérification sur chaque segment unique est contraire à la philosophie de la prédiction d'en-tête. Nous pensons que ce changement pourrait réduire le temps CPU pour le traitement du protocole TCP jusqu'à 5-10% sur les réseaux à haute vitesse.

However, putting H2 first would create a hazard: a segment from 2**32 bytes in the past might arrive at exactly the wrong time and be accepted mistakenly by the header-prediction step. The following reasoning has been introduced [Jacobson90b] to show that the probability of this failure is negligible.

Cependant, placer H2 en premier créerait un danger: un segment de 2**32 octets dans le passé pourrait arriver exactement au mauvais moment et être accepté par erreur par l'étape de prédiction d'en-tête. Le raisonnement suivant a été introduit [Jacobson90b] pour montrer que la probabilité de cet échec est négligeable.

If all segments are equally likely to show up as old duplicates, then the probability of an old duplicate exactly matching the left window edge is the maximum segment size (MSS) divided by the size of the sequence space. This ratio must be less than 2**-16, since MSS must be < 216; for example, it will be (212)/(232) = 2-20 for an FDDI link. However, the older a segment is, the less likely it is to be retained in the Internet, and under any reasonable model of segment lifetime the probability of an old duplicate exactly at the left window edge must be much smaller than 2**-16.

Si tous les segments ont la même probabilité d'apparaître comme d'anciens duplicata, alors la probabilité qu'un ancien duplicata corresponde exactement au bord gauche de la fenêtre est la taille maximale du segment (MSS) divisée par la taille de l'espace de séquence. Ce ratio doit être inférieur à 2**-16, puisque MSS doit être < 216; par exemple, il sera (212)/(232) = 2-20 pour un lien FDDI. Cependant, plus un segment est ancien, moins il est susceptible d'être conservé dans l'Internet, et selon tout modèle raisonnable de durée de vie des segments, la probabilité d'un ancien duplicata exactement au bord gauche de la fenêtre doit être beaucoup plus petite que 2**-16.

The 16 bit TCP checksum also allows a basic unreliability of one part in 2**16. A protocol mechanism whose reliability exceeds the reliability of the TCP checksum should be considered "good enough", i.e., it won't contribute significantly to the overall error rate. We therefore believe we can ignore the problem of an old duplicate being accepted by doing header prediction before checking the timestamp.

La somme de contrôle TCP de 16 bits permet également une fiabilité de base d'une partie sur 2**16. Un mécanisme de protocole dont la fiabilité dépasse la fiabilité de la somme de contrôle TCP devrait être considéré comme "suffisamment bon", c'est-à-dire qu'il ne contribuera pas de manière significative au taux d'erreur global. Nous pensons donc que nous pouvons ignorer le problème d'un ancien duplicata accepté en faisant la prédiction d'en-tête avant de vérifier l'horodatage.

However, this probabilistic argument is not universally accepted, and the consensus at present is that the performance gain does not justify the hazard in the general case. It is therefore recommended that H2 follow H1.

Cependant, cet argument probabiliste n'est pas universellement accepté, et le consensus actuel est que le gain de performance ne justifie pas le danger dans le cas général. Il est donc recommandé que H2 suive H1.

4.3 Duplicates from Earlier Incarnations of Connection (Duplicata des incarnations antérieures de la connexion)

The PAWS mechanism protects against errors due to sequence number wrap-around on high-speed connection. Segments from an earlier incarnation of the same connection are also a potential cause of old duplicate errors. In both cases, the TCP mechanisms to prevent such errors depend upon the enforcement of a maximum segment lifetime (MSL) by the Internet (IP) layer (see Appendix of RFC-1185 for a detailed discussion). Unlike the case of sequence space wrap-around, the MSL required to prevent old duplicate errors from earlier incarnations does not depend upon the transfer rate. If the IP layer enforces the recommended 2 minute MSL of TCP, and if the TCP rules are followed, TCP connections will be safe from earlier incarnations, no matter how high the network speed. Thus, the PAWS mechanism is not required for this case.

Le mécanisme PAWS protège contre les erreurs dues au bouclage des numéros de séquence sur une connexion à haute vitesse. Les segments d'une incarnation antérieure de la même connexion sont également une cause potentielle d'erreurs de duplicata ancien. Dans les deux cas, les mécanismes TCP pour prévenir de telles erreurs dépendent de l'application d'une durée de vie maximale du segment (MSL) par la couche Internet (IP) (voir l'Annexe de RFC-1185 pour une discussion détaillée). Contrairement au cas du bouclage de l'espace de séquence, le MSL requis pour prévenir les erreurs de duplicata ancien des incarnations antérieures ne dépend pas du taux de transfert. Si la couche IP applique le MSL recommandé de 2 minutes de TCP, et si les règles TCP sont suivies, les connexions TCP seront protégées des incarnations antérieures, quelle que soit la vitesse du réseau. Ainsi, le mécanisme PAWS n'est pas requis pour ce cas.

We may still ask whether the PAWS mechanism can provide additional security against old duplicates from earlier connections, allowing us to relax the enforcement of MSL by the IP layer. Appendix B explores this question, showing that further assumptions and/or mechanisms are required, beyond those of PAWS. This is not part of the current extension.

Nous pouvons encore nous demander si le mécanisme PAWS peut fournir une sécurité supplémentaire contre les anciens duplicata des connexions antérieures, nous permettant de relâcher l'application du MSL par la couche IP. L'Annexe B explore cette question, montrant que des hypothèses et/ou des mécanismes supplémentaires sont nécessaires, au-delà de ceux de PAWS. Cela ne fait pas partie de l'extension actuelle.