Perché scegliere DPI: politiche di traffico basate sulle applicazioni e visibilità

Abstract. La Deep Packet Inspection (DPI) di BQN estende la gestione della larghezza di banda oltre i limiti relativi agli abbonati e alla velocità di flusso, identificando le applicazioni che generano traffico. Questa consapevolezza delle applicazioni consente agli operatori di definire politiche per specifiche categorie di applicazioni, misurare le modalità di utilizzo delle applicazioni e valutarne le prestazioni nel tempo. Le politiche basate sulla DPI non sostituiscono le funzioni di controllo automatico di BQN. Al contrario, esse integrano la gestione automatica della congestione (ACM) di BQN, che rileva e mitiga la congestione sulla base dei segnali a livello di utente, e la gestione attiva delle code (AQM) di BQN, che applica i limiti tramite un sistema avanzato di accodamento per flusso. Insieme, DPI, ACM e AQM offrono agli operatori sia una protezione automatica della qualità dell’esperienza (QoE) sia un controllo mirato e consapevole delle applicazioni.

‍

Perché è importante la consapevolezza delle applicazioni

Il controllo della larghezza di banda a livello di abbonato risponde alla domanda: “Quanto traffico dovrebbe ricevere questo utente o gruppo?”. Il DPI aggiunge una seconda dimensione: “Che tipo di traffico sta utilizzando quella capacità?”. Questa distinzione è importante perché le applicazioni presentano diverse sensibilità in termini di QoE. Un aggiornamento software, uno streaming video, un backup su cloud, una sessione di gioco e una videoconferenza possono tutti consumare capacità, ma non reagiscono allo stesso modo a ritardi, perdite o limitazioni temporanee.

BQN utilizza profili DPI per identificare i flussi il cui dominio DPI corrisponde a firme di applicazioni predefinite o personalizzate. Queste firme predefinite includono applicazioni diffuse quali teleconferenze, i principali servizi di streaming video e gli aggiornamenti software più comuni. Una volta classificato il traffico, il sistema di policy può applicare diverse policy di flusso alle diverse applicazioni, pur operando nell’ambito dei controlli a livello di abbonato, di gruppo o di rete.

‍

Il DPI come selettore delle politiche applicative

Le politiche BQN vengono selezionate tramite regole che combinano profili e politiche. I profili classificano il traffico; le politiche definiscono l'azione. Il DPI diventa quindi un selettore per decisioni basate sulle applicazioni. Una regola può identificare il traffico proveniente da un gruppo di abbonati, un intervallo di tempo, una rete di accesso o un'interfaccia, per poi identificare ulteriormente la firma dell'applicazione tramite un profilo DPI. Ciò rende il controllo del traffico basato sulle applicazioni sufficientemente preciso da risultare utile senza trasformare la rete in un insieme di liste di accesso statiche dei router.

Tre modelli di politica coprono la maggior parte delle implementazioni:

• Priorità delle applicazioni: assegnare una priorità relativa più elevata alle applicazioni sensibili alla latenza, come le teleconferenze, quando un abbonato o un gruppo raggiunge un limite. Questa assegnazione di priorità si aggiunge a quella automatica fornita dall’elemento AQM, rafforzandola.
• Moderazione delle applicazioni: rallentare le categorie più pesanti o non interattive durante i periodi di picco, anziché applicare una penalizzazione uniforme a tutto il traffico.
• Precisione della misurazione della tariffa: individuare i test di velocità in modo che il risultato rifletta la velocità prevista dal contratto e non la capacità residua disponibile nella rete domestica, come descritto di seguito.

I test di velocità illustrano bene perché l’identificazione dell’applicazione sia importante dal punto di vista commerciale e non solo tecnico. Quando un abbonato esegue un test, interpreta il valore ottenuto come la velocità del proprio piano; tuttavia, il test entra in competizione con tutte le altre attività in corso in casa in quel momento, quindi una famiglia che sta guardando un video in streaming, eseguendo un backup sul cloud o scaricando un aggiornamento per la console otterrà un risultato ben al di sotto della velocità contrattuale, anche se la rete di accesso sta fornendo esattamente ciò che è stato venduto. L’abbonato conclude di non ricevere la velocità prevista dal proprio piano e apre un ticket, e il team di assistenza deve dedicare tempo a dimostrare una negazione. Poiché il DPI riconosce i principali servizi di test di velocità in base alla firma piuttosto che all’indirizzo del server, BQN può trattare quei flussi come un’applicazione distinta e assegnare al test l’intera quota a disposizione dell’abbonato per la sua breve durata, consentendo al traffico in background in corso di cedere la priorità mentre il test è in esecuzione. La misurazione riflette quindi il limite del piano piuttosto che il piano al netto di qualsiasi altra attività che l’abbonato stesse svolgendo in quel momento, il che elimina una categoria ricorrente e del tutto evitabile di ticket di assistenza.

‍

Dati relativi all'utilizzo e alle prestazioni dell'applicazione

