Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Il costo nascosto del QoS

pittogramma Zerouno

Approfondimenti

Il costo nascosto del QoS

22 Gen 2007

di redazione TechTarget

Il Quality of Service richiede un attenta analisi del ROI. E spesso si scopre che l’over-provisioning può essere un’ottima alternativa

Chiunque sostenga che quella del Quality of service (QoS) sia in assoluto sempre una buona idea probabilmente non ha controllato con attenzione il prezzo. Ciò non sorprende più di tanto, visto che l’indicazione del costo non è sempre semplice da individuare.

Questo aspetto non vi deve indurre a non valutare con l’adeguata attenzione un eventuale ricorso al QoS.

Dopo tutto, quando è stata l’ultima volta che avete deciso di intraprendere un progetto senza alcuna analisi sul ritorno sull’investimento (ROI)? I risultati vi hanno soddisfatto? Perché ora dovreste avvalervi del QoS senza fare un’analisi dei costi e dei benefici? Forse perché ve lo ha consigliato un vostro fornitore?

Fino ad ora, l’industria non ha approcciato direttamente la questione di un ROI per il QoS. Non è neppure scontato che una tale analisi sia necessaria. E data l’attuale congiuntura economica, ciò non è assolutamente una sorpresa. Quello che invece sorprende è che molte di queste persone sono coinvolte in implementazioni critiche che prevedono il ricorso al QoS.

Che cosa è il Quality of Service?
Per iniziare, rispondiamo alla domanda opposta, ovvero chiariamo cosa non è:

  • Non comporta un aumento del throughput né della capacità.
  • Non comporta un aumento delle prestazioni generali.
  • Non è un modo di riparare le reti danneggiate o con prestazioni al di sotto delle aspettative.
  • Non è un interruttore che una volta premuto possa fare eseguire meglio determinate applicazioni.
  • Non è la stessa cosa della Quality of Experience (QoE) dell’utente finale.

Per contro, il QoS è:

  • Un mezzo per gestire i pacchetti in modo non-uniforme.
  • Nel peggiore dei casi, riduce drasticamente la capacità globale di un percorso della rete.
  • Nel migliore dei casi, permette che un’applicazione preferenziale veda la rete come se fosse a sua completa disposizione.
  • Tipicamente, è un meccanismo end-to-end che deve essere supportato da tutti i dispositivi sul percorso di rete.
  • Può avere un effetto significativo sul QoE dell’utente finale soltanto se la rete ha un’influenza dominante su tale QoE (e quindi la rete è il collegamento più debole della catena).
  • E’ la soluzione migliore quando c’è una capacità limitata e nessuna alternativa che consenta un valido rapporto prezzo/prestazioni.

Semplificando al massimo, il QoS può essere esemplificato con la metafora di un’autostrada in cui c’è una corsia riservata. Un’automobile che potesse viaggiare su tale corsia in un momento di alta congestione di traffico sulle altre corsie non avvertirebbe il disagio dovuto a code o rallentamenti, però non potrebbe comunque oltrepassare i limiti di velocità. Tuttavia, se sull’autostrada ci fossero problemi di natura diversa (come lavori in corso, nebbia, buche o ghiaccio), allora la nostra automobile non migliorerebbe l’esperienza, anzi dovrebbe diminuire la velocità.

L’alternativa primaria al QoS è l’over-provisioning , ovvero assegnare un surplus di capacità rispetto al valore medio d’uso o a quello di picco. Nella metafora dell’autostrada, questo equivale ad aggiungere più corsie fino a che ogni veicolo non viaggi come se fosse da solo su una corsia. Lo stesso però, non sarebbe possibile andare oltre i limiti di velocità imposti.

L’over-provisioning è tipico per molte comuni risorse, compresi le CPU dei computer e lo spazio disco, le dimensioni del veicolo e la potenza del motore, i sedili dell’abitacolo, la larghezza della carreggiata, la capacità del parcheggio e così via. Queste sono assegnate tutte in termini di capacità di picco e sostanzialmente un utilizzo al di sotto del valore di picco tende a funzionare bene, senza far nascere l’esigenza di una gestione supplementare.


Squilibrio tra costi e benefici
Purtroppo, però, l’over-provisioning presenta un grande svantaggio, ha prezzi ben definiti. Quando si implementa una capacità supplementare, entrano in gioco livelli specifici di spese in conto capitale e crescenti costi operativi. Questi costi, specialmente i costi operativi, entrano nelle procedure di decison making e tendono a sviare dall’approccio over-provisioning quando l’alternativa è semplicemente “passare al QoS” per raggiungere i risultati voluti.

