Piattaforme per migliorare la QoE: Transparent Caching - I

PREMESSA: questo post, il primo di due, è stato scritto a due mani, dal sottoscritto e dal mio amico Gianfranco Ciccarella, ex-Top Manager Telecom Italia, per anni alla guida della rete di Telecom Italia Sparkle e quindi delle Strategie per l'implementazione della NGAN in Telecom Italia.

In un post precedente, scritto per far chiarezza sulla differenza tra Banda e Throughput, sono stati accennati possibili metodi per aumentare il Throughput, citando le piattaforme di Transparent caching (per inciso il post precedente è stato il più letto di questo blog, superando le 1.100 visualizzazioni). In questo post cercheremo, il plurale è d'obbligo poiché come citato nella premessa il post è stato scritto a due mani, di illustrare i vantaggi che si ottengono dall'introduzione di piattaforme di Transparent Caching, sia in termini di prestazioni che economici.

Ma prima di passare alla parte tecnica, ci sembra opportuno dare delle motivazioni. 

ALCUNI NUMERI SUL TRAFFICO INTERNET

Di statistiche sulla crescita del traffico Internet ne trovate a iosa in giro. A noi sono piaciuti questi due report Cisco che potete trovare a questo link e a questo. Vi riassumiamo alcune delle conclusioni più importanti, rimandando per il resto ai due report:

