Chiara Francalanci – Politecnico di Milano

1. Analisi delle caratteristiche dei servizi multicanale e del loro utilizzo nei sistemi esistenti WP1.2 Chiara Francalanci – Politecnico di Milano

2. Obiettivi del secondo anno di attività Obiettivi: • Studio di problemi relativi all’analisi costi-benefici ex ante, cioè precedente alla progettazione  R.1.2.3 • Studio di problemi relativi all’analisi costi-benefici ex post, cioè relativa alla gestione dei sistemi  R.1.2.3

3. Criticità • L’analisi costi-benefici deve tenere conto delle caratteristiche di adattatività e multi-canalità dei servizi MAIS • Le caratteristiche di adattatività e multi-canalità causano notevoli cambiamenti rispetto alle tradizionali tecniche di analisi costi-benefici, quali: • L’adattatività intesa come gestione delle eccezioni comporta costi di progettazione aggiuntivi? • L’adattatività intesa come allocazione dinamica delle risorse comporta risparmi? • L’adattatività intesa come sostituibilità dei servizi comporta una ridistribuzione dei ritorni?

4. Temi di approfondimento dell’analisi costi-benefici • Valutazione dei benefici derivante dall’allocazione dinamica delle risorse hardware di computazione (Ardagna et al. 2004) • Valutazione dell’aumento di complessità della progettazione e della gestione di software adattativo, per ora non monetizzato (Colombo, Francalanci, Pernici 2004) • Valutazione della relazione fra costi e parametri di qualità del servizio, per ora come modello di riferimento qualitativo (Cappiello, Francalanci, Pernici 2004) • Un modello di pricing dei servizi di rete in ambiente DiffServ (Comuzzi, Francalanci, Giacomazzi 2004)

5. Temi di approfondimento dell’analisi costi-benefici • Valutazione dei benefici derivante dall’allocazione dinamica delle risorse hardware di computazione (Ardagna et al. 2004) • Valutazione dell’aumento di complessità della progettazione e della gestione di software adattativo, per ora non monetizzato (Colombo, Francalanci, Pernici 2004) • Valutazione della relazione fra costi e parametri di qualità del servizio, per ora come modello di riferimento qualitativo (Cappiello, Francalanci, Pernici 2004) • Un modello di pricing dei servizi di rete in ambiente DiffServ (Comuzzi, Francalanci, Giacomazzi 2004)

6. Valutazione benefici dell’allocazione dinamica delle risorse hardware • Obiettivo: condividere le risorse da parte di più clienti • Condivisione: • garantire il rispetto dei requisiti di QoS • massimizzare i profitti derivanti dai contratti di Service Level Agreement (SLA) • Motivazioni: alta variabilità del carico dei sistemi Internet • Componenti: • Classificatore: identifica le richieste e le caratterizza in tempo reale in termini di effettivi requisiti di carico • Predittore: previsione del carico applicativo che dovrà essere sostenuto nel breve termine (modelli ARMA e polinomial fitting) • Controllore: alloca le risorse del sistema alle varie richieste con l’obiettivo di rispettare alcuni vincoli e criteri di ottimalità (configurazione dei server, allocazione delle applicazioni, routing e scheduling delle richieste)

7. Modello di costo e profitti derivanti dai contratti SLA • Costi associati all’uso dei server: energia elettrica, condizionamento, licenze software… • Solitamente si assume che il costo di un server sia proporzionale alla sua potenza di calcolo • Profitti derivanti dai contratti di SLA: • Utility function (percentile, tempo di risposta medio,…) • Contratti flat (vincoli di QoS stretti)

8. Valutazione benefici dell’allocazione dinamica delle risorse hardware • I profitti del Service Provider vengono valutati attraverso simulazione • L’uso di un controllore consente di migliorare i profitti anche di un ordine di grandezza rispetto al load balancing ed a politiche di scheduling tradizionali

