3. Funzionalità richieste per fornire PLPMTUD per datagramma
I principi espressi in [RFC4821] si applicano all'uso della tecnica con qualsiasi PL. Il PLPMTUD TCP è stato definito utilizzando meccanismi di protocollo TCP standard. A differenza di TCP, un PL di datagramma richiede meccanismi e considerazioni aggiuntivi per implementare PLPMTUD.
Requisiti per PLPMTUD di datagramma
1. Gestione del PLPMTU
Per i PL di datagramma, il PLPMTU è gestito da DPLPMTUD. Un PL NON DEVE inviare un datagramma (diverso da un pacchetto di sondaggio) con una dimensione al livello PL maggiore del PLPMTU corrente.
2. Pacchetti di sondaggio
L'interfaccia di rete al di sotto del PL è RICHIESTA per fornire un modo per trasmettere un pacchetto di sondaggio che sia più grande del PLPMTU.
- IPv4: Un pacchetto di sondaggio DEVE essere inviato con il bit Don't Fragment (DF) impostato nell'intestazione IP e senza frammentazione dell'endpoint del livello di rete.
- IPv6: Un pacchetto di sondaggio viene sempre inviato senza frammentazione della sorgente (come specificato in [RFC8201] Sezione 5.4).
3. Feedback di ricezione
L'endpoint PL di destinazione è RICHIESTO per fornire un metodo di feedback che indichi al mittente DPLPMTUD quando un pacchetto di sondaggio è stato ricevuto dall'endpoint PL di destinazione. Sezione 6 fornisce esempi di come un PL può fornire questa conferma dei pacchetti di sondaggio ricevuti.
4. Recupero dalla perdita di sondaggio
È RACCOMANDATO utilizzare pacchetti di sondaggio che non trasportino dati utente che richiederebbero ritrasmissione in caso di perdita. La maggior parte dei trasporti di datagramma lo consente.
Se un pacchetto di sondaggio contiene dati utente che richiedono ritrasmissione in caso di perdita:
- Il PL (o i livelli superiori) è RICHIESTO per organizzare qualsiasi ritrasmissione e/o riparazione di qualsiasi perdita risultante.
- Il PL è RICHIESTO di essere robusto nel caso in cui i pacchetti di sondaggio vengano persi per altri motivi (inclusi errori di trasmissione del collegamento, congestione).
5. Parametri PMTU
- Un mittente DPLPMTUD è RACCOMANDATO per utilizzare informazioni sulla dimensione massima del pacchetto che può essere trasmesso dal mittente sul collegamento locale (ad esempio, il MTU del collegamento locale).
- Un mittente PL PUÒ utilizzare informazioni simili sulla dimensione massima del pacchetto del livello di rete che un ricevitore può accettare quando questo viene fornito (si noti che questo potrebbe essere inferiore a EMTU_R).
Questo evita che le implementazioni tentino di inviare pacchetti di sondaggio che non possono essere trasferiti dal collegamento locale. Un valore troppo alto potrebbe ridurre l'efficienza dell'algoritmo di ricerca. Alcune applicazioni hanno anche una dimensione massima dell'unità dati del protocollo di trasporto (PDU), nel qual caso non c'è beneficio nel sondare una dimensione maggiore di questa (a meno che un trasporto non consenta il multiplexing di PDU di più applicazioni nello stesso datagramma).
6. Elaborazione dei messaggi PTB
- Un mittente DPLPMTUD PUÒ opzionalmente utilizzare i messaggi PTB ricevuti dal livello di rete per aiutare a identificare quando un percorso di rete non supporta la dimensione corrente del pacchetto di sondaggio.
- Qualsiasi messaggio PTB ricevuto DEVE essere validato prima di essere utilizzato per aggiornare le informazioni di scoperta PLPMTU [RFC8201].
Questa validazione conferma che il messaggio PTB è stato inviato in risposta a un pacchetto originato dall'endpoint PL che esegue DPLPMTUD. Questa validazione deve essere eseguita prima che il metodo di scoperta PLPMTU reagisca al messaggio PTB.
- Un messaggio PTB NON DEVE essere utilizzato per aumentare il PLPMTU [RFC8201].
- Un messaggio PTB potrebbe attivare un sondaggio per testare un PLPMTU più grande.
Un PTB_SIZE valido viene convertito in un PL_PTB_SIZE prima di essere utilizzato nella macchina a stati DPLPMTUD. Un PL_PTB_SIZE maggiore di quello attualmente sondato DOVREBBE essere ignorato (Questo messaggio PTB dovrebbe essere scartato senza ulteriore elaborazione ma potrebbe essere utilizzato come input che abilita una modalità di resilienza).
7. Sondaggio e controllo della congestione
- Un PL PUÒ utilizzare un controller di congestione per decidere quando inviare un pacchetto di sondaggio.
Se la trasmissione di pacchetti di sondaggio è limitata dal controller di congestione, questo potrebbe comportare che la trasmissione di pacchetti di sondaggio venga ritardata o sospesa durante la congestione.
- Quando la trasmissione di pacchetti di sondaggio non è controllata dal controller di congestione, l'intervallo tra i pacchetti di sondaggio DEVE essere almeno un RTT.
- La perdita di un pacchetto di sondaggio NON DOVREBBE essere trattata come un'indicazione di congestione.
- La perdita di un pacchetto di sondaggio NON DOVREBBE attivare una reazione di controllo della congestione [RFC4821].
Questo perché ciò potrebbe risultare in una riduzione non necessaria del tasso di invio.
- Un aggiornamento al PLPMTU (o MPS) NON DEVE aumentare la finestra di congestione misurata in byte [RFC4821].
Pertanto, un aumento della dimensione del pacchetto non causa un aumento del tasso di dati in byte al secondo. Un PL che mantiene la finestra di congestione in termini di limite al numero di pacchetti di dimensione fissa in sospeso DOVREBBE adattare questo limite per compensare la dimensione dei pacchetti effettivi.
La trasmissione di pacchetti di sondaggio può interagire con il funzionamento di un PL che esegue la mitigazione del burst o il pacing, e il PL potrebbe aver bisogno che la trasmissione di pacchetti di sondaggio sia regolata da questi metodi.
8. Sondaggio e controllo del flusso
Il controllo del flusso al livello PL riguarda il flusso end-to-end di dati utilizzando il servizio PL. Il controllo del flusso NON DOVREBBE applicarsi a DPLPMTUD quando i pacchetti di sondaggio utilizzano un design che non trasporta dati utente all'applicazione remota.
9. Stato PLPMTU condiviso
Il valore PMTU calcolato dal PLPMTU PUÒ anche essere memorizzato con la voce corrispondente associata alla destinazione nella cache del livello IP e utilizzato da altre istanze PL.
La specifica di PLPMTUD [RFC4821] afferma: «Se PLPMTUD aggiorna il MTU per un percorso particolare, tutte le sessioni del livello di pacchettizzazione che condividono la rappresentazione del percorso (come descritto nella Sezione 5.2) DOVREBBERO essere notificate per utilizzare il nuovo MTU». Tali metodi DEVONO essere robusti rispetto all'ampia varietà di comportamenti di inoltro di rete sottostanti. [RFC8201] Sezione 5.2 fornisce indicazioni sul caching delle informazioni PMTU e anche sulla relazione con le etichette di flusso IPv6.
Principi di progettazione
Oltre ai requisiti sopra, i seguenti principi sono dichiarati per la progettazione di un metodo DPLPMTUD:
1. Segmentazione dei dati
- Un PL PUÒ essere progettato per segmentare blocchi di dati più grandi del MPS in più datagrammi.
Tuttavia, non tutti i PL di datagramma supportano la segmentazione dei blocchi di dati.
- È RACCOMANDATO che i metodi evitino di forzare un'applicazione a utilizzare un MPS arbitrariamente piccolo per la trasmissione mentre il metodo sta cercando il PLPMTU attualmente supportato.
Un MPS ridotto può influire negativamente sulle prestazioni di un'applicazione.
2. Primitiva MPS
Per assistere le applicazioni nella scelta di una dimensione di blocco di dati appropriata, è RACCOMANDATO che il PL fornisca una primitiva che restituisca il MPS derivato dal PLPMTU al livello superiore che utilizza il PL. Il valore del MPS può cambiare a seguito di un cambiamento nel percorso o della perdita di pacchetti di sondaggio.
3. Validazione del percorso
È RACCOMANDATO che i metodi siano robusti rispetto ai cambiamenti di percorso che potrebbero essere avvenuti dall'ultima conferma delle caratteristiche del percorso e alla possibilità di ricevere informazioni di percorso incoerenti.
4. Riordino dei datagrammi
Un metodo è RICHIESTO di essere robusto rispetto alla possibilità che un flusso incontri riordino o che il traffico (inclusi i pacchetti di sondaggio) sia diviso su più di un percorso di rete.
5. Ritardo e duplicazione dei datagrammi
Il meccanismo di feedback è RICHIESTO di essere robusto rispetto alla possibilità che i pacchetti possano essere significativamente ritardati o duplicati lungo un percorso di rete.
6. Quando sondare
È RACCOMANDATO che i metodi determinino se il percorso è cambiato dall'ultima misurazione del percorso. Questo può aiutare a determinare quando sondare di nuovo il percorso.
Considerazioni di implementazione
Quando si implementa DPLPMTUD, considerare:
- Efficienza: Evitare il sondaggio eccessivo che causa overhead di rete
- Robustezza: Gestire varie condizioni di rete e scenari di guasto
- Interoperabilità: Compatibilità con protocolli e implementazioni esistenti
- Prestazioni: Minimizzare l'impatto sulle prestazioni dell'applicazione
Questi requisiti e principi garantiscono che DPLPMTUD possa funzionare in modo affidabile in varie condizioni di rete.