Gestione multicollegamento basata sul protocollo QUIC, inclusi collegamenti satellitari

Negli ultimi anni, il web ha subito un’evoluzione significativa, passando da semplici servizi basati su contenuti HTML a complesse applicazioni multimediali di streaming (sia in diretta che su domanda), interattive e cloud, che generano un traffico dinamico e intenso, rendendo necessario migliorare le prestazioni della rete in termini di maggiore capacità e minore ritardo. Allo stesso tempo, sono stati proposti nuovi protocolli standard che hanno introdotto flessibilità e nuove funzionalità non disponibili in precedenza con i protocolli basati su TCP. Ci riferiamo in particolare alla suite di protocolli QUIC, che è alla base dell’HTTP/3 e che rappresenterà il futuro della comunicazione web.

Grazie ad alcune delle sue caratteristiche innovative, come la creazione di connessioni 0-RTT tramite UDP, il protocollo QUIC può anche essere adattato per la gestione efficiente di collegamenti multipli ed eterogenei. Questo approccio è particolarmente rilevante nel contesto del meccanismo ATSSS (Access Traffic Steering, Switching, and Splitting) recentemente introdotto per le reti 5G, nonché per le architetture PEP (Performance Enhancing Proxy) nelle comunicazioni miste terrestri/satellitari.

Di seguito, dopo una breve introduzione al protocollo QUIC, descriviamo una soluzione di tunneling basata sul protocollo QUIC per consentire un approccio di comunicazione avanzato che sfrutta più collegamenti (sia a livello di accesso che di backhaul di una rete), ciascuno associato a una diversa tecnologia di rete (ad esempio, satellite, WiFi o terrestre) o dominio amministrativo.

Il Protocollo QUIC

QUIC (Quick UDP Internet Connections) è uno stack di protocolli ad ampio raggio, che dovrà essere adottato sia dai browser web che dai server web, aprendo la strada al recente HTTP/3 (che al momento della stesura di questo documento è nelle ultime fasi di standardizzazione). Più specificamente, la specifica HTTP/3 [1] impone esplicitamente l’uso del trasporto QUIC [2] insieme ad altre nuove specifiche correlate.

QUIC si basa su UDP, ma mantiene i concetti di un protocollo “orientato alla connessione” colmando alcune lacune presenti nell’uso di TCP nei precedenti HTTP/2 e HTTP/1.1. Il nuovo stack di protocollo complessivo è riportato nella Figura 1, con a sinistra il classico stack HTTP/2 e a destra il nuovo stack HTTP/3.

Figura 1: HTTP su TCP (a sinistra, HTTP/2), QUIC (a destra, HTTP/3)

Pertanto QUIC:

1. Non è solo un protocollo di trasporto ma include funzioni di congestione, controllo del flusso e recupero degli errori, meccanismi di autenticazione/sicurezza, supporto alla mobilità con una trasmissione di oggetti basata sulle priorità strettamente integrata con i protocolli HTTP e le applicazioni;
2. Non è una nuova versione del protocollo TCP in quanto offre tutte queste funzioni (e molte altre) basandosi esclusivamente sul protocollo di trasporto senza connessione UDP.

Le caratteristiche principali del protocollo QUIC possono essere riassunte nei seguenti punti:

