1. Introduction (Introduzione)

Il protocollo TCP [Postel81] è stato progettato per operare in modo affidabile su quasi qualsiasi mezzo di trasmissione indipendentemente dalla velocità di trasmissione, dal ritardo, dalla corruzione, dalla duplicazione o dal riordino dei segmenti. Le implementazioni TCP di produzione attualmente si adattano a tassi di trasferimento nell'intervallo da 100 bps a 10**7 bps e ritardi di andata e ritorno nell'intervallo da 1 ms a 100 secondi. Lavori recenti sulle prestazioni TCP hanno dimostrato che TCP può funzionare bene su una varietà di percorsi Internet, dai canali I/O da 800 Mbit/sec ai modem dial-up da 300 bit/sec [Jacobson88a].

L'introduzione delle fibre ottiche sta portando a velocità di trasmissione sempre più elevate, e i percorsi più veloci stanno uscendo dal dominio per cui TCP è stato originariamente progettato. Questo memo definisce un insieme di modeste estensioni a TCP per estendere il dominio della sua applicazione per corrispondere a questa crescente capacità di rete. Si basa su e rende obsoleti RFC-1072 [Jacobson88b] e RFC-1185 [Jacobson90b].

Non esiste una risposta di una sola riga alla domanda: "Quanto veloce può andare TCP?". Ci sono due tipi separati di problemi, prestazioni e affidabilità, e ciascuno dipende da parametri diversi. Discutiamo ciascuno a turno.

1.1 TCP Performance (Prestazioni TCP)

Le prestazioni TCP non dipendono dal tasso di trasferimento stesso, ma piuttosto dal prodotto del tasso di trasferimento e del ritardo di andata e ritorno. Questo "bandwidthdelay product (prodotto larghezza di bandaritardo)" misura la quantità di dati che "riempirebbe il tubo"; è lo spazio buffer richiesto al mittente e al ricevitore per ottenere il massimo throughput sulla connessione TCP sul percorso, cioè la quantità di dati non riconosciuti che TCP deve gestire per mantenere la pipeline piena. I problemi di prestazioni TCP sorgono quando il bandwidth*delay product è grande. Ci riferiamo a un percorso Internet che opera in questa regione come un "long, fat pipe (tubo lungo e grasso)", e a una rete che contiene questo percorso come un "LFN" (pronunciato "elephan(t)").

I canali satellitari a pacchetti ad alta capacità (ad esempio, Wideband Net di DARPA) sono LFN. Ad esempio, un canale satellite a velocità DS1 ha un bandwidth*delay product di 106 bit o più; questo corrisponde a 100 segmenti TCP in sospeso di 1200 byte ciascuno. Anche i percorsi a fibra ottica terrestri rientreranno nella classe LFN; ad esempio, un ritardo transcontinentale di 30 ms a una larghezza di banda DS3 (45Mbps) supera anche 106 bit.

Ci sono tre problemi di prestazioni fondamentali con l'attuale TCP sui percorsi LFN:

(1) Window Size Limit (Limite di dimensione della finestra)

L'intestazione TCP utilizza un campo a 16 bit per segnalare la dimensione della finestra di ricezione al mittente. Pertanto, la finestra più grande che può essere utilizzata è 2**16 = 65K byte.

Per aggirare questo problema, la sezione 2 di questo memo definisce una nuova opzione TCP, "Window Scale (Scala della finestra)", per consentire finestre più grandi di 2**16. Questa opzione definisce un fattore di scala implicito, che viene utilizzato per moltiplicare il valore della dimensione della finestra trovato in un'intestazione TCP per ottenere la vera dimensione della finestra.

(2) Recovery from Losses (Recupero dalle perdite)

Le perdite di pacchetti in un LFN possono avere un effetto catastrofico sul throughput. Fino a poco tempo fa, le implementazioni TCP che operano correttamente causerebbero lo svuotamento della pipeline di dati con ogni perdita di pacchetto e richiederebbero un'azione di avvio lento per recuperare. Recentemente, sono stati introdotti gli algoritmi Fast Retransmit e Fast Recovery [Jacobson90c]. Il loro effetto combinato è quello di recuperare dalla perdita di un pacchetto per finestra, senza svuotare la pipeline. Tuttavia, più di una perdita di pacchetto per finestra in genere risulta in un timeout di ritrasmissione e il conseguente svuotamento della pipeline e avvio lento.

