QoS in Internet
1
Sommario
 Modello dei Serivizi di Rete oltre best-
effort?
o
o
o
o
Integrated-Service: RSVP
Differentiated-Service
Dynamic Packet State
MPLS (Multi-Protocol LAbel Switching)
2
Ricapitolazione
 Necessità di diversi modelli di servizio di rete?
alcune applicazioni non operano bene con il modello
IP best-effort
o
o
o
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
o
o
o
o
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?
3
Livello di Trasporto per applicazioni
Real-Time
 Diverse idee per migliorare la trasmissione real-
time su reti best-effort
o
o
o
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
o
o
possibile eccezione: banda illimitata
deve comunque gestire ritardi di accodamento
potenzialmente elevati
4
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
o soddisfano i requisiti delle applicazioni
o semplici da implementare ai routers
• necessitano di poche informazioni di stato
• necessitano di risorse di computazione
limitate
5
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
6
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)
o
7
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):
8
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
9
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)
10
Politiche di Scheduling
 Scheduling: criteri di scelta dei pacchetti da
spedire;
 FIFO: in ordine di arrivo alla coda; pacchetti
trovano buffer pieno sono scartati
11
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
12
Politiche di Scheduling (cont.)
 Round Robin: esamina code con modalita’ round
robin (favorisci classi di bassa priorita’)
13
Politiche di Scheduling (cont.)
 Weighted Fair Queuing: generalizza round robin
fornendo un servizio differenziato ad ogni classe
per un dato periodo di tempo
14
Meccanismi di Policing
 Tre criteri per valutare le risorse
assegnate:
o
o
o
(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
15
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.
16
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.
17
Strumenti di Base
 Marcatura dei pacchetti per
Isolamento dei flussi: previene
distinguere applicazioni
un flusso di prevalere sugli
appartenenti a classi diverse:
altri.
uso del campo ToS (Type of
o Meccanismi di
Service)
sorveglianza, ex: Leaky
 Classificazione dei pacchetti
Bucket
per distingure tra flussi
o Isolamento logico con
diversi, i.e. utenti e/o
riservazione delle risorse
applicazioni che ricevono
destinate ai singoli flussi
diverso trattamento ai
 Mentre si isolano i flussi si
routers
desidera comunque assegnare
 Operazioni di marcatura e
ad un flusso la banda
classificazione eseguiti
momentaneamente
all’estremità della rete o sul
inutilizzata
terminale.
 Call Admission: non sempre
possibile accomodare tutti i
flussi che richiedono risorse
18
Meccanismi di Registrazione
 Modalità di registr.:
stabilisce il meccanismo di
priorità di selezione dei
pacchetti ai router per la
trasmissione sul link:
o
o
FCFS, utilizzato in besteffort
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
w1
w2
w3
 Classe i garantita per
una frazione di servizio

wi /  wj
j
19
Meccanismi di Regolazione
 Sorveglianza del tasso
di emissione delle
sorgenti:
o
o
o
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:
o sorgente ottiene r
o
o
o
o
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
20
Leaky Bucket + WFQ
 Consideriamo n flussi
regolati leaky bucket
con parametri: bi, ri,
i=1,..,n
 Meccanismo di
registrazione WFQ:
o
o
banda totale: R
priorità wi per flusso i
 Flusso i servito con
tasso maggiore di
R wi /  wj
 Quale è il massimo
ritardo di un pacchetto
del flusso i?
 Pacchetto del burst
iniziale ha massimo
ritardo:
bi /( R wi /  wj )
j
 Massimo ritardo di un
pacchetto non del
burst?
 dipende da ri
j
21
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)
22
Problemi
Call Admission
Applicazioni Adattative
 Ogni router deve essere
 Quanto si deve adattare
capace di garantire la
un’applicazione?
disponibilità delle risorse
 Se non si può adattare
 può richiedere un’ampia
abbastanza, deve
attività di segnalazione
interrompersi (quindi
 Come deve essere specificata
rifiutata)
la garanzia
o bit-rate costante? (CBR)
 servizi saranno meno
