QoS in Internet

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

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?

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

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

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

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)

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):

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

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)

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

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

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

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

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

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.

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.

Strumenti di Base 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. 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

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

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

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

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)

Problemi 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

Confronto degli Approcci Proposti Nome Descrizione QoS complessità Int-Serv Architettura per la riservazione di risorse SI alta RSVP Protocollo di Riservazione Diff-Serv Architettura a Priorità NO bassa MPLS Architettura label-switching (stabilimento di circuito) In futuro? ?

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.

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

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

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.

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

R-Spec 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)

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

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)

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?

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

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

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

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 Dynamic-Filter Rsv S1,S2 Change to S1,S4 R2 S3 S4

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

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

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!

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

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

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

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

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

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

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

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

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

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

Modelli di Coda per AF Diverse code per pacchetti di diverse classi Pacchetti di priorità inferiore serviti solo quando nessun pacchetto di priorità maggiore nel sistema

Confronto di AF e EF Vantaggi di AF Svantaggi di AF classi a priorità maggiore completamente non condizionate dalle classi a priorità inferiori Svantaggi di AF traffico ad alta priorità non può usare buffer del traffico a priorità inferiore, anche quando vi è disponibilità se una sessione invia pacchetti sia ad alta che a bassa priorità, l’ordinamento dei pacchetti è difficile da determinare

Problematiche in Diff-Serv AF e EF non sono ancora al livello di standardizzazione ma al livello di ricerca “Affitto di linee virtuali” e servizi in classe “Olympic” sotto discussione Impatto dell’attraversamento di ASs e routers non Abilitati DS Diff-Serv non mantiene informazioni di stato nel core, ma non fornisce garanzie molto robuste E’ possibile ottenere entrambi i requisiti: niente informazioni di stato con garanzie robuste?

Riepilogo Int-Serv: Diff-Serv: modello forte per QoS: riservazione larga quantità di informazioni di stato processo di riservazione di complessità notevole Diff-Serv: modello debole per QoS: classificazione nessun info di stato per-flow nel core bassa complessità Nessun approccio è completamente soddisfacente Vi sono altre alternative al di fuori di IP?

MPLS Multiprotocol Label Switching fornisce un modello di instradamento / inoltro alternativo ad IP può potenzialmente essere usato per riservare risorse e soddisfare requisiti di QoS l’architettura per questo scopo ancora non è stata stabilita

Problemi con IP routing Lento (IP table lookup ad ogni passo) Nessuna scelta nel cammino a destinazione (deve essere il cammino più breve) Non può offrire garanzie di QoS: sessione è costretta al multiplexing con i pacchetti di altri flussi

MPLS Problema: IP switching non è lo strumento più efficiente per la comunicazione nelle reti Rimuovi header di Layer 2 Longest matching prefix lookup New Layer 2 header Longest matching prefix lookup è costoso grande database di prefissi lunghezza-variabile, confronto bit-per-bit prefissi possono essere lunghi (32 bits) Network (3) Link (2) Physical (1) layer 2 header layer 3 data

Tag-Switching Per i cammini usati più comunemente, si aggiunge un tag speciale, che permette di identificare rapidamente l’interfaccia di destinazione può essere disposto in vari luoghi per essere compatibile con diverse tecnolgie link e network layer dentro l’header del layer 2 in un header separato tra il layer 2 ed il 3 (shim) come parte dell’header di livello 3 layer 2 header layer 3 data tag è un breve identificatore usato solo se vi è un match esatto (al contario di longest matching prefix) possibile locazione del tag

Tag switching cont’d Lookup con piccoli tag è molto più veloce spesso facile da realizzare in hardware spesso è necessario coinvolgere layer 3 Network (3) Link (2) Physical (1) layer 2 header layer 3 data

Virtual Circuit con MPLS Può stabilire route fissate (alternative) con etichette L L L L src dest Nota: può aggregare flussi con stessa etichetta Può realizzare etichettatura lungo il cammino (i.e., router può stabilire un’ etichetta)