L'espansione della dimensione della finestra per corrispondere alla capacità di un LFN comporta un corrispondente aumento della probabilità che più di un pacchetto per finestra venga eliminato. Ciò potrebbe avere un effetto devastante sul throughput di TCP su un LFN. Inoltre, se un meccanismo di controllo della congestione basato su qualche forma di eliminazione casuale fosse introdotto nei gateway, le eliminazioni di pacchetti distribuite casualmente diventerebbero comuni, possibilmente aumentando la probabilità di eliminare più di un pacchetto per finestra.

Per generalizzare il meccanismo Fast Retransmit/Fast Recovery per gestire più pacchetti eliminati per finestra, sono richiesti acknowledgment selettivi. A differenza dei normali acknowledgment cumulativi di TCP, gli acknowledgment selettivi forniscono al mittente un quadro completo di quali segmenti sono in coda al ricevitore e quali non sono ancora arrivati. Alcune prove a favore degli acknowledgment selettivi sono state pubblicate [NBS85], e gli acknowledgment selettivi sono stati inclusi in un certo numero di protocolli Internet sperimentali -- VMTP [Cheriton88], NETBLT [Clark87] e RDP [Velten84], e proposti per OSI TP4 [NBS85]. Tuttavia, nel regime non-LFN, gli acknowledgment selettivi riducono il numero di pacchetti ritrasmessi ma non migliorano altrimenti le prestazioni, rendendo la loro complessità di valore discutibile. Tuttavia, gli acknowledgment selettivi dovrebbero diventare molto più importanti nel regime LFN.

RFC-1072 ha definito una nuova opzione TCP "SACK" per inviare un acknowledgment selettivo. Tuttavia, ci sono importanti questioni tecniche da risolvere riguardo sia al formato che alla semantica dell'opzione SACK. Pertanto, SACK è stato omesso da questo pacchetto di estensioni. Si spera che SACK possa "recuperare" durante il processo di standardizzazione.

(3) Round-Trip Measurement (Misurazione del tempo di andata e ritorno)

TCP implementa la consegna affidabile dei dati ritrasmettendo segmenti che non vengono riconosciuti entro un certo intervallo di timeout di ritrasmissione (RTO, Retransmission Timeout). La determinazione dinamica accurata di un RTO appropriato è essenziale per le prestazioni TCP. RTO viene determinato stimando la media e la varianza del tempo di andata e ritorno misurato (RTT, Round-Trip Time), cioè l'intervallo di tempo tra l'invio di un segmento e la ricezione di un riconoscimento per esso [Jacobson88a].

La sezione 4 introduce una nuova opzione TCP, "Timestamps (Timestamp)", e quindi definisce un meccanismo che utilizza questa opzione che consente di cronometrare quasi ogni segmento, comprese le ritrasmissioni, a costo computazionale trascurabile. Utilizziamo il mnemonico RTTM (Round Trip Time Measurement, Misurazione del tempo di andata e ritorno) per questo meccanismo, per distinguerlo da altri usi dell'opzione Timestamps.

1.2 TCP Reliability (Affidabilità TCP)

Ora passiamo dalle prestazioni all'affidabilità. L'alta velocità di trasferimento influisce sulle prestazioni TCP attraverso il bandwidth*delay product. Tuttavia, l'alta velocità di trasferimento da sola può minacciare l'affidabilità TCP violando le ipotesi alla base del meccanismo TCP per il rilevamento dei duplicati e il sequenziamento.

Un tipo di errore particolarmente grave può derivare da un riutilizzo accidentale dei numeri di sequenza TCP nei segmenti di dati. Supponiamo che un "old duplicate segment (vecchio segmento duplicato)", ad esempio, un segmento di dati duplicato che è stato ritardato nelle code Internet, venga consegnato al ricevitore al momento sbagliato, in modo che i suoi numeri di sequenza cadano da qualche parte all'interno della finestra corrente. Non ci sarebbe alcun fallimento del checksum per avvertire dell'errore, e il risultato potrebbe essere una corruzione non rilevata dei dati. La ricezione di un vecchio segmento ACK duplicato al trasmettitore potrebbe essere solo leggermente meno grave: è probabile che blocchi la connessione in modo che non possa essere fatto alcun ulteriore progresso, forzando un RST sulla connessione.