• Da qui al 2020, il traffico Internet globale raggiungerà i 2,3 Zettabyte (1 Zettabyte = 10^21, ossia 1 miliardo di Terabyte), con una crescita cumulativa annua del 22% (che equivale a un incremento in 4 anni di 2,2 volte).
• L'intensità di traffico Internet nell'ora di punta avrà invece una crescita cumulativa annua del 36%, raggiungendo nel 2020 i 3.000 Tbit/s (3 volte circa il valore attuale), mentre la crescita media sarà più lenta e arriverà a circa 500 Tbit/s (il doppio circa del valore attuale). E non dimenticate che gli ISP pianificano lo sviluppo della rete sulla base del traffico in ora di punta ! (i vecchi telefonisti questo lo sanno molto bene, l'incremento dei circuiti era sempre basato sul traffico telefonico in ora di punta). La figura seguente, tratta dal primo dei due report Cisco sopra citati, riassume quanto detto.

• Il traffico video globale sarà pari all'82% del totale del traffico Internet (era il 70 % nel 2015), raggiungendo nel 2020 circa i 110 Exabyte per mese (1 Exabyte = 10^18, ossia 1 milione di Terabyte).
• Il traffico veicolato attraverso CDN (Content Delivery Networks) sarà circa il 64,5% dell'intero traffico Internet. Ad oggi ad esempio, la sola Akamai ne veicola il 45%. La crescita cumulativa annua è riportata in questa figura, tratta sempre dal primo dei due report Cisco citati sopra.

Come si può notare da quanto appena detto, la crescita maggiore è imputabile al traffico video, per cui è a questo che è necessario rivolgere maggiormente l'attenzione per migliorarne la qualità di fruizione, quella che è nota come Quality of Experience (QoE, vedi prossima sezione). Tutti conosciamo il fenomeno Netflix, che è riuscita in pochi anni a creare un mercato alternativo alle major televisive di tutto il mondo. Fra poco molti di più sentiranno parlare del servizio Amazon Prime Video, primo concorrente serio di Netflix, già presente in 200 paesi tra cui l'Italia. E non è estraneo a tutto questo il recente tentativo di scalata a Mediaset da parte della media-company Francese Vivendi, con l'intento dichiarato di porre le basi per una Netflix Europea. 

Bene, ciò premesso, è di vitale importanza per gli ISP/Carriers e per i Content Provider (es. Netflix, Amazon Prime Video e tutti gli OTT) garantire ai propri Clienti una QoE elevata, perché questa potrà garantire una consistente fonte di ricavi. Ovviamente la partita da giocare sarà quella di un modello di business in cui anche gli ISP/Carriers abbiano la loro parte, cosa che oggi non succede. Ma questo esula dallo scopo di questo post.

Tutti questi servizi video utilizzano come protocollo di trasporto il TCP, che come visto nel post precedente su Banda e Throughput, pone dei limiti al Throughput complessivo a causa del suo funzionamento intrinseco, limiti che non sono risolti dall'aumento della banda disponibile. E la QoE dipende in modo fondamentale dal Throughput ! I due parametri fondamentali che limitano il Throughput sono il Round Trip Time (RTT) e la perdita di pacchetti. Per cui, per aumentare la QoE è su questi parametri che bisogna porre l'attenzione. C'è poi un altro aspetto fondamentale da considerare, aumentare la QoE ha un suo costo: quali sono questi costi e soprattutto, quale è il ROI (Return On Investement) ?

Nel seguito di questo post cercheremo di dare delle risposte a questi due quesiti, proponendo una soluzione, l'utilizzo di piattaforme di Transparent Caching (che altro non sono che una evoluzione del concetto di CDN) che secondo il nostro modesto parere dovrebbe essere considerata un must nelle moderne reti IP.

Però prima di addentrarci sul funzionamento delle piattaforme di Transparent Caching vogliamo chiarire un punto, spesso fonte di confusione: la differenza tra QoE e QoS (Quality of Service). All'apparenza sembrano due concetti simili, in realtà sono abbastanza diversi.

QoE E QoS

Chi di voi ha "trafficato" in passato con la telefonia di base, non potrà non ricordare il celebre MOS (Mean Opinion Score), un indice che misurava (o meglio, misura) la bontà dell'audio telefonico. La modalità di misura è descritta nel documento ITU-T P.800, che descrive la procedura per ottenere la misura della bontà di un segnale telefonico ricevuto, tramite una statistica di "opinioni" di ascolto: un gruppo di persone (di norma tra un minimo di 4 e un massimo di 40) esprimono un parere tramite un punteggio (su scala da 1 (peggiore) a 5 (migliore)), su tre diversi aspetti dell'ascolto:

• Qualità del parlato (Listening Quality).
• Sforzo richiesto per la comprensione (Listening Effort).
• Gradimento dell'intensità sonora (Loudness Preference).

Bene, il MOS è un classico esempio di misura della QoE. Una metodologia simile a quella che porta alla determinazione del MOS "telefonico", è stata sviluppata anche per il video e standardizzata nei documenti ITU-R BT.500, orientato alla determinazione della QoE dei segnali video broadcast (es. TV analogica/digitale/satellitare) e ITU-T P.910, orientato alla determinazione della QoE dei segnali video multimediali (es. videoconferenza, video su Internet). Alcuni fattori chiave su cui viene valutata la QoE video sono la qualità delle immagini, il tempo di attesa per l'inizio del video, la fluidità di utilizzo (ossia, senza interruzioni o degradi dovute al buffering). Per chi volesse approfondire l'argomento, consigliamo questo link di Wikipedia.

La tabella seguente, tratta dal report "Viewer Experience Report" di Conviva del 2013 (scaricabile a questo link), mostra l'impatto positivo a seguito di un miglioramento della percezione della QoE video.

La QoS è invece un insieme di funzionalità "di rete", che consentono di trattare in modo differenziato le varie classi di traffico IP. Tipiche funzionalità di QoS sono ad esempio la gestione delle code con meccanismi di priorità, l'assegnazione di una banda minima garantita alle varie classi di traffico, la gestione degli scarti dei pacchetti, il controllo del traffico, ecc. . Il problema di fondo è però che queste funzionalità hanno scarso impatto sui due parametri chiave che limitano il Throughput, ossia il RTT e la perdita dei pacchetti, e quindi da sole non sono determinanti per aumentare la QoE.  

E' interessante infine notare che un ridotto RTT e un ridotto tempo di download di una pagina web, porta notevoli benefici anche ad applicazioni non video. Ad esempio, è stato stimato che una riduzione di 1 sec nel download time, porta per Amazon un incremento del 10% dei ricavi, per Bing una riduzione di 2 sec nel download time porta ad un incremento dei ricavi del 5%, e così via.

Morale della favola, per incrementare la QoE è vitale accorciare il RTT, e l'unico modo per far questo, a meno che un domani non si scopra che la velocità della luce sia di gran lunga superiore al valore attuale, è avvicinare i contenuti a chi ne fruisce. E qui entrano in gioco le piattaforme che consentono di migliorare la QoE e che sono essenzialmente di due tipi: 

• Piattaforme che migliorano le prestazioni degli applicativi come Transparent Caching, acceleratori di protocollo e Front End Optimization. Queste piattaforme riducono il RTT e, in alcuni casi, la perdita dei pacchetti, avvicinando i contenuti ai fruitori (caching dei contenuti vicino agli end user), oppure dividendo la connessione TCP tra sorgente e destinazione in più connessioni con minore RTT (acceleratori di protocollo). Le piattaforme di Front End Optimization consentono di ridurre il download time, diminuendo il numero di messaggi che sorgente e destinazione si scambiano quando si realizza il primo collegamento. 
• Piattaforme Cloud, che consentono di eseguire il software degli applicativi vicino agli end user. In questo modo si riduce il RTT e, in alcuni casi, la perdita dei pacchetti. Le piattaforme Cloud possono essere considerate come una forma di caching, che memorizza gli applicativi  invece dei contenuti (caching di funzioni rispetto al caching di contenuti).

Il focus di questo post sarà sulle piattaforme di Transparent Caching. Delle altre tratteremo in post successivi.

TRANSPARENT CACHING: ASPETTI GENERALI

Prima di vedere il funzionamento, è necessario chiarire il punto più ovvio: a cosa serve una piattaforma di Transparent Caching ? L'idea è semplice ed è quella delle classiche CDN: avvicinare i contenuti agli end user, in modo da ridurre sia il RTT che la perdita dei pacchetti, migliorando così le prestazioni, in particolare il Throughput, e quindi la QoE. 

A differenza delle classiche CDN, le piattaforme di di Transparent Caching agiscono però in modo "più intelligente", utilizzando funzionalità di self learning, ossia imparano dinamicamente i contenuti più importanti (ossia, i più richiesti), classificandoli in ordine di importanza, dove importanza equivale a "più visti". I contenuti vengono quindi memorizzati in una piattaforma e resi disponibili su richiesta. In sostanza, una piattaforma di Transparent Caching altro non è che un sistema di storage, dove gli oggetti memorizzati sono i contenuti più richiesti dagli end user.

Ma, in cosa consiste una piattaforma di Transparent Caching ? Bene, qui la risposta è semplice, si tratta di un software intelligente, installato su un comune server COTS. 

L'Hardware deve essere sufficientemente potente sia in termini di forwarding del traffico (quindi, interfacce ad almeno 10 Gbit/s), che soprattutto di memorizzazione (dell'ordine delle decine di Tbit/s).