Quale è la migliore soluzione? IntServ ha perso Troppe informazioni di stato e complessità nel protocollo di segnalazione incapace si quantificare in modo accurato le necessità dell’applicazione in modo semplice e conveniente DiffServ sta perdendo Non charo quale tipo di servizio un flusso ottiene se compra una classe premium Cosa accade ai flussi che non appartengono alla classe premium MPLS: ancora molto interesse, ma non è chiaro cosa realmente cambia? Vincitore attuale: sovra-dimensionamento!! Bandwidth è poco costosa ISPs forniscono abbastanza banda da soddisfare le necessità delle applicazioni

E’ il sovra-dimensionamento la risposta? Problema: i punti di collegamento tra ISPs parte del traffico deve attraversare diversi ISPs il traffico attravera i “peering point” tra ISPs ISPs non sono incentivati per fare apparire migliori gli altri ISPs, quindi non sovra-dimensionano ai peering point Soluzioni: ISPs duplicano i buffer e il contenuto all’interno del loro dominio Cosa fare con contenuti che cambiano dinamicamente? Vi sarà sembra abbastanza banda? Quale sarà la prossima applicazione killer?

Esercizio 1 Supponete una politica di registrazione WFQ applicata ad un buffer che supporta tre classi con valori 0,5, 0,25, 0,25. a) Supponiamo che ogni classe abbia un numero elevato di pacchetti nel buffer. Secondo quale ordine di sequenza occorre servire le code per assicurare i valori assegnati da WFQ? b) Supponiamo che siano presenti un numero elevato di pacchetti della classe 1 e 2 e nessun pacchetto della classe 3. In che ordine di sequenza occorre servire le code per assicurare i valori assegnati?

Esercizio 2 Considerate la strategia leaky bucket che sorveglia il tasso medio e la dimensione della raffica di un flusso di pacchetti. Prendiamo in esame anche il tasso di picco p. Mostrare come possa essere impiegato un secondo dispositivo leaky bucket posto in serie in modo da sorvegliare il tasso medio, quello di picco e la dimensione della raffica.

Esercizio 3 Si consideri un’applicazione telefonica su Internet con codifica PCM con un ritardo di trasmissione medio di 100 msec ed una deviazione massima dal valore medio dei tempi di trasmissione dei pacchetti (jitter) di 60 msec (per chiarezza, il tempo di trasmissione di ogni pacchetto oscilla tra i 40 msec ed i 160 msec.) Si calcoli il minimo ritardo di riproduzione e la dimensione minima del buffer in uno schema a ritardo di riproduzione fissato che permette di trasmettere tutti i pacchetti ricevuti alla destinazione.

Esercizio 4 Ogni flusso che attraversa un router e’ caratterizzato da una specifica leaky bucket con r=100 pckt/sec e b=15 pckt ed un Rspec che prevede un ritardo per hop di al massimo 100 msec. Supponiamo che i flussi condividano un buffer di 200 pacchetti a cui e’ assegnato un rate di 900 pckt/sec. Determinare il massimo numero di flussi accettati dalla politica di Admission Control.

Esercizio 5 Si consideri un flusso con Tspec caratterizzato da una specifica leaky bucket con rate pari a 100pckt/sec e bucket size uguale a 20 pckts, e con Rspec caratterizzato da un delay end – to – end di 200 msec. Si assuma che il flusso debba atraversare 4 routers prima di giungere a destinazione e che ad ogni router siano presenti altri 3 flussi con caratteristiche di Tspec identiche a quelle del flusso indicato. Quale è la velocità minima ad ognuno dei quattro router affinché l’attivita di Admission Control abbia successo?

Esercizio 6 Si consideri un meccanismo di registrazione weighted fair queueing presso uno switch su cui incidono 3 flussi di differenti classi di traffico. I flussi delle tre classi sono descritti da una specifica leaky bucket del tipo: b1=20, r1=100; b2=60, r2=200, b3=20, r3=400. Le classi sono ordinate secondo priorita’ crescente. Lo switch ha massimo rate disponibile di 800 pacchetti al secondo. Assegnare i pesi alle tre classi in modo tale che siano soddisfatti i requisiti sulla specifica del traffico per ogni flusso ed il ritardo allo switch non superi i 200 msec.