L'affidabilità TCP dipende dall'esistenza di un limite sulla durata di vita di un segmento: il "Maximum Segment Lifetime (Durata massima del segmento)" o MSL. Un MSL è generalmente richiesto da qualsiasi protocollo di trasporto affidabile, poiché ogni campo di numero di sequenza deve essere finito, e quindi qualsiasi numero di sequenza può eventualmente essere riutilizzato. Nella suite di protocolli Internet, il limite MSL è applicato da un meccanismo a livello IP, il campo "Time-to-Live (Tempo di vita)" o TTL.

La duplicazione dei numeri di sequenza potrebbe verificarsi in due modi:

(1) Sequence number wrap-around on the current connection (Avvolgimento del numero di sequenza sulla connessione corrente)

Un numero di sequenza TCP contiene 32 bit. A una velocità di trasferimento sufficientemente alta, lo spazio di sequenza a 32 bit può essere "avvolto" (ciclato) entro il tempo in cui un segmento viene ritardato nelle code.

(2) Earlier incarnation of the connection (Incarnazione precedente della connessione)

Supponiamo che una connessione termini, sia per una sequenza di chiusura appropriata o a causa di un crash dell'host, e che la stessa connessione (cioè, utilizzando la stessa coppia di socket) venga immediatamente riaperta. Un segmento ritardato dalla connessione terminata potrebbe cadere all'interno della finestra corrente per la nuova incarnazione ed essere accettato come valido.

I duplicati da incarnazioni precedenti, caso (2), vengono evitati applicando l'MSL fisso corrente della specifica TCP, come spiegato nella sezione 5.3 e nell'appendice B. Tuttavia, il caso (1), evitare il riutilizzo dei numeri di sequenza all'interno della stessa connessione, richiede un limite MSL che dipende dalla velocità di trasferimento, e a velocità sufficientemente elevate, è richiesto un nuovo meccanismo.

Più specificamente, se la larghezza di banda effettiva massima alla quale TCP è in grado di trasmettere su un particolare percorso è B byte per secondo, allora il seguente vincolo deve essere soddisfatto per un funzionamento senza errori:

2**31 / B  > MSL (secs)                     [1]

La seguente tabella mostra il valore per Twrap = 2**31/B in secondi, per alcuni valori importanti della larghezza di banda B:

Network	B*8 bits/sec	B bytes/sec	Twrap secs
ARPANET	56kbps	7KBps	310*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

È chiaro che l'avvolgimento dello spazio di sequenza non è un problema per la commutazione di pacchetti a 56kbps o anche per Ethernet a 10Mbps. D'altra parte, alle velocità DS3 e FDDI, Twrap è paragonabile all'MSL di 2 minuti assunto dalla specifica TCP [Postel81]. Muovendosi verso velocità gigabit, Twrap diventa troppo piccolo per un'applicazione affidabile da parte del meccanismo TTL di Internet.

Il campo finestra a 16 bit di TCP limita la larghezza di banda effettiva B a 2**16/RTT, dove RTT è il tempo di andata e ritorno in secondi [McKenzie89]. Se l'RTT è sufficientemente grande, questo limita B a un valore che soddisfa il vincolo [1] per un valore MSL grande. Ad esempio, consideriamo una dorsale transcontinentale con un RTT di 60ms (stabilito dalle leggi della fisica). Con il bandwidth*delay product limitato a 64KB dalla dimensione della finestra TCP, B è quindi limitato a 1.1MBps, non importa quanto sia alta la velocità di trasferimento teorica del percorso. Ciò corrisponde al ciclo dello spazio di numero di sequenza in Twrap= 2000 secondi, che è sicuro nell'Internet di oggi.

È importante capire che il colpevole non è la finestra più grande ma piuttosto l'alta larghezza di banda. Ad esempio, consideriamo una LAN FDDI (molto grande) con un diametro di 10km. Utilizzando la velocità della luce, possiamo calcolare l'RTT attraverso l'anello come (210**4)/(310**8) = 67 microsecondi, e il delay*bandwidth product è quindi di 833 byte. Una connessione TCP attraverso questa LAN utilizzando una finestra di soli 833 byte funzionerà alla piena velocità di 100mbps e può avvolgere lo spazio di sequenza in circa 3 minuti, molto vicino all'MSL di TCP. Pertanto, l'alta velocità da sola può causare un problema di affidabilità con l'avvolgimento del numero di sequenza, anche senza finestre estese.

