7. The Probing Method (Il metodo di sondaggio)

Questa sezione descrive i dettagli del metodo di sondaggio MTU, incluso come inviare sondaggi e processare le indicazioni di errore necessarie per cercare il Path MTU.

7.1. Intervalli di dimensione dei pacchetti

Questo documento descrive il metodo di sondaggio usando tre variabili di stato:

search_low: La più piccola dimensione di sondaggio utile, meno uno. La rete è prevista essere in grado di consegnare pacchetti di dimensione search_low.

search_high: La più grande dimensione di sondaggio utile. I pacchetti di dimensione search_high sono previsti essere troppo grandi per la rete da consegnare.

eff_pmtu: Il PMTU effettivo per questo flusso. Questo è il più grande pacchetto non di sondaggio permesso da PLPMTUD per il percorso.

search_low          eff_pmtu         search_high
    |                   |                  |
...------------------------>
intervallo di dimensione non-sondaggio
    <-------------------------------------->
                intervallo di dimensione di sondaggio

Quando si trasmettono non-sondaggi, il livello di pacchettizzazione DOVREBBE (SHOULD) creare pacchetti di una dimensione minore o uguale a eff_pmtu.

Quando si trasmettono sondaggi, il livello di pacchettizzazione DEVE (MUST) selezionare una dimensione di sondaggio maggiore di search_low e minore o uguale a search_high.

Quando si sonda verso l'alto, eff_pmtu è sempre uguale a search_low. In altri stati, come condizioni iniziali, dopo l'elaborazione di messaggi ICMP PTB o seguendo PLPMTUD su un altro flusso che condivide la stessa rappresentazione del percorso, eff_pmtu può essere diverso da search_low. Normalmente, eff_pmtu sarà maggiore o uguale a search_low e minore di search_high. È generalmente previsto ma non richiesto che la dimensione del sondaggio sia maggiore di eff_pmtu.

Per condizioni iniziali quando non ci sono informazioni sul percorso, eff_pmtu può essere maggiore di search_low. Il valore iniziale di search_low DOVREBBE (SHOULD) essere conservativamente basso, ma le prestazioni possono essere migliori se eff_pmtu inizia a un valore più alto, meno conservativo. Vedi Sezione 7.2.

Se eff_pmtu è più grande di search_low, è esplicitamente permesso inviare pacchetti non di sondaggio più grandi di search_low. Quando un tale pacchetto è riconosciuto, è effettivamente un "sondaggio implicito" e search_low DOVREBBE (SHOULD) essere aumentato alla dimensione del pacchetto riconosciuto. Tuttavia, se un "sondaggio implicito" viene perso, NON DEVE (MUST NOT) essere trattato come un fallimento del sondaggio come sarebbe un vero sondaggio. Se eff_pmtu è troppo grande, questa condizione sarà rilevata solo con messaggi ICMP PTB o scoperta di buco nero (vedi Sezione 7.7).

7.2. Selezione dei valori iniziali

Il valore iniziale per search_high DOVREBBE (SHOULD) essere il più grande pacchetto possibile che potrebbe essere supportato dal flusso. Questo può essere limitato dal MTU dell'interfaccia locale, da un meccanismo di protocollo esplicito come l'opzione TCP MSS, o da un limite intrinseco come la dimensione di un campo di lunghezza del protocollo. Inoltre, il valore iniziale per search_high PUÒ (MAY) essere limitato da un'opzione di configurazione per prevenire il sondaggio sopra una certa dimensione massima. Search_high è probabile essere lo stesso del Path MTU iniziale come calcolato dall'algoritmo classico di scoperta del Path MTU.

È RACCOMANDATO (RECOMMENDED) che search_low sia inizialmente impostato su una dimensione MTU che probabilmente funzionerà su una gamma molto ampia di ambienti. Date le tecnologie di oggi, un valore di 1024 byte è probabilmente abbastanza sicuro. Il valore iniziale per search_low DOVREBBE (SHOULD) essere configurabile.

