10. Specific Packetization Layers (Livelli di pacchettizzazione specifici)

Tutti i protocolli del livello di pacchettizzazione devono considerare tutti i problemi discussi nella Sezione 6. Per molti protocolli, è semplice affrontare questi problemi. Questa sezione discute dettagli specifici per implementare PLPMTUD con alcuni protocolli. Si spera che le descrizioni qui saranno illustrazioni sufficienti per gli implementatori ad adattarsi a protocolli aggiuntivi.

10.1. Metodo di sondaggio usando TCP

TCP non ha un meccanismo per distinguere dati in-band da padding. Pertanto, TCP deve generare sondaggi segmentando appropriatamente i dati. Ci sono due approcci alla segmentazione: sovrapposto e non sovrapposto.

Metodo non sovrapposto

Nel metodo non sovrapposto, i dati sono segmentati in modo che il sondaggio e qualsiasi segmento successivo non contengano dati sovrapposti. Se il sondaggio è perso, la "lacuna del sondaggio" sarà una dimensione di sondaggio completa meno le intestazioni. I dati nella lacuna del sondaggio dovranno essere ritrasmessi con multipli segmenti più piccoli.

Numero di sequenza TCP

t   <---->
i         <-------->           (sondaggio)
m                   <---->
e
                .
                .                (sondaggio perso)
                .

            <---->               (lacuna del sondaggio ritrasmessa)
                  <-->

Metodo sovrapposto

Un approccio alternativo è inviare dati successivi sovrapponendo il sondaggio in modo che la lacuna del sondaggio sia uguale in lunghezza al MSS corrente. Nel caso di un sondaggio riuscito, questo ha sovraccarico aggiuntivo in quanto invierà alcuni dati due volte, ma dovrà ritrasmettere solo un segmento dopo un sondaggio perso. Quando un sondaggio riesce, ci saranno probabilmente alcuni acknowledgment duplicati generati a causa dei dati duplicati inviati. È importante che questi acknowledgment duplicati non attivino Fast Retransmit. Come tale, un'implementazione che usa questo approccio DOVREBBE (SHOULD) limitare la dimensione del sondaggio a tre volte il MSS corrente (causando al massimo 2 acknowledgment duplicati), o aggiustare appropriatamente la sua soglia di acknowledgment duplicato per i dati immediatamente dopo un sondaggio riuscito.

Numero di sequenza TCP

t   <---->
i         <-------->           (sondaggio)
m               <---->
e                     <---->

                .
                .                (sondaggio perso)
                .

            <---->               (lacuna del sondaggio ritrasmessa)

La scelta di quale metodo di segmentazione usare dovrebbe essere basata su ciò che è più semplice ed efficiente per una data implementazione TCP.

10.2. Metodo di sondaggio usando SCTP

Nel Stream Control Transmission Protocol (SCTP) [RFC2960], l'applicazione scrive messaggi a SCTP, che divide i dati in "chunk" più piccoli adatti per la trasmissione attraverso la rete. Ogni chunk è assegnato un Transmission Sequence Number (TSN). Una volta che un TSN è stato trasmesso, SCTP non può cambiare la dimensione del chunk. Il supporto multi-percorso SCTP normalmente richiede che SCTP scelga una dimensione di chunk tale che i suoi messaggi si adattino al più piccolo PMTU di tutti i percorsi. Sebbene non richiesto, le implementazioni possono raggruppare multipli chunk di dati insieme per creare pacchetti IP più grandi da inviare su percorsi con un PMTU più grande. Nota che SCTP deve sondare indipendentemente il PMTU su ogni percorso al peer.

Il metodo RACCOMANDATO (RECOMMENDED) per generare sondaggi è aggiungere un chunk consistente solo di padding a un messaggio SCTP. Il chunk PAD definito in [RFC4820] DOVREBBE (SHOULD) essere attaccato a un chunk HEARTBEAT (HB) di lunghezza minima per costruire un pacchetto di sondaggio. Questo metodo è completamente compatibile con tutte le implementazioni SCTP attuali.

SCTP PUÒ (MAY) anche sondare con un metodo simile a quello di TCP descritto sopra, usando dati inline. Usare un tale metodo ha il vantaggio che i sondaggi riusciti non hanno sovraccarico aggiuntivo; tuttavia, i sondaggi falliti richiederanno ritrasmissione di dati, che può impattare le prestazioni del flusso.

10.3. Metodo di sondaggio per frammentazione IP

Ci sono alcuni protocolli e applicazioni che normalmente inviano grandi datagrammi e si affidano alla frammentazione IP per consegnarli. È noto da molto tempo che questo ha alcune conseguenze indesiderabili [Kent87]. Più recentemente, è emerso che la frammentazione IPv4 non è sufficientemente robusta per uso generale nell'Internet di oggi. Il campo di identificazione IP a 16 bit non è abbastanza grande per prevenire frequenti frammenti IP mal associati, e i checksum TCP e UDP sono insufficienti per prevenire che i dati corrotti risultanti siano consegnati agli strati di protocollo superiori [frag-errors].

Come menzionato nella Sezione 8, i protocolli datagramma (come UDP) potrebbero affidarsi alla frammentazione IP come livello di pacchettizzazione. Tuttavia, usare la frammentazione IP per implementare PLPMTUD è problematico perché lo strato IP non ha un meccanismo per determinare se i pacchetti sono infine consegnati al nodo lontano, senza partecipazione diretta dell'applicazione.