1. Essendo basato su UDP, richiede l’esecuzione di alcune funzionalità TCP quali il controllo della congestione (in realtà una versione rivista del TCP Cubic o BBR [3]), il controllo del flusso e la gestione degli errori (ritrasmissioni, timeout) che nella pratica sono demandati allo strato di applicazione (approccio cross-layer).
2. Uso obbligatorio di HTTP/3 nella versione basata su datagramma per UDP (DTLS)
3. La comunicazione è stata migliorata con l’introduzione del concetto STREAM: la trasmissione è organizzata in STREAM in modo tale che, in caso di perdita di un pacchetto, solo lo STREAM di destinazione sia interessato alle ritrasmissioni, mentre il resto delle informazioni può essere elaborato (evitando il problema di blocco dell’inizio della linea con TCP). Ciò significa che durante lo scaricamento di una pagina web, in caso di problemi sullo STREAM che trasporta un’immagine, il resto della pagina può comunque essere visualizzato e non viene bloccato dai meccanismi di ritrasmissione in ordine del TCP.
4. QUIC è strettamente legato a HTTP/s, con una corrispondenza esplicita degli oggetti HTTP agli STREAM.
5. Introduzione alla trasmissione con codifica di canale con correzione degli errori in avanti (FEC, non mostrata in figura) per collegamenti con perdita di dati, con l’obiettivo di ridurre le ritrasmissioni (si noti che questo aspetto non è disponibile in TCP)
6. Viene accelerata la creazione della connessione introducendo la funzionalità 0-RTT ereditata da TLS1.3: nella maggior parte dei casi, il primo messaggio verrà utilizzato per stabilire la connessione e trasferire contemporaneamente i dati dell’applicazione.
7. Viene introdotto un ID di connessione (CID) che viene trasmesso all’interno della conversazione QUIC per distinguere le diverse relazioni da estremo a estremo. La connessione non è identificata dalle coppie IP/porta a livello di socket. All’interno della stessa connessione è possibile definire diversi STREAM, che trasmettono pacchetti QUIC (QPACK).
8. Poiché il CID viene gestito a livello di applicazione, e non dal socket UDP sottostante, può essere sfruttato per introdurre nuove funzionalità come la migrazione della connessione, con la possibilità di trasferire la connessione QUIC tra reti diverse senza reimpostare la connessione in caso di cambiamento di rete (ad esempio, rebinding NAT) dovuto a configurazioni mobili o multi-homed.

Per maggiori dettagli su QUIC, invitiamo i lettori interessati a consultare le specifiche RFC e le descrizioni disponibili in diversi documenti tecnici su Internet, come ad esempio https://cloudflare-quic.com/

La maggior parte dei dispositivi consente di abilitare l’uso di QUIC come parte di HTTP/3 sia sui browser web desktop (ad esempio Safari, Google Chrome, Firefox) sia come opzione anche negli smartphone, come mostrato nella Figura 2 – Pagina di configurazione avanzata di WebKit.

 

Figura 2: Le funzionalità sperimentali su un dispositivo iOS consentono di abilitare le funzionalità HTTP/3.

Per quanto riguarda il lato server, stiamo assistendo a un costante aumento della sua adozione da parte dei grandi operatori (come Google, Facebook, ecc.).

QUIC Multiverso

QUIC è stato rilasciato da Google nelle fasi iniziali, ma successivamente è stato esaminato dai gruppi di lavoro di IETF per ulteriori sviluppi; pertanto, attualmente sono disponibili due versioni dello stack del protocollo QUIC, che presentano alcune differenze e sono incompatibili nella pratica:

1. Google QUIC (GQUIC)
2. IETF QUIC (IQUIC)

L’IQUIC mira a risolvere alcuni problemi di realizzazione del GQUIC, aprendo le sue specifiche alla più ampia comunità Internet (IETF/RFC) e diventando così la versione di riferimento per HTTP/3. L’IQUIC riporta anche un numero di versione nelle sue intestazioni, che rappresenta la compatibilità con tali specifiche.

Senza approfondire lo studio delle varianti del protocollo QUIC, possiamo evidenziare alcune differenze sostanziali tra le due versioni. Innanzitutto, definiamo il “flusso” come il flusso di pacchetti tra due peer; ipotizziamo che il client (C) sia l’iniziatore della comunicazione e il server (S) sia il punto finale. Pertanto, vengono definite due direzioni: C ⇒ S e S ⇒ C. Di seguito vengono riportate alcune differenze:

Tabella 1: Differenze tra le versioni QUIC

	GQUIC	IQUIC
