1. Introduzione (Introduction)

Descriviamo prima il meccanismo con cui TCP utilizza la perdita di pacchetti come indicazione di congestione. Successivamente, spieghiamo che aggiungendo la gestione attiva della coda (Active Queue Management, AQM, come RED) all'infrastruttura Internet, i router possono rilevare la congestione prima che le code si riempiano, e quindi i router non sono più limitati all'utilizzo della perdita di pacchetti come indicazione di congestione. I router possono invece impostare il codepoint Congestion Experienced (CE, Congestione Sperimentata) nell'intestazione IP dei pacchetti provenienti da un protocollo di trasporto che supporta ECN. Descriviamo quando il codepoint CE viene impostato in un router e descriviamo le modifiche necessarie affinché TCP supporti ECN. Le modifiche per altri protocolli di trasporto (ad esempio, unicast o multicast inaffidabile, multicast affidabile, altri protocolli di trasporto unicast affidabili) possono essere considerate man mano che tali protocolli vengono sviluppati e passano attraverso il processo di standardizzazione. Descriviamo anche in questo documento i problemi relativi all'uso di ECN all'interno di tunnel IP, e in particolare all'interno di tunnel IPsec.

Un principio guida di questo documento è che, nella misura del possibile, i meccanismi specificati qui dovrebbero essere distribuibili in modo incrementale. Una sfida per il principio di distribuzione incrementale è che alcuni tunnel IP preesistenti non sono compatibili con l'uso di ECN. Man mano che ECN viene distribuito, i tunnel IP incompatibili dovranno essere aggiornati per conformarsi alle specifiche di questo documento.

Questo documento rende obsoleto RFC 2481 "A Proposal to add Explicit Congestion Notification (ECN) to IP", che ha definito ECN come protocollo sperimentale per la comunità Internet. Questo documento aggiorna anche RFC 2474 "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" riguardo alla definizione del campo ECN nell'intestazione IP, aggiorna RFC 2401 "Security Architecture for the Internet Protocol" per modificare il trattamento dell'ottetto TOS IPv4 e dell'ottetto Traffic Class IPv6 nella costruzione dell'intestazione in modalità tunnel per essere compatibile con l'uso di ECN, e aggiorna RFC 793 "Transmission Control Protocol" riguardo alla definizione di due nuovi flag nell'intestazione TCP.

Gli algoritmi di controllo e prevenzione della congestione di TCP si basano sul concetto di trattare la rete come una scatola nera [Jacobson88, Jacobson90]. La congestione o altri stati della rete vengono determinati dai sistemi terminali sondando lo stato della rete, cioè aumentando gradualmente il carico sulla rete (aumentando la finestra di pacchetti in sospeso nella rete) fino a quando la rete diventa congestionata e perde pacchetti. Trattare la rete come una "scatola nera" e la perdita come indicazione di congestione della rete è appropriato per i dati puramente "best-effort" trasportati da TCP, che hanno poca o nessuna sensibilità al ritardo o alla perdita di singoli pacchetti. Inoltre, gli algoritmi di gestione della congestione di TCP incorporano tecniche (come Fast Retransmit e Fast Recovery) per minimizzare l'impatto della perdita dal punto di vista del throughput. Tuttavia, questi meccanismi non sono progettati per aiutare le applicazioni che sono effettivamente sensibili al ritardo o alla perdita di uno o più pacchetti individuali. Il traffico interattivo (come telnet, navigazione web e trasferimento di dati audio e video) può essere sensibile alla perdita di pacchetti (in particolare quando si utilizzano protocolli di trasporto dati inaffidabili come UDP), o sensibile all'aumento del ritardo dei pacchetti risultante dalla necessità di ritrasmettere i pacchetti dopo la perdita (nel contesto della semantica di trasporto dati affidabile fornita da TCP).

Poiché TCP determina la finestra di congestione appropriata aumentando gradualmente la dimensione della finestra fino a incontrare pacchetti persi, questo porta a un accumulo di code nei router collo di bottiglia. Per la maggior parte delle politiche di scarto dei pacchetti nei router che non sono sensibili al carico imposto da ciascun singolo flusso (ad esempio, tail-drop quando la coda si riempie), questo significa che i pacchetti di alcuni flussi sensibili al ritardo possono essere scartati. Inoltre, questa politica di scarto porta a una sincronizzazione delle perdite tra più flussi.

I meccanismi di gestione attiva della coda rilevano la congestione prima che le code si riempiano e forniscono un'indicazione di questa congestione ai nodi terminali. Pertanto, la gestione attiva della coda può ridurre i ritardi di accodamento non necessari per tutto il traffico che condivide quella coda. I vantaggi della gestione attiva della coda sono discussi in RFC 2309 [RFC2309]. La gestione attiva della coda evita alcune delle caratteristiche indesiderabili dello scarto quando la coda si riempie, inclusa la sincronizzazione indesiderata delle perdite tra più flussi. Ancora più importante, la gestione attiva della coda significa che i protocolli di trasporto con meccanismi di controllo della congestione (come TCP) non devono fare affidamento esclusivamente sul trabocco del buffer come unica indicazione di congestione.

I meccanismi di gestione attiva della coda possono utilizzare uno dei diversi metodi per indicare la congestione ai nodi terminali. Un metodo è utilizzare lo scarto dei pacchetti, che è la pratica corrente. Tuttavia, la gestione attiva della coda consente ai router di separare la politica per l'accodamento o lo scarto dei pacchetti dalla politica per l'indicazione della congestione. Pertanto, la gestione attiva della coda consente ai router di utilizzare il codepoint Congestion Experienced (CE) nell'intestazione IP come indicazione di congestione, piuttosto che fare affidamento esclusivamente sullo scarto dei pacchetti. Questo ha il potenziale per ridurre l'impatto della perdita sui flussi sensibili al ritardo.

Ci sono middlebox (come firewall, bilanciatori di carico o sistemi di rilevamento delle intrusioni) su Internet che o scartano i pacchetti TCP SYN configurati per negoziare ECN, o rispondono con un RST. Questo documento specifica procedure che le implementazioni TCP possono utilizzare per fornire una connettività robusta in presenza di tali dispositivi.