6. Common Packetization Properties (Proprietà comuni di pacchettizzazione)
Questa sezione descrive le proprietà e caratteristiche generali del livello di pacchettizzazione necessarie per implementare PLPMTUD. Descrive anche alcuni problemi di implementazione comuni a tutti i livelli di pacchettizzazione.
6.1. Meccanismo per rilevare le perdite
È importante che il livello di pacchettizzazione abbia un meccanismo tempestivo e robusto per rilevare e segnalare le perdite. PLPMTUD effettua aggiustamenti MTU sulla base delle perdite rilevate. Qualsiasi ritardo o inaccuratezza nella notifica delle perdite è probabile che risulti in decisioni MTU errate o convergenza lenta. È importante che il meccanismo possa distinguere in modo robusto tra la perdita isolata di solo un sondaggio e altre perdite nelle finestre principale e finale del sondaggio.
È meglio se i protocolli di pacchettizzazione usano un meccanismo esplicito di rilevamento delle perdite come un tabellone Selective Acknowledgment (SACK) [RFC3517] o vettore ACK [RFC4340] per distinguere le perdite reali dai dati riordinati, sebbene meccanismi impliciti come il conteggio degli acknowledgment duplicati in stile TCP Reno siano sufficienti.
PLPMTUD può anche essere implementato in protocolli che si affidano ai timeout come meccanismo principale per il recupero delle perdite; tuttavia, i timeout NON DOVREBBERO (SHOULD NOT) essere usati come meccanismo principale di indicazione delle perdite a meno che non ci siano altre alternative.
6.2. Generazione di sondaggi
Ci sono diversi modi possibili per alterare i livelli di pacchettizzazione per generare sondaggi. Le diverse tecniche comportano diversi sovraccarichi in tre aree: difficoltà nel generare il pacchetto di sondaggio (in termini di complessità di implementazione del livello di pacchettizzazione e movimento extra di dati), possibile capacità di rete aggiuntiva consumata dai sondaggi, e il sovraccarico di recupero dai sondaggi falliti (sia sovraccarichi di rete che di protocollo).
Alcuni protocolli potrebbero essere estesi per permettere padding arbitrario con dati fittizi. Questo semplifica notevolmente l'implementazione perché il sondaggio può essere eseguito senza partecipazione dagli strati superiori e se il sondaggio fallisce, i dati mancanti (la "lacuna del sondaggio") sono assicurati di adattarsi all'attuale MTU quando vengono ritrasmessi.
Molti protocolli del livello di pacchettizzazione possono trasportare messaggi di controllo puri (senza dati da strati di protocollo superiori), che possono essere riempiti a lunghezze arbitrarie. Ad esempio, il chunk PAD SCTP può essere usato in questo modo (vedi sezione 10.2). Questo approccio ha il vantaggio che nulla deve essere ritrasmesso se il sondaggio viene perso.
Queste tecniche non funzionano per TCP, perché non c'è un campo di lunghezza separato o altro meccanismo per differenziare il padding dai dati del payload reali. Con TCP l'unico approccio è inviare dati del payload aggiuntivi in un segmento sovradimensionato.
In alcuni casi, potrebbe non esserci meccanismi ragionevoli per generare sondaggi all'interno del protocollo del livello di pacchettizzazione stesso. Come ultima risorsa, potrebbe essere possibile affidarsi a un protocollo ausiliario, come ICMP ECHO ("ping"), per inviare pacchetti di sondaggio.