Connessione	Considera un flusso bidirezionale tra client e server. La connessione è identificata da un unico ID di connessione in entrambe le direzioni. L’ID ha una lunghezza fissa di 8 bit.	Considera un flusso unidirezionale tra client e server. La comunicazione tra i due peer è composta da due connessioni distinte identificate da due ID di connessione univoci, uno per ciascuna direzione (C ⇒ S e S ⇒ C). L’ID ha una dimensione variabile.
Crittografia	Utilizza una propria suite crittografica denominata “QUIC Crypto” QUIC-c [4]	Si basa su TLS 1.3 [5]
Migrazione della connessione	Un peer può accettare un flusso di messaggi identificati dall’ID di connessione (protetto tramite QUIC-c) anche se i parametri IP/UDP sono stati modificati.	Prima di accettare pacchetti in entrata con parametri IP/UDP diversi, è necessario completare una procedura di convalida del percorso. In questo modo: i) viene garantita la reperibilità del collegamento sul percorso; ii) viene verificato il peer (“autenticato” sul nuovo percorso); iii) l’ID della connessione dovrebbe cambiare per preservare la privacy.
Intestazione	Il numero del pacchetto è in chiaro nell’intestazione così come l’ID della connessione.	Il numero del pacchetto è crittografato con il payload.

Uso congiunto di collegamenti terrestri e satellitari

Le moderne applicazioni di rete sono caratterizzate da un fabbisogno sempre maggiore di risorse, con un aumento significativo delle dimensioni medie dei contenuti web che stanno diventando sempre più impegnativi, compresi i contenuti interattivi e multimediali. Molti contenuti richiesti contemporaneamente attraverso lo stesso collegamento possono, in alcuni casi, causare un calo delle prestazioni a causa della congestione. È invece possibile ottimizzare l’esperienza degli utenti utilizzando congiuntamente collegamenti diversi, introducendo configurazioni con più connessioni di rete o multicollegamento, sia come soluzioni di backhaul che a livello di accesso.

Con backhaul si intendono i collegamenti di trasporto utilizzati all’interno della rete centrale del fornitore di servizi Internet (ISP) per connettere i propri utenti alla rete dati (cioè Internet). In questo caso, l’uso di collegamenti ridondanti o paralleli è a carico dell’operatore di rete, rendendo la loro esistenza trasparente agli utenti finali. Al contrario, assistiamo a una disponibilità sempre più diffusa di diversi accessi a Internet direttamente nei dispositivi degli utenti finali, come nel caso particolare degli smartphone, che dispongono ad esempio sia di accesso via cavo quando sono a casa (tramite Wi-Fi) sia di accesso radio alla rete 4G/5G. Finora, con poche eccezioni, tali collegamenti non sono abilitati contemporaneamente.

Sebbene l’utilizzo di collegamenti con caratteristiche simili possa migliorare la robustezza, l’uso di collegamenti molto diversi tra loro (una “rete ibrida”) può apportare ulteriori vantaggi. Il riferimento è in particolare alla combinazione di tecnologie terrestri e satellitari. Finora, il satellite non è stato preso seriamente in considerazione come soluzione di backhaul o accesso complementare per molte ragioni:

• costi elevati;
• elevata complessità dei terminali (grandi antenne per ottenere velocità di trasmissione dati elevate);
• ritardi di propagazione elevati.

Pertanto, di norma il suo uso viene limitato alle sole aree rurali o remote come soluzione di ultima risorsa.

Oggi, i grandi investimenti nei sistemi satellitari ad altissima velocità (VHTS, come KONNECT VHTS in GEO orbit) e nelle mega costellazioni LEO (come StarLink e OneWeb) hanno portato a una significativa riduzione dei costi delle comunicazioni satellitari, nonché dei ritardi nel secondo caso, spingendo le grandi aziende ICT a riconoscere il potenziale del segmento satellitare e a iniziare a investire a loro volta.

In questo contesto, il segmento satellitare può essere sfruttato principalmente in due modi, sia in ambiente rurale che urbano:

• come collegamento aggiuntivo per far fronte alle congestioni di rete sul collegamento primario o per il “channel bonding” al fine di aumentare la capacità del canale;
• come collegamento di riserva per recuperare e/o ripristinare la connettività in caso di interruzione del collegamento (ad esempio, in caso di calamità naturali) e migliorare la resilienza.