9. Temi di approfondimento dell’analisi costi-benefici • Valutazione dei benefici derivante dall’allocazione dinamica delle risorse hardware di computazione (Ardagna et al. 2004) • Un modello di pricing dei servizi di rete in ambiente DiffServ (Comuzzi, Francalanci, Giacomazzi 2004) • Valutazione dell’aumento di complessità della progettazione e della gestione di software adattativo, per ora non monetizzato (Colombo, Francalanci, Pernici 2004) • Valutazione della relazione fra costi e parametri di qualità del servizio, per ora come modello di riferimento qualitativo (Cappiello, Francalanci, Pernici 2004)

10. Obiettivo • Descrizione di un modello di negoziazione automatica bilaterale • Il campo di applicazione del modello è una rete di tipo di DiffServ (vengono gestiti aggregati di traffico con QoS e non singoli flussi di traffico), gli attori della negoziazione sono ISP della rete • Fornitore: gestore delle diverse classi di servizio • Cliente: negozia le caratteristiche degli attributi dell’accesso alla rete • Il modello è adattabile al caso dell’erogazione di servizi multicanale

11. Modello di pricing Modello di negoziazione per servizi di rete • Attributi di negoziazione • Caratteristiche tecniche del servizio (frequenza media dei token bucket, profondità media dei token bucket, ritardo medio nella trasmissione dei pacchetti, probabilità di superare la soglia di ritardo) • Prezzo • Ciascun partecipante possiede delle proprie quality function per ciascun attributo (Q(x): R  [0,1]) • La quality function totale è ottenuta come funzione (produttoria) delle quality function per le singole caratteristiche tecniche

12. Modello di pricing Modello di negoziazione per servizi di rete • I partecipanti definiscono una propria funzione di utilità V che tiene conto degli attributi e del prezzo, nel caso più semplice: • Cliente: rapporto qualità prezzo V(X,p)=Q(X)/p • Fornitore: prodotto qualità prezzo V(X,p)=Q(X)*p

13. Modello di pricing Modello di negoziazione per servizi di rete • Prezzo • Il prezzo è un attributo particolare, ciascun partecipante ha un proprio modello per generare il prezzo da allegare a ciascun offerta • Fornitore: ha un modello di prezzo esatto, che fornisce un valore per ogni combinazione delle caratteristiche tecniche negoziabili • Cliente: non possiede un modello di prezzo esatto, ma riesce ad associare una fascia di prezzo ritenuta valida a ogni possibile combinazione delle caratteristiche tecniche negoziabili

14. Modello di pricing Strategie di negoziazione • Esistono due principali strategie di negoziazione • Compromesso: un partecipante tenta, in vari modi, di avvicinarsi all’offerta appena formulata dalla controparte • Stima del prezzo: la contro-offerta è generata attraverso una stima del modello di prezzo dell’avversario (questa strategia è attuabile dal cliente, in quanto il fornitore ha un modello esatto per calcolare il prezzo), cercando di minimizzarlo a parità di qualità

15. Modello di pricing P p x P p x Strategie di negoziazione: compromesso • Mi avvicino alla controparte scegliendo l’offerta con utilità più alta in un intorno di raggio = (t) crescente nel tempo secondo un andamento esponenziale o polinomiale

16. Modello di pricing p A x p A x Strategie di negoziazione: stima del prezzo • In un intorno si raggio crescente nel tempo, un partecipante tenta di scegliere l’offerta che minimizza la distanza tra la sua ultima offerta e la curva della stima del prezzo (lineare in figura) • Le funzioni  utilizzate sono lo stesse della strategia precedente

17. Modello di pricing Protocollo di negoziazione • Il fornitore fa la prima offerta (scegliendola tra una serie di offerte predefinite e massimizzando la propria V) • Il cliente risponde con una contro-offerta, inizia lo scambio reciproco di offerte • Condizione di uscita: un partecipante (es. il cliente) manda la propria offerta al tempo t+1 solo se vale la condizione Altrimenti accetta l’offerta della controparte al tempo t

