6. Considerazioni sulle prestazioni
- Considerazioni sulle prestazioni
Il traffico a raffica può spesso portare a perdite di pacchetti temporalmente correlate; a sua volta, ciò può portare a risposte non ottimali dai controller di congestione nei protocolli in esecuzione su UDP. Per evitare ciò, i proxy UDP DOVREBBERO sforzarsi di evitare di aumentare la rafficità del traffico UDP; NON DOVREBBERO accodare i pacchetti per aumentare il batching.
Quando il protocollo in esecuzione su UDP che viene proxyato utilizza il controllo della congestione (ad esempio, [QUIC]), il traffico proxyato incorrerà in almeno due controller di congestione nidificati. La connessione HTTP sottostante NON DEVE disabilitare il controllo della congestione a meno che non abbia un modo fuori banda per sapere con assoluta certezza che il traffico interno è controllato dalla congestione.
Se un client o un proxy UDP con una connessione contenente un flusso di richiesta di proxying UDP disabilita il controllo della congestione, NON DEVE segnalare il supporto Explicit Congestion Notification (ECN) [ECN] su quella connessione. Cioè, DEVE contrassegnare tutte le intestazioni IP con il punto di codice Not-ECT. PUÒ continuare a segnalare feedback ECN tramite frame QUIC ACK_ECN o il bit TCP ECE, poiché il peer potrebbe non aver disabilitato il controllo della congestione.
Quando il protocollo in esecuzione su UDP che viene proxyato utilizza il recupero delle perdite (ad esempio, [QUIC]) e la connessione HTTP sottostante viene eseguita su TCP, il traffico proxyato incorrerà in almeno due meccanismi di recupero delle perdite nidificati. Ciò può ridurre le prestazioni poiché entrambi possono a volte ritrasmettere indipendentemente gli stessi dati. Per evitare ciò, il proxying UDP DOVREBBE essere eseguito su HTTP/3 per consentire di sfruttare il frame QUIC DATAGRAM.
6.1. Considerazioni sull'MTU
Quando si utilizza HTTP/3 con l'estensione datagramma QUIC [QUIC-DGRAM], i payload UDP vengono trasmessi in frame QUIC DATAGRAM. Poiché questi non possono essere frammentati, possono trasportare solo payload fino a una determinata lunghezza determinata dalla configurazione della connessione QUIC e dal Path MTU (PMTU). Se un proxy UDP sta utilizzando frame QUIC DATAGRAM e riceve un payload UDP dalla destinazione che non rientra in un frame QUIC DATAGRAM, il proxy UDP NON DOVREBBE inviare il payload UDP in una capsula DATAGRAM, poiché ciò vanifica la caratteristica di inaffidabilità end-to-end da cui dipendono metodi come Datagram Packetization Layer PMTU Discovery (DPLPMTUD) [DPLPMTUD]. In questo scenario, il proxy UDP DOVREBBE scartare il payload UDP e inviare un messaggio ICMP Packet Too Big alla destinazione; vedere la Sezione 3.2 di [ICMP6].
6.2. Tunneling dei contrassegni ECN
Il proxying UDP non crea un tunnel IP-in-IP, quindi la guida in [ECN-TUNNEL] sul trasferimento dei contrassegni ECN tra intestazioni IP interne ed esterne non si applica. Non c'è un'intestazione IP interna nei tunnel di proxying UDP.
In questa specifica, si noti che i client di proxying UDP non hanno la capacità di controllare i punti di codice ECN sui pacchetti UDP che il proxy UDP invia alla destinazione, né i proxy UDP possono comunicare i contrassegni di ciascun pacchetto UDP dalla destinazione al proxy UDP.
Un proxy UDP DEVE ignorare i bit ECN nell'intestazione IP dei pacchetti UDP ricevuti dalla destinazione e DEVE impostare i bit ECN su Not-ECT sui pacchetti UDP che invia alla destinazione. Questi non si riferiscono in alcun modo ai contrassegni ECN dei pacchetti inviati tra client e proxy UDP.