5. PMTUD del livello di pacchettizzazione dei datagrammi

Questa sezione specifica la PLPMTUD per datagrammi (DPLPMTUD). Il metodo può essere introdotto in vari punti dello stack del protocollo IP per scoprire il PLPMTU in modo che un'applicazione possa utilizzare un MPS appropriato per il percorso di rete corrente.

DPLPMTUD DOVREBBE essere eseguito solo su un livello tra una coppia di endpoint. Pertanto, quando DPLPMTUD è abilitato a un livello inferiore, un PL di livello superiore o un'applicazione dovrebbe evitare di utilizzare DPLPMTUD. Un PL DEVE regolare l'MPS indicato da DPLPMTUD per tenere conto di qualsiasi overhead aggiuntivo introdotto dal PL.

Esempi di posizione di implementazione DPLPMTUD

Application Data  *
   ↓
QUIC/RTP         * (Può implementare DPLPMTUD)
   ↓
UDP              * (Può implementare DPLPMTUD)
   ↓
IP Layer
   ↓
Network Interface

L'idea centrale di DPLPMTUD è il sondaggio da parte del mittente. I pacchetti di sondaggio vengono inviati per trovare la dimensione massima del messaggio utente che può essere trasferito completamente dal mittente alla destinazione.

Le sezioni seguenti identificano i componenti richiesti per l'implementazione, forniscono una panoramica delle fasi operative e specificano la macchina a stati e l'algoritmo di ricerca.

5.1. Componenti DPLPMTUD

Questa sezione descrive i timer, le costanti e le variabili di DPLPMTUD.

5.1.1. Timer

Il metodo utilizza fino a tre timer:

PROBE_TIMER

• Configurazione: Timeout maggiore del tempo massimo per ricevere una conferma di un pacchetto di sondaggio
• Minimo: NON DEVE essere inferiore a 1 secondo
• Raccomandato: DOVREBBE essere maggiore di 15 secondi
• Riferimento: La sezione 3.1.1 delle linee guida sull'uso di UDP [BCP145] fornisce indicazioni sulla selezione dei valori del timer

PMTU_RAISE_TIMER

• Funzione: Il periodo durante il quale un mittente continuerà a utilizzare il PLPMTU corrente, dopo il quale rientra nella fase di ricerca
• Periodo: 600 secondi, come raccomandato da PLPMTUD [RFC4821]
• Ottimizzazione: DPLPMTUD PUÒ inibire l'invio di pacchetti di sondaggio quando non sono stati inviati dati dell'applicazione dall'ultimo pacchetto di sondaggio. Un PL che preferisce utilizzare l'ultimo PMTU quando invia nuovamente dati utente può scegliere di continuare la scoperta PMTU per ogni percorso. Tuttavia, ciò comporterà l'invio di pacchetti aggiuntivi

CONFIRMATION_TIMER

• Applicabilità: NON DEVE essere utilizzato quando viene utilizzato un PL confermato
• Funzione: Per altri PL, configurato come il periodo durante il quale un mittente PL attende prima di confermare che il PLPMTU corrente è ancora supportato
• Relazione: Più piccolo di PMTU_RAISE_TIMER, utilizzato per ridurre il PLPMTU (ad esempio, quando si incontra un buco nero)
• Frequenza: La conferma deve essere abbastanza frequente da evitare che il PL mittente metta in buco nero una grande quantità di traffico quando i dati fluiscono
• Riferimento: La sezione 3.1.1 delle linee guida sull'uso di UDP [BCP145] fornisce indicazioni sulla selezione dei valori del timer
• Ottimizzazione: DPLPMTUD PUÒ inibire l'invio di pacchetti di sondaggio quando non sono stati inviati dati dell'applicazione dall'ultimo pacchetto di sondaggio

Nota: DPLPMTUD specifica vari timer; tuttavia, un'implementazione può scegliere di realizzare queste funzioni di timer utilizzando un singolo timer.

5.1.2. Costanti

Sono definite le seguenti costanti:

MAX_PROBES