18. Modelli di pricing Simulazioni e risultati • E’ stata testata la strategia di tipo “compromesso”: • L’algoritmo è progettato per convergere, il tempo di convergenza tende a saturare aumentando il timeout • La natura dell’agreement dipende fortemente dai “pattern di concessione” dei partecipanti, chi concede di più tende ad allontanarsi di più dai valori auspicati dei parametri che meno impattano sulla funzione di utilità, diventano impredicibili • Gli agenti tendono a non far decrescere la loro utilità, modificando le caratteristiche del canale e il prezzo

19. Modelli di pricing Tempi di convergenza • Dipendono dal timeout associato al processo • Aumentano se i comportamenti dei partecipanti sono differenti (più o meno cooperativi)

20. Temi di approfondimento dell’analisi costi-benefici • Valutazione dei benefici derivante dall’allocazione dinamica delle risorse hardware di computazione (Ardagna et al. 2004) • Un modello di pricing dei servizi di rete in ambiente DiffServ (Comuzzi, Francalanci, Giacomazzi 2004) • Valutazione dell’aumento di complessità della progettazione e della gestione di software adattativo, per ora non monetizzato (Colombo, Francalanci, Pernici 2004) • Valutazione della relazione fra costi e parametri di qualità del servizio, per ora come modello di riferimento qualitativo (Cappiello, Francalanci, Pernici 2004)

21. Valutazione dell’aumento della complessità di progettazione SW Requisiti non funzionali: • Flessibilità: “Capacità di un servizio (o di un insieme di servizi) di compensare a run-time violazioni dei vincoli di qualità” • Controllabilità: “Localizzazione delle attività di controllo sui vincoli di qualità” • Adattatività: “Capacità di un insieme di servizi di riorganizzare il flusso di interazione standard a fronte della continua violazione nel tempo dei vincoli di qualità”.

22. Valutazione dell’aumento della complessità di progettazione SW Costi di progettazione: • La progettazione concettuale si complica in funzione dei requisiti non-funzionali esaminati • analisi dei requisiti: estrazione dei requisiti, valutazione degli scenari possibili, valutazione dei contenuti informativi fruibili in funzione del canale (o del dispositivo)… • sviluppo: il costo di sviluppo cresce al crescere delle linee di codice da sviluppare (LOC) • Risparmi in termini di costi di integrazione • sistemi informativi restano eterogenei, • riduzione dei costi rispetto a EAI, • resta l’integrazione di processo (razionalizzazione del procurement)

23. Valutazione dell’aumento della complessità di progettazione SW Costi di erogazione del servizio: • Risparmi in termini di costi da affrontare a fronte della mancata erogazione di un servizio • è possibile rinegoziare il prezzo di erogazione invece di abortire la conversazione • è possibile erogare su un canale diverso il servizio invece di interrompere la conversazione • Tanto più un ambiente è intrinsecamente incerto, tanto più il numero di violazioni è potenzialmente alto, tanto più l’adattatività fornisce benefici in termini di costi di erogazione

24. Valutazione dell’aumento della complessità di progettazione SW Costi di manutenzione: • Manutenzione potenzialmente più onerosa (conversazioni più complesse, più attori coinvolti) • Per mitigare l’onere della manutenzione: • utilizzo modelli concettuali per supportare l’implementazione di nuove versioni che conservino tutte o una parte delle proprietà delle versione precedente (model checking, proprietà espresse attraverso formule LTL) • utilizzo di pattern che formalizzano interazioni notevoli e che possano essere composti per ottenere interazioni più complesse (es. secondo modelli organizzativi) + pattern repository