In definitiva, una rete ibrida è definita come la combinazione di un collegamento terrestre e satellitare, come rappresentato nella Figura 3, sia per l’accesso che per il backhaul.

Figura 3: Architettura di rete tipica che tiene conto di una rete di backhaul ibrida

Satellite nella rete di accesso

Un caso significativo in cui l’uso di collegamenti di accesso molto diversi può portare a diversi miglioramenti del servizio è rappresentato dall’Access Traffic Steering, Switching & Splitting (ATSSS), recentemente definito per le reti 5G a partire dalla versione 16, che sfrutta l’accesso non 3GPP. Anche se il 3GPP ha definito solo meccanismi di accesso alternativi terrestri, ovvero WiFi (WLAN) e cavo (wireline), sono possibili estensioni all’uso del satellite. Nell’ATSSS, il traffico della tratta in salita e della tratta in discesa, indipendentemente, può utilizzare il collegamento principale (cioè, 5G New Radio), o il collegamento secondario non 3GPP (cioè WiFi), o entrambi, in base allo stato della rete, ai requisiti delle applicazioni e, eventualmente, alle politiche dell’operatore di servizi. In questo modo, se si considera come collegamento alternativo quello satellitare, è possibile migliorare la resilienza, la disponibilità, la mobilità e la copertura del servizio; allo stesso tempo, grazie alla natura di trasmissione del satellite, è possibile inviare ad esempio IPTV in diretta via satellite nella tratta in discesa, alleviando il carico della rete terrestre centrale in caso di grandi eventi (ad esempio, sport, concerti, ecc.).

In ATSSS la gestione dei collegamenti multipli è delegata alle apparecchiature degli utenti finali (UE) e alla funzione del piano utente 5G (UPF), tramite protocolli di accesso multiplo standardizzati dedicati, come MP-TCP o ATSSS-LL.

Backhaul ibrido satellitare-terrestre

Nelle comunicazioni satellitari (SatCom), i Performance Enhancing Proxies (PEP) sono adottati per accelerare la comunicazione tra client e server [6] e sono collocati ai bordi del collegamento SatCom. I PEP sono il luogo ideale per consentire una gestione multicollegamento, permettendo un backhaul di rete ibrido. Considerando il satellite come una tecnologia supplementare o complementare alle reti terrestri tradizionali, è possibile ottenere migliori prestazioni e nuovi servizi. In questa situazione, l’agente PEP ha il compito di gestire i flussi di dati che possono essere spostati dinamicamente attraverso diversi domini di rete durante la loro vita.

Il PEP legacy è in realtà un agente basato su hardware, che esegue software e protocolli di rete personalizzati basati su una configurazione e un’architettura statiche. Recentemente, nell’ottica della softwarizzazione che caratterizza le reti moderne (compreso il 5G), è stato un agente PEP virtuale (vPEP), presentato in [7] e [8] insieme a una validazione funzionale preliminare.

Il vPEP rappresenta una catena di funzioni di rete virtuali (VNF – livello IP e superiore) distribuite per consentire l’integrazione proposto ottimizzata di un componente satellitare e permettere la gestione e la commutazione del traffico senza soluzione di continuità. Un’architettura abilitata al vPEP può utilizzare in modo trasparente per gli utenti finali il collegamento satellitare o terrestre seguendo logiche di ottimizzazione specifiche per l’instradamento, il direzionamento e il collegamento utilizzando catene di VNF dedicate e un protocollo di tunnelling specifico

Architettura di riferimento

Possiamo fare riferimento allo scenario tipico descritto in precedenza, considerando la connettività Internet dai terminali degli utenti finali attraverso reti di accesso fisse 4G/5G o cablate. Il satellite può rappresentare un accesso aggiuntivo (tramite ATSSS) o un collegamento di backhauling (tramite vPEP), supportando la rete di accesso terrestre alle reti core con l’obiettivo di scaricare la rete terrestre dell’ISP offrendo al contempo servizi basati sul satellite (come il multicast). In questo modo, le applicazioni TCP/IP comuni possono attraversare alternativamente un collegamento terrestre, un collegamento satellitare o contemporaneamente entrambi sulla base degli obiettivi di QoS e dei requisiti di servizio.