La scelta di “passare al QoS” non è però sempre la migliore. Per esempio, c’è una miriade di costi impliciti (operativi e di capitale) connessi con il deployment del QoS. I requisiti per un’implementazione di successo non sono sempre elencati in modo chiaro, mentre gli ostacoli incontrati nel corso dell’implementazione rosicchiano costantemente il ROI.

Per impiegare con successo il QoS, l’implementazione deve essere:

  • end-to-end (esclusi i casi speciali quali i collegamenti satellitari o wireless)
  • robusta e affidabile
  • convergente e appropriata ai vari tipi di prestazioni dell’applicazione
  • supportata da un accordo che riguardi i domini del service provider
  • semplice e scalabile.

In quei casi speciali, dove l’uso è limitato, il QoS può essere implementato e controllato in modo efficace. Ma una volta che si sviluppa oltre la mole di lavoro che un singolo responsabile può gestire, diventa fragile. Basta soltanto che un unico dispositivo non “rispetti” i bit TOS/DSCP per spezzare la catena end-to-end del servizio. Quando sono coinvolti domini multipli del service provider, è richiesto un alto grado di coordinazione, sia in termini di accordi di business sia di implementazione tecnica.

Non va poi sottovalutato il fatto che ottenere un corretto QoS non è una strada senza ostacoli. QoS non è “un interruttore” che basta girare per avviare il processo: deve essere pensato in modo specifico per la rete in questione, per le applicazioni in uso e per i requisiti degli utenti. Non esiste una soluzione chiave in mano. Il tuning del QoS è un’arte che richiede ingegneri “smart” con un buon “feeling” con la loro rete.


Analisi del ROI
Ma allora, dove compaiono i costi impliciti in un’analisi del ROI per il QoS?

• Costo di implementazione
o Investimenti di capitali
o Sforzo di progetto per rispondere alla crescente complessità
o Individuazione delle incompatibilità tra le differenti implementazioni dei vendor

• Costo di sperimentazione/tuning
o Abbandono del vendor da parte del cliente e/o impatto sulla produttività dell’utente
o Il lavoro richiede tecnici esperti
o Laboratorio e/o infrastruttura di simulazione per il testing
o Mezzi limitati per convalidare l’implementazione
o Difficoltà di replicare le reali condizioni in laboratorio

• Costo di manutenzione
o La difficoltà di convalidare le performance desiderate porta a reclami dell’utente
o Il centro di supporto ha limitate possibilità di diagnostica
o L’analisi dei malfunzionamenti del QoS richiede parecchio tempo

• Implicazioni per il service provider
o Mantenimento di meccanismi multipli per i clienti
o Sviluppo di complessi contratti di inter-dominio
o Ricorso ai SLA (Service Level Agreement)
o Risposte alle chiamate al centro di supporto

Il costo apparente del QoS può quindi essere abbastanza elevato, in funzione del contesto in cui è impiegato. Con il crescere della complessità delle reti, la semplicità e l’affidabilità dell’over -provisioning diventano sempre più punti a favore, nonostante implichino un costo esplicito per la larghezza di banda supplementare. Le reti ottiche offrono una capacità potenziale quasi infinita e rappresentano una valida opportunità anche per l’utenza residenziale. E con le interfacce desktop per le reti cablate GigE e con i costi in discesa dello switch per-porta, è più difficile vedere come imperativa la scelta del QoS.

Alcuni potrebbero sospettare che ci siano delle questioni che vanno oltre le semplici considerazioni tecnologiche. Non nascondiamo che esistono situazioni in cui il QoS sia assolutamente essenziale e rappresenti la migliore scelta di progetto. Di seguito riportiamo alcune semplici regole pratiche per stabilire se un’implementazione del QoS è appropriata:

  • Sulle reti con buone performance;
  • Quando le applicazioni hanno requisiti di prestazioni specifici;
  • Dove la capacità è richiesta ma limitata;
  • Dove è proibitivo in termini di spesa aumentare la capacità.

Dovunque questi quattro punti non sono soddisfatti, dovreste considerare un’alternativa, quale l’over-provisioning: è rapido, semplice, scalabile, affidabile e al giusto prezzo.

redazione TechTarget

Articolo 1 di 5