5. Notifica Esplicita di Congestione in IP (Explicit Congestion Notification in IP)
Questo documento specifica che Internet fornisce un'indicazione di congestione per la congestione incipiente (come in RED e lavori precedenti [RJ90]), dove la notifica a volte può essere effettuata marcando i pacchetti piuttosto che scartandoli. Questo utilizza il campo ECN nell'intestazione IP, che contiene due bit, formando quattro codepoint ECN, da '00' a '11'. I codepoint ECN-Capable Transport (ECT, Trasporto Capace di ECN) '10' e '01' sono impostati dal mittente dei dati per indicare che gli endpoint del protocollo di trasporto supportano ECN; ci riferiamo a questi rispettivamente come ECT(0) ed ECT(1). La frase "the ECT codepoint" (il codepoint ECT) in questo documento si riferisce a uno dei due codepoint ECT. I router trattano i codepoint ECT(0) ed ECT(1) come equivalenti. I mittenti sono liberi di utilizzare il codepoint ECT(0) o ECT(1) per indicare ECT, su base pacchetto per pacchetto (packet-by-packet).
La motivazione principale per l'uso di entrambi i codepoint ECT, ECT(0) ed ECT(1), è il desiderio di consentire ai mittenti dei dati di verificare che gli elementi di rete non stiano cancellando il codepoint CE e che i ricevitori dei dati stiano segnalando correttamente ai mittenti la ricezione di pacchetti con il codepoint CE impostato, come richiesto dal protocollo di trasporto. Le linee guida su come i mittenti e i ricevitori differenziano tra i codepoint ECT(0) ed ECT(1) saranno fornite in documenti separati per ciascun protocollo di trasporto. In particolare, questo documento non affronta il meccanismo per i nodi terminali TCP di differenziare tra i codepoint ECT(0) ed ECT(1). I protocolli e i mittenti che richiedono solo un singolo codepoint ECT DOVREBBERO utilizzare ECT(0).
Il codepoint not-ECT '00' indica un pacchetto che non utilizza ECN. Il codepoint CE '11' è impostato dai router per indicare la congestione ai nodi terminali. I pacchetti che arrivano a una coda piena vengono scartati dai router, proprio come senza ECN.
+-----+-----+
| CAMPO ECN |
+-----+-----+
ECT CE [Obsoleto] Nomi RFC 2481 per i bit ECN.
0 0 Not-ECT
0 1 ECT(1)
1 0 ECT(0)
1 1 CE
Figura 1: Il campo ECN in IP
L'uso di due codepoint ECT fornisce essenzialmente un nonce ECN di un bit nell'intestazione del pacchetto, e quando i router impostano il codepoint CE, "cancellano" necessariamente il nonce [SCWA99]. Ad esempio, un router che cancella il codepoint CE avrebbe difficoltà aggiuntive nel ricostruire il nonce originale, quindi la cancellazione ripetuta del codepoint CE è più probabile che venga rilevata dai nodi terminali. Il nonce ECN può anche affrontare il comportamento scorretto dei ricevitori di trasporto nel mentire ai mittenti di trasporto sul fatto che il codepoint CE sia stato impostato nei pacchetti. La motivazione per l'uso di due codepoint ECT è discussa più dettagliatamente nella Sezione 20, che discute anche alcune possibilità alternative per il quarto codepoint ECT (cioè, il codepoint '01'). La compatibilità all'indietro con le implementazioni ECN precedenti che non comprendono il codepoint ECT(1) è discussa nella Sezione 11.
In RFC 2481 [RFC2481], il campo ECN era diviso in un bit ECN-Capable Transport (ECT) e un bit CE. Il campo ECN in RFC 2481 con solo il bit ECN-Capable Transport (ECT) impostato corrisponde al codepoint ECT(0) in questo documento, e il campo ECN in RFC 2481 con entrambi i bit ECT e CE impostati corrisponde al codepoint CE in questo documento. Il codepoint '01' non era definito in RFC 2481, motivo per cui ECT(0) è raccomandato quando è richiesto un solo codepoint ECT.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| CAMPO DS, DSCP | CAMPO ECN |
+-----+-----+-----+-----+-----+-----+-----+-----+
DSCP: codepoint differentiated services
ECN: Explicit Congestion Notification
Figura 2: I campi Differentiated Services ed ECN in IP
I bit 6 e 7 nell'ottetto TOS IPv4 sono designati come campo ECN. L'ottetto TOS IPv4 corrisponde all'ottetto Traffic Class in IPv6, e la definizione del campo ECN è la stessa in entrambi i casi. Le definizioni dell'ottetto TOS IPv4 [RFC791] e dell'ottetto Traffic Class IPv6 sono state sostituite dal campo DS (Differentiated Services) a sei bit [RFC2474, RFC2780]. I bit 6 e 7 sono elencati come Currently Unused (Attualmente Inutilizzati) in [RFC2474] e sono designati in RFC 2780 come approvati per uso sperimentale con ECN. La Sezione 22 fornisce una breve storia dell'ottetto TOS.
A causa della storia instabile dell'ottetto TOS, l'uso del campo ECN specificato in questo documento non è garantito essere compatibile all'indietro con usi passati di questi due bit prima di ECN. I pericoli potenziali di questa mancanza di compatibilità all'indietro sono discussi nella Sezione 22.
L'algoritmo di controllo della congestione seguito dai sistemi terminali deve essere essenzialmente lo stesso per la risposta al controllo della congestione a un singolo pacchetto CE in un trasporto che supporta ECN come per un singolo pacchetto perso. Ad esempio, per TCP che supporta ECN, il TCP sorgente DEVE dimezzare la sua finestra di congestione per qualsiasi finestra di dati contenente una perdita di pacchetti o un'indicazione ECN.
Una ragione per richiedere che la risposta al controllo della congestione a un pacchetto CE sia essenzialmente la stessa della risposta a un pacchetto perso è per adattarsi alla distribuzione incrementale di ECN sia nei sistemi terminali che nei router. Alcuni router potrebbero scartare i pacchetti che supportano ECN (ad esempio, utilizzando la stessa politica AQM per il rilevamento della congestione) mentre altri router impostano il codepoint CE a livelli di congestione equivalenti. Allo stesso modo, i router potrebbero scartare i pacchetti che non supportano ECN ma impostare il codepoint CE nei pacchetti che supportano ECN a livelli di congestione equivalenti. Questo potrebbe portare a un trattamento iniquo di flussi diversi se la risposta al controllo della congestione al codepoint CE fosse diversa dalla risposta alla perdita di pacchetti.
Un altro obiettivo è che i sistemi terminali dovrebbero rispondere alla congestione al massimo una volta per finestra di dati (cioè, al massimo una volta per tempo di andata e ritorno), per evitare di rispondere più volte a molteplici indicazioni di congestione in un singolo tempo di andata e ritorno.
Per i router, il codepoint CE di un pacchetto che supporta ECN DOVREBBE essere impostato solo se il router avrebbe altrimenti scartato il pacchetto come indicazione di congestione ai nodi terminali. Quando i buffer del router non sono ancora pieni e il router è preparato a scartare i pacchetti per notificare ai nodi terminali la congestione incipiente, il router DOVREBBE prima verificare se l'intestazione IP di quel pacchetto ha un codepoint ECT impostato. Se è così, allora il router POTREBBE invece impostare il codepoint CE nell'intestazione IP piuttosto che scartare il pacchetto.
Un ambiente in cui tutti i nodi terminali supportano ECN potrebbe consentire lo sviluppo di nuovi standard per l'impostazione del codepoint CE, e nuovi meccanismi di controllo della congestione per i nodi terminali che reagiscono ai pacchetti CE. Tuttavia, questo è un problema di ricerca e quindi non è discusso in questo documento.
Quando un router riceve un pacchetto CE (cioè, un pacchetto con il codepoint CE impostato), il codepoint CE rimane invariato e il pacchetto viene trasmesso nel modo normale. Quando si verifica una congestione grave e le code del router sono piene, il router non ha altra scelta se non scartare alcuni pacchetti quando arrivano nuovi pacchetti. Ci aspettiamo che tale perdita di pacchetti diventi relativamente rara quando la maggior parte dei sistemi terminali supporta ECN e partecipa ai meccanismi di controllo della congestione TCP o altro compatibili. In un ambiente compatibile con ECN ben configurato, la perdita di pacchetti dovrebbe verificarsi principalmente durante i transitori o in presenza di sorgenti non cooperative.
La discussione sopra su quando CE può essere impostato invece di scartare un pacchetto si applica per default a tutti i Differentiated Services Per-Hop Behaviors (PHB) [RFC 2475]. Le specifiche per i PHB possono fornire ulteriori dettagli su come le implementazioni conformi scelgono tra l'impostazione di CE e lo scarto dei pacchetti, ma questo non è richiesto. I router NON DEVONO assolutamente impostare CE invece di scartare un pacchetto quando lo scarto che si verifica è causato da ragioni diverse dalla congestione o quando si desidera indicare la congestione incipiente ai nodi terminali (ad esempio, un nodo edge diffserv potrebbe essere configurato per scartare incondizionatamente determinate classi di traffico per impedire che entrino nel loro dominio diffserv).
Ci aspettiamo che i router impostino il codepoint CE in base alla congestione incipiente indicata dalla lunghezza media della coda, utilizzando l'algoritmo RED raccomandato in [FJ93, RFC2309]. Per quanto ne sappiamo, questa è l'unica proposta attualmente in discussione nell'IETF per far sì che i router scartino attivamente i pacchetti prima che si verifichi il trabocco del buffer. Tuttavia, questo documento non tenta di specificare un particolare meccanismo di gestione attiva della coda, lasciando tale lavoro ad altre aree dell'IETF, se necessario. Mentre ECN è inseparabile dall'avere meccanismi ragionevoli di gestione attiva della coda nei router, il contrario non è vero; i meccanismi di gestione attiva della coda vengono sviluppati e distribuiti indipendentemente da ECN, utilizzando lo scarto dei pacchetti per l'indicazione della congestione nell'architettura IP senza ECN.