Il vero elemento chiave è però il software. Questo deve essere in grado, oltre che di memorizzare i contenuti più importanti (es. video di vari tipi, pagine web, ecc.), e di gestire l'handshake che consente ad un end user di ottenere in modo trasparente i contenuti direttamente dalla piattaforma, e non dalla sorgente reale del contenuto (che potrebbe essere molto, troppo "lontana" dall'end user), anche di fornire funzionalità analitiche che consentano di rispondere ad aspetti critici del servizio, come:

• Quale è la banda utilizzata dai servizi video, che sono i più bandwidth demanding, e che come visto nella sezione precedente, costituiscono anche la maggior parte del traffico Internet ?
• Quante sono le sessioni video contemporanee ? Questo è un aspetto molto importante per dimensionare la banda in uscita dalla piattaforma verso gli end user (anche detta cache fan-out).
• Quali sono i siti più visitati e chi sono i top consumers ? Queste statistiche sono importanti per definire offerte mirate e quindi migliorare il rapporto ISP-Clienti. 
• Quale è il profilo di traffico giornaliero, settimanale, mensile ?

Ciò premesso, non resta che vedere il funzionamento. Innanzitutto è necessario rispondere a due quesiti chiave: 

• Come inserire in rete una piattaforma di Transparent Caching ?  
• A quale livello della rete posizionare le piattaforme di Transparent Caching ? 

Circa il primo quesito, esistono due modalità;

• Inline: consiste nell'inserire la piattaforma nel forwarding path del traffico. 
• Out-of-band: la piattaforma viene inserita al di fuori del forwarding path; questa modalità ha bisogno di (semplici) componenti aggiuntive (es. tap ottici, porte SPAN) che consentano una replica passiva del traffico, che così può essere intercettato dalla piattaforma in modo assolutamente trasparente (da qui il nome Transparent Caching).

Per varie ragioni, che per brevità non approfondiamo, onde evitare di scrivere un trattato piuttosto che un post, la modalità preferita è quella out-of-band, che è illustrata nella figura seguente.