DPI trasforma inoltre BQN in una piattaforma di visibilità delle applicazioni. Con BQN, gli operatori possono vedere quali applicazioni sono in esecuzione nella rete e come si comportano, fino al livello dei singoli gruppi di abbonati e del traffico in tempo reale di un singolo abbonato. Questi dati hanno un valore operativo diretto. I team di assistenza possono determinare se un reclamo è legato a un’applicazione specifica, a un problema di accesso dell’abbonato o a un segmento di rete congestionato. I team di ingegneria possono individuare se la pressione sulla capacità nelle ore di punta è causata da un numero limitato di categorie ad alto consumo o da una domanda diffusa da parte degli abbonati. I team di prodotto possono comprendere il mix di applicazioni e definire politiche che tutelino la QoE interattiva senza sopprimere inutilmente il traffico utile.

‍

In che modo il DPI integra l’ACM e l’AQM

ACM e AQM sono meccanismi di controllo automatico. L'ACM rileva la congestione osservando la velocità, la latenza e il comportamento in termini di perdita dei dati degli abbonati, quindi mitiga la situazione quando questa si verifica. L'AQM applica dei limiti tramite l'accodamento per flusso, in modo che un flusso intenso non causi ritardi eccessivi agli altri flussi. Le politiche basate sul DPI integrano l'intento dell'operatore. Esse rispondono a domande per le quali l'ACM e l'AQM non sono stati progettati, ad esempio quali categorie di applicazioni debbano ricevere la priorità durante le ore di punta e quali categorie ad alto volume debbano essere moderate.

Il rapporto è quindi complementare. L’ACM individua il vero punto di congestione e regola la velocità operativa. L’AQM mantiene brevi le code e isola i flussi al limite imposto. Il DPI determina come le applicazioni debbano essere gestite all’interno di quell’ambiente controllato. Ad esempio, quando un gruppo di abbonati raggiunge un limite di velocità durante le ore di punta, l’AQM impedisce la formazione di code condivise di grandi dimensioni, l’ACM rileva se la congestione rimane dannosa e le politiche DPI possono dare priorità alle applicazioni in tempo reale rispetto agli aggiornamenti in background o ad altro traffico elastico.

‍

Principi di progettazione per le politiche basate sul DPI

• Utilizzate il DPI per esprimere le vostre intenzioni, non per sostituire il controllo automatico. Lasciate che siano l’ACM e l’AQM a gestire i meccanismi di gestione della congestione; utilizzate il DPI per decidere quali classi di applicazioni meritino un trattamento speciale.
• Applicare la logica delle ore di punta. Combinare i profili DPI e temporali in modo che le politiche si attivino quando la capacità è limitata.
• Verifica i dati relativi alle metriche dell'applicazione. Controlla la velocità dell'applicazione, le latenze, le ritrasmissioni e l'andamento dell'utilizzo prima e dopo le modifiche alle politiche.
• Operare per gruppo di abbonati. Utilizzare i gruppi di abbonati per definire criteri specifici per il segmento interessato.

‍

DPI e ASN per l’identificazione delle applicazioni

Un’alternativa più semplice al DPI consiste nel classificare il traffico in base agli intervalli IP o al numero di sistema autonomo (ASN) da cui proviene. Questo approccio è economico, ma identifica l’entità che gestisce i server, non il servizio che l’abbonato sta effettivamente utilizzando. I grandi fornitori di contenuti offrono molti servizi distinti dallo stesso ASN e spesso dagli stessi intervalli di indirizzi, quindi una regola basata sull’ASN non è in grado di distinguerli. Netflix ne è l’esempio più lampante: lo streaming video e il test di velocità fast.com sono entrambi gestiti da Netflix e compaiono sotto lo stesso sistema autonomo, eppure richiedono un trattamento opposto — uno streaming video è elastico, viene memorizzato nel buffer ed è un candidato legittimo per la moderazione nelle ore di punta, mentre un test di velocità è un flusso di misurazione breve il cui risultato viene interpretato dall’abbonato come la velocità del proprio piano tariffario. Allo stesso modo, Google può ospitare, sotto lo stesso indirizzo IP, servizi diversi come lo streaming video di YouTube, Google Drive e Google Meet. Una regola basata sull’ASN rileva un’unica origine e tratta tutto in modo identico; un profilo DPI riconosce la firma del servizio e consente all’operatore di moderare lo streaming lasciando inalterato il test di velocità.

‍

Conclusione

BQN DPI integra l’intelligenza applicativa nel ciclo di gestione della larghezza di banda. Consente agli operatori di identificare le applicazioni, definire politiche basate sulle applicazioni e misurarne l’utilizzo e le prestazioni. ACM e AQM continuano a fornire le basi per la QoE automatica: ACM rileva e mitiga la congestione, mentre AQM gestisce le code e l’isolamento dei flussi. Il DPI le integra aggiungendo l’intento delle politiche e la visibilità, consentendo agli operatori di proteggere i servizi sensibili alla latenza, moderare la domanda elastica e comprendere quali applicazioni stanno effettivamente generando il carico di rete.