4. PAWS -- Protect Against Wrapped Sequence Numbers (PAWS -- Protezione contro l'avvolgimento dei numeri di sequenza)

4. PAWS: Protect Against Wrapped Sequence Numbers (PAWS: Protezione contro l'avvolgimento dei numeri di sequenza)

4.1 Introduction (Introduzione)

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 sezione 4.2 descrive un semplice meccanismo per rifiutare vecchi segmenti duplicati che potrebbero corrompere una connessione TCP aperta; chiamiamo questo meccanismo PAWS (Protect Against Wrapped Sequence numbers, protezione contro l'avvolgimento dei numeri di sequenza). PAWS opera all'interno di una singola connessione TCP, utilizzando lo stato salvato nel blocco di controllo della connessione. La sezione 4.3 e l'Appendice C discutono le implicazioni del meccanismo PAWS per evitare vecchi duplicati da incarnazioni precedenti della stessa connessione.

4.2 The PAWS Mechanism (Il meccanismo 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 utilizza la stessa opzione TCP Timestamps del meccanismo RTTM descritto in precedenza, e presume che ogni segmento TCP ricevuto (inclusi i segmenti di dati e ACK) contenga un timestamp SEG.TSval i cui valori sono monotonicamente non decrescenti nel tempo. L'idea di base è che un segmento può essere scartato come vecchio duplicato se viene ricevuto con un timestamp SEG.TSval inferiore a un certo timestamp ricevuto di recente su questa connessione.

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.

Sia nel meccanismo PAWS che in quello RTTM, i "timestamp" sono interi senza segno a 32 bit in uno spazio modulare a 32 bit. Pertanto, "minore di (less than)" è definito allo stesso modo dei numeri di sequenza TCP, e si applicano le stesse tecniche di implementazione. Se s e t sono valori timestamp, s < t se 0 < (t - s) < 2**31, calcolato in aritmetica a 32 bit senza segno.

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.

La scelta dei timestamp in arrivo da salvare per questo confronto deve garantire un valore monotonicamente crescente. Ad esempio, potremmo salvare il timestamp dal segmento che ha fatto avanzare per ultimo il bordo sinistro della finestra di ricezione, cioè il segmento in sequenza più recente. Invece, scegliamo il valore TS.Recent introdotto nella Sezione 3.4 per il meccanismo RTTM, poiché l'utilizzo di un valore comune sia per PAWS che per RTTM semplifica l'implementazione di entrambi. Come spiegato nella Sezione 3.4, TS.Recent differisce dal timestamp dell'ultimo segmento in sequenza solo nel caso di ACK ritardati, e quindi di meno di una finestra. Entrambe le scelte proteggeranno quindi contro l'avvolgimento del numero di sequenza.

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 è stato specificato in modo simmetrico, in modo che i timestamp TSval siano trasportati sia nei segmenti di dati che in quelli ACK e siano riflessi nei campi TSecr trasportati nei segmenti ACK o dati di ritorno. PAWS sottopone tutti i segmenti in arrivo allo stesso test, e quindi protegge contro i segmenti ACK duplicati così come i segmenti di dati. (Un algoritmo asimmetrico alternativo proteggerebbe contro vecchi ACK duplicati: il mittente di dati rifiuterebbe i segmenti ACK in arrivo i cui valori TSecr erano inferiori al TSecr salvato dall'ultimo segmento il cui campo ACK ha fatto avanzare il bordo sinistro della finestra di invio. Questo algoritmo è stato ritenuto carente in economia di meccanismo e simmetria.)

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.

I timestamp TSval inviati sui segmenti {SYN} e {SYN,ACK} vengono utilizzati per inizializzare PAWS. PAWS protegge contro vecchi segmenti non-SYN duplicati e segmenti SYN duplicati ricevuti mentre esiste una connessione sincronizzata. I segmenti {SYN} e {SYN,ACK} duplicati ricevuti quando non c'è connessione verranno scartati dal normale handshake a 3 vie e dai controlli del numero di sequenza di 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.

Si raccomanda che i segmenti RST NON trasportino timestamp e che i segmenti RST siano accettabili indipendentemente dal loro timestamp. I vecchi segmenti RST duplicati dovrebbero essere estremamente improbabili, e la loro funzione di pulizia dovrebbe avere la precedenza sui timestamp.

4.2.1 Basic PAWS Algorithm (Algoritmo PAWS di base)

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

L'algoritmo PAWS richiede che la seguente elaborazione venga eseguita su tutti i segmenti in arrivo per una connessione sincronizzata:

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:

Se c'è un'opzione Timestamps nel segmento in arrivo e SEG.TSval < TS.Recent e se TS.Recent è valido (vedi discussione successiva), allora tratta il segmento in arrivo come non accettabile:

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

Invia un acknowledgment in risposta come specificato in RFC-793 pagina 69 e scarta il segmento.

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.

Nota: è necessario inviare un segmento ACK per mantenere i meccanismi di TCP per rilevare e recuperare da connessioni semi-aperte. Ad esempio, vedi Figura 10 di RFC-793.

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

Se il segmento è fuori dalla finestra, rifiutalo (elaborazione TCP normale)

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

Se un segmento in arrivo soddisfa: SEG.SEQ <= Last.ACK.sent (vedi Sezione 3.4), allora registra il suo timestamp in TS.Recent.

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

Se un segmento in arrivo è in sequenza (cioè, al bordo sinistro della finestra), allora accettalo normalmente.

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).

Altrimenti, tratta il segmento come un normale segmento TCP nella finestra, fuori sequenza (ad es., mettilo in coda per la consegna successiva all'utente).

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

I passaggi R2, R4 e R5 sono i normali passaggi di elaborazione TCP specificati da 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.

È importante notare che il timestamp viene controllato solo quando un segmento arriva per la prima volta al ricevitore, indipendentemente dal fatto che sia in sequenza o debba essere messo in coda per la consegna successiva. Considera il seguente esempio.

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.

Supponiamo che la sequenza di segmenti: A.1, B.1, C.1, ..., Z.1 sia stata inviata, dove la lettera indica il numero di sequenza e la cifra rappresenta il timestamp. Supponiamo anche che il segmento B.1 sia stato perso. Il timestamp in TS.TStamp è 1 (da A.1), quindi C.1, ..., Z.1 sono considerati accettabili e messi in coda. Quando B viene ritrasmesso come segmento B.2 (usando l'ultimo timestamp), riempie il buco e fa sì che tutti i segmenti fino a Z vengano confermati e passati all'utente. I timestamp dei segmenti in coda non vengono ispezionati di nuovo in questo momento, poiché sono già stati accettati. Quando B.2 viene accettato, TS.Stamp viene impostato su 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.

Questa regola consente prestazioni ragionevoli in caso di perdita. Una finestra completa di dati è in transito in ogni momento, e dopo una perdita una finestra completa meno un pacchetto apparirà fuori sequenza per essere messa in coda al ricevitore (ad es., fino a ~2**30 byte di dati); l'opzione timestamp non deve comportare lo scarto di questi dati.

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

In certe circostanze improbabili, l'algoritmo delle regole R1-R4 potrebbe portare a scartare alcuni segmenti inutilmente, come mostrato nel seguente esempio:

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.

Supponiamo di nuovo che i segmenti: A.1, B.1, C.1, ..., Z.1 siano stati inviati in sequenza e che il segmento B.1 sia stato perso. Inoltre, supponiamo che la consegna di alcuni dei C.1, ... Z.1 sia ritardata fino a DOPO che la ritrasmissione B.2 arrivi al ricevitore. Questi segmenti ritardati verranno scartati inutilmente quando arrivano, poiché i loro timestamp sono ora obsoleti.

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.

Questo caso è molto improbabile che si verifichi. Se la ritrasmissione è stata attivata da un timeout, alcuni dei segmenti C.1, ... Z.1 devono essere stati ritardati più a lungo del tempo RTO. Questo è presumibilmente un evento improbabile, altrimenti ci sarebbero molti timeout e ritrasmissioni spurie. Se la ritrasmissione di B è stata attivata dall'algoritmo di "ritrasmissione rapida (fast retransmit)", cioè da ACK duplicati, allora i segmenti in coda che hanno causato questi ACK devono essere già stati ricevuti.

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.

Anche se un segmento fosse ritardato oltre l'RTO, il meccanismo di ritrasmissione rapida [Jacobson90c] causerà la ritrasmissione dei pacchetti ritardati contemporaneamente a B.2, evitando un RTT extra e quindi causando una penalità di prestazioni molto piccola.

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

Non conosciamo alcun caso con una probabilità significativa di verificarsi in cui i timestamp causeranno un degrado delle prestazioni scartando inutilmente i segmenti.

4.2.2 Timestamp Clock (Clock timestamp)

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.

È importante capire che l'algoritmo PAWS non richiede la sincronizzazione del clock tra mittente e ricevitore. Il clock timestamp del mittente viene utilizzato per timbrare i segmenti, e il mittente utilizza il timestamp riflesso per misurare gli RTT. Tuttavia, il ricevitore tratta il timestamp semplicemente come un numero seriale monotonicamente crescente, senza alcuna connessione necessaria al suo clock. Dal punto di vista del ricevitore, il timestamp agisce come un'estensione logica dei bit di ordine superiore del numero di sequenza.

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

L'algoritmo del ricevitore pone alcuni requisiti sulla frequenza del clock timestamp.

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

Il clock timestamp non deve essere "troppo lento".

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.

Deve fare tick almeno una volta per ogni 231 byte inviati. Infatti, per essere utile al mittente per la temporizzazione del round trip, il clock dovrebbe fare tick almeno una volta per finestra di dati, e anche con l'estensione di finestra RFC-1072, 231 byte devono essere almeno due finestre.

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!

Per rendere questo più quantitativo, qualsiasi clock più veloce di 1 tick/sec rifiuterà vecchi segmenti duplicati per velocità di collegamento di ~8 Gbps. Un clock timestamp di 1ms funzionerà a velocità di collegamento fino a 8 Tbps (8*10**12) bps!

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

Il clock timestamp non deve essere "troppo veloce".

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.

Il suo tempo di riciclo deve essere maggiore di MSL secondi. Poiché il clock (timestamp) è di 32 bit e l'MSL nel caso peggiore è di 255 secondi, la frequenza massima accettabile del clock è un tick ogni 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.

Tuttavia, è desiderabile stabilire un periodo di riciclo molto più lungo, per gestire timestamp obsoleti su connessioni inattive (vedi Sezione 4.2.3), e per rilassare il requisito MSL per prevenire l'avvolgimento del numero di sequenza. Con un clock timestamp di 1 ms, il timestamp a 32 bit avvolgerà il suo bit di segno in 24,8 giorni. Quindi, rifiuterà vecchi duplicati sulla stessa connessione se MSL è di 24,8 giorni o meno. Questa sembra essere una cifra molto sicura; un MSL di 24,8 giorni o più può probabilmente essere assunto dal sistema gateway senza richiedere un'applicazione precisa dell'MSL da parte del valore TTL nel livello 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.

Sulla base di queste considerazioni, scegliamo una frequenza del clock timestamp nell'intervallo da 1 ms a 1 sec per tick. Questo intervallo corrisponde anche ai requisiti del meccanismo RTTM, che non necessita di molta più risoluzione della granularità del timer di ritrasmissione, ad es., decine o centinaia di millisecondi.

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.

Il meccanismo PAWS pone anche un forte requisito di monotonicità sul clock timestamp del mittente. Il metodo di implementazione del clock timestamp per soddisfare questo requisito dipende dall'hardware e dal software del sistema.

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

  Alcuni host hanno un clock hardware che è garantito essere monotonico tra i reset hardware.

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

  Un'interruzione di clock può essere utilizzata per semplicemente incrementare un intero binario di 1 periodicamente.

• 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).

  Il clock timestamp può essere derivato da un clock di sistema che è soggetto a cambiamenti bruschi, aggiungendo un valore di offset variabile. Questo offset viene inizializzato a zero. Quando è necessario un nuovo valore del clock timestamp, l'offset può essere regolato secondo necessità per rendere il nuovo valore uguale o maggiore del valore precedente (che è stato salvato per questo scopo).

4.2.3 Outdated Timestamps (Timestamp obsoleti)

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).

Se una connessione rimane inattiva abbastanza a lungo perché il clock timestamp dell'altro TCP avvolga il suo bit di segno, allora il valore salvato in TS.Recent diventerà troppo vecchio; di conseguenza, il meccanismo PAWS farà sì che tutti i segmenti successivi vengano rifiutati, congelando la connessione (fino a quando il clock timestamp non avvolge di nuovo il suo bit di segno).

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.

Con l'intervallo scelto di frequenze del clock timestamp (da 1 sec a 1 ms), il tempo per avvolgere il bit di segno sarà tra 24,8 giorni e 24800 giorni. Una connessione TCP che è inattiva per più di 24 giorni e poi torna in vita è estremamente insolita. Tuttavia, è indesiderabile in linea di principio porre qualsiasi limitazione sulla durata delle connessioni 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.)

Pertanto richiediamo che un'implementazione di PAWS includa un meccanismo per "invalidare" il valore TS.Recent quando una connessione è inattiva per più di 24 giorni. (Una soluzione alternativa al problema dei timestamp obsoleti sarebbe inviare segmenti keepalive a una velocità molto bassa, ma comunque più spesso del tempo di avvolgimento per i timestamp, ad es., una volta al giorno. Questo imporrebbe un overhead trascurabile. Tuttavia, la specifica TCP non ha mai incluso i keepalive, quindi è stata scelta la soluzione basata sull'invalidazione.)

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.

Si noti che un TCP non conosce la frequenza, e quindi, il tempo di avvolgimento, dell'altro TCP, quindi deve assumere il peggio. La validità di TS.Recent deve essere controllata solo se il controllo del timestamp PAWS di base fallisce, cioè solo se SEG.TSval < TS.Recent. Se TS.Recent risulta non valido, allora il segmento viene accettato, indipendentemente dal fallimento del controllo del timestamp, e la regola R3 aggiorna TS.Recent con il TSval dal nuovo segmento.

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.

Per rilevare quanto tempo la connessione è stata inattiva, il TCP può aggiornare un clock o un valore timestamp associato alla connessione ogni volta che TS.Recent viene aggiornato, ad esempio. I dettagli dipenderanno dall'implementazione.

4.2.4 Header Prediction (Predizione dell'intestazione)

"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 "predizione dell'intestazione (Header prediction)" [Jacobson90a] è una tecnica di implementazione del protocollo di trasporto ad alte prestazioni che è più importante per i collegamenti ad alta velocità. Questa tecnica ottimizza il codice per il caso più comune, ricevere un segmento correttamente e in ordine. Usando la predizione dell'intestazione, il ricevitore pone la domanda: "Questo segmento è il prossimo in sequenza?" A questa domanda si può rispondere con meno istruzioni macchina rispetto alla domanda "Questo segmento è all'interno della finestra?"

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

L'aggiunta della predizione dell'intestazione alla nostra procedura di timestamp porta alla seguente sequenza raccomandata per l'elaborazione di un segmento TCP in arrivo:

H1) Check timestamp (same as step R1 above)

Controlla timestamp (uguale al passaggio R1 sopra)

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.

Esegui predizione dell'intestazione: se il segmento è il prossimo in sequenza e se non ci sono condizioni speciali che richiedono elaborazione aggiuntiva, accetta il segmento, registra il suo timestamp e salta 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.

Elabora il segmento normalmente, come specificato in RFC-793. Questo include lo scarto dei segmenti che sono fuori dalla finestra e possibilmente l'invio di acknowledgment, e la messa in coda di segmenti nella finestra, fuori sequenza.

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.

Un'altra possibilità sarebbe scambiare i passaggi H1 e H2, cioè eseguire il passaggio di predizione dell'intestazione H2 PER PRIMO, ed eseguire H1 e H3 solo quando la predizione dell'intestazione fallisce. Questo potrebbe essere un miglioramento delle prestazioni, poiché il controllo del timestamp nel passaggio H1 è molto improbabile che fallisca, e richiede aritmetica di intervallo su un campo finito, un'operazione relativamente costosa. Eseguire questo controllo su ogni singolo segmento è contrario alla filosofia della predizione dell'intestazione. Crediamo che questo cambiamento potrebbe ridurre il tempo CPU per l'elaborazione del protocollo TCP fino al 5-10% su reti ad alta velocità.

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.

Tuttavia, mettere H2 per primo creerebbe un pericolo: un segmento da 2**32 byte nel passato potrebbe arrivare esattamente nel momento sbagliato ed essere accettato erroneamente dal passaggio di predizione dell'intestazione. Il seguente ragionamento è stato introdotto [Jacobson90b] per mostrare che la probabilità di questo fallimento è trascurabile.

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.

Se tutti i segmenti hanno la stessa probabilità di apparire come vecchi duplicati, allora la probabilità che un vecchio duplicato corrisponda esattamente al bordo sinistro della finestra è la dimensione massima del segmento (MSS) divisa per la dimensione dello spazio di sequenza. Questo rapporto deve essere inferiore a 2**-16, poiché MSS deve essere < 216; ad esempio, sarà (212)/(232) = 2-20 per un collegamento FDDI. Tuttavia, più un segmento è vecchio, meno è probabile che venga mantenuto in Internet, e sotto qualsiasi modello ragionevole di durata del segmento la probabilità di un vecchio duplicato esattamente al bordo sinistro della finestra deve essere molto inferiore a 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.

Il checksum TCP a 16 bit consente anche un'inaffidabilità di base di una parte su 2**16. Un meccanismo di protocollo la cui affidabilità supera l'affidabilità del checksum TCP dovrebbe essere considerato "abbastanza buono", cioè non contribuirà in modo significativo al tasso di errore complessivo. Pertanto riteniamo di poter ignorare il problema di un vecchio duplicato accettato facendo la predizione dell'intestazione prima di controllare il timestamp.

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.

Tuttavia, questo argomento probabilistico non è universalmente accettato, e il consenso attuale è che il guadagno di prestazioni non giustifica il pericolo nel caso generale. Pertanto si raccomanda che H2 segua H1.

4.3 Duplicates from Earlier Incarnations of Connection (Duplicati da incarnazioni precedenti della connessione)

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.

Il meccanismo PAWS protegge dagli errori dovuti all'avvolgimento del numero di sequenza su connessioni ad alta velocità. I segmenti da un'incarnazione precedente della stessa connessione sono anche una causa potenziale di errori di vecchi duplicati. In entrambi i casi, i meccanismi TCP per prevenire tali errori dipendono dall'applicazione di una durata massima del segmento (MSL) da parte del livello Internet (IP) (vedi Appendice di RFC-1185 per una discussione dettagliata). A differenza del caso di avvolgimento dello spazio di sequenza, l'MSL richiesto per prevenire errori di vecchi duplicati da incarnazioni precedenti non dipende dalla velocità di trasferimento. Se il livello IP applica l'MSL raccomandato di 2 minuti di TCP, e se vengono seguite le regole TCP, le connessioni TCP saranno al sicuro da incarnazioni precedenti, indipendentemente da quanto alta sia la velocità della rete. Pertanto, il meccanismo PAWS non è richiesto per questo caso.

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.

Possiamo ancora chiedere se il meccanismo PAWS possa fornire sicurezza aggiuntiva contro vecchi duplicati da connessioni precedenti, permettendoci di rilassare l'applicazione dell'MSL da parte del livello IP. L'Appendice B esplora questa domanda, mostrando che sono richieste ulteriori assunzioni e/o meccanismi, oltre a quelli di PAWS. Questo non fa parte dell'estensione attuale.