Il protocollo Delta-T di Watson [Watson81] include meccanismi a livello di rete per l'applicazione precisa di un MSL. Al contrario, il meccanismo IP per l'applicazione MSL è definito in modo vago e implementato ancora più vagamente in Internet. Pertanto, è imprudente dipendere dall'applicazione attiva di MSL per le connessioni TCP, ed è irrealistico immaginare di impostare MSL più piccoli dei valori attuali (ad esempio, 120 secondi specificati per TCP).

Una possibile soluzione al problema del ciclo dello spazio di sequenza sarebbe quella di aumentare la dimensione del campo del numero di sequenza TCP. Ad esempio, il campo del numero di sequenza (e anche il campo di riconoscimento) potrebbe essere espanso a 64 bit. Ciò potrebbe essere fatto modificando l'intestazione TCP o tramite un'opzione aggiuntiva.

La sezione 5 presenta un meccanismo diverso, che chiamiamo PAWS (Protect Against Wrapped Sequence numbers, Protezione contro i numeri di sequenza avvolti), per estendere l'affidabilità TCP a velocità di trasferimento ben oltre il limite superiore prevedibile delle larghezze di banda di rete. PAWS utilizza l'opzione TCP Timestamps definita nella sezione 4 per proteggersi dai vecchi duplicati dalla stessa connessione.

1.3 Using TCP options (Utilizzo delle opzioni TCP)

Le estensioni definite in questo memo utilizzano tutte nuove opzioni TCP. Dobbiamo affrontare due possibili problemi riguardanti l'uso delle opzioni TCP: (1) compatibilità e (2) overhead.

Dobbiamo prestare molta attenzione alla compatibilità, cioè all'interoperazione con le implementazioni esistenti. L'unica opzione TCP definita in precedenza, MSS, può apparire solo su un segmento SYN. Ogni implementazione dovrebbe (e ci aspettiamo che la maggior parte lo farà) ignorare le opzioni sconosciute sui segmenti SYN. Tuttavia, alcune implementazioni TCP difettose potrebbero andare in crash alla prima comparsa di un'opzione su un segmento non-SYN. Pertanto, per ciascuna delle estensioni definite di seguito, le opzioni TCP verranno inviate su segmenti non-SYN solo quando uno scambio di opzioni sui segmenti SYN ha indicato che entrambi i lati comprendono l'estensione. Inoltre, un'opzione di estensione verrà inviata in un segmento <SYN,ACK> solo se l'opzione corrispondente è stata ricevuta nel segmento <SYN> iniziale.

Può essere sollevata una domanda riguardo all'overhead di larghezza di banda e di elaborazione per le opzioni TCP. Quelle opzioni che si verificano sui segmenti SYN non sono probabilmente causa di preoccupazione per le prestazioni. L'apertura di una connessione TCP richiede l'esecuzione di codice di caso speciale significativo, e l'elaborazione delle opzioni è improbabile che aumenti significativamente quel costo.

D'altra parte, un'opzione Timestamps può apparire in qualsiasi segmento di dati o ACK, aggiungendo 12 byte all'intestazione TCP di 20 byte. Crediamo che la larghezza di banda risparmiata riducendo le ritrasmissioni inutili compenserà più che l'extra larghezza di banda dell'intestazione.

C'è anche un problema riguardo all'overhead di elaborazione per l'analisi del formato allineato a byte variabile delle opzioni, in particolare con una CPU di architettura RISC. Per soddisfare questa preoccupazione, l'appendice A contiene un layout consigliato delle opzioni nelle intestazioni TCP per ottenere un ragionevole allineamento del campo dati. Nello spirito di Header Prediction, un TCP può testare rapidamente questo layout e se è verificato quindi utilizzare un percorso veloce. Gli host che utilizzano questo layout canonico utilizzeranno effettivamente le opzioni come un insieme di campi a formato fisso aggiunti all'intestazione TCP. Tuttavia, per mantenere il framework filosofico e protocollo delle opzioni TCP, un TCP deve essere preparato ad analizzare un campo di opzioni arbitrario, sebbene con minore efficienza.

Infine, osserviamo che la maggior parte dei meccanismi definiti in questo memo sono importanti per LFN e/o reti ad altissima velocità. Per le reti a bassa velocità, potrebbe essere un'ottimizzazione delle prestazioni NON utilizzare questi meccanismi. Un fornitore TCP preoccupato delle prestazioni ottimali sui percorsi a bassa velocità potrebbe considerare di disattivare queste estensioni per i percorsi a bassa velocità, o consentire a un utente o a un gestore dell'installazione di disabilitarle.