Joy Marino su Wikipedia, per chi non lo conoscesse.
ecco il testo che mi ha mandato: (cliccare sul link qui sotto)
Meme 1
Da Risposta a “Stefano Quintarelli su QoE e QoS”
1. Definizioni e commenti su QoS e QoE (in rosso le parti prese dai documenti ITU, ETSI e IETF)
L’ITU (il CCITT non esiste più da vent’anni…) fornisce la seguente definizione di QoE [ITU-T Recomm. P.10 [i.37]/G.100 Amendment 2]:
Quality of Experience (QoE): The overall acceptability of an application or service, as perceived subjectively by the end-user.
NOTES
1. Quality of Experience includes the complete end-to-end system effects (client, terminal, network, services infrastructure, etc).
2. Overall acceptability may be influenced by user expectations and context.
Questa definizione, molto generale, è ripresa da altri enti di normativa, come l’ ETSI, che definisce la QoE come segue [TR 102 643]:
Quality of Experience (QoE) : measure of user performance based on both objective and subjective psychological measures of using an ICT service or product
NOTES
It takes into account technical parameters (e.g. QoS) and usage context variables (e.g. communication task) and measures both the process and outcomes of communication (e.g. user effectiveness, efficiency, satisfaction and enjoyment).
The appropriate psychological measures will be dependent on the communication context. Objective psychological measures do not rely on the opinion of the user (e.g. task completion time measured in seconds, task accuracy measured in number of errors). Subjective psychological measures are based on the opinion of the user (e.g. perceived quality of medium, satisfaction with a service).
EXAMPLE: A service provider may conclude that a service with a certain level of QoS used for a particular communication situation offers users excellent QoE, whist with a different level of QoS provides poor QoE.
Quando si parla di QoE, si fa riferimento alla qualità che l’end-user rileva nella fruizione di un determinato servizio/applicazione/contenuto. Questa è la “qualità” importante per l’end-user, quella che lui è disposto ad acquistare, ma anche quella che, se diventa insoddisfacente, lo induce a “cambiare fornitore”.
La QoE è legata, ma è differente, dalla QoS (Quality of Service); ad esempio lo stesso documento ETSI sopra citato chiarisce che:
QoS work is based on technical performance (i.e. it is mainly technology-centred) whereas QoE is based on end-user behaviour (it is user-centred).
Quando si parla di QoS si fa riferimento a parametri tecnici relativi a come i flussi dati vengono trattati nella rete; fra i principali ci sono: bandwidth (or bit rate), delay, delay variation (jitter), packet loss.
Organizzazioni come IETF sviluppano meccanismi e soluzioni per costruire reti che cercano di ottimizzare i parametri di QoS. Esempi sono i modelli noti come ”intserv” [RFC 1633] e “diffserv” [RFC 2475] [ Cisco def: IntServ follows the signaled-QoS model, where the end-hosts signal their QoS needs to the network, while DiffServ works on the provisioned-QoS model, where network elements are set up to service multiple classes of traffic with varying QoS requirements ].
Senza entrare in dettagli, le tecniche di QoS , come l’uso di “classi di priorità” nei pacchetti, servono per ottimizzare il funzionamento della rete anche in caso di situazioni critiche (tenendo conto che le risorse di rete, come la banda, le “porte” nei router, la capacità complessiva di un router, ecc… non sono mai “infinite” ed hanno un costo).
QoE e QoS sono due cose ben differenti. Come si legge nelle parole di Gambardella e Ciccarella (di seguito G&C), nonché nelle definizioni di entrambe le autorità di standard citate, ITU e ETSI, QoE fa riferimento agli aspetti soggettivi dell'esperienza del fruitore, mentre QoS si basa su parametri tecnici misurabili, quali quelli citati (bit rate, delay, jitter, packet loss). Aggiungerei che sono diverse anche da un altro punto di vista: sui parametri di QoS è possibile avere garanzie di servizio misurabili, sotto forma di SLA (Service Level Agreement), per cui ad esempio il packet loss non deve mai scendere al di sotto di un minimo prefissato, o la bandwidth deve sempre essere maggiore o uguale ad un "minimo garantito".
Per un'esperienza soggettiva questo è praticamente impossibile da quantificare, per cui una QoE non potrà che essere definita in termini approssimati e statisticamente vaghi, del tipo di "per la maggior parte del tempo la qualità video è molto buona".
Per garantire la QoS occorrono due elementi, come indicato da G&C:
- l'allocazione dedicata di risorse tecniche di rete, che sono costose e mai "infinite";
- l'adozione di opportuni protocolli di rete, quali quelli definiti da IETF citati (intserv, diffserv).
Purtroppo i protocolli di QoS non sono facilmente interoperanti tra operatori diversi ed ancor di più nel contesto delle interconnessioni tra operatori Internet. Dall'altra parte i costi infrastrutturali implicano che un servizio con QoS deve necessariamente costare di più di uno in modalità BE (Best Effort).
Lo scenario della QoE è totalmente diverso. In particolare non è richiesta una QoS con parametri stringenti come sembrano implicare G&C: se così fosse, nessun servizio che il fruitore giudichi "soggettivamente buono" sarebbe mai stato erogato sopra Internet, notoriamente BE, mentre sono innumerevoli i servizi, anche citati da G&C, che vengono fruiti in ogni momento ovunque nel mondo con qualità "mediamente" molto buona.
Meme 2
Da Risposta a “Stefano Quintarelli su QoE e QoS”
Se la QoS non è “adeguata” (es. delay, jitter, packet loss troppo alti), non è possibile offrire agli end-users i richiesti livelli di QoE. Tuttavia, in molti casi non è possibile agire solo sulla QoS per garantire una QoE adeguata.
Chiariamo questo punto molto importante con un esempio.
- Prendiamo in considerazione la realizzazione di un collegamento di rete tra un end-user ed un sito WEB che fornisce servizi/applicazioni/contenuti
- Il collegamento viene progettato in modo tale da avere un bit rate di 50Mbps, valori di latenza, packet-loss e jitter “il più bassi possibile”, ed in modo da fornire le migliori prestazioni in termini di QoS consentite dalle reti IP attraversate (ad es. si realizza un IP-VPN, con risorse dedicate).
- Si noti che sul bit-rate non ci sono vincoli (se non il costo) a realizzare velocità anche superiori a 50 Mbps. Anche su jitter e packet loss si può lavorare per ottenere valori estremamente bassi (tenendo conto che, a parità di altri parametri, il packet loss dipende dalla distanza).
- La latenza presenta dei “limiti fisici” intrinseci, legati alla distanza fra sito WEB ed end-user ed al numero di router attraversati sulle reti IP che collegano il WEB e l’end-user. I limiti fisici sono ad es. i ritardi di propagazione trasmissiva, i tempi di attraversamento dei router, i tempi di codifica e di trattamento del segnale nell’ultimo miglio,…
- A causa dei “limiti fisici”, non è possibile ridurre il valore della latenza sotto una certa soglia se si utilizzano le tecniche di QoS (come ad esempio la assegnazione di priorità e la realizzazione di circuiti virtuali “dedicati”)
- Assumiamo ora che il canale così realizzato sia usato per fruire di applicativi (es. WEB Browsing, Streaming Video, File Transfer, Peer-to-Peer). Gli applicativi utilizzano protocolli a livello superiore rispetto al livello IP.
- La QoE per l’utente dipende, in gran parte, dal “throughput” a livello applicativo, cioè dalla effettiva velocità di trasferimento delle informazioni a livello applicativo (non dal bit-rate trasmissivo del collegamento).
- Il punto fondamentale è il seguente: il throughput dipende certamente dal bit rate (non può mai essere più alto del bit-rate), ma dipende molto anche dalla latenza (e dal packet loss).
- Più precisamente, il throughput a livello applicativo (QoE) è inversamente proporzionale alla latenza (esistono formule che consentono di calcolare il Throughput in funzione di Latenza e Packet Loss).
Ad es. considerando il download di un file da 4GByte, Akamai [Akamai 2012 Investors Summit] ha rilevato che, con una latenza di 1,6ms ed un packet loss=0,6% , il throughput che si ottiene per il download del file è di 44Mbps, ed è quindi possibile scaricare il file in poco più di 12 minuti. Invece con una latenza di 96ms, ed un packet loss=1,4% il throughput si riduce soltanto a 0,4Mbps, e ci vogliono ben 20 ore per scaricare il file !
Questo esempio chiarisce che le tecniche per la QoS non sono sufficienti, in alcuni casi, per avere livelli adeguati di QoE.
Nell'esempio si parla di parametri tecnici di QoS "più bassi possibile": mi sembra sia un ossimoro, questa definizione si adatta esattamente ad un servizio erogato in "Best Effort"!
In secondo luogo, non è genericamente vero che il throughput sia inversamente proporzionale alla latenza: se così fosse nessuna trasmissione via satellite consentirebbe velocità decenti, perché è noto che la latenza nelle comunicazioni via satellite è di alcune centinaia di ms.
In realtà i valori citati corrispondono ad una trasmissione via protocollo TCP/IP (solo una dei numerosi protocolli utilizzabili via Internet), ed inoltre solo nel caso che certi parametri del protocollo assumano valori di default piuttosto obsoleti, ad esempio nel caso di vecchie versioni del s.o. Windows XP. Tutti i sistemi operativi moderni sono in grado di dare prestazioni trasmissive in situazioni di latenza alta molto migliori, soprattutto quando si tratta di trasmettere files di grandi dimensioni (come nell'esempio citato). Diverso è il discorso nel caso di una semplice "navigazione Web", ma non mi pare che questa rientri negli interessi di G&C (peccato perché buona parte dei ricavi degli operatori di accesso, nonché i ricavi da pubblicità dei citati OTT/CP, dipendano dalla percezione di buona qualità della mera “navigazione").
Ben diverso è il discorso per quanto riguarda il packet loss. Qualsiasi comunicazione che abbia una perdita di pacchetti superiore al 1% viene gravemente deteriorata (ancor di più se la latenza è alta), a meno che non preveda provvedimenti a priori (ad esempio: correzione d’errore). Tanto è vero che nel definire come deve essere, in termini statistici, un servizio di accesso BE, si specifica che il tasso di perdita di pacchetti debba essere al disotto di un valore minimo accettabile salvo in caso di particolari - e rare - situazioni di congestione. Se il packet loss è alto è il segno che la rete di accesso non è più adeguata ai livelli di utilizzo ed è tempo di adeguare l’infrastruttura di rete.
Parlando di QoE a livello applicativo occorre evidenziare che l'erogatore dell'applicazione, sia esso un OTT o un CP, ha la possibilità di adottare software e protocolli specifici, riuscendo a far percepire al fruitore una QoE buona anche in caso di reti BE con latenze medio-alte. Per richiamare l'esempio, un servizio di accesso che fornisca 50 Mbps in BE (ad es. nel 95% del tempo, come da definizione di AGCOM) e con una latenza mediamente entro 10 ms sarebbe adeguato per il download di files di 4 GByte, imponendo solo un piccolo ritardo iniziale.
Diverso infine è il caso delle CDN (Content Delivery Network), come la citata Akamai: il mestiere di queste è quello di velocizzare la fruizione dei contenuti Web in modo trasparente per l'utente e senza interventi sui protocolli o sull'applicazione. È soprattutto per le CDN, ed in misura molto minore per i CP, che interviene un'altra modalità per ottenere QoE anche quando la QoS non è garantita lungo tutta la filiera dal server su Internet al dispositivo di fruizione dell'utente finale. Come vedremo qui sotto.
Meme 3
Da Risposta a “Stefano Quintarelli su QoE e QoS”
Per questo, è necessario utilizzare altri tipi di soluzioni, che sono in grado di migliorare la QoE e che, in prima approssimazione,
- avvicinano i contenuti all’end-user (tecniche di “distribuzione” dei contenuti)
- rendono più “efficaci e veloci” i protocolli di comunicazione utilizzati
Queste tecniche (molto diverse dalle tecniche per la QoS) sono realizzate dalle ”piattaforme per QoE”, come Content Delivery Networks, Transparent Cache, Application Delivery Networks, WEB Acceleration Platforms, Front End Optimization Platforms, …
Le piattaforme per la QoE lavorano “al di sopra” del livello IP e sono utilizzate da anni, al di fuori delle reti domestiche, da soggetti che operano a livello internazionale (Akamai, Level3, Google, Netflix,…).
Per soddisfare i crescenti requisiti di qualità, le piattaforme per la QoE devono essere realizzate anche “dentro” le reti domestiche dei Telco/ISP e devono essere sempre più vicine agli end user. In questo modo infatti si riduce la “distanza” che i flussi di traffico devono percorrere, e quindi si riduce la latenza, ottenendo livelli di throughput più alti e migliore QoE.
Nella rete domestica sono possibili due alternative per realizzare le piattaforme per QoE: le piattaforme sono realizzate da OTT/CP , oppure da Telco/ISP.
I due casi presentano differenze significative:
l’OTT/CP realizza la propria piattaforma per QoE, che inserisce “dentro” la rete del Telco/ISP vicino agli end user (fino alla rete di accesso verso gli end user). Se la piattaforma per QoE venisse realizzata da un OTT nella rete di un Telco/ISP, sarebbe solo quello specifico OTT che utilizzerebbe questo tipo di terminazione, poiché l’OTT non ha e non avrà obblighi regolatori. La piattaforma per QoE sarebbe quindi “dedicata all’OTT” che è in grado di investire e/o di indurre il Telco/ISP ad accettare di ospitare le piattaforme dell’ OTT/CP.
Questa sarebbe una vera barriera per piccoli OTT/CP e consentirebbe di rafforzare la posizione dominante dei ben noti Hypergiants.
Se invece le piattaforme per QoE fossero realizzate da un Telco e la terminazione con qualità fosse fornita dal Telco, che deve offrire lo stesso tipo di servizio a qualunque OTT/CP, la possibilità di terminare il traffico con adeguata QoE sarebbe a disposizione di qualunque OTT/CP, indipendentemente dalla sua dimensione.
E’ importante evidenziare che nel “Caso b.”, in cui il Telco/ISP mette a disposizione il servizio di terminazione con qualità differenziata a tutti gli interessati, si favorisce lo sviluppo di nuovi modelli di business fra Telco/ISP ed OTT/CP (ad es. modelli basati su revenue sharing) e si determinano le condizioni per relazioni di tipo “multi-side market”. La diffusa realizzazione dei nuovi modelli può dare un notevole impulso allo sviluppo di Internet ed è attuabile rapidamente, mediante negoziazione diretta fra le parti, senza richiedere nuovi interventi di tipo legale o regolatorio.
Anche G&C arrivano ad affermare che le tecniche più adatte a dare QoE in assenza di una QoS vera e propria sono quelle comunemente utilizzate da Akamai e simili ("Content Delivery Networks, Transparent Cache, Application Delivery Networks, WEB Acceleration Platforms, Front End Optimization Platforms, …")
Si tratta in effetti di tecniche che operano sopra in livello IP, e sono del tutto trasparenti al fruitore finale, il quale continua a vedere gli stessi contenuti con le stesse applicazioni, solo che, quando il meccanismo di caching trasparente interviene, i contenuti provengono da un server che è più prossimo. Sostenere che una tecnica di questo tipo violi la Network Neutrality è assurdo. Nessun servizio viene penalizzato o artificialmente ritardato per dare la precedenza, anzi, il traffico sulle interconnessioni tra operatori viene alleggerito in caso di CDN, diminuendo il rischio di “colli di bottiglia”. Nessun fruitore viene artificialmente discriminato nell'erogazione del servizio di caching trasparente, le uniche discriminanti essendo la posizione geografica del fruitore (cache diverse servono regioni geografiche diverse più o meno bene) o, al più, l'operatore di accesso di cui è cliente (perché non tutti gli operatori partecipano al posizionamento delle cache, vedi sotto).
La controprova che si tratta di tecniche che non alterano la NN è data dal fatto che queste tecniche operano egregiamente sulle reti BE, senza dover ricorrere a particolari privilegi di QoS. In particolare per far funzionare queste tecniche non è affatto necessario quel sistema di QoS interoperante tra gli Operatori europei che sarebbe alla base della proposta della Kroes da cui tutto l'interminabile dibattito che ha coinvolto Quintarelli, Gambardella, Ciccarella, De Biase, e numerosi altri, era partito.
Dove è più opportuno posizionare le cache (cioè i server che gestiscono questi contenuti "velocizzati") è un dato di progetto di chi realizza il servizio e tutte le opzioni sono, almeno sulla carta, aperte, fermo restando che minore è la latenza per raggiungere il fruitore finale, migliori saranno le prestazioni. Il fornitore del servizio di CDN (G&C distinguono due tipologie diverse che per il momento vengono trattate congiuntamente) sceglierà a seconda del rapporto costi/prestazioni delle diverse alternative.
Per servire i clienti di un insieme di operatori di accesso medio-piccoli potrebbe non essere conveniente posizionare più cache in ognuno di essi, ed un unico sistema di cache presso un punto di interscambio che sia prossimo (in latenza) a tali operatori potrebbe essere preferibile, specie se sia il fornitore di CDN che gli operatori di accesso dispongono di connessioni capienti ed a costo marginale con il punto di interscambio, come accade normalmente in caso di peering gratuito.
Per servire i clienti di un operatore di accesso grande potrebbe essere preferibile posizionare le cache all'interno della rete dell'operatore stesso, scelta che va pesata rispetto al costo che l'operatore potrebbe chiedere per ospitare il servizio (o in cui incorre se lo realizza per sé). In ogni caso il posizionamento dentro la rete consente di eliminare i colli di bottiglia dovuti alle interconnessioni tra operatori (oltre a ridurre una parte della latenza). Però la porzione di rete che termina sul cliente finale di accesso verrà comunque attraversata in modalità BE e la latenza legata a quella tratta non potrà essere annullata.
Prendiamo ora in considerazione le due alternative che prospettano G&C.
Dal punto di vista del Ecosistema di Internet non dovrebbero essere opzioni alternative, ma complementari e coesistenti, al fine da dare a tutti la più ampia possibilità di scelta ed avere un mercato competitivo e sano anche dei servizi CDN.
Diverse sono le necessità a seconda degli attori, per cui è opportuno prenderli in considerazione separatamente.
- Per un CP globale la prima esigenza è quella di raggiungere tutti i potenziali fruitori in modo uniforme e trasparente e, preferibilmente, con costi comparabili in tutto il mondo. Cercherà quindi di affidarsi a soggetti che abbiano copertura globale e che offrano una modalità di gestione dei contenuti standardizzata. Una CDN globale è quindi preferita; potrebbe essere accettabile un insieme di operatori di accesso che aderissero ad uno standard universale di gestione dei contenuti, ma rimarrebbe sempre la complicazione dei rapporti economici con svariati fornitori.
- Un CP/OTT sceglie di appoggiarsi sia a soggetti CDN “terzi" (“buy”) sia ad una propria rete di distribuzione di contenuti (“make”), graduando le due soluzioni secondo costi/benefici. La trasparenza del servizio e la standardizzazione delle modalità di gestione sono indispensabili, mentre sarà il costo o la dipendenza dei costi dai volumi di contenuti fruiti, ad orientare la scelta tra make e buy.
- Per un operatore CDN che sia "terzo" rispetto ai potenziali clienti CP una discriminazione di qualunque tipo sui potenziali clienti sarebbe controproducente: dopotutto opera in un mercato aperto dove ci sono altri soggetti consimili e concorrenti, ed ogni cliente rifiutato è un cliente per la concorrenza. Al più potrebbe avere inefficienze gestionali che lo rendono poco appetibile per CP medio-piccoli, ma questa sarebbe un'opportunità per un concorrente per sviluppare soluzioni per quella nicchia di mercato.
- Un operatore di accesso Telco/ISP che sceglie di offrire un servizio di CDN (sottolineo: trasparente e senza una QoS discriminatoria su cui basarsi), avrebbe piena libertà di offrire il servizio a qualsiasi categoria di OTT/CP volesse, perché non esiste obbligo regolamentare su questi servizi, purché non crei barriere artificiali alla concorrenza per soggetti CDN indipendenti e non discrimini il servizio per particolari tipologie dei suoi clienti (verso cui ha, in effetti, un obbligo regolamentato). Già oggi questo è possibile e, se davvero gli OTT e le CDN discriminassero quali clienti CP accettare e quali discriminare, gli operatori avrebbero un’ottima opportunità di business da sfruttare. Ma evidentemente non è un mercato aperto dei servizi con soggetti, anche diversi, in concorrenza, quello che interessa il Telco/ISP.
È importante evidenziare che fin qui si è parlato semplicemente di QoE, come del resto fanno anche G&C. Nell'ultimo capoverso sopracitato, ecco ricomparire la QoS che era stata detta non sufficiente e non necessaria. Anzi, sembra che "la terminazione con qualità differenziata" sia:
i) possibile sia nel caso a. (soggetti CDN, OTT, CP) che nel caso b. (soggetto Telco),
ii) indispensabile per le piattaforme di QoE. Entrambi gli assunti sono in contraddizione con quanto argomentato più sopra.
Nella realtà nessuno tranne il Telco che "possiede" i clienti di accesso ha modo di alterare la QoS. D’altra parte il cliente/fruitore è interessato ad avere un'esperienza "di qualità", ma avrebbe molto da ridire se questa fosse ottenuta a scapito degli altri servizi che utilizza, senza il suo consenso informato. Ed infine un Telco in genere Ha dato prova di essere più interessato a legare a sé i clienti proponendo servizi esclusivi che non siano replicabili dagli altri ISP o Telco, piuttosto che cooperare per offrire soluzioni di CDN che siano aperte, interoperanti ed utilizzabili con pari condizioni da CP grandi e piccoli.
Meme 4
Da commento 29 a “Stefano Quintarelli, una visione fin troppo parziale”
Su tali punti si osserva quanto segue.La QoS sulla rete di accesso è certamente utile ed è infatti già normalmente gestita da Telco/ISP per fornire adeguate prestazioni agli end-user. Il punto chiave però è che la QoS sull’accesso NON consente di fornire alcuni dei servizi che oggi sono già offerti sulle reti IP e non consente di fornire nuovi servizi IP come ad es. quelli che richiedono un alto throughput (es. streaming video 4K, WEB Acceleration, servizi Cloud). E’ necessario lavorare a livello della rete domestica di un Telco o di un ISP (su tutta la rete, non solo sull’accesso) ed a livello delle reti internazionali per consentire ad es. a Netflix o a Google o a qualunque OTT/CP di fornire, senza limitazioni da parte delle reti, i loro servizi. In particolare le piattaforme necessarie, come già detto, oltre a quelle della QoS, sono quelle della QoE, già utilizzate da anni da OTT/CP (i Telco/ISP hanno cominciato solo recentemente a considerare ed utilizzare queste piattaforme).
Con riferimento a che cosa i Telco/IPS possono/devono offrire ai fornitori di contenuti, i punti chiave sono:
- i fornitori di contenuti non acquistano QoS, ma chiedono QoE (d’altra parte anche gli end user sono interessati alla QoE, non alla QoS…) per poter offrire i loro servizi ed allargare la base clienti.
- nel caso in cui la rete domestica del Telco/ISP non sia in grado di fornire un’adeguata QoE, tipicamente l’OTT/CP utilizza la propria piattaforma per QoE, che chiede di inserire “dentro” la rete del Telco/ISP vicino agli end-user (fino alla rete di accesso verso gli end-user). Questo approccio consente di fornire servizi con adeguata QoE, ma “disintermedia” completamente il Telco/ISP, che si trova ad avere gravi problemi di sostenibilità economica.
- L’alternativa è quella seguita ormai da molti Telco: fornire, oltre alla terminazione best effort, anche terminazione con qualità differenziata agli OTT/CP. La stessa modalità di terminazione può essere utilizzata da qualunque OTT/CP, in linea con i veri principi della Net Neutrality. Questo consente ai Telco/ISP di avere ricavi sia da end user, sia da OTT/CP, in relazione agli specifici benefici che i diversi soggetti ottengono.
Come già osservato precedentemente, sarebbe bene non confondere QoS e QoE, che sono concetti disgiunti e non consequenziali. Come osservano anche G&C, quando parliamo di contenuti “fruibili” quello che interessa è la QoE ai fruitori e, conseguentemente, ai produttori.
In realtà esistono categorie di clienti che sono interessati alla QoS, magari sono proprio quelli a cui fa riferimento la Kroes parlando di applicazioni “mission critical”, ma rientriamo nella classe degli usi professionali della rete, dove forse è possibile spuntare prezzi premium per i servizi erogati, ma anche dove è il cliente finale che ha necessità e competenza per negoziare quali servizi vuole avere con qualità ed ottenere i livelli di servizio garantiti che gli interessano.
Una categoria di utenti che non sembra particolarmente interessante per G&C, i cui esempi di fruizione sono tutti riferiti all’ambito simil-televisivo, una categoria di servizi che notoriamente devono avere i più bassi costi per volume trasportato, dovendosi confrontare con le tecniche broadcast sia terrestri che satellitari.
La nota di G&C rivela il nodo centrale di tutta la contrapposizione tra i servizi CDN realizzati da soggetti terzi e quelli che potrebbero erogare gli operatori di accesso sulle proprie reti. La preoccupazione dei Telco è quella di essere disintermediati ed in conseguenza di questo subire “problemi di sostenibilità economica”. Ne consegue che l’ipotizzata alternativa secondo cui siano i Telco ad intervenire sulla QoE, ma non utilizzando le tecniche di caching che si sono fin qui dimostrate adeguate a dare una buona QoE al fruitore, bensì attraverso uno stravolgimento dell’architettura, imponendo la differenziazione della qualità nella terminazione sul “ultimo miglio”!
Intanto si osserva che essendo una alternativa che nasce con scopi difensivi (proteggere i propri interessi economici messi a rischio dalla disintermediazione) dovrebbe essere mutuamente esclusiva e non coesistente con i servizi delle CDN di terze parti, producendo quindi una restrizione, anziché un’apertura del mercato.
In secondo luogo una CDN, o anche un OTT/CP che volesse posizionare i propri server nella rete del Telco/ISP dovrebbe fare investimenti infrastrutturali e pagare un costo per i servizi erogati dal Telco, ponendosi quindi su un piano di parità rispetto ad analoghe iniziative del Telco stesso (e migliorando il suo conto economico).
Infine occorre chiarire bene quali sono le risorse di rete che sono scarse e che mettono a rischio la sostenibilità economica del Telco.
Ipotizziamo che siano quelle relative all’ultimo miglio. In questo caso dovrebbe comunque essere diritto del cliente di accesso di ottenere quella banda trasmissiva “media” che il suo contratto “best effort” si impegna a dargli (ad esempio secondo le modalità di qualità misurabile che AGCOM ha stabilito per il sistema “Misura Internet”). Se questa velocità trasmissiva è data, sarà una scelta del cliente come utilizzarla nell’ambito dei suoi interessi, e quindi se, ad esempio, una famiglia tipo sta aggiornando il sistema operativo del desktop, sta caricando su cloud le foto dell’ultima vacanza, sta vedendo un film in HD e navigando su web per la ricerca di scuola, forse non si stupirà se il film “parte” con qualche minuto di ritardo o se la navigazione non è rapida come di consueto. In ogni caso, se la somma dei consumi è in linea con il contratto di servizio sottoscritto, la decisione su quali servizi eventualmente privilegiare deve essere nelle mani di chi ha sottoscritto il contratto di accesso, e non certo in quelle di una ignota entità, dall’altra parte del mondo, che ha interesse a spuntare un cent in più di pubblicità velocizzando i suoi video.
Immaginiamo che le risorse scarse siano quelle che collegano la rete del operatore con il resto di Internet. È molto difficile a credere, perché il mercato dell’interconnessione globale è molto competitivo (ci sono circa una dozzina di player globali in concorrenza tra loro) come dimostra la discesa dei prezzi in Europa e negli US. Ed in ogni caso è possibile realizzare innumerevoli accordi di “peering gratuito” tra operatori che afferiscono ad una stessa area geografica (regione, nazione, continente), che consentono di abbattere a costi marginali una consistente quota del traffico inter-operatore. In fine, la stessa “value proposition” degli operatori di CDN è basata sull’abbattimento del traffico globale a favore di traffico dai server di cache all’interno della rete dell’operatore verso le terminazioni cliente; quindi un Telco/ISP che avesse problemi di sostenibilità economica in questo segmento di rete dovrebbe accogliere a braccia aperte i temuti CDN indipendenti.
Infine il collo di bottiglia potrebbe essere dovuto all’infrastruttura di distribuzione geografica (backbone e backhauling) dell’operatore Telco. Intanto si tratta di una infrastruttura sotto il totale controllo del Telco stesso (mentre operatori “ISP” più piccoli possono dipendere in parte dai servizi wholesale acquistati da un Telco), quindi tutto quanto riguarda le prestazioni e le tecniche di gestione (dal capacity planning all’utilizzo di tecniche di controllo della congestione del traffico che sono al di sotto del livello IP) sono sotto la sua responsabilità e pianificazione. È evidente che progettare e realizzare una rete NGAN di tipo Ultra Larga Banda senza potenziare adeguatamente l’infrastruttura di distribuzione è peggio che fare le nozze con i fichi secchi. Per quanto riguarda i costi infrastrutturali, se da tempo non esistono barriere “dure” all’incremento della banda trasmissiva che viaggia su fibre ottiche, per cui il costo cresce logaritmicamente (cioè cresce linearmente per ogni raddoppio della capacità); lo stesso vale per gli apparati di commutazione (switch, router), dove, con l’entrata in produzione delle interfacce ottiche a 100 Gbps, i costi tornano a crescere logaritmicamente.
In conclusione, contrariamente a quanto scriveva lo studio A.T. Kearney commissionato dalle Telco nel 2010, i costi infrastrutturali continueranno essere sostenuti per la massima parte dai ricavi dei clienti di accesso, e solo in misura marginale, se mai, dai ricavi di altro tipo (servizi premium con QoS per clienti business, affitto spazi e bandwidth a CDN/CP/OTT, …). E saranno sostenibili perché i ricavi cresceranno linearmente con il numero di terminazioni ULB affittate, mentre i costi cresceranno logaritmicamente.
La domanda vera, però, specie in un Paese come l’Italia, è se ci sono le killer application che convincano il cliente finale ad acquistare terminazioni a 50 Mbps, pagandole il giusto ed ottenendone la piena fruibilità, oppure se offerte di questo genere continueranno ad essere classificate come “ADSL appena un po' più veloci” e come tali con ben poca attrattività.
Meme 5
Da commento 29 a “Stefano Quintarelli, una visione fin troppo parziale”
La proposta che sia l’ end user a decidere verso quali siti/contenuti applicare QoS o QoE è assolutamente impraticabile per le seguenti ragioni:
- l’ end user può decidere che tipo di accesso vuole acquistare in termini di bit rate (es 7M, 20M, 100M…) ma, in generale, non conosce quali sono le specifiche prestazioni di rete necessarie per poter fruire di uno specifico servizio e contenuto. Ad es non è detto che tutti gli end user sappiano che per lo streaming 4K è necessario un bit rate di 10M o 20M.
Cosa ancora più importante, il cliente in generale utilizzerà servizi (come lo streaming 4K) di fornitori diversi (es Netflix, Youtube, Apple ecc..). Se fosse quindi il cliente ad indicare verso quali siti e per quali contenuti applicare QoE/QoS, il cliente dovrebbe, ogni volta che vuole utilizzare un sito/fornitore, fare una specifica richiesta (alla quale è associato un costo per l’end-user) e ciò richiederebbe un’azione di provisioning nella rete! Questa modalità operativa è chiaramente insostenibile.
- Gli OTT/CP che forniscono servizi e contenuti vogliono raggiungere il maggior numero di clienti con una QoS/QoE adeguata per massimizzare la customer base. Sono quindi loro che, come sempre avvenuto, si preoccupano di garantire che il trasporto abbia una qualità adeguata, e per far questo definiscono accordi con i Telco/ISP che forniscono gli accessi internet agli end users. Gli accordi possono prevedere l’acquisto di terminazione con qualità differenziata, oppure, se il Telco/ISP non dispone di questo tipo di trasporto, l’accordo può essere relativo all’ inserimento nella rete del Telco di piattaforme dell’OTT che realizzano la QoE.
Innazitutto, non è vero che la proposta di Quintarelli riguardasse siti o contenuti; la proposta riguardava servizi.
Si osservi che nell’ultimo capoverso compaiono numerosi termini qualitativi (“maggior numero di clienti”, “qualità adeguata”, “qualità differenziata”) che non implicano nessuna garanzia di servizio. Un tempo la Rolls Royce prometteva per le sue autovetture una “potenza sufficiente” per le aspettative dei suoi - facoltosi - clienti. Ma in questo caso siamo in un mercato di massa, e le possibilità di verificare la qualità di entrambe le tipologie di clienti del Telco (il quale, nella visione di G&C si propone come intermediario di un two-sided market tra produttori e fruitori di contenuti) sono quasi nulle: il CP potrà avere contezza solo in termini statistici di quanto bene vengono fruiti i suoi contenuti (e quindi si ritorna al punto di partenza: si tratta ancora di un BE!) Gli utenti finali sono, nelle parole stesse di G&C, ignoranti di quanto necessitano e di quello che viene erogato loro. L’unica arma che rimane loro è quella, assai spuntata, della rescissione del contratto di fornitura, che è, nella migliore delle ipotesi, tipicamente onerosa e molto lenta, e che in alcune aree geografiche potrebbe non essere nemmeno possibile.
La proposta di Quintarelli faceva esplicito riferimento alla QoS (e non alla QoE per cui, come già scritto, non è possibile dare garanzie misurabili). Considero due livelli possibili:
a) una prioritizzazione a livello della coda dedicata al cliente (“last mile”, in ogni caso una risorsa dedicata e non contendibile);
b) una vera garanzia di servizio end-to-end tra due postazioni ovunque in Internet.
La prima non dovrebbe suscitare scandalo nel operatore o appelli all’incompetenza ed ignoranza del cliente. Intanto si tratta di una tecnologia già presente e che ha un certo grado di diffusione, specie nel settore SOHO (“small office - home office”): dispositivi che assegnano priorità differenziate per tipologie di servizio, secondo la libera scelta ed il totale controllo del titolare della linea ADSL, sono già diffusi. Intervenendo “a valle” della linea non sono così efficienti come se fossero “ a monte” della stessa, ma il concetto è provato funzionare e, soprattutto, è in pieno accordo con il principio che sulla risorsa a lui dedicata è il cliente finale che ha diritto di stabilire che cosa è prioritario e che cosa non lo è.
La seconda in effetti implica davvero che venga gestito un completo provisioning della rete, come osservano G&C. Ad esempio, il progetto ETICS, finanziato dalla Comunità Europea, e che, in qualche modo, sta dietro la proposta di servizi QoS del Single Market europeo (ASQ), delinea un insieme di protocolli e sistemi di gestione per la QoS inter-operatore che non possono esimere dal provisioning delle risorse lungo tutta la catena. Ed è un ovvia considerazione quella che, se si pensa che una tale gestione non è realizzabile, allora l’intero progetto di QoS interoperante diventa improponibile. Ma qualcuno - qualche Telco intendo dire - dovrebbe spiegarlo ai paladini del “Telecom Single Market” europeo…
Meme 6
Da commento 29 a “Stefano Quintarelli, una visione fin troppo parziale”
Questa seconda soluzione (l’ inserimento nella rete del Telco di piattaforme dell’OTT che realizzano la QoE) dovrebbe preoccupare le persone che difendono l’apertura del mercato e che vogliono evitare la costituzione di SPM. Infatti:
- Se la piattaforma per QoE fosse realizzata da un OTT nella rete di un Telco/ISP, sarebbe solo quello specifico OTT che potrebbe utilizzare questo tipo di terminazione. La piattaforma per QoE sarebbe quindi dedicata all’OTT che è in grado, viste le sue dimensioni, di investire e/o di indurre il Telco/ISP ad accettare di ospitare le piattaforme dell’ OTT/CP. Questa sarebbe una vera barriera per piccoli OTT/CP e consentirebbe di rafforzare la posizione dominante dei ben noti hypergiants.
- Se invece la terminazione con qualità (QoE/QoS) venisse fornita dal Telco/ISP che deve offrire lo stesso tipo di servizio a qualunque OTT/CP, la possibilità di terminare il traffico con adeguata QoE sarebbe a disposizione di qualunque OTT/CP indipendentemente dalla sua dimensione.
Inoltre se il Telco/ISP avesse un suo market place collegato alle piattaforme per QoE/QoS, qualunque applicazione/contenuto potrebbe essere inserito nel market place e potrebbe raggiungere i clienti del Telco/ISP e più in generale tutto l’ecosistema IP con adeguata qualità. Il costo per l’OTT/CP (in genere basato su modelli pay-per-use) è estremamente più basso rispetto ad altri tipi di soluzione che prevedano la realizzazione a carico dell’ OTT/CP di infrastrutture di rete e di soluzioni per la distribuzione di contenuti.
L’unica cosa che dovrebbe preoccupare le persone che difendono l’apertura del mercato è la mancanza di alternative. Sarebbe un’ottima cosa se esistessero più soluzioni alternative per facilitare la fruizione di contenuti alla popolazione di clienti finali di un dato Telco, e per di più secondo le due alternative proposte, e cioè:
a) più piattaforme per QoE realizzate da CDN (come Akamai, Lime Light, CDNetworks ed altri), oppure da OTT/CP (come Google, Amazon, Apple[1] o altri) ospitate sulla rete del Telco;
b) una piattaforma per QoE fornita dal Telco stesso a prezzi competitivi sia ai grandi OTT che ai piccoli CP.
Soprattutto ricordando che - come Chris Anderson scrive e Amazon dimostra - c’è molto valore nelle Long Tail in Internet: il primo dei CP, Google/Youtube, pesa solo per il 10% del totale; chi riuscisse ad offrire una soluzione di QoE decente ai piccoli CP potrebbe incassare di più che da 3 Google messe insieme!
Perché il Telco non accetta la sfida e compete? Perché deve aver bisogno di un mercato protetto (cioè un non-mercato) per investire in un servizio?
Ma la domanda porterebbe lontano. Perché dovremmo chiederci allo stesso modo perché chi aveva risorse per investire e rapporto diretto con il cliente finale ha perso le occasioni del business del Search (Google è arrivato ultimo di una discreta serie di iniziative nate fin dagli anni ’90), della distribuzione di contenuti video (Netflix è nato come piccolo distributore alla Blockbuster; Casa di Alice, Cubovision, per rimanere in Italia, avevano risorse e mercato ben prima), della videoconferenza su Internet, e così via.
[1] Non vorrei incorrere per troppa fretta nell’equivoco (equivoco?) in cui è caduto Bernabé: Apple è una azienda manifatturiera, Amazon è un’azienda di commercio elettronico, ed entrambe sono intermediarie nella distribuzione di beni (come libri, musica, app). I loro fatturati riflettono questi modelli di business, in analogia ad altre imprese commerciali. Qui sono aggregate come “OTT/CP” solo per brevità.
Commenti