Il funzionamento corretto della scoperta del Path MTU è critico per il funzionamento robusto ed efficiente di Internet. Qualsiasi cambiamento maggiore (come descritto in questo documento) ha il potenziale di essere molto dirompente se causa cambiamenti inattesi nei comportamenti del protocollo. La selezione del valore iniziale per eff_pmtu determina in che misura il comportamento di un'implementazione PLPMTUD assomiglia a PMTUD classica nei casi in cui il metodo classico è sufficiente.

Una configurazione conservativa sarebbe impostare eff_pmtu a search_high, e affidarsi ai messaggi ICMP PTB per impostare eff_pmtu verso il basso come appropriato. In questa configurazione, PMTUD classica è completamente funzionale e PLPMTUD è invocato solo per recuperare da buchi neri ICMP attraverso la procedura descritta nella Sezione 7.7.

In alcuni casi, dove è noto che PMTUD classica probabilmente fallirà (ad esempio, se i messaggi ICMP PTB sono amministrativamente disabilitati per motivi di sicurezza), usare un piccolo eff_pmtu iniziale eviterà i costosi timeout richiesti per la rilevazione del buco nero. Il compromesso è che usare un eff_pmtu iniziale più piccolo del necessario potrebbe causare prestazioni ridotte.

Nota che l'eff_pmtu iniziale può essere qualsiasi valore nell'intervallo search_low a search_high. Un eff_pmtu iniziale di 1400 byte potrebbe essere un buon compromesso perché sarebbe sicuro per quasi tutti i tunnel su tutte le apparecchiature di rete comuni, eppure vicino al MTU ottimale per la maggior parte dei percorsi in Internet oggi. Questo potrebbe essere migliorato usando alcune statistiche di altri flussi recenti: ad esempio, l'eff_pmtu iniziale per un flusso potrebbe essere impostato alla mediana della dimensione del sondaggio per tutti i sondaggi riusciti recenti.

Poiché il costo di PLPMTUD è dominato dai sovraccarichi specifici del protocollo di generazione e elaborazione dei sondaggi, è probabilmente desiderabile che ogni protocollo abbia le proprie euristiche per selezionare l'eff_pmtu iniziale. È particolarmente importante che i protocolli senza connessione e altri protocolli che potrebbero non ricevere chiare indicazioni di buchi neri ICMP usino valori iniziali conservativi (più piccoli) per eff_pmtu, come descritto nella Sezione 10.3.

Ci DOVREBBERO (SHOULD) essere opzioni di configurazione per protocollo e per rotta per sovrascrivere i valori iniziali per eff_pmtu e altre variabili di stato PLPMTUD.

7.3. Selezione della dimensione del sondaggio

Il sondaggio può avere una dimensione ovunque nell'"intervallo di dimensione del sondaggio" descritto sopra. Tuttavia, una serie di fattori influisce sulla selezione di una dimensione appropriata. Una strategia semplice potrebbe essere fare una ricerca binaria dimezzando l'intervallo di dimensione del sondaggio con ogni sondaggio. Tuttavia, per alcuni protocolli, come TCP, i sondaggi falliti sono più costosi di quelli riusciti, poiché i dati in un sondaggio fallito dovranno essere ritrasmessi. Per tali protocolli, una strategia che aumenta la dimensione del sondaggio in incrementi più piccoli potrebbe avere un sovraccarico inferiore. Per molti protocolli, sia a che sopra il livello di pacchettizzazione, il beneficio dell'aumento delle dimensioni MTU può seguire una funzione a gradini tale che non è vantaggioso sondare all'interno di certe regioni affatto.

Come ottimizzazione, può essere appropriato sondare a certe dimensioni MTU comuni o previste, ad esempio, 1500 byte per Ethernet standard, o 1500 byte meno le dimensioni delle intestazioni per protocolli di tunnel.

Alcuni protocolli possono usare altri meccanismi per scegliere le dimensioni dei sondaggi. Ad esempio, i protocolli che hanno certe dimensioni di blocchi di dati naturali potrebbero semplicemente assemblare messaggi da un numero di blocchi fino a quando la dimensione totale è minore di search_high, e se possibile maggiore di search_low.