o leaky-bucket?
predicibili
o
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
23
Confronto degli Approcci Proposti
Nome
Descrizione
QoS
complessità
Int-Serv
Architettura per la
riservazione di risorse
SI
alta
RSVP
Protocollo di
Riservazione
SI
alta
Diff-Serv Architettura a Priorità
NO
bassa
In futuro?
?
MPLS
Architettura labelswitching (stabilimento
di circuito)
24
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.
25
Integrated Services: Classi
 QoS garantita
o fornisce una garanzia rigida sul ritardo di accodamento ai
routers;
o 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
o fornisce QoS simile a quella fornita da internet quando
non congestionata
o intesa per applicazioni real-time che operano bene nelle
reti IP odierne quando non congestionate
26
Call Admission per QoS garantita
 La sessione deve prima dichiarare i suoi
requisiti di QoS e caratterizzare il
traffico che sarà immesso nella rete
o
R-spec: definisce la QoS richiesta
o
T-spec: definisce le caratteristiche del
traffico
• rate che deve essere riservato dal router per il flusso
• ritardo end-to-end o per hop
• leaky bucket + peak rate, dimensione del pacchetto
 Un protocollo di segnalazione è necessario
per trasportare R-spec and T-spec ai
routers
o
RSVP è il principale candidato per tale
protocollo di segnalazione
27
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.
28
T-Spec
 Definisce le caratt. del traffico in termini di
o leaky bucket (r = rate, b = bucket size)
o peak rate (p = velocità di riempimento del bucket)
o max segment size (M)
o min segment size (m)
 Traffico deve rimanere al di sotto di M + min(pT,
rT+b-M) per tutti i tempi T
o
o
o
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
29
R-Spec
 Definisce le richieste
minime desiderate da
un flusso
o
o
o
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
o
o
Rout = min(Rin, R’)
Sout = Sin – B/R’
 Flusso accettato solo se le
seguenti condizioni valgono
o
o
o
R’ ≥ r
B≥b
Sout > 0
(rate bound)
(bucket bound)
(delay bound)
30
Call Admission per Carico Controllato
 Un paradigma più flessibile
o
o
non garantisce contro le perdite ed il ritardo
li rende però meno probabili
 solo T-Spec è usato
o
o
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
o
o
o
politiche di ammissione più flessibili
garanzie più lasche
dipende dall’abilità dell’applicazione di adattarsi a
• bassi tassi di perdita
• gestire ritardi variabili / jitter
31
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
o
o
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)
32
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
o
o
o
o
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
o
o
informazioni di stato ai router
come gestire lo splitting dei flussi in direzione downstream?
33
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
o
o
o
o
è il protocollo usato per trasportare e coordinare le
informazioni di setup delle chiamate (e.g., T-SPEC, RSPEC)
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
34
RSVP Stili di prenotazione
 Filtro aperto: qualsisasi sender può usare le risorse richieste
dal ricevente
o
ex: banda
S1
S2
No-Filter Rsv
R1
R2
S3
S4
35
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
S2
Fixed-Filter Rsv: S1,S2
R1
R2
S3
S4
36
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
S2
Change to S
Dynamic-Filter
Rsv
1,S4S1,S2
R1
R2
S3
S4
37
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
38
Costo di Int-Serv / RSVP
 Int-Serv / RSVP riservano risorse garantite per
un flusso ammesso in rete
 Richiede precise specifiche per i flussi ammessi
o
o
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
o
o
possono variare nel tempo (leaky-bucket troppo
restrittivo)
possono essere non noti all’inizio della sessione
• e.g., sessioni interattive, giochi distribuiti
39
Problemi con Int-Serv / Admission
Control
 Larga quantità di messaggi segnalazione
o routers devono comunicare i requisiti di riservazione
o riservazione viene svolta sessione per sessione
 Attività di sorveglianza?
o grande quantità di info di stato
o 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!
40
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
41
Differentiated Services
 Approccio:
o Solo semplici funzioni nel core della rete, e funzioni
relativamente complesse ai router di periferia o ai
terminali
o 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
42
Funzionalità degli Edge Router
 Agli host abilitati DS oppure al primo router abilitato DS
o
o
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
43
Funzionalità del Core
 Instradamento: in accordo al “Per-Hop-Behavior”