Per quanto riguarda il secondo quesito, logica vorrebbe che la risposta sia semplice: inserire la piattaforma nella sezione della rete più vicina agli end user. Ad esempio, in una rete con accesso FTTH o FTTCab, il punto più vicino agli end user, tralasciando le ONU (Optical Network Unit) che sono distribuite sul territorio al di fuori del perimetro di centrale, sono gli apparati OLT (Optical Line Termination) posizionati in centrale, che concentrano il traffico da/verso più ONU. 

Una soluzione del genere richiede però una attenta valutazione sia tecnica che (soprattutto) economica. Dal punto di vista tecnico la domanda chiave da porsi è, gli OLT supportano funzionalità di IP Edge ?  Se no, è impossibile la configurazione della figura sopra (il perché si capirà meglio nella successiva sezione sul funzionamento). Dal punto di vista dell'economicità della soluzione, bisogna considerare che gli apparati OLT sono molti, potrebbero tranquillamente essere dell'ordine delle migliaia, e questo potrebbe portare a costi sia di deployment che di esercizio (CAPEX e OPEX), troppo elevati. Per cui questo aspetto richiede una attenta analisi dei costi/benefici, che sarà illustrata nella seconda parte di questo post, che "andrà in onda" nel seguito.  

TRANSPARENT CACHING: FUNZIONAMENTO

Il funzionamento di base di una piattaforma di Transparent Caching è basato su dei "trucchi" molto semplici, che utilizzano messaggi dei protocolli tradizionali come TCP e HTTP. Nel funzionamento bisogna considerare due casi, l'assenza e la presenza del contenuto richiesto nella piattaforma.

Vediamo cosa accade nel caso (più semplice) in cui il contenuto richiesto dall'end user non sia presente nella piattaforma di Transparent Caching. 

1. L'end user richiede il contenuto (ad esempio un film da Netflix) attraverso un classico messaggio HTTP GET, indirizzato al server del content provider (Netflix). Il messaggio, grazie al tap ottico, viene intercettato dalla piattaforma di Transparent Caching, che provvede a creare, sulla base di campi del messaggio HTTP GET, un identificativo del contenuto (CID, Content ID). Una volta creato il CID, la piattaforma verifica se il CID è presente o meno nel proprio Database. 
2. Poiché il CID non è presente, la piattaforma di Transparent Caching memorizza il contenuto richiesto dall'end user, intercettando il contenuto (via tap ottico) che viene inviato nella direzione downstream dal content provider all'end user. Il contenuto è quindi disponibile nella piattaforma per future richieste. 

Tutta la  procedura è riassunta nella figura seguente.

Vediamo ora invece il caso più complesso in cui il contenuto è già presente nella piattaforma di Transparent Caching. 

1. Come nel caso precedente, l'end user richiede il contenuto al server del content provider, attraverso un classico messaggio HTTP GET. Il messaggio, grazie al tap ottico, viene intercettato dalla piattaforma di Transparent Caching, che provvede a creare il CID. La piattaforma di Transparent Caching verifica che il CID è già presente nel proprio Database.
2. La piattaforma di Transparent Caching a questo punto esegue due azioni: invia all'end user un messaggio HTTP 302 (Redirect) con il quale richiede all'end user di scaricare il contenuto richiesto direttamente dalla piattaforma di Transparent Caching, quindi invia sempre all'end user un messaggio TCP FIN con indirizzo IP sorgente del server del content provider, per chiudere la connessione TCP verso il content provider.
3. A fronte della ricezione dei due messaggi, l'end user invia un nuovo messaggio HTTP GET questa volta indirizzato alla piattaforma di Transparent Caching, per il download del contenuto, e quindi invia al server del content provider un messaggio TCP FIN per completare la procedura di chiusura della connessione TCP.
4. A questo punto, la piattaforma di Transparent Caching invia il contenuto all'end user.

Tutta la  procedura è riassunta nelle due figure seguenti.