Poiché il collegamento satellitare potrebbe essere non fidato e, molto probabilmente, gestito in modo indipendente da un Operatore di Rete Satellitare (SNO), è necessario definire protocolli robusti di multi-accesso adatti allo sfruttamento di collegamenti multipli. Ciò significa che tali protocolli devono funzionare con NAT, sottoreti diverse e potenzialmente con la presenza di firewall Layer7, sfruttando in pratica la semplice connettività IP.

Si noti che nel caso di ATSSS è stato definito un protocollo di accesso multiplo di livello 2, ovvero ATSSS-LL, ma la sua realizzazione è attualmente lasciata aperta e dipendente dai fornitori e, di conseguenza, lascia un vuoto tecnologico da colmare.

Sia nel caso dell’accesso che del backhauling, possiamo quindi considerare un’architettura simile, in cui vengono introdotti agenti dedicati per consentire la gestione del collegamento multiplo. Nella Figura 4 riportiamo uno dei due casi, un backhauling ibrido abilitato da vPEP; una configurazione simile è applicabile anche all’ATSSS, in cui la gestione del multicollegamento è una componente dell’UE e dell’UPF della rete 5G.

Figura 4: Scenario di riferimento in cui un insieme di web-client genera traffico web, richiedendo dati ai server situati nella rete dati. Il traffico web è gestito da agenti vPEP dislocati ai bordi della rete di backhaul dotata di collegamenti terrestri e satellitari.

 

In questo contesto, è necessario realizzare un protocollo Multi Link/Multi Access adatto a consentire la comunicazione su entrambi i collegamenti (e in linea di principio anche su più di due collegamenti), e l’idea è quella di sfruttare il protocollo QUIC.

Alternativa al protocollo TCP

L’obiettivo principale dell’utilizzo di più collegamenti è di spostare dinamicamente i flussi di dati tra diversi domini di rete e non solo quello di selezionare il collegamento più adatto per ogni connessione o per ogni pacchetto. Una connessione TCP spostata verso una nuova rete gestita all’interno di un dominio amministrativo diverso può essere compromessa. Infatti, in caso di NAT, firewall (con o senza deep packet inspection) e sottoreti diverse, il socket del livello di trasporto (basato sulla tupla [IP/porta]) può cambiare, causando un RESET da parte del server e richiedendo l’instaurazione di una nuova connessione TCP (“ERROR NETWORK CHANGED” appare sulla maggior parte dei browser web). Una nuova connessione implica una nuova fase di handshake sul nuovo percorso, che richiede almeno 1 RTT sul nuovo collegamento e può introdurre sprechi di risorse e tempi morti, rendendo complicata la migrazione diretta delle connessioni.

Per superare queste limitazioni, alcune soluzioni basate su TCP consentono di gestire una comunicazione multipath o multihoming supportando i cambiamenti di rete (ad esempio, MP-TCP, SCTP). In realtà, per gli ATSSS 5G il supporto MP-TCP è considerato obbligatorio.

Tuttavia, MP-TCP soffre di alcune lacune se si considera lo scenario di riferimento descritto sopra. Infatti, può essere configurato con path-manager statici e predefiniti durante la fase di setup, in particolare: i) ‘default’ utilizzerà come collegamento di default quello con RTT più basso e poi, quando la finestra di congestione è piena, inizierà a utilizzare il successivo collegamento con RTT più alto; ii) ‘redundant’ permette la trasmissione di pacchetti su tutti i collegamenti disponibili garantendo la comunicazione attraverso altri collegamenti in caso di interruzione del collegamento (funzionando come ‘riserva’). Quindi, i collegamenti di destinazione che MP-TCP deve utilizzare richiedono una configurazione a priori. Anche se recentemente è stata definita una gestione delle connessioni MP-TCP più intelligente [9], abbiamo deciso di concentrarci su una soluzione alternativa flessibile sulla base del protocollo QUIC, recentemente definito. Si può prendere in considerazione anche MP-QUIC, anche se è ancora una bozza di specifica IETF e recentemente è stato incluso nella Rel-18 del 5G.

