10. Considerazioni sulle prestazioni
Il traffico a raffica può spesso portare a perdite di pacchetti correlate temporalmente; a sua volta, questo può portare a risposte non ottimali dai controller di congestione nei protocolli che vengono eseguiti all'interno del tunnel. Per evitare ciò, gli endpoint di proxying IP DOVREBBERO sforzarsi di evitare di aumentare la raffichezza del traffico IP; NON DOVREBBERO accodare i pacchetti al fine di aumentare il batching oltre la quantità minima richiesta per sfruttare gli offload hardware.
Quando il protocollo in esecuzione all'interno del tunnel utilizza il controllo della congestione (ad esempio, [TCP] o [QUIC]), il traffico proxy incorrerà in almeno due controller di congestione annidati. Quando i pacchetti tunnelizzati vengono inviati utilizzando frame QUIC DATAGRAM, la connessione HTTP esterna PUÒ disabilitare il controllo della congestione per quei pacchetti che contengono solo frame QUIC DATAGRAM che incapsulano pacchetti IP. Gli implementatori trarranno vantaggio dalla lettura della guida nella Sezione 3.1.11 di UDP-USAGE.
Quando il protocollo in esecuzione all'interno del tunnel utilizza il recupero delle perdite (ad esempio, [TCP] o [QUIC]) e la connessione HTTP esterna viene eseguita su TCP, il traffico proxy incorrerà in almeno due meccanismi di recupero delle perdite annidati. Ciò può ridurre le prestazioni, poiché entrambi possono talvolta ritrasmettere indipendentemente gli stessi dati. Per evitare ciò, il proxying IP DOVREBBE essere eseguito su HTTP/3 per consentire di sfruttare il frame QUIC DATAGRAM.
10.1. Considerazioni sull'MTU
Quando si utilizza HTTP/3 con l'estensione QUIC Datagram [DGRAM], i pacchetti IP vengono trasmessi in frame QUIC DATAGRAM. Poiché questi frame non possono essere frammentati, possono trasportare solo pacchetti fino a una data lunghezza determinata dalla configurazione della connessione QUIC e dal Path MTU (PMTU). Se un endpoint sta utilizzando frame QUIC DATAGRAM e tenta di instradare un pacchetto IP attraverso il tunnel che non si adatta all'interno di un frame QUIC DATAGRAM, il proxy IP NON DOVREBBE inviare il pacchetto IP 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, l'endpoint DOVREBBE scartare il pacchetto IP e inviare un messaggio ICMP Packet Too Big al mittente del pacchetto scartato; vedere Sezione 3.2 di ICMPv6.
10.2. Considerazioni sull'ECN
Se un endpoint di proxying IP con una connessione contenente un flusso di richiesta di proxying IP disabilita il controllo della congestione, non può segnalare il supporto Explicit Congestion Notification (ECN) [ECN] su quella connessione esterna. Cioè, il mittente QUIC DEVE contrassegnare tutte le intestazioni IP con il punto di codice Not ECN-Capable Transport (Not-ECT) per i pacchetti QUIC che sono al di fuori del controllo della congestione. L'endpoint può comunque segnalare il feedback ECN tramite frame QUIC ACK_ECN o il bit TCP ECN-Echo (ECE), poiché il peer potrebbe non aver disabilitato il controllo della congestione.
Viceversa, se il controllo della congestione non è disabilitato sulla connessione esterna, la guida in [ECN-TUNNEL] sul trasferimento dei contrassegni ECN tra intestazioni IP interne ed esterne non si applica perché la connessione esterna reagirà correttamente alle notifiche di congestione se utilizza ECN. Il traffico interno può anche utilizzare ECN, indipendentemente dal fatto che sia in uso sulla connessione esterna.
10.3. Considerazioni sui servizi differenziati
I pacchetti IP tunnelizzati possono avere Differentiated Services Code Points (DSCP) [DSCP] impostati nel campo dell'intestazione IP della classe di traffico per richiedere un particolare comportamento per-hop. Se un endpoint di proxying IP è configurato come parte di un dominio Differentiated Services, PUÒ implementare la differenziazione del traffico basata su questi contrassegni. Tuttavia, l'uso di HTTP può limitare le possibilità di trattamento differenziato dei pacchetti IP tunnelizzati sul percorso tra gli endpoint di proxying IP.
Quando una connessione HTTP è controllata dalla congestione, contrassegnare i pacchetti con diversi DSCP può portare al riordino tra di essi, e ciò può a sua volta portare il controller di congestione della connessione di trasporto sottostante a prestazioni scadenti. Se i pacchetti tunnelizzati sono soggetti al controllo della congestione dalla connessione esterna, devono evitare di trasportare contrassegni DSCP che non sono equivalenti nel comportamento di inoltro per prevenire questa situazione. In questo scenario, l'endpoint di proxying IP NON DEVE copiare il campo DSCP dall'intestazione IP interna all'intestazione IP esterna del pacchetto che trasporta questo pacchetto. Invece, un'applicazione dovrebbe utilizzare connessioni separate al proxy, una per ogni DSCP. Si noti che questo documento non definisce un modo per le richieste di limitare l'ambito a particolari valori DSCP; tale supporto è lasciato a estensioni future.
Se i pacchetti tunnelizzati utilizzano datagrammi QUIC e non sono soggetti al controllo della congestione dalla connessione esterna, gli endpoint di proxying IP POSSONO tradurre il valore del campo DSCP dal traffico tunnelizzato all'intestazione IP esterna. Gli endpoint di proxying IP NON DEVONO unire più pacchetti interni nello stesso pacchetto esterno a meno che non abbiano lo stesso contrassegno DSCP o una classe di traffico equivalente. Si noti che la capacità di tradurre i valori DSCP dipende dal fatto che l'ingresso e l'uscita del tunnel appartengano allo stesso dominio Differentiated Services o meno.