• Definizione: Il valore massimo del contatore PROBE_COUNT
• Significato: Rappresenta un limite sul numero di tentativi di sondaggio consecutivi di qualsiasi dimensione
• Vantaggio: Un valore MAX_PROBES maggiore di 1 può fornire robustezza alla perdita di pacchetti isolata
• Predefinito: 3

MIN_PLPMTU

• Definizione: La dimensione PLPMTU più piccola che DPLPMTUD tenterà di utilizzare
• Configurazione: Un endpoint potrebbe dover configurare MIN_PLPMTU per fornire spazio per intestazioni di estensione e altra incapsulamento ai livelli sotto il PL
• Dipendenza dal percorso: Questo valore può dipendere dall'interfaccia e dal percorso
• IPv6: Questa dimensione è maggiore o uguale alla dimensione al PL che risulta in un pacchetto IPv6 da 1280 byte, come specificato in [RFC8200]
• IPv4: Questa dimensione è maggiore o uguale alla dimensione al PL che risulta in un pacchetto IPv4 da 68 byte
  • Nota: I router IPv4 sono tenuti a poter inoltrare un datagramma di 68 byte senza ulteriore frammentazione. Questa è la dimensione combinata di un'intestazione IPv4 e la dimensione minima del frammento di 8 byte. Inoltre, i ricevitori sono tenuti a poter riassemblare datagrammi frammentati di almeno 576 byte, come indicato nella sezione 3.3.3 di [RFC1122]

MAX_PLPMTU

• Definizione: La dimensione PLPMTU più grande
• Limitazione: Deve essere minore o uguale alla dimensione massima del pacchetto PL che può essere inviato sull'interfaccia in uscita (vincolata dall'MTU dell'interfaccia locale)
• Considerazione: Dovrebbe anche essere minore della dimensione massima del pacchetto PL che l'endpoint remoto può ricevere (vincolato da EMTU_R) quando questo è noto
• Limitazione di progettazione: Può essere limitata dal design o dalla configurazione del PL in uso
• Limitazione dell'applicazione: Un'applicazione o un PL PUÒ scegliere un MAX_PLPMTU più piccolo quando non c'è bisogno di inviare pacchetti più grandi di una dimensione specifica

BASE_PLPMTU

• Definizione: Una dimensione configurata che si prevede funzioni per la maggior parte dei percorsi
• Intervallo: Uguale o maggiore di MIN_PLPMTU e minore di MAX_PLPMTU
• Raccomandato: Per la maggior parte dei PL, un BASE_PLPMTU adatto sarà maggiore di 1200 byte
• IPv4: Quando si utilizza IPv4, non c'è una dimensione equivalente attualmente specificata, un BASE_PLPMTU predefinito di 1200 byte è RACCOMANDATO

5.1.3. Variabili

Questo metodo utilizza un insieme di variabili:

PROBED_SIZE

• Definizione: La dimensione del pacchetto di sondaggio corrente come determinato al PL
• Natura: Questo è un valore provvisorio per il PLPMTU, in attesa di conferma

PROBE_COUNT

• Definizione: Un conteggio del numero di pacchetti di sondaggio non riusciti successivi che sono stati inviati
• Reset: Questo viene impostato a zero ogni volta che un pacchetto di sondaggio viene confermato
• Nota: Una certa perdita di sondaggi è prevista durante una ricerca, quindi la perdita di un singolo sondaggio non è un'indicazione di un problema PMTU

Diagramma di relazione della dimensione del pacchetto

MAX_PLPMTU ────────┐
                   │
                   ↓
PROBED_SIZE ───────┤ (In sondaggio)
                   │
                   ↓
PLPMTU ────────────┤ (Attualmente utilizzato)
                   │
                   ↓
BASE_PLPMTU ───────┤ (Baseline)
                   │
                   ↓
MIN_PLPMTU ────────┘ (Minimo)

Il diagramma sopra illustra la relazione tra le costanti e le variabili della dimensione del pacchetto quando l'algoritmo DPLPMTUD esegue il sondaggio del percorso per aumentare la dimensione PLPMTU. Sono stati inviati pacchetti di sondaggio della dimensione PROBED_SIZE. Una volta confermati, il PLPMTU verrà aumentato a PROBED_SIZE, consentendo all'algoritmo DPLPMTUD di aumentare ulteriormente PROBED_SIZE, muovendosi verso l'invio di pacchetti di sondaggio della dimensione PMTU effettiva.

