PREMESSA: questo post è il seguito del post con identico titolo che potete trovare a questo link. Come il primo, è 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. Chiediamo perdono in anticipo per le (piccole e semplici) derivazioni analitiche, ma siamo stati colti entrambi da una sorta di "Sindrome di Peter Pan" ...
UN PARAMETRO FONDAMENTALE: IL CACHE HIT RATIO
Una piattaforma di Transparent Caching, come è facile immaginare, svolge il suo lavoro al meglio, quanto più è alta la probabilità che la richiesta di un end user sia per un contenuto già presente nella memoria (cache) della piattaforma. Questa probabilità è un parametro fondamentale nella valutazione delle prestazioni della piattaforma, è ed nota come Cache Hit Ratio, abbreviato da qui in poi semplicemente come Hit Ratio (HR).
Come è intuitivo, HR dipende dall'ampiezza della memoria della cache: maggiore è questa ampiezza, maggiori i contenuti memorizzati, e di conseguenza maggiore è HR. Ma come varia HR in funzione dell'ampiezza della cache ? Qui ci viene in aiuto un lavoro di Breslau e altri, che potete scaricare a questo link. L'articolo definisce un modello teorico per la probabilità (condizionata) che all'arrivo di una richiesta dell'end user, questa sia per un determinato contenuto. Formalizzando un po' meglio, sia N il numero totale di oggetti presenti nell'universo Internet (es. pagine web, file video di tutti i tipi, ecc.), e P(N,i) la probabilità che all'arrivo di una richiesta, questa sia per il contenuto i. I contenuti siano memorizzati secondo un ordine di "popolarità decrescente", partendo dal contenuto più richiesto; in altre parole, il contenuto 1 è il più richiesto, il 2 è il secondo, e così via.
I risultati principali del lavoro di Breslau e altri sono i seguenti:
- La probabilità P(N,i) segue una classica "Legge di Zipf", dove 0 < α < 1 (NOTA: in letteratura qualcuno chiama questa legge di tipo Zipf-like, lasciando la notazione "Legge di Zipf" al solo caso α = 1):
- Supponendo un'ampiezza finita della cache pari a C oggetti, il parametro HR in funzione di C segue una legge esponenziale del tipo (NOTA: la relazione deve leggersi HR(C) è proporzionale a ...):
Da stime realizzate attraverso misure reali, si è visto che il parametro α assume valori nell'intervallo [0,7; 0,9]. Il valore da utilizzare nelle applicazioni reali viene stimato a partire dai dati "catturati" dalla piattaforma di Transparent Caching nel primo periodo di funzionamento (a occhio e croce dopo 1-2 ore di funzionamento), e quindi stimato attraverso algoritmi di "curve fitting" (es. metodi di regressione lineare, quadratica, ecc.).
La figura seguente riporta l'andamento della probabilità P(N,i) secondo la legge di Zipf, per vari valori del parametro α e per N=10.000. Come si può notare, per valori tipici del parametro α, la probabilità che venga richiesto il contenuto più popolare varia dal 2% (α=0,7) al 6% circa (α=0,9).
Più interessante è invece il grafico del parametro HR in funzione di C, riportato nella figura seguente per vari valori di N e per valori del parametro α pari a 0,7 e 0,9.
L'aspetto interessante da notare è che già con una cache di dimensione pari al 10% del numero totale di oggetti, il valore di HR è abbastanza consistente (65%<HR<70% (α=0,9), 45%<HR<50% (α=0,7)).
INCREMENTO DEL THROUGHPUT
Vediamo ora di quantificare come l'introduzione di piattaforme di Transparent Caching consenta di migliorare il Throughput complessivo, rispetto a una situazione senza piattaforme.
Una piattaforma di Transparent Caching non utilizza banda dedicata per memorizzare i contenuti, poiché come visto nel post precedente, memorizza i contenuti più richiesti dagli end user quando gli end user li ricevono dai server dei content provider, e segue le preferenze degli end user aggiornando i contenuti più richiesti. Nell’ipotesi che la banda tra server e end user non limiti il Throughput, una piattaforma di Transparent Caching è caratterizzata, oltre che dall'HR illustrato nella sezione precedente, dai seguenti parametri;
- TH(c): è il Throughput dei contenuti memorizzati nella cache.
- TH(nc): è il Throughput dei contenuti non memorizzati nella cache.
- TH(eu): è il Throughput, misurato dall’end user, dei contenuti inviati dal server di un content provider. Nel caso di assenza di piattaforme di Transparent Caching (che equivale HR=0) è TH(eu) = TH(nc).
Si noti che TH(eu) è dato dalla somma di due componenti:
- Il Throughput nel caso in cui il contenuto sia già presente nella piattaforma (= TH(hit) nella figura). Poiché la probabilità che il contenuto richiesto sia già presente nella piattaforma di Transparent Caching è pari ad HR, si ha TH(hit) = HR*TH(c).
- Il Throughput nel caso in cui il contenuto non sia presente nella piattaforma (= TH(no-hit) nella figura), e quindi arriva direttamente dal server del content provider. Poiché la probabilità che il contenuto richiesto non sia presente nella piattaforma di Transparent Caching è pari ad 1-HR, si ha TH(no-hit) = (1-HR)*TH(nc).
- RTT(tot) e p(tot) rispettivamente RTT e packet loss tra il server del content provider e l'end user.
- RTT(c) e p(c) rispettivamente RTT e packet loss tra la piattaforma di Transparent Caching e l'end user.
dove K è un valore costante. Ora, definendo l'incremento relativo di Throughput come:
ΔTH = [TH(eu) - TH(nc)] / TH(nc)
applicando le relazioni sopra viste, e ricordando dalla figura che:
TH(eu) = HR*TH(c) + (1 - HR)*TH(nc)
e ipotizzando che p(c) = p(nc), si ottiene la seguente relazione:
ΔTH = HR*[RTT(nc)/RTT(c) -1]
dalla quale si evince che l'incremento (relativo) di Throughput dipende dall'Hit Ratio (HR) e dal rapporto RTT(nc)/RTT(c) (NOTA: questa è una valutazione conservativa dell'incremento di Throughput, poiché certamente è p(nc) > p(c). Ponendo p(c) = p(nc) si ipotizza che la cache non migliori il packet loss e che quindi questo sia lo stesso per i contenuti forniti dal server del content provider e per quelli forniti dalla piattaforma di Transparent Caching).
Un'altra misura dell'incremento di Throughput è lo Speed Up (SU), definito come:
SU = TH(eu)/TH(nc) = 1 + ΔTH
Il rapporto RTT(nc)/RTT(c) dipende dal livello di rete dove è posizionata la piattaforma di Transparent Caching. Per quantificare con dei numeri l'incremento di Throughput, la tabella seguente riassume l'incremento e lo Speed Up (espressi in %), in funzione del livello di rete dove è posizionata la piattaforma. I valori di RTT riportati sono tratti da stime reali sulla rete di un grande ISP Italiano.
Un veloce sguardo alla tabella consente di valutare i vantaggi dell'utilizzo di piattaforme di Transparent Caching, a vari livelli della rete. E' ovvio che i maggiori vantaggi si hanno posizionando le piattaforme al livello di accesso. Ma questo porta a due considerazioni:
- Man mano che ci si avvicina agli end user, i costi aumentano (sia in termini di CAPEX che di OPEX) e quindi è necessario valutare attentamente i costi/benefici.
- E' necessario spostare l'IP Edge verso gli end user. E questo non è sempre possibile, o meglio, sarebbe possibile ma a causa o di un progetto di rete già consolidato, o perché gli amministratori della rete vogliono mantenere una separazione logica netta tra Accesso/Metro/Core, purtroppo non avviene.
ANALISI DEI COSTI
La valutazione dell'opportunità dell'introduzione di una piattaforma di Transparent Caching, non può prescindere da un'attenta analisi dei costi. E' fondamentale valutare, come già detto nella prima parte di questo post, non solo i guadagni in termini di QoE, ma anche i risparmi in termini di costi di deployment.
Per arrivare a determinare un modello per la valutazione dei risparmi che si ottengono, abbiamo bisogno delle seguenti definizioni:
- TH : Throughput di picco downstream [Gbps].
- CRU : costo unitario della rete a monte del POP nel quale si inserisce la piattaforma di Transparent Caching [KEuro/Gbps].
- CCU : costo unitario della piattaforma di Transparent Caching riferito al fan out [KEuro/Gbps].
- HR : Hit Ratio della piattaforma di Transparent Caching.
- R(%) : risparmio ottenuto con il deployment delle piattaforme.
R(%) = 100*(CdR senza TC – CdR con TC)/(CdR senza TC)
dove CdR = Costo di Rete e TC = piattaforma di Transparent Caching.
Ora, semplici considerazioni consentono di dedurre che:
- CdR senza TC = CRU*TH;
- CdR con TC = CRU*TH*(1-HR) + CCU*TH*HR
R(%) = 100*HR*(1- CCU/CRU)
Il valore di CRU dipende da come è stata progettata la rete dell'ISP, dagli apparati utilizzati, dalla ridondanza di progetto, dalle spese di esercizio, e altre componenti. Un valore di riferimento, per le reti fisse, potrebbe essere compreso nell'intervallo 150-250 KEuro/Gbps.
La componente CCU, ossia il costo per unità di fan out di una piattaforma di Transparent Caching, è invece la somma dei costi della componente HW e della componente SW della piattaforma.
La componente HW ha un costo che dipende dalla capacità di trattamento del traffico intercettato dalla piattaforma, spesso indicato come fan in (NOTA: il fan in è la somma sia del traffico downstream, ossia dai content provider agli end user, che del (trascurabile) traffico upstream, che va nel verso opposto). Per semplicità supporremo che la piattaforma abbia un fan in multiplo di 10 Gbps. Indicando con CHw il costo unitario dell'HW per unità di fan in (= 10 Gbps), e con CSw il costo del software per unità di fan out, si ha:
CCU = [CHw * IntSup(Bin/10 Gbps) + CSw * Bout]/(Bout) =
= [CHw/(Bout) * IntSup(Bin/10 Gbps) + CSw]
dove Bin indica il fan in, Bout = Bin*HR è il fan out della piattaforma e IntSup(X) è l'intero superiore di X (es. IntSup(2,4) = 3).
In conclusione, si hanno risparmi sui costi di rete, se vale la condizione:
CRU ≥ (CHw/(Bin*HR))*IntSup(Bin/10 Gbps) + CSw
Per avere una sensazione sui numeri, valori plausibili di CHw e CSw sono rispettivamente 5 KEuro/Gbps e 20-25 KEuro/Gbps. Solo per fare un esempio, ipotizzando Bin = 20 Gbps, CHw = 5, CSw = 25 e HR = 0,6, per ottenere risparmi, il valore di CRU deve essere maggiore di 33,3 KEuro/Gbps. Considerato che da dati di contabilità industriale, come citato sopra, il valore di CRU per una rete fissa è nell'intervallo 150-250 KEuro/Gbps, si evince immediatamente che l'installazione di piattaforme di Transparent Caching, oltre ai vantaggi che consente di ottenere sulla QoE, risulta fortemente conveniente anche da un punto di vista economico.
Se non credete a noi (e magari ne avete solide ragioni), potete però credere a questo studio dei (mitici) Bell Labs, fatto sulla rete nella rete di un grande ISP Tier 1 negli USA. Dallo studio si evince che l'introduzione di piattaforme di Transparent Caching distribuite, comporta una riduzione del TCO (Total Cost of Ownership) del 33%, calcolato su un arco temporale di 5 anni. Che non sono proprio bruscolini !!!
CONCLUSIONI
Con questo post sulle piattaforme di Transparent Caching (ricordo diviso in due parti, la prima parte la trovate qui), abbiamo cercato di darvi, oltre che informazioni sul funzionamento, anche motivazioni tecnico-economiche sull'opportunità della loro introduzione in rete. I problemi da risolvere sono ancora molti, primo fra tutti la quantità di traffico cacheable (ricordiamo che il traffico HTTPS non è cacheable), ma l'introduzione di queste piattaforme comporta, come abbiamo dimostrato, notevoli vantaggi sia in termini di QoE, che economici. E poi potrebbero essere un importante strumento con cui fare un po' di revenue sharing con gli OTT, che oggi "intascano" la grande fetta degli introiti, lasciando ai Telco le briciole.
Nessun commento:
Posta un commento