Il lettore attento avrà notato però un problema nel funzionamento delle piattaforme di Transparent Caching, queste hanno bisogno che l’URI richiesta via HTTP sia "visibile" (il payload può anche essere cifrato, anzi lo è sempre per il DRM (= Digital Rights Management)). Quindi, il traffico che utilizza HTTPS, senza un accordo tra OTT e Telco/ISP, oppure tra OTT e vendor delle piattaforme di Transparent Caching, per "vedere" l’URI richiesta, non è cacheable, ossia non può essere memorizzato nella piattaforma, perdendo così tutti i vantaggi del suo deployment. Il traffico HTTPS è oggi moltissimo in Internet (es. Google, YouTube, Facebook, ecc.), ciononostante il deployment delle piattaforme di Transparent Caching è comunque importante per tanti altri motivi, tra cui:

• Il Transparent Caching è molto utile anche per gli OTT, poiché migliora le prestazioni e riduce il carico sui loro server, lasciando la completa visibilità del comportamento degli end user. Infatti, gli OTT "vedono" i contenuti richiesti dagli end user e la qualità con la quale li ricevono.
• La distribuzione di piattaforme di Transparent Caching fatta dagli OTT (Google, Facebook, Netflix,…) all’edge delle reti dei Telco/ISP, non riduce l’importanza del Transparent Caching per le reti domestiche, poiché con le reti UBB (Ultra BroadBand) il rapporto (Throughput/Bit Rate) si riduce, e quindi non si utilizzano in modo ‘corretto’ le risorse di rete e non si monetizza la rete UBB fissa e mobile. Per farlo servono piattaforme per QoE "deep into the domestic Network”, come proposto dall'iniziativa MEC (Mobile Edge Computing) di ETSI e da tutti i progetti sulle nuove architetture di rete fissa e mobile che sono basati su Distributed Cloud e piattaforme per la QoE (vedi report di Bell Consulting, GSMA, 3GPP, principali vendor come Huawei, Nokia, …). 
• Il fatto che gli OTT utilizzino in modo molto pesante il Transparent Caching è la conferma che non è destinato a scomparire, anche perché non esistono altre tecnologie per distribuire grandi quantità di contenuti in modo efficiente e con costi sostenibili. Solo per fare un esempio, non è possibile, per motivi di costo, fare il caching locale di tutti i contenuti dei Data Center di Google, poiché si dovrebbero realizzare migliaia di Data Center di grandi dimensioni, distribuiti a livello mondiale. Google utilizza Transparent Caching nella sua rete (Google Global Cache), e se ha bisogno di QoE, paga i Telco  per avere questo servizio (vedi V. Cerf “Knocking Down Strawmen”, IEEE INTERNET COMPUTING, Nov.-Dec. 2014) 
• I Telco non vogliono essere disintermediati dagli OTT/CSP (CSP = Content Service Provider, es. Akamai) e non accettano di avere “deep into their network” le piattaforme di Transparent Caching degli OTT/CSP, ma offrono servizi di terminazione con qualità migliorata, per i quali ricevono un pagamento  (two sides market).
• Netflix non propone più ai Telco/ISP la sua piattaforma di Transparent Caching, sia perché ha deciso di investire nei contenuti, sia perché molti Telco/ISP non accettano questa soluzione. Per migliorare la QoE, Netflix fa push sui Telco/ISP con un ranking pubblicato settimanalmente, e fa con loro accordi di revenue sharing.
• Qwilt, uno dei maggiori vendor mondiali di piattaforme di Transparent Caching, utilizzate anche da Telecom Italia, ha lanciato nel 2014 il progetto Streaming Video Alliance, che ha l’obiettivo di consentire “open caching", e che ha ottenuto il supporto di Content Provider, Content Service Provider, Vendor di apparati di networking (uno fra tutti, Cisco), Telco, ISP, ecc … (vedi anche questo articolo).

QUALI SONO I VANTAGGI ?

Prima di introdurre una qualsiasi nuova tecnologia in rete, è fondamentale chiedersi quali vantaggi questa comporta, e valutarne i costi/benefici in relazione ad altre tecnologie più o meno equivalenti. L'introduzione delle piattaforme di Transparent Caching non sfugge (ovviamente) a queste considerazioni. 

Vediamo quindi i vantaggi che si ottengono sia in termini più squisitamente tecnici e quindi economici.