Come già discusso, QUIC supporta in modo nativo la funzione di migrazione della connessione che consente di spostare la comunicazione su un altro collegamento, garantendo al contempo una connessione a 0-RTT. La migrazione si conclude quando viene rilevata una modifica dei parametri di rete (ad esempio, Source-IP) da parte di un peer che continua a trasmettere dati sul link in cui sono arrivati i pacchetti. Si noti che nel caso di i) GQUIC la comunicazione continuerà direttamente sul nuovo percorso, mentre nel caso di ii) IQUIC è necessaria la procedura di Path Validation per garantire la raggiungibilità sul nuovo percorso, che richiede un ulteriore 1RTT. In definitiva, un sottoinsieme delle caratteristiche di GQUIC può essere sfruttato per affrontare tutte le operazioni di indirizzamento, commutazione e suddivisione del traffico in modo molto efficiente, definendo un insieme di cosiddetti “tunnel basati su QUIC”.

Tunnel QUIC

Il concetto

Innanzitutto, ricordiamo il concetto di “tunnel”. Tecnicamente si tratta di un metodo per trasportare i dati dell’utente attraverso una rete utilizzando protocolli tipicamente non supportati da quella rete o semplicemente per aggiungere un ulteriore livello di sicurezza e privacy: il tunnelling funziona incapsulando i pacchetti dell’utente all’interno di altri pacchetti (IP-over-IP) e di solito viene utilizzato nelle reti private virtuali (VPN). Logicamente rappresenta un’associazione 1:1 tra due peer. Pertanto, un tunnel QUIC può essere definito come un’associazione tra un client e un server che fa leva su QUIC a livello di trasporto, indipendentemente dall’effettivo dominio di rete attraversato. I tunnel QUIC sono quindi utilizzati per gestire in modo efficiente i collegamenti ibridi di backhaul satellite-terrestre della nostra architettura di riferimento.

L’idea principale è quella di terminare tutte le connessioni TCP in entrata sul primo vPEP, quindi di incapsulare il carico utile (ad esempio la richiesta “GET”) in pacchetti QUIC e infine di inoltrarli a un punto estremo vPEP corrispondente, che ripristina la connessione TCP originale al web-server finale.

È quindi possibile creare una serie di tunnel QUIC quando si attraversa la rete ibrida di backhaul. In questo modo i vPEP incaricati di abilitare tali tunnel assumono due ruoli principali:

• Proxy server per velocizzare eventualmente la connessione su collegamenti satellitari
• Elemento proxy QUIC per gestire dinamicamente il cambio di percorso tra diverse reti di backhaul

Si noti che grazie alle caratteristiche di multiplexing di QUIC, un singolo tunnel QUIC può trasportare un aggregato di traffico relativo a diversi client. In base allo stato della rete o alla politica dell’ISP, è possibile spostare dinamicamente questa aggregazione da una rete all’altra. È possibile realizzare diverse configurazioni, ovvero stabilire un numero predefinito di tunnel in base ai livelli di priorità, ai tipi di applicazioni, ai percorsi logici dei dati all’interno della rete (network slices) e così via, a seconda della flessibilità richiesta.

Nel laboratorio

L’architettura QUIC-tunnel proposta, realizzata in un banco di prova basato su Linux, è rappresentata nella Figura 5. Sono identificate tre reti di area:

• Rete di accesso (lato client)
• Rete di backhaul (lato proxy)
• Rete dati (lato server)

Sul lato client, la rete di accesso offre a diversi client web la connettività verso server web remoti situati sul lato server. Il lato Proxy comprende la Rete di Backhaul, circondata da una coppia di vPEP per fornire un servizio efficiente e trasparente utilizzando tunnel basati sul protocollo QUIC.