25. Progettazione concettuale e requisiti funzionali e non funzionali Valutazione dell’aumento della complessità di progettazione SW commit commit Adatta il comportamento per esercitare una funzione di controllo Beg(Production) [Received(null, provider, order) (beav = 1)]| s provider Beg(Production) [Received(null, provider, order) (beav = 0)]| begin End(My_control) [Achieved(QoS_goal) (Done(Re-execute< null, provider, production>)]| Re-execute< null, provider, production> End(Production)| s provider begin End(My_Control) [Achieved(QoS_goal)| c End(Production)| user c End(My_Control) [Achieved(QoS_goal)  Done(Re-execute< null, provider, production>)]| provider End(QoS_Control)[]| abort End(My_Control) [Achieved(provider, QoS_goal)]| Conteggio eventi anomali End(My_Control) [Achieved(QoS_goal)]|Set(beav, 1) Counter(n) End(abort)[ ]|  End(commit)[ ]|

26. Valutazione dell’aumento della complessità di progettazione SW • Stimati dei costi di progettazione di una conversazione adattativa sulla base della complessità ciclomatica di McCabe. • In generale, la complessità ciclomatica viene calcolata sul flusso di controllo di un programma descritto attraverso un grafo orientato. Questo tipo di metrica è derivata dalla teoria dei grafi dove, per un grafo orientato e fortemente connesso, viene definito il numero ciclomatico: v(g) = e-n+1, e: archi, n: nodi

27. Temi di approfondimento dell’analisi costi-benefici • Valutazione dei benefici derivante dall’allocazione dinamica delle risorse hardware di computazione (Ardagna et al. 2004) • Un modello di pricing dei servizi di rete in ambiente DiffServ (Comuzzi, Francalanci, Giacomazzi 2004) • Valutazione dell’aumento di complessità della progettazione e della gestione di software adattativo, per ora non monetizzato (Colombo, Francalanci, Pernici 2004) • Valutazione della relazione fra costi e parametri di qualità del servizio, per ora come modello di riferimento qualitativo (Cappiello, Francalanci, Pernici 2004)

28. Per lo studio della qualità del servizio nell’ambito del progetto MAIS è stata effettuata una analisi delle fonti, costituite dai deliverables MAIS dell’anno 2003/2004 + alcuni rapporti. E’ stato costituito quello che si definisce Registry delle qualità in cui sono stati riportate le dimensioni MAIS. Dall’analisi bottom up dei deliverables del progetto MAIS emergono circa 225 dimensioni di qualità. Le qualità sono state classificate in base ai diversi livelli definiti in MAIS: Architectural Model Functional Model Context Model Channel Model Piattaforma MAIS Valutazione della relazione fra costi e parametri di QoS

29. Valutazione della relazione fra costi e parametri di QoS

30. Valutazione della relazione fra costi e parametri di QoS Livello dei requisiti di qualità Costo della non qualità Livello di qualità Costo della qualità Costo totale della qualità = Costo della qualità + Costo della non qualità

31. Valutazione della relazione fra costi e parametri di QoS • Si vogliono definire le relazioni tra il costo e le dimensioni di qualità nelle varie fasi di sviluppo e redesign dei servizi • Si vogliono definire i livelli accettabili della qualità considerando i costi implicati • Es. Availability

32. Valutazione della relazione fra costi e parametri di QoS • I costi della non qualità sono costi derivati dallo scostamento del servizio dai requisiti di qualità espressi dagli utenti. Sono suddivisi in: • Costi diretti, legati all’insoddisfazione della clientela e corrispondente abbassamento dei ritorni • Costi indiretti • I costi della non qualità indiretti sono classificati come: • Tempo umano: ad esempio, scarsa qualità implica interventi extra sul sistema da parte del personale IT • Risorse informatiche: ad esempio, il tempo di risorse impiegate nell’esecuzione di servizi inutili

33. Conclusioni • Nel terzo anno di attività si vuole: • raffinare il modello di valutazione dei benefici dell’allocazione dinamica delle risorse hardware • estendere il modello di negoziazione al caso molti-molti e multi-canale • approfondire la relazione fra costi e parametri di qualità, arrivando, se possibile, alla definizione di un modello della non qualità • verificare il modello della non qualità nel caso specifico della qualità dei dati