Ogni livello di pacchettizzazione DEVE (MUST) determinare quando il sondaggio ha convergito, cioè quando l'intervallo di dimensione del sondaggio è abbastanza piccolo che ulteriori sondaggi non valgono più il loro costo. Quando il sondaggio ha convergito, un timer DOVREBBE (SHOULD) essere impostato. Quando il timer scade, search_high dovrebbe essere reimpostato al suo valore iniziale (descritto sopra) in modo che il sondaggio possa riprendere. Così, se il percorso cambia, aumentando il Path MTU, allora il flusso ne trarrà vantaggio alla fine. Il valore per questo timer NON DEVE (MUST NOT) essere inferiore a 5 minuti ed è raccomandato essere 10 minuti, per RFC 1981.

7.4. Precondizioni del sondaggio

Prima di inviare un sondaggio, il flusso DEVE (MUST) soddisfare almeno le seguenti condizioni:

• Non ha sondaggi o perdite in sospeso.
• Se l'ultimo sondaggio è fallito o era inconcludente, allora il timeout del sondaggio è scaduto (vedi Sezione 7.6.2).
• La finestra disponibile è maggiore della dimensione del sondaggio.
• Per un protocollo che usa dati in-band per il sondaggio, abbastanza dati sono disponibili per inviare il sondaggio.

Inoltre, gli algoritmi di rilevamento delle perdite tempestive nella maggior parte dei protocolli hanno pre-condizioni che DOVREBBERO (SHOULD) essere soddisfatte prima di inviare un sondaggio. Ad esempio, TCP Fast Retransmit non è robusto a meno che non ci siano segmenti sufficienti che seguono un sondaggio; cioè, il mittente DOVREBBE (SHOULD) avere abbastanza dati in coda e una finestra del ricevitore sufficiente per inviare il sondaggio più almeno Tcprexmtthresh [RFC2760] segmenti aggiuntivi. Questa restrizione può inibire il sondaggio in alcuni stati del protocollo, come troppo vicino alla fine di una connessione, o quando la finestra è troppo piccola.

I protocolli POSSONO (MAY) ritardare l'invio di non-sondaggi per accumulare abbastanza dati per soddisfare le precondizioni per il sondaggio. L'algoritmo di invio ritardato DOVREBBE (SHOULD) usare una tecnica di auto-scalatura per limitare appropriatamente il tempo che i dati sono ritardati. Ad esempio, gli ACK che ritornano possono essere usati per prevenire che la finestra cada di più della quantità di dati necessari per il sondaggio.

7.5. Conduzione di un sondaggio

Una volta che una dimensione di sondaggio nell'intervallo appropriato è stata selezionata, e le precondizioni sopra sono state soddisfatte, il livello di pacchettizzazione PUÒ (MAY) condurre un sondaggio. Per fare ciò, crea un pacchetto di sondaggio tale che la sua dimensione, inclusa le intestazioni IP più esterne, sia uguale alla dimensione del sondaggio. Dopo aver inviato il sondaggio attende una risposta, che avrà uno dei seguenti risultati:

Successo: Il sondaggio è riconosciuto come essere stato ricevuto dall'host remoto.

Fallimento: Un meccanismo del protocollo indica che il sondaggio è stato perso, ma nessun pacchetto nella finestra principale o finale è stato perso.

Fallimento di timeout: Un meccanismo del protocollo indica che il sondaggio è stato perso, e nessun pacchetto nella finestra principale è stato perso, ma è incapace di determinare se qualsiasi pacchetto nella finestra finale è stato perso. Ad esempio, la perdita è rilevata da un timeout, e la ritrasmissione go-back-n è usata.

Inconcludente: Il sondaggio è stato perso in aggiunta ad altri pacchetti nelle finestre principali o finali.

7.6. Risposta ai risultati del sondaggio

Quando un sondaggio è completato, il risultato DOVREBBE (SHOULD) essere processato come segue, categorizzato per il tipo di risultato del sondaggio.

7.6.1. Successo del sondaggio