Per supportare la frammentazione IP come livello di pacchettizzazione sotto un'applicazione non modificata, un'implementazione DOVREBBE (SHOULD) affidarsi alla condivisione del Path MTU descritta nella Sezione 5.2 più un protocollo ausiliario per sondare il Path MTU. Ci sono una serie di protocolli che potrebbero essere usati a questo scopo, come ICMP ECHO e ECHO REPLY, o datagrammi UDP in stile "traceroute" che attivano messaggi ICMP. L'uso di ICMP ECHO e ECHO REPLY sonderà sia i percorsi in avanti che di ritorno, quindi il mittente sarà solo in grado di trarre vantaggio dal minimo dei due. Altri metodi che sondano solo il percorso in avanti sono preferiti se disponibili.

Tutti questi approcci hanno una serie di problemi di robustezza potenziali. I fallimenti più probabili sono dovuti a perdite non correlate a MTU (ad esempio, nodi che scartano alcuni tipi di protocollo). Queste perdite non correlate a MTU possono prevenire che PLPMTUD aumenti il MTU, forzando la frammentazione IP a usare un MTU più piccolo del necessario. Poiché questi fallimenti non sono probabili causare problemi di interoperabilità, sono relativamente benigni.

Tuttavia, esistono altri modi di fallimento più seri, come quelli che potrebbero essere causati da middle box o router dello strato superiore che scelgono percorsi diversi per diversi tipi di protocollo o sessioni. In tali ambienti, i protocolli ausiliari possono legittimamente sperimentare un Path MTU diverso dal protocollo principale. Se il protocollo ausiliario trova un MTU più grande del protocollo principale, PLPMTUD può selezionare un MTU che non è utilizzabile dal protocollo principale. Sebbene questo sia un problema potenzialmente serio, questo tipo di situazione è probabile essere visto come incorretto da un gran numero di osservatori, e quindi ci sarà una forte motivazione per correggerlo.

Poiché i protocolli senza connessione potrebbero non mantenere abbastanza stato per diagnosticare efficacemente i buchi neri MTU, sarebbe più robusto errare sul lato dell'uso di un MTU iniziale troppo piccolo (ad esempio, 1 kByte o meno) prima di sondare un percorso per misurare il MTU. Per questa ragione, le implementazioni che usano frammentazione IP DOVREBBERO (SHOULD) usare un eff_pmtu iniziale, che è selezionato come descritto nella Sezione 7.2, eccetto usando un controllo globale separato per l'eff_mtu iniziale predefinito per protocolli senza connessione.

I protocolli senza connessione introducono anche un problema aggiuntivo con il mantenimento della cache di informazioni del percorso: non ci sono eventi corrispondenti all'instaurazione e alla chiusura della connessione da usare per gestire la cache stessa. Un approccio naturale sarebbe mantenere una voce di cache immutabile per il "percorso predefinito", che ha un eff_pmtu che è fissato al valore iniziale per protocolli senza connessione. Il protocollo ausiliario di scoperta del Path MTU sarebbe invocato una volta che il numero di datagrammi frammentati a qualsiasi destinazione particolare raggiunge una certa soglia configurabile (ad esempio, 5 datagrammi). Una nuova voce di cache del percorso sarebbe creata quando il protocollo ausiliario aggiorna eff_pmtu, e cancellata sulla base di un timer o di un algoritmo di sostituzione della cache Least Recently Used.

10.4. Metodo di sondaggio usando applicazioni

Gli svantaggi di affidarsi alla frammentazione IP e a un protocollo ausiliario per eseguire la scoperta del Path MTU possono essere superati implementando la scoperta del Path MTU all'interno dell'applicazione stessa, usando il proprio protocollo dell'applicazione. L'applicazione deve avere qualche metodo appropriato per generare sondaggi e avere un meccanismo accurato e tempestivo per determinare se i sondaggi sono stati persi.

Idealmente, il protocollo dell'applicazione include una funzione echo leggera che conferma la consegna del messaggio, più un meccanismo per riempire i messaggi alla dimensione di sondaggio desiderata, tale che il padding non sia echoato. Questa combinazione (simile a SCTP HB più PAD) è RACCOMANDATA (RECOMMENDED) perché un'applicazione può misurare separatamente il MTU di ogni direzione su un percorso con MTU asimmetrici.

Per protocolli che non possono implementare PLPMTUD con "echo più pad", ci sono spesso metodi alternativi per generare sondaggi. Ad esempio, il protocollo può avere un echo di lunghezza variabile che misura effettivamente il MTU minimo sia del percorso in avanti che di ritorno, o ci può essere un modo per aggiungere padding a messaggi regolari che portano dati reali dell'applicazione. Ci possono anche essere modi alternativi per segmentare dati dell'applicazione per generare sondaggi, o come ultima risorsa, può essere fattibile estendere il protocollo con nuovi tipi di messaggio specificamente per supportare la scoperta MTU.

Nota che se è necessario aggiungere nuovi tipi di messaggio per supportare PLPMTUD, l'approccio più generale è aggiungere messaggi ECHO e PAD, che permettono la massima latitudine possibile in come un'implementazione specifica dell'applicazione di PLPMTUD interagisce con altre applicazioni e protocolli sullo stesso sistema finale.

Tutte le tecniche di sondaggio dell'applicazione richiedono la capacità di inviare messaggi che sono più grandi dell'attuale eff_pmtu descritto nella Sezione 9.