QoS in Internet

1. QoS in Internet

2. Modello dei Serivizi di Rete oltre best-effort? Integrated-Service: RSVP Differentiated-Service Dynamic Packet State MPLS (Multi-Protocol LAbel Switching) Sommario

3. Ricapitolazione • Necessità di diversi modelli di servizio di rete? alcune applicazioni non operano bene con il modello IP best-effort • non può controllare il tasso di perdita • non può controllare il ritardo di pacchetto • non è possibile proteggersi da altre sessioni con richieste di banda eccessive • Applicazioni diverse hanno richieste di servizio spesso molto diverse • ftp: rate-adaptive, troppo lento comunue non ammissibile • audio non compresso: basso ritardo e perdita, velocità costante • MPEG video: basso ritardo e perdita, alta variabilità del rate • giochi interattivi: basso ritardo e perdita, bassa variabilità del rate • Può un modello di servizio Internet soddisfare i requisiti di applicazioni cosi’ diverse?

4. Livello di Trasporto per applicazioni Real-Time • Diverse idee per migliorare la trasmissione real-time su reti best-effort • jitter: bufferizzazione e playout adattivo • perdite: forward error correction (FEC) • protocolli: RTP, RTCP, RTSP, H.323,… • Servizi Real-Time comunque impredicibili Conclusione: gestire la trasmissione real-time solo al livello di trasporto non sufficiente • possibile eccezione: banda illimitata • deve comunque gestire ritardi di accodamento potenzialmente elevati

5. Approcci a Livello di Rete per Applicazioni Real-Time • Cosa può essere fatto a livello di rete per migliorare le prestazioni di appl. Real-Time? • Si desiderano soluzioni che • soddisfano i requisiti delle applicazioni • semplici da implementare ai routers • necessitano di poche informazioni di stato • necessitano di risorse di computazione limitate

6. QoS in Reti IP • Gruppi di lavoro IETF propongono migliore QoS in reti IP (oltre best effort) per fornire qualita di servizio • Lavoro in progress include RSVP, Differentiated Services, e Integrated Services

7. Principi per garantire QoS • Considera una applicazione audio a 1Mbps e un’applicaz. FTP che condividono link da 1.5 Mbps. • bursts di FTP possono congestionare la rete e causare perdita di pacchetti audio: dare priorita’ a audio PRINCIPIO 1: Marcare i pacchetti (Marking) per permettere ai router di distinguere fra classi di servizio (e avere nuovi router che lo facciano)

8. Principi per garantire QoS (cont.) PRINCIPIO 2: proteggi un’applicazione da altre applicazioni • Anche applicazioni real time possono usare piu’ banda (es. applicazione audio prenota 1 Mbps e manda a 3Mbps) • Introdurre meccanismi che assicurino di utilizzare la banda richiesta (Policing) • Marking e Policing devono essere fatti ai bordi della rete (edges):

9. Principi per garantire QoS (cont.) • Alternativa a Marking e Policing: alloca e garantisci la banda a ogni applicazione; uso inefficiente della banda PRINCIPIO 3: Mentre separi le applicazioni utilizza le risorse efficientemente

10. Principi per garantire QoS (cont.) • Il traffico non puo’ superare la capacita’ di banda! PRINCIPIO 4: Utilizzare politica di ammissione di chiamata (Call Admission): un’applicazione dichiara cio’ che serve e puo’ essere accettata o rifiutata (se non c’e’ abbastanza banda)

11. Politiche di Scheduling • Scheduling: criteri di scelta dei pacchetti da spedire; • FIFO: in ordine di arrivo alla coda; pacchetti trovano buffer pieno sono scartati