Quando il sondaggio è consegnato, è un'indicazione che il Path MTU è almeno grande quanto la dimensione del sondaggio. Impostare search_low alla dimensione del sondaggio. Se la dimensione del sondaggio è maggiore di eff_pmtu, aumentare eff_pmtu alla dimensione del sondaggio. La dimensione del sondaggio potrebbe essere minore di eff_pmtu se il flusso non ha usato il MTU completo del percorso perché è soggetto a qualche altra limitazione, come dati disponibili in una sessione interattiva.

Nota che se i pacchetti di un flusso sono instradati via percorsi multipli, o su un percorso con un MTU non deterministico, la consegna di un singolo pacchetto di sondaggio non indica che tutti i pacchetti di quella dimensione saranno consegnati. Per essere robusto in un tale caso, il livello di pacchettizzazione DOVREBBE (SHOULD) condurre verifica MTU come descritto nella Sezione 7.8.

7.6.2. Fallimento del sondaggio

Quando solo il sondaggio è perso, è trattato come un'indicazione che il Path MTU è minore della dimensione del sondaggio. Solo in questo caso, la perdita NON DOVREBBE (SHOULD NOT) essere interpretata come segnale di congestione.

In assenza di altre indicazioni, impostare search_high alla dimensione del sondaggio meno uno. L'eff_pmtu potrebbe essere maggiore della dimensione del sondaggio se il flusso non ha usato il MTU completo del percorso perché è soggetto a qualche altra limitazione, come dati disponibili in una sessione interattiva. Se eff_pmtu è maggiore della dimensione del sondaggio, eff_pmtu DEVE (MUST) essere ridotto a non più grande di search_high, e DOVREBBE (SHOULD) essere ridotto a search_low, poiché eff_pmtu è stato determinato essere invalido, simile a dopo un timeout completo (vedi Sezione 7.7).

Se un messaggio ICMP PTB viene ricevuto corrispondente al pacchetto di sondaggio, allora search_high e eff_pmtu POSSONO (MAY) essere impostati dal valore MTU indicato nel messaggio. Nota che il messaggio ICMP può essere ricevuto sia prima che dopo l'indicazione di perdita del protocollo.

Un evento di fallimento del sondaggio è l'unica situazione sotto la quale il livello di pacchettizzazione DOVREBBE (SHOULD) ignorare la perdita come segnale di congestione. Poiché c'è un piccolo rischio che sopprimere il controllo della congestione potrebbe avere conseguenze inattese (anche per una perdita isolata), è RICHIESTO (REQUIRED) che gli eventi di fallimento del sondaggio siano meno frequenti del periodo normale per le perdite sotto controllo della congestione standard. Specificamente, dopo un evento di fallimento del sondaggio e controllo della congestione soppresso, PLPMTUD NON DEVE (MUST NOT) sondare di nuovo fino a un intervallo che è più grande dell'intervallo atteso tra eventi di controllo della congestione. Vedi Sezione 4 per i dettagli. La stima più semplice dell'intervallo al prossimo evento di congestione è lo stesso numero di round trip come la finestra di congestione corrente in pacchetti.

7.6.3. Fallimento di timeout del sondaggio

Se la perdita è stata rilevata con un timeout e riparata con ritrasmissione go-back-n, allora la riduzione della finestra di congestione sarà necessaria. Il prezzo relativamente alto di un sondaggio fallito in questo caso può meritare un intervallo di tempo più lungo fino al prossimo sondaggio. Un intervallo di tempo che è cinque volte il caso di fallimento non-timeout (Sezione 7.6.2) è RACCOMANDATO (RECOMMENDED).

7.6.4. Sondaggio inconcludente

La presenza di altre perdite vicino alla perdita del sondaggio può indicare che il sondaggio è stato perso a causa di congestione piuttosto che a causa di una limitazione MTU. In questo caso, le variabili di stato eff_pmtu, search_low e search_high NON DOVREBBERO (SHOULD NOT) essere aggiornate, e lo stesso sondaggio di dimensione DOVREBBE (SHOULD) essere tentato di nuovo non appena le precondizioni del sondaggio sono soddisfatte (cioè, una volta che il livello di pacchettizzazione non ha perdite non recuperate in sospeso). A questo punto, è particolarmente appropriato ri-sondare poiché la finestra di congestione del flusso sarà al suo punto più basso, minimizzando la probabilità di perdite di congestione.

