BBC a NL: distribuzione IP è il futuro che sta sostituendo DTT, satellite e cavo coassiale con vantaggi enormi anche sul quale qualitativo. Ma con un’infrastruttura di proprietà (come BIDI) che può garantire qualità e latenza voluti, sotto il controllo del broadcaster.
Il multicast è regolarmente proposto come soluzione potenziale al problema della scalabilità, ma non è mai stato implementato nella distribuzione dei contenuti BBC (audio o video). Esistono numerosi progetti di ricerca che ne dimostrano l’efficacia, ma nulla e’ mai stato implementato in produzione.
Di switch in switch
A seguito della pubblicazione da parte di NL di numerosi articoli riguardanti il futuro spegnimento dell’FM (che potremmo forse meglio definire il passaggio dell’unico medium rimasto analogico, la Radio, nell’era digitale), si è sviluppato un ampio dibattito sui vari canali social.
Uno dei filoni più interessanti può essere riassunto come segue: “Ce la farà la rete a supportare tutti gli utenti che attualmente utilizzano l’FM?”.
Il casus (belli) DAZN
La stessa preoccupazione – relativa però alla televisione – è stata espressa da AGCOM a riguardo alla prossima stagione della Serie A, distribuita in esclusiva IP da DAZN. La tematica è la medesima ed è destinata a divenire sempre più importante.
Pubblicità
BIDI, la bacchetta magica della BBC
Abbiamo pertanto deciso di approfondire l’argomento tramite un’analisi dell’infrastruttura BIDI della BBC (che ci ha rilasciato delle dichiarazioni dirette) – che ha iniziato a porsi questo problema da oltre un decennio – ed un’intervista a Francesco Triolo di Meway.
Il problema
Cominciamo col riassumere il problema: la diffusione FM (e DAB) è di tipo intrinsecamente “multicast”: uno stesso flusso elettromagnetico viene trasmesso da un unico device (trasmettitore con relativa antenna) e ricevuto da un numero potenzialmente illimitato di utenti (dotati di antenna e ricevitore/decoder).
Scalabilità
Non esistono problemi di scalabilità, semmai di poca efficienza globale quando gli ascoltatori sono scarsi o sintonizzati su molti canali differenti.
Lo Streaming classico
Nel caso dello streaming IP, il metodo classico di distribuire i contenuti è unicast: uno streaming server centralizzato apre una connessione con ciascun client (utente ascoltatore) a cui fornisce un flusso individuale, eventualmente tarato sulla banda passante dell’utente. Il traffico sulla rete è quindi inutilmente composto da migliaia di flussi tutti uguali, ciascuno destinato ad un singolo ascoltatore.
Un modello inadeguato
Con l’unicast il broadcaster deve decidere a priori quanti utenti contemporanei gestire (per dimensionare server e relativi costi); la scalabilità non è garantita e l’aumento di capacità risulta spesso molto complesso.
Inoltre, in caso di grande numero di connessioni (ad esempio per un concerto, o un evento di cronaca improvviso) il server raggiunge rapidamente il numero massimo di connessioni. Lasciando i potenziali ascoltatori con un bel messaggio di errore (incomprensibile come da sana tradizione informatica).
Multicast
Una soluzione spesso proposta consiste nel trasmettere pacchetti multicast, cioè privi di un indirizzo unico di destinazione. Questa tipologia di diffusione era già stata utilizzata agli albori del web, ad esempio per la trasmissione del concerto dei Rolling Stones del novembre 1994 al Cotton Bowl di Dallas.
Pubblicità
Mbone
Successivamente l’Mbone (così era chiamato) venne disattivato (si trattava in ogni caso una struttura sperimentale) e la nascente industria dello streaming si uniformò al modello unicast. Per molti anni non si pose il problema del sovraccarico di rete, stante il fatto che la grandissima maggioranza degli ascoltatori e dei telespettatori continuavano ad usare i sistemi tradizionali di distribuzione.
Numeri Misteriosi
Col tempo abbiamo assistito tutti ad un aumento continuo degli ascolti via web (spesso tramite le app).
Impossibile sapere con certezza l’entità del fenomeno: ad oggi non ci risulta che nessuna grande emittente italiana renda pubblico il numero di connessioni contemporanea ai propri stream.
Nessun successo per la musica cristiana Hip Hop
Sono invece disponibili informazioni su reti minori, qualche broadcaster estero che non ha problemi di riservatezza e alcuni esilaranti sinonimi.
Un dato certo
Per cui l’unico dato certo che abbiamo è quello del 20 febbraio 2017, quando per un probabile errore di configurazione, i server Icecast di un importante gruppo radiofonico italiano sono rimasti per qualche ora in chiaro.
Pubblicità
Disponibile
Siamo in possesso dello screenshot di quell’evento che può sempre essere richiesto a chi scrive. Per dare un’idea, una delle prime quindici radio più ascoltate in quell’anno (1.435.000 ascoltatori nel giorno medio) vedeva il giorno 20 febbraio un picco di ascolti contemporanei pari a 3.280.
Un invito
Certamente dal 2017 la situazione si sarà evoluta non poco; in proposito sarebbe molto interessante se qualche emittente rompesse gli indugi e facesse un “coming out” sui propri numeri (e non sarebbe un problema: tanto – si sa – la maggior parte degli ascolti viene tuttora da radio analogiche installate in auto).
Pubblicità
Problema non più remoto
La problematica potrebbe apparire ancora remota, in fondo non c’è una data per lo spegnimento dell’FM. Ma nel caso (televisivo) del Campionato di Calcio stiamo parlando di questa estate. Per affrontare il problema, come abbiamo visto, AGCOM invita all’adozione del modello CDN, Content Distribution Network.
BBC: Internet First
Corre l’anno 2015 e in un importante speech il direttore della BBC Tony Hall afferma che l’ente britannico avrebbe dovuto mettersi in un’ottica Internet First. Un’iniziativa che avrebbe portato al lancio dell’ iPlayer e dell’infrastruttura CDN proprietaria detta BIDI: BBC Intenet Distribution Infrastructure
Una CDN gestita in prima persona
Ed ecco l’idea a suo modo rivoluzionaria della BBC: niente Akamai, niente Fastly e neppure Amazon S3: anziché affidarsi a CDN di terzi la BBC avrebbe costruito la propria CDN.
Una mossa apparentemente controcorrente, dopo anni di differenziazione forzata dalla legge tra content provider e service provider (per il DTT) e di buzzwords come “leverage di infrastrutture di cloud” (di moda per IPTv e IPRadio).
Pubblicità
Integrazione verticale
Eppure l’integrazione verticale è uno dei pilastri della strategia delle società californiane di maggior capitalizzazione nell’high tech: ad esempio Apple, che controlla dalle CPU ai sistemi operativi e Tesla, che progetta e produce dalle batterie ai sistemi operativi. Seguendo la stessa logica pare assurdo che nel broadcasting la distribuzione debba essere delegata a terzi.
Pubblicità
Le motivazioni
Semplici le motivazioni dichiarate da BBC per la creazione di BIDI: la prima, che la distribuzione IP è il futuro e che sta rimpiazzando DTT, satellite e cavo coassiale. La seconda è la qualità del servizio: solo un’infrastruttura di proprietà può garantire qualità e latenza voluti, sotto il controllo del broadcaster.
Not Afraid
Not afraid of opening up, nessuna paura a fornire i dati essenziali da parte della BBC: a ottobre 2020 questa infrastruttura (ancora largamente in fase di implementazione) serviva 249.000 utenti contemporanei. Ma di cosa si tratta?
BIDI
L’infrastruttura BIDI consiste in numerose cache HTTP distribuite denominate Caching Cells e raggruppate in Caching Batteries. In sostanza, apparati di rete proprietari installati presso i rack degli ISP e gestiti in prima persona.
Sono queste batterie a servire i flussi di dati agli utenti, in base agli algoritmi dinamici di un servizio di matchmaking che seleziona la batteria più opportuna in base a criteri geografici, di carico istantaneo e di qualità di servizio.
Commodity
Ogni batteria è costruita su hardware “commodity” ed è ospitata nel POP più vicino possibile agli utenti finali. A fine 2020 la BBC operava 102 batterie in 24 datacenter di tre differenti ISP con ben 8 peering locations.
E il multicast ?
Nella presentazione di BIDI non abbiamo trovato in alcuna slide la parola multicast.
In un paper di BBC Research datato 2017 troviamo Il seguente schema con relativa spiegazione:
La consegna dei pacchetti
Si prevede in questo scenario di suddividere i pacchetti di dati che costituiscono lo stream audio video in blocchi di ridotte dimensioni (4 secondi ciascuno) emessi (per così dire) sia in modalità multicast che unicast. La ricezione (per così dire) dei pacchetti viene effettuata da un “proxy” a livello utente, implementato nella app (nel caso di device intelligenti quali uno smartphone) o nel router casalingo.
Pubblicità
Unicast solo quando necessario
Il quale darebbe priorità ai pacchetti multicast, richiedendo quelli unicast solo nel caso uno dei segmenti vada perso (o sia ricevuto corrotto). In definitiva, un sistema combinato col potenziale di diminuire di molto il traffico di rete, quantomeno in importanti segmenti della stessa.
Il tempo del multicast non è ancora venuto (per le CDN ogni momento è buono)
Purtroppo la soluzione multicast resta sulla carta (anzi: nei files): in merito all’effettiva implementazione siamo riusciti a interpellare direttamente l’autore dello studio, Alistair Wooldrige – Senior Product Manager nel gruppo OnLine Technology/Media Distribution di BBC.
Una soluzione nei fatti non implementabile
Ecco quanto ha dichiarato a NL: “Il multicast è regolarmente proposto come soluzione potenziale al problema della scalabilità, ma non è mai stato implementato nella distribuzione dei contenuti BBC (audio o video). Esistono numerosi progetti di ricerca che ne dimostrano l’efficacia, ma nulla e’ mai stato implementato in produzione. La difficoltà principale sta nel fatto che il multicast funziona bene all’interno di un network singolo gestito da una specifica organizzazione, ma molto difficile da configurare in maniera affidabile quando si parla di numerose reti interconnesse, come è appunto Internet“.
Nel prossimo articolo approfondiremo la situazione italiana, con l’aiuto, tra l’altro, di Francesco Triolo di Meway. (M.H.B. per NL)