12. Politiche di Scheduling (cont.) • Priority Queuing: pacchetti hanno diverse priorita’ • Ci sono piu’ code (una per ciascuna classe di priorita’ • Trasmetti prima pacchetti di priorita’ piu’ alta

13. Politiche di Scheduling (cont.) • Round Robin: esamina code con modalita’ round robin (favorisci classi di bassa priorita’)

14. Politiche di Scheduling (cont.) • Weighted Fair Queuing: generalizza round robin fornendo un servizio differenziato ad ogni classe per un dato periodo di tempo

15. Meccanismi di Policing • Tre criteri per valutare le risorse assegnate: • (Long term) Flusso medio (average Rate): num. di pacchetti in un intervallo di tempo (100 pacchetti al sec. o 6000 pacchetti al min) • Flusso massimo (Peak Rate): esempio, 6000 pacchetti al minuto (media) e 1500 pacch. al sec (picco) • (Max.) Dimensione Burst (burst=raffica): Max. numero di pacchetti spediti consecutivamente in un breve periodo di tempo

16. Meccanismi di Policing (cont.) Meccanismi Token Bucket: si limita input a un specificato valore di Burst Size e Average Rate. • Bucket (secchio) puo’ avere b gettoni (tokens); se il buffer non e’ pieno si generano r gettoni/sec.

17. Meccanismi di Policing (cont.) • In un intervallo di tempo di durata t il numero di pacchetti ammessi e’ al max (r t + b). • Token bucket e WFQ possono essere combinati.

18. Strumenti di Base Isolamento dei flussi: previene un flusso di prevalere sugli altri. • Meccanismi di sorveglianza, ex: Leaky Bucket • Isolamento logico con riservazione delle risorse destinate ai singoli flussi • Mentre si isolano i flussi si desidera comunque assegnare ad un flusso la banda momentaneamente inutilizzata • Call Admission: non sempre possibile accomodare tutti i flussi che richiedono risorse • Marcatura dei pacchetti per distinguere applicazioni appartenenti a classi diverse: uso del campo ToS (Type of Service) • Classificazione dei pacchetti per distingure tra flussi diversi, i.e. utenti e/o applicazioni che ricevono diverso trattamento ai routers • Operazioni di marcatura e classificazione eseguiti all’estremità della rete o sul terminale.

19. Meccanismi di Registrazione • Modalità di registr.: stabilisce il meccanismo di priorità di selezione dei pacchetti ai router per la trasmissione sul link: • FCFS, utilizzato in best-effort • Accodamento prioritario: diversa priorità sulla base della marcatura del pacchetto. Sempre trasmette pacchetto a priorità più alta. FCFS all’interno di ogni classe di priorità. • Weighted Fair Queuing • Classe i garantita per una frazione di servizio w1 w2 w3

20. Meccanismi di Regolazione • Sorveglianza del tasso di emissione delle sorgenti: • mean rate: ex 6000 pckt/min meno vincolato di 100 pckts/sec • pick rate: ex 1000 pckt/sec • burst: max numero di pckts inviati istantaneamente nella rete (max velocità di accesso alla rete) • Leaky Bucket: • sorgente ottiene r token/sec • può immagazzinare fino a b token • max bucket size: b pckts • rt + b pckts in t sec. • r: rate medio a lungo termine

21. Leaky Bucket + WFQ • Consideriamo n flussi regolati leaky bucket con parametri: bi, ri, i=1,..,n • Meccanismo di registrazione WFQ: • banda totale: R • priorità wi per flusso i • Flusso i servito con tasso maggiore di • Quale è il massimo ritardo di un pacchetto del flusso i? • Pacchetto del burst iniziale ha massimo ritardo: • Massimo ritardo di un pacchetto non del burst? • dipende da ri

22. Approcci Per applicazioni con requisiti di QoS, due opzioni possibili call-admission: • applicazione specifica i requisiti alla rete (rate, buffer) • rete determina se vi è disponibilità di risorse per l’applicazione • appl. accettata se vi sono risorse disponibili, rifiutata altrimenti applicazioni adattative - si adeguano alle condizioni di rete • rete può dare un trattamento preferenziale a determinati flussi (senza garanzia) • se la banda disponibile si riduce, modifica la codifica • utilizzo di opportunità per buffering, caching, prefetching • accorgimenti per tollerare perdite moderate (FEC, codifiche tolleranti alle perdite)

23. Call Admission Ogni router deve essere capace di garantire la disponibilità delle risorse può richiedere un’ampia attività di segnalazione Come deve essere specificata la garanzia bit-rate costante? (CBR) leaky-bucket? WFQ? richiede implementazione di meccanismi di sorveglianza (verificare che i flussi siano conformi a ciò che richiedono) complicato, informazioni di stato pesanti flussi possono essere rifiutati Applicazioni Adattative Quanto si deve adattare un’applicazione? Se non si può adattare abbastanza, deve interrompersi (quindi rifiutata) servizi saranno meno predicibili Problemi

24. Confronto degli Approcci Proposti

25. Integrated Services • Un’architettura per fornire QoS garantita in reti IP per sessioni individuali • si basa sulla riservazione delle risorse; routers devono mantenere informazioni di stato (Circuiti Virtuali?), registrare le risorse assegnate e decidere su questa base a riguardo di nuove richieste di connessione.

26. Integrated Services: Classi • QoS garantita • fornisce una garanzia rigida sul ritardo di accodamento ai routers; • intesa per applicazioni con vincoli real-time stretti che sono altamente sensibili al valore atteso ed alla varianza del ritardo end-to-end • Carico Controllato • fornisce QoS simile a quella fornita da internet quando non congestionata • intesa per applicazioni real-time che operano bene nelle reti IP odierne quando non congestionate

27. Call Admission per QoS garantita • La sessione deve prima dichiarare i suoi requisiti di QoS e caratterizzare il traffico che sarà immesso nella rete • R-spec: definisce la QoS richiesta • rate che deve essere riservato dal router per il flusso • ritardo end-to-end o per hop • T-spec: definisce le caratteristiche del traffico • leaky bucket + peak rate, dimensione del pacchetto • Un protocollo di segnalazione è necessario per trasportare R-spec and T-spec ai routers • RSVP è il principale candidato per tale protocollo di segnalazione

28. Call Admission • Call Admission: routers ammetteranno le chiamate sulla base delle R-spec and T-spec indicate e sulla base delle risorse correntemente allocate ad altre chiamate ai routers.

29. T-Spec • Definisce le caratt. del traffico in termini di • leaky bucket (r = rate, b = bucket size) • peak rate (p = velocità di riempimento del bucket) • max segment size (M) • min segment size (m) • Traffico deve rimanere al di sotto di M + min(pT, rT+b-M) per tutti i tempi T • M bits permessi per il pacchetto corrente (pkt arrival) • M + pT: non può ricevere più di un pacchetto oltre al tasso di peak rate • non deve andare oltre la capacità rT+b di leaky bucket

30. Definisce le richieste minime desiderate da un flusso R: rate a cui i pacchetti sono presentati al router S: tempo di slack permesso (tempo dall’ingresso alla destinazione) modificati dal router (Rin, Sin) valori ingresso (Rout, Sout) valori uscita Sin – Sout = max tempo trascorso nel router Se il router alloca una dimensione di buffer B al flusso e processa i pacchetti ad un rate R’ allora Rout = min(Rin, R’) Sout = Sin – B/R’ Flusso accettato solo se le seguenti condizioni valgono R’ ≥ r (rate bound) B ≥ b (bucket bound) Sout > 0 (delay bound) R-Spec

31. Call Admission per Carico Controllato • Un paradigma più flessibile • non garantisce contro le perdite ed il ritardo • li rende però meno probabili • solo T-Spec è usato • i routers non ammettono più carico di quello che possono gestire su lunghi orizzonti temporali • brevi orizzonti temporali non sono protetti (a causa della mancanza di R-Spec) • In confronto alla QoS-garantita con politiche di Call Admission • politiche di ammissione più flessibili • garanzie più lasche • dipende dall’abilità dell’applicazione di adattarsi a • bassi tassi di perdita • gestire ritardi variabili / jitter

32. Scalabilità: combinazione di T-Spec • Problema: Mantenere lo stato per ogni flusso è molto costoso • Soluzione: combinare lo stato di diversi flussi (i.e., T-Specs) in un singolo stato • Occorre essere più conservativi (i.e., occorre soddisfare requisiti di QoS di più flussi) • Diversi modelli di combinazione • Somma: tutti i flussi possono essere attivi allo stesso tempo (ex, teleconferenza video) • Unione: solo uno dei flussi attivo ad un certo tempo (ex, teleconferenza audio)

33. Combinazione di T-Spec Dati due T-Specs (r1, b1, p1, m1, M1) and (r2, b2, p2, m2, M2) • La somma dei T-Spec è (r1+r2, b1+b2, p1+p2, min(m1,m2), max(M1,M2)) • L’unione dei T-Spec è (max(r1,r2), max(b1,b2), max(p1,p2), min(m1,m2), max(M1,M2)) • L’unione permette un uso migliore delle risorse • meno informzioni di stato ai routers • meno dimensione di buffer e ampiezza banda riservata • Come gestire i flussi all’estremità della rete? • quanto in comune? • Somma di T-Spec • informazioni di stato ai router • come gestire lo splitting dei flussi in direzione downstream?

34. RSVP • Int-Serv specifica solo il framework per la riservazione delle risorse di rete • Occorre un protocollo usato dai routers per trasportare le informazione sulla riservazione delle risorse • Resource Reservation Protocol • è il protocollo usato per trasportare e coordinare le informazioni di setup delle chiamate (e.g., T-SPEC, R-SPEC) • progettato per adattarsi anche a riservazione multicast • ricevitore prende l’iniziativa (più facile per multicast) • fornisce supporto per unire flussi destinati ad un receiver da sorgenti multiple in un singolo gruppo di multicast

35. RSVP Stili di prenotazione • Filtro aperto: qualsisasi sender può usare le risorse richieste dal ricevente • ex: banda S1 R1 S2 No-Filter Rsv R2 S3 S4

36. RSVP Stili di Prenotazione • Filtro Fissato: solo i senders specificati possono utilizzare le risorse riservate. Una larghezza di banda viene specificata per ogni sender. S1 R1 S2 Fixed-Filter Rsv: S1,S2 R2 S3 S4

37. RSVP Stili di Prenotazione • Filtro Dinamico: solo i senders specificati possono usare le risorse. E’ possibile modificare l’insieme dei senders senza rinegoziare i dettagli della riservazione delle risorse. S1 R1 S2 Change to S1,S4 Dynamic-Filter Rsv S1,S2 R2 S3 S4

38. RSVP – Messaggi di Percorso • Il sender invia un messaggio cosidetto di percorso ai receivers della sessione. • Messaggio di percorso può contenere spec necessario per una data sorgente • Messaggio di percorso utilizzato per dedurre informazione sulla routes su cui inviare il messaggio di riservazione • I messaggi di riservazione possono unire le richieste di riservazione di banda di più ricevitori collocati downstream • Può essere necessario prevenire l’eventualità di rifiuti ripetuti a causa di un Tspec dominante. Determina anche il rifiuto di richieste per banda minore da parte di altri receivers • Il modulo RSVP ai routers blocca una richiesta dominante dopo un numero di rifiuti ripetuti • Modulo RSVP (presente a snd, rcv e routers) riceve i pacchetti IP che trasportano messaggi RSVP

39. Costo di Int-Serv / RSVP • Int-Serv / RSVP riservano risorse garantite per un flusso ammesso in rete • Richiede precise specifiche per i flussi ammessi • se specifiche sovra-dimensionate, risorse inutilizzate • se specifiche sotto-dimensionate, risorse saranno insufficienti ed i requisiti non soddisfatti • Problema: spesso difficile per le applicazioni specificare esattamente i requisiti • possono variare nel tempo (leaky-bucket troppo restrittivo) • possono essere non noti all’inizio della sessione • e.g., sessioni interattive, giochi distribuiti

40. Problemi con Int-Serv / Admission Control • Larga quantità di messaggi segnalazione • routers devono comunicare i requisiti di riservazione • riservazione viene svolta sessione per sessione • Attività di sorveglianza? • grande quantità di info di stato • carico addizionale di processamento / complessità ai routers • Segnalazione e sorveglianza aumentano con il numero di flussi attivi • Routers nel core della rete gestiscono traffico di migliaia di flussi • Approccio Int-Serv non è scalabile!

41. Differentiated Services Inteso per rispondere alle difficolta di Intserv e RSVP; • Scalabilità: mantenere lo stato ai routers in reti ad alta velocità è difficile a causa del grande numero di flussi • Modello di Servizio Flessibile: Intserv ha solo due classi, si desidera fornire più classi di servizio; ex: distinzioni ‘relative’ di servizio (Platinum, Gold, Silver, …) • Segnalazione più semplice: (rispetto RSVP) molte applicazioni ed utenti possono desiderare di specificare una nozione più qualitativa di QoS

42. Differentiated Services • Approccio: • Solo semplici funzioni nel core della rete, e funzioni relativamente complesse ai router di periferia o ai terminali • Non definisce classi di servizio, invece fornisce componenti funzionali con cui le classi di servizio possono essere costruite End host End host core routers edge routers

43. Funzionalità degli Edge Router • Agli host abilitati DS oppure al primo router abilitato DS • Classificazione: i nodi di periferia marcano i pacchetti in accordo alle regole di classificazione da essere specificate (manualmente da amministratore, oppure da un protocollo ancora non definito) • Condizionamento del Traffico: nodo di periferia può ritardare e quindi inviare oppure può scartare un pacchetto

44. Funzionalità del Core • Instradamento: in accordo al “Per-Hop-Behavior” (PHB) specificato per la particolare classe di pacchetto; • Un PHB definito solo dalla marcatura della classe • i routers nel core necessitano solo di mantenere uno stato per ogni classe • Grande Vantaggio: Niente stato per-sessione, informazioni di stato mantenute dai core routers • politiche di sorveglianza nel core facili da mantenere (se gli edge-routers sono affidabili) • Grande Svantaggio: non si possono avere garanzie rigorose

45. Riservazione in Diff-Serv • La riservazione in Diff-Serv viene realizzata con granularità molto maggiore di Int-Serv • edge-routers riservano un profilo per tutte le sessioni ad una data destinazione • il profilo viene rinegoziato su un orizzonte temporale molto più lungo (ex: giorni) • le sessioni “negoziano” solo con l’estremità per adeguarsi ad un dato profilo • Confronto con Int-Serv • ogni sessione deve negoziare un profilo con ogni router sul cammino • negoziazioni sono concluse al rate a cui inizia la sessione

46. Classificazione e Condizionamento • Pacchetto è marcato nel campo Type of Service (TOS) di IPv4, e Traffic Class in IPv6 • 6 bits usati per Differentiated Service Code Point (DSCP) per determinare il PHB che riceverà il pacchetto • 2 bits non usati

47. Classificazione e Condizionamento all’estremità • Può essere desiderabile limitare il rate di iniezione del traffico nella rete di alcune classi; l’utente dichiara il profilo del traffico (ex: rate and burst size); traffico è monitorato e plasmato se non conforme

48. Instradamento: Per Hop Behaviour-PHB • PHB consiste di una differenza osservabile (misurabile) nelle prestazioni offerte dalla politica di instradamento di un nodo diff-serv • PHB non specifica come raggiungere un determinato comportamento nelle politiche di inoltro • Esempi: • Classe A ottiene x% della banda sul link di uscita in intervalli di tempo di una data lunghezza • Pacchetti della classe A lasciano il router prima dei pacchetti della classe B

49. Instradamento (PHB) • Solo due PHBs attualmente considerati: • Expedited Forwarding (EF): il rate di inoltro dei pacchetti di una classe è uguale o maggiore ad un dato rate specificato (link logico con rate minimo) • Assured Forwarding (AF): 4 classi, ognuna garantita con una minima quantità di banda e buffering; ognuna con tre differenti categorie di preferenza di abbandono

50. Modelli di coda per EF • Pacchetti delle diverse classi entrano la stessa coda • servizio negato dopo che la coda raggiunge una certa soglia • e.g., 3 classi: verde (priorità più alta), giallo (media), rosso (priorità più bassa) red rejection-point yellow rejection-point