7.7. Timeout completo

Sotto tutte le condizioni, un timeout completo (anche noto come "timeout persistente" in altri documenti) DOVREBBE (SHOULD) essere preso come un'indicazione di qualche evento significativamente dirompente nella rete, come un fallimento del router o un cambiamento di routing a un percorso con un MTU più piccolo. Per TCP, questo si verifica quando la soglia di timeout R1 descritta da [RFC1122] scade.

Se c'è un timeout completo e non c'era un messaggio ICMP che indicava un motivo (PTB, Net unreachable, ecc., o il messaggio ICMP è stato ignorato per qualche motivo), la prima azione di recupero RACCOMANDATA (RECOMMENDED) è trattare questo come un buco nero ICMP rilevato come definito in [RFC2923].

La risposta a un buco nero rilevato dipende dai valori correnti per search_low e eff_pmtu. Se eff_pmtu è maggiore di search_low, impostare eff_pmtu a search_low. Altrimenti, impostare sia eff_pmtu che search_low al valore iniziale per search_low. Su timeout successivi aggiuntivi, search_low e eff_pmtu DOVREBBERO (SHOULD) essere dimezzati, con un limite inferiore di 68 byte per IPv4 e 1280 byte per IPv6. Limiti inferiori ancora più bassi POSSONO (MAY) essere permessi per supportare operazione limitata su collegamenti con MTU che sono più piccoli di quelli permessi dalle specifiche IP.

7.8. Verifica MTU

È possibile che un flusso attraversi simultaneamente percorsi multipli, ma un'implementazione sarà solo in grado di mantenere una singola rappresentazione del percorso per il flusso. Se i percorsi hanno MTU diversi, memorizzare il MTU minimo di tutti i percorsi nella rappresentazione del percorso del flusso risulterà in comportamento corretto. Se i messaggi ICMP PTB sono consegnati, allora PMTUD classica funzionerà correttamente in questa situazione.

Se la consegna ICMP fallisce, rompendo PMTUD classica, la connessione si affiderà esclusivamente a PLPMTUD. In questo caso, PLPMTUD può anche fallire poiché assume che un flusso attraversi un percorso con un singolo MTU. Un sondaggio con una dimensione maggiore del minimo ma minore del massimo dei Path MTU può essere riuscito. Tuttavia, aumentando il PMTU effettivo del flusso, il tasso di perdita aumenterà significativamente. Il flusso può ancora fare progressi, ma il tasso di perdita risultante è probabile essere inaccettabile. Ad esempio, quando si usa striping round-robin bidirezionale, il 50% dei pacchetti a dimensione piena verrebbero scartati.

Lo striping in questo modo è spesso operativamente indesiderabile per altre ragioni (ad esempio, a causa di riordinamento dei pacchetti) ed è solitamente evitato facendo hash di ogni flusso a un singolo percorso. Tuttavia, per aumentare la robustezza, un'implementazione DOVREBBE (SHOULD) implementare qualche forma di verifica MTU, tale che se aumentare eff_pmtu risulta in un forte aumento del tasso di perdita, cadrà indietro usando un MTU più basso.

Una strategia RACCOMANDATA (RECOMMENDED) sarebbe salvare il valore di eff_pmtu prima di aumentarlo. Poi, se il tasso di perdita sale sopra una soglia per un periodo di tempo (ad esempio, il tasso di perdita è più alto del 10% su multipli intervalli di timeout di ritrasmissione (RTO)), allora il nuovo MTU è considerato incorretto. Il valore salvato di eff_pmtu DOVREBBE (SHOULD) essere ripristinato, e search_high ridotto nello stesso modo come in un fallimento del sondaggio. Le implementazioni PLPMTUD DOVREBBERO (SHOULD) implementare verifica MTU.