5.1.4. Panoramica delle fasi DPLPMTUD

Questa sezione fornisce una visione informativa di alto livello del metodo DPLPMTUD descrivendo il movimento del metodo attraverso diverse fasi operative. Maggiori dettagli possono essere trovati nella macchina a stati (Sezione 5.2).

Diagramma di flusso delle fasi DPLPMTUD

Iniziale → Fase base → Fase di ricerca → Fase di ricerca completa
  ↓                                      ↑
  └──────→ Fase di errore ←──────────────┘

Fase base

• Scopo: La fase base utilizza pacchetti della dimensione BASE_PLPMTU per confermare la connettività al peer remoto
• Conferma della connessione: Per un PL orientato alla connessione, la conferma della connessione è implicita (può essere eseguita nell'handshake della connessione PL). Un PL senza connessione invia pacchetti di sondaggio e utilizza la conferma di questo pacchetto di sondaggio per confermare che il peer remoto è raggiungibile
• Conferma PLPMTU: Il mittente conferma anche che il percorso di rete supporta BASE_PLPMTU. Questo può essere raggiunto utilizzando meccanismi PL (ad esempio, utilizzando un pacchetto di handshake della dimensione BASE_PLPMTU) o inviando un pacchetto di sondaggio della dimensione BASE_PLPMTU e confermando la ricezione di quel pacchetto di sondaggio
• Tempistica del sondaggio: Un pacchetto di sondaggio della dimensione BASE_PLPMTU può essere inviato immediatamente all'ingresso nella fase base (dopo il controllo della connessione). Un PL che non desidera supportare percorsi con un PLPMTU inferiore a BASE_PLPMTU può semplificare questa fase in un singolo passaggio eseguendo il controllo della connessione utilizzando un sondaggio della dimensione BASE_PLPMTU
• Successo: Una volta confermato, DPLPMTUD entra nella fase di ricerca
• Fallimento: Se la fase base non riesce a confermare BASE_PLPMTU, DPLPMTUD entra nella fase di errore

Fase di ricerca

• Scopo: La fase di ricerca utilizza un algoritmo di ricerca per inviare pacchetti di sondaggio per cercare di aumentare il PLPMTU
• Terminazione: L'algoritmo si conclude entrando nella fase di ricerca completa quando viene trovato un PLPMTU appropriato
• Risposta PTB: Il PL può rispondere ai messaggi PTB utilizzando messaggi PTB per avanzare o terminare la ricerca, vedere Sezione 4.6

Fase di ricerca completa

• Stato: La fase di ricerca completa viene raggiunta quando il PLPMTU è supportato su un percorso di rete
• Conferma periodica: Il PL può utilizzare il CONFIRMATION_TIMER per ripetere periodicamente i pacchetti di sondaggio della dimensione PLPMTU corrente
• Rilevamento del buco nero: Se il mittente non può confermare la raggiungibilità (ad esempio, se il CONFIRMATION_TIMER scade) o il PL segnala una mancanza di raggiungibilità, viene rilevato un buco nero e DPLPMTUD entra nella fase base
• Ricerca periodica: Il PMTU_RAISE_TIMER viene utilizzato per riprendere periodicamente la fase di ricerca per scoprire se il PLPMTU può essere aumentato

Fase di errore

• Trigger: La fase di errore viene raggiunta quando le informazioni PLPMTU per un percorso sono contraddittorie o non valide (ad esempio, non possono supportare BASE_PLPMTU), il che impedisce a DPLPMTUD di continuare e riduce il PLPMTU
• Mitigazione: Questo stato implementa un metodo per mitigare le oscillazioni nel motore degli eventi di stato. Segnala un valore MPS conservativo ai livelli superiori tramite il PL
• Uscita: Questo stato viene abbandonato quando i pacchetti di sondaggio non rilevano più un errore. Il mittente PL entra quindi nello stato di ricerca

Robustezza: Un metodo che si limita a ridurre il PLPMTU a una dimensione appropriata è sufficiente per garantire un funzionamento affidabile, ma potrebbe essere molto inefficiente quando il PMTU effettivo cambia o quando il metodo (per qualsiasi motivo) fa una scelta non ottimale per il PLPMTU.

Implementazione completa: Un'implementazione completa di DPLPMTUD fornisce un algoritmo che consente a un mittente DPLPMTUD di aumentare il PLPMTU a seguito di cambiamenti nelle caratteristiche del percorso, ad esempio quando un collegamento viene riconfigurato con un MTU più grande, o quando c'è un cambiamento nell'insieme dei collegamenti attraversati da un flusso end-to-end (ad esempio, dopo una decisione di failover di routing o percorso).

5.2. Macchina a stati

La macchina a stati per DPLPMTUD è rappresentata di seguito. Se è supportato il multipercorso o il multihoming, è necessaria una macchina a stati per ogni percorso.

Nota: Per chiarezza, il diagramma non mostra tutte le transizioni.

Diagramma della macchina a stati

        [DISABLED]
            ↓ ↑
      Connessione stabilita/Persa
            ↓ ↑
         [BASE] ←──────────────┐
            ↓                   │
        Successo del sondaggio Rilevamento del buco nero
            ↓                   │
       [SEARCHING] ─────────────┤
            ↓                   │
      Sondaggio completo/Fallito│
            ↓                   │
    [SEARCH_COMPLETE] ──────────┘
            ↑ ↓
      Aumento periodico/Rilevamento del buco nero

        [ERROR]
      (Gestione degli errori)

Definizioni degli stati

DISABLED

• Stato iniziale: Lo stato iniziale prima dell'inizio del sondaggio
• Condizione di ingresso: Raggiunto da qualsiasi altro stato quando il PL indica una perdita di connettività
• Condizione di uscita: Uscita da questo stato una volta che il PL indica la connettività al PL remoto
• Transizione: Quando si transita allo stato BASE, un pacchetto di sondaggio della dimensione BASE_PLPMTU può essere inviato immediatamente

BASE

• Scopo: Utilizzato per confermare che il percorso di rete supporta la dimensione BASE_PLPMTU, destinato a consentire a un'applicazione di continuare a funzionare quando il PMTU effettivo è temporaneamente ridotto. Cerca anche di evitare che un mittente che utilizza DPLPMTUD non sappia che i pacchetti non vengono consegnati a causa di un buco nero di pacchetti o ICMP per un periodo prolungato durante il quale sta cercando un PLPMTU più grande
• All'ingresso: PROBED_SIZE è impostato sulla dimensione BASE_PLPMTU e PROBE_COUNT è impostato a zero
• Sondaggio: Ogni volta che viene inviato un pacchetto di sondaggio, viene avviato il PROBE_TIMER
• Uscita riuscita: Lo stato viene abbandonato quando un pacchetto di sondaggio viene confermato, il mittente PL entra nello stato SEARCHING
• Uscita per fallimento: Lo stato viene anche abbandonato quando PROBE_COUNT raggiunge MAX_PROBES o viene ricevuto un messaggio PTB validato. Ciò fa sì che il mittente PL entri nello stato ERROR

SEARCHING

• Stato principale: Questo è lo stato di sondaggio principale
• Condizione di ingresso: Raggiunto quando un sondaggio di BASE_PLPMTU si completa
• Sondaggio riuscito: Ogni volta che un pacchetto di sondaggio viene confermato, PROBE_COUNT viene impostato a zero, PLPMTU viene impostato su PROBED_SIZE e PROBED_SIZE viene quindi aumentato utilizzando l'algoritmo di ricerca (come descritto nella Sezione 5.3)
• Fallimento del sondaggio: Quando un pacchetto di sondaggio viene inviato senza essere confermato entro il periodo PROBE_TIMER, PROBE_COUNT viene incrementato e viene trasmesso un nuovo sondaggio
• Condizione di uscita: Uscita quando PROBE_COUNT raggiunge MAX_PROBES per entrare in SEARCH_COMPLETE, viene ricevuto un PTB validato corrispondente all'ultima dimensione del sondaggio riuscito (PL_PTB_SIZE = PLPMTU), o un sondaggio della dimensione MAX_PLPMTU viene confermato (PLPMTU = MAX_PLPMTU)
• Rilevamento del buco nero: Quando viene rilevato un buco nero mentre si è nello stato SEARCHING, ciò fa sì che il mittente PL entri nello stato BASE

SEARCH_COMPLETE

• Flag di completamento: Indica che la ricerca è completata. Questo è lo stato di manutenzione normale dove il PL non sta sondando per aggiornare il PLPMTU
• Durata: DPLPMTUD rimane in questo stato fino a quando scade il PMTU_RAISE_TIMER o viene rilevato un buco nero
• PL non confermato: Quando DPLPMTUD utilizza un PL non confermato ed è nello stato SEARCH_COMPLETE, il CONFIRMATION_TIMER reimposta periodicamente PROBE_COUNT e pianifica un pacchetto di sondaggio della dimensione PLPMTU. Se MAX_PROBES pacchetti di sondaggio consecutivi della dimensione PLPMTU non vengono confermati, il metodo entra nello stato BASE
• PL confermato: Quando viene utilizzato con un PL confermato (ad esempio, SCTP), DPLPMTUD NON DOVREBBE continuare a generare sondaggi PLPMTU in questo stato

ERROR

• Situazione di fallimento: Indica che il percorso di rete non è noto per supportare un PLPMTU di almeno la dimensione BASE_PLPMTU o ci sono informazioni contraddittorie sul percorso di rete che potrebbero altrimenti far oscillare eccessivamente il segnale MPS ai livelli superiori
• Mitigazione dell'oscillazione: Questo stato implementa un metodo per mitigare le oscillazioni nel motore degli eventi di stato
• Valore conservativo: Segnala un valore MPS conservativo ai livelli superiori tramite il PL
• Uscita: Questo stato viene abbandonato quando i pacchetti di sondaggio non rilevano più un errore. Il mittente PL entra quindi nello stato SEARCHING
• Frammentazione dell'endpoint: L'implementazione consente di abilitare la frammentazione dell'endpoint se DPLPMTUD non può validare MIN_PLPMTU entro i sondaggi PROBE_COUNT
• Disabilitazione: Se DPLPMTUD non può validare MIN_PLPMTU, le implementazioni passeranno allo stato DISABLED
• Nota: MIN_PLPMTU può essere lo stesso di BASE_PLPMTU, semplificando il funzionamento di questo stato

5.3. Ricerca per aumentare il PLPMTU

Questa sezione descrive gli algoritmi utilizzati da DPLPMTUD per cercare un PLPMTU più grande.

5.3.1. Sondaggio per un PLPMTU più grande

Le implementazioni utilizzano un algoritmo di ricerca nell'intervallo di ricerca per determinare se il percorso di rete può supportare un PLPMTU più grande.

Il metodo scopre l'intervallo di ricerca confermando il PLPMTU minimo e quindi utilizzando il sondaggio per selezionare un PROBED_SIZE minore o uguale a MAX_PLPMTU. Il MAX_PLPMTU è il minimo dell'MTU locale e EMTU_R (quando appreso dall'endpoint remoto). MAX_PLPMTU PUÒ essere ridotto da un'applicazione che imposta un massimo per la dimensione dei datagrammi che invierà.

Quando viene inviato il primo sondaggio di dimensione maggiore o uguale a PLPMTU, PROBE_COUNT viene inizializzato a zero. Ogni pacchetto di sondaggio inviato con successo al peer remoto viene confermato da una conferma dal PL (vedere Sezione 4.1).

Ogni volta che un pacchetto di sondaggio viene inviato alla destinazione, viene avviato il PROBE_TIMER. Il timer viene annullato quando il PL riceve una conferma che il pacchetto di sondaggio è stato inviato con successo attraverso il percorso (Sezione 4.1). Questo conferma che PROBED_SIZE è supportato e il valore PROBED_SIZE viene quindi assegnato a PLPMTU. L'algoritmo di ricerca può continuare a inviare sondaggi successivi di dimensioni crescenti.

Se il timer scade prima che un pacchetto di sondaggio venga confermato, il sondaggio non è riuscito a confermare PROBED_SIZE. Ogni volta che il PROBE_TIMER scade, PROBE_COUNT viene incrementato, il PROBE_TIMER viene reinizializzato e può essere inviato un nuovo sondaggio della stessa dimensione o di qualsiasi altra dimensione (come determinato dall'algoritmo di ricerca). È configurato un numero massimo di sondaggi non riusciti consecutivi (MAX_PROBES). Se il valore di PROBE_COUNT raggiunge MAX_PROBES, il sondaggio si fermerà e il mittente PL entra nello stato SEARCH_COMPLETE.

5.3.2. Selezione delle dimensioni del sondaggio

L'algoritmo di ricerca determina l'aumento minimo utile nel PLPMTU. Non è costruttivo per il mittente PL tentare di sondare tutte le dimensioni. Ciò imporrebbe un carico non necessario sul percorso. Le implementazioni DOVREBBERO selezionare un insieme di dimensioni di pacchetti di sondaggio per massimizzare il guadagno in PLPMTU da ogni passaggio di ricerca.

Le implementazioni possono ottimizzare la procedura di ricerca selezionando dimensioni di passaggio da una tabella di dimensioni PMTU comuni. Quando si seleziona una dimensione successiva appropriata da ricercare, gli implementatori dovrebbero anche considerare le dimensioni MPS comuni che le applicazioni potrebbero cercare di utilizzare e che potrebbero esserci dimensioni MTU comuni in uso nella rete.

5.3.3. Resilienza alle informazioni sul percorso incoerenti

La decisione di aumentare il PLPMTU deve essere resiliente alla possibilità di incoerenza nelle informazioni che sono state apprese sul percorso di rete. L'incoerenza nel percorso può sorgere quando i pacchetti di sondaggio vengono persi per motivi diversi dalla dimensione del pacchetto (cioè, perdita non correlata alla dimensione) o a causa di frequenti cambiamenti di percorso. Frequenti cambiamenti di percorso potrebbero risultare da un "jitter" inaspettato -- dove alcuni pacchetti di un flusso vengono consegnati lungo un percorso, ma altri pacchetti seguono un percorso diverso con proprietà diverse.

Un mittente PL è in grado di rilevare l'incoerenza da una sequenza di sondaggi PLPMTU confermati o da una sequenza di messaggi PTB che riceve. Un mittente PL può utilizzare un pattern di ricerca alternativo quando rileva informazioni sul percorso incoerenti, uno che limita l'MPS fornito a un valore più piccolo per un periodo di tempo. Questo evita una perdita di pacchetti non necessaria.

5.4. Robustezza ai percorsi incoerenti

Alcuni percorsi potrebbero non essere in grado di sostenere pacchetti della dimensione BASE_PLPMTU. Lo stato di errore può essere implementato per fornire robustezza per tali percorsi. Questo consente un ripiego a un PLPMTU più piccolo di quanto desiderato piuttosto che subire un fallimento della connessione. Questo può utilizzare metodi come la frammentazione IP dell'endpoint per consentire al mittente PL di comunicare utilizzando pacchetti più piccoli di BASE_PLPMTU.

Riepilogo dell'algoritmo

Elementi chiave dell'algoritmo DPLPMTUD:

1. Inizio conservativo: Iniziare da BASE_PLPMTU
2. Sondaggio progressivo: Aumentare gradualmente la dimensione del sondaggio
3. Meccanismo di conferma: Verificare che ogni dimensione sia disponibile
4. Rilevamento del buco nero: Rispondere rapidamente ai problemi del percorso
5. Manutenzione periodica: Mantenere il PLPMTU aggiornato
6. Recupero degli errori: Gestire situazioni eccezionali

Questi meccanismi insieme garantiscono che DPLPMTUD possa funzionare in modo affidabile ed efficiente in varie condizioni di rete.