• Aumento del Throughput delle applicazioni. Questa affermazione, benché intuitiva poiché legata all'avvicinamento dei contenuti agli end user, andrebbe sostanziata con dei numeri. Nella seconda parte di questo post quantificheremo l'aumento del Throughput con una semplice formuletta. Facciamo notare comunque che la valutazione dipende in modo essenziale dalla posizione nella rete delle piattaforme di Transparent Caching. Come sempre c'è un trade-off da risolvere, più si avvicinano i contenuti agli end user, migliori sono le prestazioni ma maggiori sono le piattaforme da inserire in rete, e quindi maggiori i costi.
• Diminuzione della banda necessaria in rete per il trasporto del traffico. E anche questa affermazione è abbastanza intuitiva. Infatti, una volta memorizzati i contenuti nella piattaforma di Transparent Caching, non vi è più bisogno di trasportarli dal content provider all'end user, ma solo dalla piattaforma agli end user, risparmiando quindi la banda nel segmento di rete dal content provider all'IP Edge. Se ci fate caso, tutto questo assomiglia molto al risparmio di banda che ottiene veicolando il traffico attraverso protocolli di routing multicast. 
• Maggiore affidabilità rispetto alle soluzioni tradizionali. Questo è un punto che va chiarito meglio. Nelle soluzioni tradizionali di caching, i contenuti vengono memorizzati in una piattaforma di storage, che è collegata all'IP Edge. Eventualmente, oltre alla piattaforma di storage, possono essere utilizzati dei sofisticati (e costosi !) apparati DPI (Deep Packet Inspection), per analizzare il traffico e decidere quale memorizzare. Tutto il traffico ingresso-uscita dall'IP Edge deve quindi passare per questo sistema, e per far questo si utilizzano nell'IP Edge funzionalità di PBR (Policy Based Routing), che per quanto sofisticate, non possono raggiungere livelli di granularità elevati. Ad esempio, non sono in grado di differenziare un traffico video da un traffico web, se entrambi questi tipi di traffico utilizzano a livello applicativo lo stesso protocollo (es. HTTP, come oggi avviene universalmente). Ora, se il collegamento tra il sistema di storage+DPI dovesse cadere, il traffico ingresso-uscita intercettato dal PBR, tutto il traffico HTTP ad esempio, rimarrebbe bloccato nell'IP Edge, almeno fino a quando non viene cambiata manualmente la configurazione del PBR. Con una piattaforma di Transparent Caching, inserita in rete nel modo illustrato nelle due sezioni precedenti, anche se l'intera piattaforma dovesse andare fuori servizio, il traffico verrebbe veicolato allo stesso identico modo di come avverrebbe in assenza della piattaforma, senza interruzione alcuna. L'unico problema è che ritornerebbe, almeno per i servizi video, a una QoE scadente. Il normale traffico web, che di solito non viene intercettato dalla piattaforma, continuerebbe a fluire regolarmente, senza interruzione alcuna.
• Risparmio complessivo dei costi di rete. Questo è un aspetto estremamente importante, che però deve essere sostanziato con una attenta analisi dei costi. Le variabili in gioco sono molte, dal costo delle piattaforme, al loro numero, che dipende a sua volta dalla loro posizione sulla rete, ai costi di esercizio (es. energia consumata, costo del personale per la gestione), al numero di end user, e altro. Nella seconda parte di questo post cercheremo di quantificare il cost saving che si ottiene dall'introduzione di queste piattaforme, dando ove possibile anche dei numeri che consentano di valutarne i benefici.

Dietro a tutto questo c'è comunque una domanda fondamentale che gli Telco/ISP che decidono di seguire questa strada, devono porsi. Quale è il modello di business da adottare, per fare in modo che l'introduzione delle piattaforme di QoE si traduca poi in maggiori ricavi, e non solo quindi in maggiori costi ? Perché è noto e arcinoto che nel nuovo mondo dell'Internet globale, chi ha fatto e chi sta facendo realmente i grossi affari sono i fornitori di contenuti, Google, Facebook, Amazon, Netflix ecc. ecc. . I Telco tradizionali mettono in campo una poderosa (e costosa) infrastruttura di rete, che però non genera che una piccola frazione dei ricavi dell'intera catena del valore.  

Qui termina la prima parte di questo post sulle piattaforme di Transparent Caching. Nella seconda parte, che sarà pubblicata di seguito, illustreremo, quantificandoli, i vantaggi in termini di Throughput che si ottengono con l'introduzione di queste piattaforme, i risparmi sui costi complessivi di rete, e daremo qualche idea sui modelli di business che i Telco/ISP tradizionali possono adottare, per far crescere i loro ricavi. 

A presto (terremoto permettendo) !