In realtà, i due agenti vPEP sono rappresentati nella figura da Redirector + Proxy-Client e Proxy-Server, rispettivamente come client e server. Il vPEP-client ha il compito di aggregare il traffico web in categorie da associare a tunnel QUIC separati (Redirector). Inoltre, il vPEP-client è autorizzato a spostare i tunnel tra diversi link di backhaul (terrestri e satellitari), seguendo regole di controllo predeterminate (Proxy-Client). Il vPEP-server ha il compito di terminare i tunnel QUIC e di ripristinare la connessione TCP legacy al web-server (Proxy-Server).

Una volta che il traffico è gestito attraverso un insieme di tunnel, in caso di necessità, il percorso predefinito (ad esempio, terrestre) può essere scaricato spostando selettivamente uno o più tunnel su un percorso alternativo (ad esempio, satellitare). Mentre il Redirector è incaricato di creare l’associazione “traffico : tunnel” nel lato client, l’elemento Proxy-Client è l’entità incaricata di eseguire la migrazione del tunnel nel lato proxy.

Figura 5: Tutto il traffico relativo agli utenti Flat (tubo giallo) viene reindirizzato nel tunnel a bassa priorità (#2), mentre quello relativo agli utenti Business (tubo verde) viene reindirizzato nel tunnel ad alta priorità (#1)

Conclusione

Questo lavoro propone una soluzione pratica per la gestione di più collegamenti in una rete di backhaul ibrida che include un collegamento satellitare ad alto ritardo. Un sottoinsieme di caratteristiche del protocollo di trasporto QUIC, scelto come base per l’HTTP/3, viene selezionato per realizzare un nuovo elemento di rete, il vPEP, in una prospettiva 5G. Infatti, il vPEP è definito come un insieme di funzioni finalizzate all’ottimizzazione della comunicazione tra clienti web e server considerando una configurazione di rete backhaul eterogenea. Il punto focale di questo lavoro è costituito da due funzioni:

1. Facilità di migrazione di una connessione tra diversi domini di rete grazie alle caratteristiche di progettazione del QUIC (un protocollo di trasporto basato su UDP);
2. Approccio aggregato per prendere decisioni ed eseguire operazioni non sulle singole connessioni ma su un aggregato, cioè un insieme di connessioni TCP unite da caratteristiche comuni (provenienti dalla stessa Area Network, appartenenti allo stesso utente, che richiedono contenuti simili, ecc…)

Riferimenti

[1] Hypertext Transfer Protocol Version 3 (HTTP/3), Internet-Draft [ONLINE]
[2] QUIC: A UDP-Based Multiplexed and Secure Transport, Internet-Draft [ONLINE]
[3] QUIC Loss Detection and Congestion Control, Internet-Draft [ONLINE]
[4] QUIC Crypto [ONLINE]
[5] “The Transport Layer Security (TLS) Protocol Version 1.3”, Eric Rescorla, RFC 8446
[6] “Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations”, Jim Griner and John Border and Markku Kojo and Zach D. Shelby and Gabriel Montenegro, RFC 3135
[7] Abdelsalam, A., Bujari, A., Luglio, M., Munaretto, D., Palazzi, C.E., Quadrini, M., Romano, S.P., Roseti, C., Zampognaro, F. “Implementation of Virtualised Network Functions (VNFs) for Broadband Satellite Networks” (2019) 2019 European Conference on Networks and Communications, EuCNC 2019, art. no. 8801954, pp. 182-186. DOI: 10.1109/EuCNC.2019.8801954
[8] A. Bujari, M. Luglio, C. E. Palazzi, M. Quadrini, C. Roseti and F. Zampognaro, “A Virtual PEP for Web Optimization over a Satellite-Terrestrial Backhaul,” in IEEE Communications Magazine, vol. 58, no. 10, pp. 42-48, October 2020, DOI: 10.1109/MCOM.001.2000322.
[9] Intel, Multipath TCP Daemon, https://github.com/intel/mptcpd

 

© RomARS – Mattia Quadrini