(PHB) specificato per la particolare classe di
pacchetto;
o
o
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
o
politiche di sorveglianza nel core facili da mantenere (se
gli edge-routers sono affidabili)
 Grande Svantaggio: non si possono avere garanzie
rigorose
44
Riservazione in Diff-Serv
 La riservazione in Diff-Serv viene realizzata con
granularità molto maggiore di Int-Serv
o
o
o
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
o ogni sessione deve negoziare un profilo con ogni router
sul cammino
o negoziazioni sono concluse al rate a cui inizia la sessione
45
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
46
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
47
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:
o
o
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
48
Instradamento (PHB)
 Solo due PHBs attualmente considerati:
o 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)
o Assured Forwarding (AF): 4 classi, ognuna
garantita con una minima quantità di banda e
buffering; ognuna con tre differenti categorie
di preferenza di abbandono
49
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)
yellow rejection-point
red rejection-point
50
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
51
Confronto di AF e EF
 Vantaggi di AF
o classi a priorità maggiore completamente non
condizionate dalle classi a priorità inferiori
 Svantaggi di AF
o traffico ad alta priorità non può usare buffer del
traffico a priorità inferiore, anche quando vi è
disponibilità
o se una sessione invia pacchetti sia ad alta che a bassa
priorità, l’ordinamento dei pacchetti è difficile da
determinare
52
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?
53
Riepilogo
 Int-Serv:
o modello forte per QoS: riservazione
o larga quantità di informazioni di stato
o processo di riservazione di complessità notevole
 Diff-Serv:
o modello debole per QoS: classificazione
o nessun info di stato per-flow nel core
o bassa complessità
 Nessun approccio è completamente soddisfacente
 Vi sono altre alternative al di fuori di IP?
54
MPLS
 Multiprotocol Label Switching
o fornisce un modello di instradamento / inoltro alternativo
ad IP
o può potenzialmente essere usato per riservare risorse e
soddisfare requisiti di QoS
o l’architettura per questo scopo ancora non è stata
stabilita
55
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
56
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
layer 2
header
layer 3
header
data
Network (3)
Link (2)
Physical (1)
 Longest matching
prefix lookup è
costoso
o grande database di
prefissi
o lunghezza-variabile,
confronto bit-per-bit
o prefissi possono
essere lunghi (32 bits)
57
Tag-Switching
 Per i cammini usati più comunemente, si aggiunge
un tag speciale, che permette di identificare
rapidamente l’interfaccia di destinazione
o
può essere disposto in vari luoghi per essere compatibile
con diverse tecnolgie link e network layer
layer 2
header
layer 3
header
data
• 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
possibile
locazione
del tag


tag è un breve identificatore
usato solo se vi è un match
esatto (al contario di longest
matching prefix)
58
Tag switching cont’d
 Lookup con piccoli tag è molto più veloce
o spesso facile da realizzare in hardware
o spesso è necessario coinvolgere layer 3
layer 2
header
layer 3
header
data
Network (3)
Link (2)
Physical (1)
59
Virtual Circuit con MPLS
 Può stabilire route fissate (alternative) con etichette
L
L
src
L
L
dest
Nota: può aggregare flussi con stessa etichetta
o Può realizzare etichettatura lungo il cammino (i.e., router può
stabilire un’ etichetta)
60
o
Quale è la migliore soluzione?
 IntServ ha perso
o
o
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
o
o
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!!
o
o
Bandwidth è poco costosa
ISPs forniscono abbastanza banda da soddisfare le necessità
delle applicazioni
61
E’ il sovra-dimensionamento la risposta?
 Problema: i punti di collegamento tra ISPs
o parte del traffico deve attraversare diversi ISPs
o il traffico attravera i “peering point” tra ISPs
o ISPs non sono incentivati per fare apparire migliori gli
altri ISPs, quindi non sovra-dimensionano ai peering point
 Soluzioni:
o ISPs duplicano i buffer e il contenuto all’interno del loro
dominio
o Cosa fare con contenuti che cambiano dinamicamente?
 Vi sarà sembra abbastanza banda?
o Quale sarà la prossima applicazione killer?
62
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?
63
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.
64
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.
65
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.
66
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?
67
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.
68