Nicola Ciulli

Tecniche per la garanzia di qualità in
reti di telecomunicazioni multiservizi
MQOS Workshop 2000
Courmayeur, 12 - 14 Gennaio 2000
A ttività im p lem en ta tiva
e sp erim en tale n ell’am b ito In tS erv - D iffS erv
p resso l’U n iversità d i P isa
Nicola Ciulli ([email protected])
Università degli Studi di Pisa
Dipartimento di Ingegneria della Informazione:
Elettronica, Informatica, Telecomunicazioni
Gruppo di Ricerca Reti di Telecomunicazioni
wwwtlc.iet.unipi.it
C o m po nen ti fo nda m en tali d i reti IP con Q o S (1/2 )
Funzionalità aggiuntive di un “next generation router”:
piano di Controllo:
• (RC.1) gestione della segnalazione adottata nella rete (es. RSVP in IntServ)
• (RC.2) algoritmi efficienti di Admission Control delle connessioni
• (RC.3) interfaccia per il monitoraggio di statistiche relative al funzionamento
• (RC.4) interfaccia di management
• (RC.5) gestione della segnalazione ATM
• (RC.6) traduzione degli indirizzi IP → ATM
• (RC.7) traduzione della segnalazione (RSVP) in UNI x.x
piano Dati:
• (RD.1) classificatore di pacchetto in flussi (o connessioni)
• (RD.2) policer (LBAP o di peak-rate)
• (RD.3) scheduler di pacchetto efficienti e fair
• (RD.4) acquisizione di parametri statistici packet-by-packet
• (RD.5) associazione tra connessione a livello di pacchetto e VC ATM
• (RD.6) meccanismi di trasporto IP over ATM
• (RD.7) scheduler di celle
C o m po nen ti fo nda m en tali d i reti IP con Q o S (2/2 )
Funzionalità aggiuntive di un “next generation host”:
piano di Controllo:
• (HC.1) interfaccia per la gestione user-friendly della segnalazione
adottata nella rete (es. RSVP in IntServ)
• (HC.2) specifica user-friendly delle applicazioni per la quali si desidera la
QoS
• (HC.3) se sorgente: stima automatica del Sender TSpec del traffico
generato
• (HC.4) se ricevitore: specifica user-friendly del livello di QoS desiderato
piano Dati:
• (HD.1) classificatore di pacchetto
• (HD.2) Token Bucket shaper
• (HD.3) scheduler di pacchetto
A ttività im plem enta tiva sulle fun zion i C ontrol-plan e del route r
Funzionalità
Attività svolta
Integrazione del demone SolarisRSVP 0.4.11 con varie modifiche di
natura:
Segnalazione RSVP
•
Correttiva (per l’eliminazione di bug)
•
Funzionale (per il supporto RSVP-over-ATM e di management
locale)
Admission Control
Integrazione del meccanismo di CAC di SolarisRSVP 0.4.11
Implementazione ex-novo di un’applicazione (qvc) per il
Raccolta Statistiche
campionamento periodico di un set di parametri statistici
Implementazione ex-novo di un’interfaccia di management locale
(locresv) delle reservation RSVP e di gestione remota (via Web)
Management
dell’intero router
Integrazione della segnalazione UNI 3.1 sviluppata da FORE, con
Segnalazione ATM
piccole modifiche per il supporto di VC VBR
Traduzione indirizzi IP- Integrazione del meccanismo di traduzione della Classical IP over ATM
ATM
(RFC 1577)
Traduzione della
segnalazione RSVP in Implementazione ex-novo del meccanismo
UNI 3.1
% di
“impleme
ntatività”
20 %
0%
100 %
100 %
5%
0%
100 %
A ttività im plem enta tiva sulle fun zion i D ata-plan e de l rou ter
Funzionalità
Attività svolta
Classificatore di
pacchetto
Integrazione del classificatore del CBQ v2.0
Policer
Packet Scheduler
Modulo statistico
Associazione
connessione a livello di
pacchetto - VC
Meccanismi di
trasporto IP-over-ATM
Scheduler di cella
Implementazione ex-novo di un policer Token Bucket e peak-rate (per
connessione RSVP)
Inizialmente: integrazione e modifiche “bug-fixing” al CBQ 2.0;
soluzione finale: implementazione ex-novo degli algoritmi Weighted
Round Robin (WRR) e Worst-case Fair Weighted Fair Queuing
(WF²Q+)
Implementazione ex-novo di un modulo statistico che aggiorna il set di
parametri statistici per ogni connessione e per ogni evento (partenza o
arrivo di un pacchetto da/all’interfaccia di uscita)
Implementazione di un modulo per l’associazione efficiente (senza
doppia classificazione) di un pacchetto IP con la sua VC dedicata
% di
“impleme
ntatività”
0%
100 %
100 %
100 %
100 %
Integrazione del client Classical IP over ATM e AAL 5
0%
assente
0%
A ttività im plem enta tiva sulle fun zion i C ontrol & D ata -p la ne d ell’h ost
Funzionalità
gestione user-friendly
della segnalazione
RSVP
specifica user-friendly
delle connessioni
Stima automatica del
Sender TSpec
Scelta user-friendly del
livello di QoS
desiderato
Classificatore
Shaper
Scheduler
Attività svolta
Implementazione ex-novo del tool Rsvp Manager Module (RMM) per
Sun Sparc (Solaris 2.5.1), SGI Indy (IRIX 6.2 / 6.4) e PC (Linux 2.1.104)
Implementazione ex-novo di un modulo di scelta semi-automatica delle
connessioni, integrato in RMM
Implementazione ex-novo del modulo Automatic Tspec Retrieval (ATR),
integrato in RMM
Implementazione ex-novo di un modulo dedicato, integrato in RMM
assente
assente
assente
% di
“impleme
ntatività”
100 %
100 %
100 %
100 %
0%
0%
0%
Lista de lle a ttività
La nostra attività implementativa:
• Implementazione di nuovi scheduler di pacchetto (UPISA WRR e WF²Q+)
• modifiche di tipo “bug fixing” e funzionali (per il supporto di ATM) al demone
RSVP (compatibilità con RFC 2379, 2380, 2381)
• caratterizzazione LBAP del traffico e sviluppo di un policer LBAP e peak-rate
• Sviluppo di un’applicazione (qvc) per l’estrazione dei parametri statistici dall’HED
e per la gestione locale delle reservation (locresv)
• evoluzione di RMM alla versione 3.0 (gestione user-friendly delle
connessioni e nuovi algoritmi di stima automatica del TSpec);
• Interfaccia Web per la gestione remota dell’HED;
• meccanismo di “TCP Cheating”
La nostra attività di sperimentazione:
• Test funzionali e prestazionali degli scheduler di pacchetto (WF²Q+);
• Confronto di scalabilità tra scheduler FIFO e WF²Q+
• Sperimentazione sul “TCP Cheating"
C o nfigurazion e de l tria l In tS e rv-over-A T M
Jebediah
HED20
Sun Sparc 20
Radiology
department
subnet
100baseTX
Kernelsul
- level
Misure
CBQ
traffic probes
FORE
ATM NIC
Krusty
HED5
Sun Sparc 5
FORE
ATM NIC
Newbridge
RSVP host
CS 3000 Workgroup
switch
Linux/Windows PC
(Background traffic source:
MGEN / NETPERF / VIC / VAT
on CLIP or native ATM;
Netmeeting on CLIP)
TLC lab
subnet
10baseT
CS 1000 WGS
remote link
Stanley
RSVP host
(receiver)
Sun UltraSparc 5
(Advantage Windows;
Osiris)
(source)
Sun UltraSparc 1
(Advantage Windows;
Osiris)
Barney
HP Internet
Advisor
FORE
ATM NIC
HP BSTS
Background
cell flow
source/receiver
Itchy
FORE
ATM NIC
Linux/Windows PC
(Background
traffic receiver:
DREC / NETSERVER /
VIC/ VAT on CLIP or
native ATM;
Netmeeting)
A rchitettu ra softw are de l rou te r H yb rid E dg e D e vice (H E D )
User-level
Kernel-level
IWF
QoS
mapping
)C
T(
lo
rt
no
C
cif
fa
rT
DE
H
locresv
rsvpd
rsvpd
)C Admission Control
A( (Packet level)
lo
rt
no
C
no
is
si
m
dA
DE fore_clip
H Admission Control
RSVP
daemon
local reserv.
manager
cbq
IP
LBAP+peak
policer
packet
classifier+
scheduler
Statistic
module
cbq,
fore_clip
cbq
pkt.sch.-CLIP
integration
cbq,
fore_clip
fore_clip
fore_clip
UNI 3.1
= Control interaction
= Data interaction
Statistic
application(s)
(ATM level)
fore_clip
Flow-Table
Manager
ip
qvc
fore_sdapi
fore_uni
CLIP client
FORE sba200e
ATM card driver
Ethernet card
driver(s)
fore_sba200e
le0, hme0
S ch em a del servizio su lle if di uscita dell’H E D
bBE
ϕBE
PP
= Peak-rate Policer
TB
= Token Bucket
rs,1
bs,1
b1
PP
ϕ1
TB
classifier
rs,2
CLIP queue
WF²Q+ rate
WRR limiter
bs,2
b2
PP
ϕ2
TB
rs,N
bs,N
bN
PP
TB
ϕN
tx
c
T est sul W F ²Q +
Tre fasi principali nelle attività di test sul WF²Q+:
• (1) fase iniziale di test automatici su trial ridotto con traffico sintetico;
• (2) test sul trial completo con traffici reali;
• (3) test sulla scalabilità dell’implementazione del W F ²Q +.
C o n figu ra zio n e “rid o tta” d el tria l (s c en a rio d e lle fa si d i tes t 1 e 3):
script con
mgen, qvc,
locresv
le0
hme0
ci1
HED
20
drec
flussi MGEN
ci0
ATM network
(CS1000 and
CS3000)
Raccolta
statistiche
ci0
HED
5
le0
ci1
C o nfigurazion e de i test sul W F ²Q + su l trial IntS erv-over-A T M
Brockman
Linux PC
(MPEG-1 video server)
MPEG-1
VBR / CBR
traffic
le0
hme0
Ethernet
hub
ci1
Ethernet
switch
video traffic
monitoring
HED
20
packet scheduler
statistics sampling
ci0
HED
5
ci0
Ethernet
hub
le0
ci1
Barney
Linux PC
(MPEG-1 video client)
MGEN
QoS traffic
Stanley
Sun UltraSparc 5
(MGEN QoS traffic source)
remote link
CS 3000 WGS
CS 1000 WGS
Meaning of symbols:
MGEN
Best Effort
traffic
le0
hme0
Itchy
Scratchy
Linux PC
(CLIP client;
MGEN BE traffic source)
Linux PC
(CLIP client;
MGEN BE receiver)
= 10baseT if.
= 100baseTX if.
ci1
= CLIP if.
ci0
= RSVP over ATM if.
= congested if.
U n a no ta ai test su gli sched uler
•i molti test su uno scheduler richiedono uno stato di congestione
dell’interfaccia di uscita. Nel caso delle interfacce CLIP (standard e RSVPover-ATM) si è reso necessario sviluppare dei meccanismi di limitazione del
rate di servizio:
Algoritmo
Com portam ento
Token Bucket tra lo scheduler e
il servizio di TX
Preciso, ma peggiora le worstcase fairness dello scheduler
Allungamento del tem po di
servizio a livello CBQ
Tempo di servizio allungato più
del necessario
Allungamento del tem po di
servizio a livello CLIP
Molto preciso, m a non c’è più
tempo di CPU a disposizione
del livello di applicazione
quando l’interfaccia è
congestionata
Allungamento del tem po di
servizio a livello CBQ m ediante
un TB
Preciso; attualm ente in uso
C a ra tteristich e de side ra bili di u no sch ed uler
• Limitazione del rate di servizio (operata dal TB policer: tiene ciascun flusso
nei limiti della descrizione fornita alla rete)
• redistribuzione della banda inutilizzata (la banda libera dovrebbe essere
riassegnata alle connessioni attive proporzionalmente alle loro quote di banda
riservata)
• Isolamento dei flussi (una connessione dovrebbe essere protetta - in
termini di rate di servizio e ritardo di coda sperimentati - dal comportamento
delle altre connessioni)
• ritardo di coda basso e limitato (lo scheduler dovrebbe garantire ritardi di
coda relativamente bassi per ciascuna connessione, e un limite superiore per
il ritardo sperimentato da ciascun pacchetto di una connessione)
• Fairness (il servizio offerto dallo scheduler alle varie connessioni dovrebbe
essere proporzionale alla quota di banda prenotata anche su scale temporali
piccole - es. pochi tempi di pacchetto)
P erch é il W F ²Q + ?
Scheduler
WRR
(Weighted
Round Robin)
WFQ
(Weighted Fair
Queuing)
Vantaggi
• Facilità di implementazione
• Work-conserving
svantaggi
• Non work-conserving ( =
spreco di banda del link)
• Bassa fairness
• Delay bound dipendente dal
numero di connessioni
• Difficile da implementare
• Delay bound e fairness
dipendente dal numero di
connessioni
• Work-conserving
• La più alta fairness attualmente
(Worst-case Fair
disponibile
• Difficile da implementare
Weighted Fair
• Delay bound indipendente dal
Queuing)
numero di connessioni
• Work-conserving
• La più alta fairness attualmente
disponibile
• Non è ancora lo “scheduler
• Delay bound indipendente dal
WF²Q+
ideale”…
numero di connessioni
• Relativamente facile da
implementare
WF²Q
E sito d ei test sul W F ²Q +
Proprietà
• limitazione del rate di servizio
• redistribuzione della banda
• isolamento dei flussi
• ritardi di coda (medi e massimi) limitati e
relativamente bassi
risultato
YES
YES
YES
Note
1
YES
• Fairness
YES
2
•➏ scalabilità
?
3
Notes:
• (1) la banda ottenuta da una sessione con peso ϕ¡ è ϕ¡/ ϕB, dove ϕB è la somma dei pesi delle
sessioni backlogged.
• (2) La fairness è stata misurata con il Worst-case Fair Index (WFI):
k
k
k
WFI = d i ≤ ai + Qi ,s (ai ) / ri + Ci ,s
• (3) Il verdetto sulla scalabiltà del WF²Q+ è arduo, in quanto è influenzato contemporaneamente dall’
algoritmo, la sua implementazione e la piattaforma hardware sulla quale essa gira. Le prestazioni del
WF²Q+ sono mantenute per un numero di reservation intorno a 400 (di cui, però, solo poche sono
attive) o fino a 50 ÷100 reservation tutte attive contemporaneamente.
W F ²Q +: lim itazio ne d el ra te di se rvizio
W F ²Q +: rid istribuzione della ba nda
W F ²Q +: isolam e nto de i flu ssi (rate d i servizio)
W F ²Q +: isolam e nto de i flu ssi (drop ra te)
W F ²Q +: isolam e nto de i flu ssi (rita rd o m e dio di coda )
W F ²Q +: isolam e nto de i flu ssi (rita rd o m a ssim o d i cod a)
C a ra tterizzazio ne L B A P del traffico : p ano ra m ica del prob le m a
• Possibili scenari in un ambiente IntServ:
• la sorgente di traffico fa lo shaping sul flusso generato per renderlo
conforme al TSpec (dunque il traffico immesso in rete e’ conforme);
• la sorgente di traffico non fa shaping ma stima (on-line) una descrizione
Token Bucket del traffico e la usa per l’emissione del TSpec (il traffico
immesso in rete e’ conforme se la caratterizzazione e’ buona);
• la sorgente di traffico non fa shaping, ne’ si preoccupa di stimare il TB
del traffico, e i boundary router operano un reshaping del flusso (poiche’
il traffico puo’ essere non conforme).
• Il minimo descrittore LBAP (ρ, σ) per un dato traffico non e’ unico
ρ
token
bucket
(r, b)
regulator
bucket
σ
good
non conf.
d
U n esem p io di ca ra tte rizzazio ne L B A P
r
rif-1
d(t)
[t1 , t2 ] ⊆ [t S , t E ]
r ⋅ (t 2 − t1 ) + b ≥ d (t 2 ) − d (t1 )
∀ t1 , t 2 |
b(0, t x )
rif-2
b(0, t x )
30000
0
ta
tb
28000
tx
26000
24000
22000
20000
18000
16000
Due tipi di
caratterizzazione LBAP:
14000
12000
10000
8000
6000
4000
2000
774400
739200
704000
668800
633600
598400
563200
528000
492800
457600
422400
387200
352000
316800
281600
246400
211200
176000
140800
105600
70400
35200
0
0
• Off-line
• On-line
N e ce ssità di un enfo rcem ent sui param etri d i T o ke n B ucke t
ρ
token
bucket
(r, b)
σ
good
σ
ρ
non conf.
discard
Un meccanismo di enforcement dei parametri di TB dichiarati nel Sender
TSpec è necessario in quanto:
• lo scheduler puo’ essere Work Conserving: un aumento del rate di servizio
permette burst maggiori della burst size dichiarata dalla sorgente
• i parametri TB usati per dimensionare la coda non sono necessariamente
copiati dal Sender TSpec
P olice r LB A P e pe ak-rate
Due tipi di policer possono essere attivati separatamente per ogni
connessione WRR / WF²Q+:
• LBAP (Linear Bounded Arrival Process) policing:
fa rispettare i parametri r e b dichiarati nel Sender TSpec; i test hanno
mostrato una buona precisione nella limitazione del rate medio (errore
inferiore all’1%).
• Peak rate policing:
fa rispettare la distanza minima (intervallo di peak-rate) tra i pacchetti
conformi (non tra tutti i pacchetti entranti):
Tn = Tn-1 + Ln / p
(dove Tn è timestamp dell’ultimo pacchetto conforme e Ln la sua
dimensione, Tn-1 è il timestamp dell’ultimo pacchetto conforme e p è il
peak rate sottoposto a policing).
P olice r LB A P e pe ak-rate: d ia gram m a di flu sso
K-th
K-th Packet
Packet arrival:
arrival:
•• timestamp:
timestamp: t(k)
t(k)
•• size:
size: s(k)
s(k)
peak-rate
peak-rate
policing
policing
isis enabled
enabled
??
No
No
LBAP
LBAP polici
policinngg
isis enabled
enabled
??
Yes
Yes
Yes
Yes
No
No
TB_level
TB_level <-<-- min
min {TB_depth,
{TB_depth,
TB_level
+
r
*
[t(k)
TB_level + r * [t(k) -- t(k-1)]
t(k-1)] }}
t(k)
t(k) ≥≥
ot(k-1)
ot(k-1) ++ s(k)
s(k) // pp
??
Yes
Yes
TB_level
TB_level -- s(s(k)
k) ≥≥ 00
??
No
No
non
non conformant
conformant
packet:
packet: discard
discard
ot(k)
ot(k) == t(k)
t(k)
Yes
Yes
TB_level
TB_level <-<-TB_level
TB_level -- s(s(k)
k)
the
the packet
packet isis
conformant:
conformant: try
try to
to
queue
it
queue it
No
No
qvc e locresv (1/2): due app licazioni pe r la g estio ne d ell’H E D
•i comandi per la gestione locale delle reservation (locresv) attualmente disponibili:
- creare una nuova reservation (set)
qvc command:
- modificare una reservation (mod)
qvc: usage: qvc [-h | -I <if> | -f <log file> |
-i <interval(ms)> | -s <# of samples>
- rimuovere una reservation (del)
-d <duration(s)> | -p <cbq priority> | -m]
qvc dumps a number of CLIP and CBQ statistics.
- elencare le reservation attive (sho)
NOTES:
……….
- attivare il policing su una reservation (pol)
(3) <if> ::= [+]<interface name> (+ is the RSVP
over ATM indicator).
- creare una reservation “fantasma” (gst)
(4) <cbq priority> is for non-ROA ifs and specify
- attivare il “TCP Cheating” su una reservation (cht) the priority level whose classes must be looked
at; default value is 3.
• I meccanismi di policing e TCP Cheating possono essere automaticamente abilitati
per ogni reservation instaurata (manualmente o via segnalazione RSVP) usando
appositi comandi nel file di configurazione rsvpd.conf (rispettivamente:
police_lbap, police_peak, police_all, cheat_tcp)
locresv command:
locresv: usage:
locresv set <resv name> <if> <nhop> <class> <r> <b> <p> <m> <M> <R> <S>
<proto> <src ip> <src port> <dst ip> <dst port>
locresv del <if> {<tc handle> | <resv name>}
locresv mod <if> {<tc handle> | <resv name>} <class> <r> <b> <p> <m> <M> <R> <S>
<proto> <src ip> <src port> <dst ip> <dst port>
locresv pol <if> {<tc handle> | <resv name>} {all | lbap | peak | off}
locresv cht <if> {<tc handle> | <resv name>} {on | off}
locresv sho
NOTES: (1)
(2)
(3)
(4)
<class> ::= {cls | gs}, <proto> ::= {udp | tcp}
<tc handle> is hex value (0x...), <resv name> ::= {<name> | anon}
rates are in Kb/s, sizes are in B
'cht' (cheat tcp) command applies to FF reservations only
qvc e locresv (2/2): param etri statistici d isp onibili
Level
Parameter
•
HED CLIP and ATM-driver
level (for each outgoing VC)
•
•
•
•
•
•
•
•
•
•
•
HED packet scheduler level
(for each schduler’s
connection)
•
•
•
•
•
•
•
•
•
•
•
•
Number of packets and bytes sent on the VC
Average packet and bit rate (each one got with two different algorithms)
number of times the DMA queue was found full
number of free places in the DMA queue
Other parameters related to the inner workings of the HED CLIP and the ATM-driver
number of packets sent for a class
number of packets dropped
average service rate (kb/s and p/s)
average dropping rate (kb/s and p/s)
number of times the class went over-limit (CBQ)
number of over-actions and delay-actions for that class (CBQ)
Number of borrowings (CBQ)
the allocated byte transmission time (WRR)
the allocated number of bytes for each round of the WRR scheduler (WRR)
the class queue occupancy (in terms of packets and bytes)
Average queue occupancy (packets/bytes)
Average number of packets/bytes in queue just before an accepted packet enters
Average number of packets/bytes in queue found by any arrived packet
Average number of packets/bytes in queue just after a packet exits
Average queue occupancy (packets/bytes) for each flow of a set sharing the BE queue
Average number of tokens in the Token Bucket
Worst-case Fair Index (WFI)
Average queuing delay (µs)
Maximum queuing delay in a sampling period (µs)
R svp M a nag er M od ule (R M M ) 3.0 : caratte ristiche p rin cipa li
• Doppio modo operativo: “support mode” (interfaccia user-friendly con minima conoscenza
dei meccanismi RSVP richiesta) e “raw testing mode” (gestione completa e dettagliata della
segnalazione RSVP)
• In entrambe le modalità, una GUI intuitiva aiuta l’utente a definire le sessioni RSVP, ad
abilitarle o disabilitarle (PATH & RESV or PATH-TEAR / RESV-TEAR) o a chiuderle.
• Modulo Automatic Tspec Retrieval (ATR): per ogni sessione aperta come “Sender”, è
possibile attivare un filtro per il monitoraggio del traffico emesso su quella data connessione;
tale informazione viene poi elaborata per fornire una stima on-line automatica dei parametri
del Sender TSpec da includere nei messaggi PATH); tali messaggi subiscono un refresh se i
parametri cambiano.
• Scelta semi-automatica della sessione RSVP: una nuova interfaccia a disposizione degli
utenti incapaci o non intenzionati ad aver a che fare con indirizzi IP e (soprattutto) con numeri
di porte TCP / UDP. Questa interfaccia elenca automaticamente tutte le connessioni
associate a una data applicazione o a un dato peer remoto, ovvero fornisce una lista
completa di tutte le connessioni TCP / UDP cui l’host partecipa.
• Scelta user-friendly del livello di QoS: nella modalità “support”, l’utente può decidere di
utilizzare i parametri del Sender TSpec per specificare la reservation (richiedendola anche
automaticamente all’arrivo del primo PATH), oppure di modificare agendo su due slider-bar
dal significato piuttosto intuitivo (“banda” e “ritardo”).
• RMM è disponibile su Linux 2.1.104, Solaris 2.5.1, Irix 6.2/6.4.
R svp M a nag er M od ule (R M M ) 3.0 : u na p ano ra m ica
Defining a new
RSVP session
RMM main window
Sender session
management
(with Auto-Tspec
capability)
Receiver
session
management
in the support
mode
Receiver session
management
in the testing mode
User-friendly selection of UDP/TCP connections
RSVP events tracing
Inte rfaccia W e b pe r la g estio ne rem o ta de ll’H E D
Caratteristiche dell’interfaccia Web:
• pagine HTML “leggère” per ridurre l’impatto sulle
prestazioni del Data-plane;
• accesso semplificato ai file di log dell’HED;
• interfaccia grafica per i comandi dell’HED (locresv e qvc);
• fruizione remota dei dump delle statistiche dell’HED;
• visitabile presso http://jebediah.pisa.ccr.it:100
Il m eccanism o d i “T C P C h eating ” (1/2): intro du zion e
Sender
Receiver
host
host
TCP
connection
TCP ACKable
segment (1)
real ACK (2)
fake ACK
fake
segment (3)
Legacy
internet
Ingress
router (A)
QoS capable
(e.g. IntServ)
IP network
Egress
Legacy
internet
router (B)
Note:
(1) un “ACKable segment” è un segmento TCP con una (o più) delle seguenti caratteristiche:
• payload non nullo;
• contiene informazioni di controllo TCP (uno dei bit SYN, FIN or RST è settato).
(2) l’ACK vero, una volta raggiunto il router A, subirà le seguenti azioni:
• nel suo campo “ACK number” sarà scritto il valore dell’ultimo “fake ACK number” generato, e quindi sarà inoltrato - se
ha un payload non nullo o contenga informazione di controllo TCP;
• sarà scartato - altrimenti.
(3) Per risolvere il problema dei “buchi” nel flusso di byte del ricevitore (che costringe il ricevitore stesso a uno stallo e alla
reiterazione dell’ACK sul numero d’ordine del primo byte del “buco”), il router B dovrebbe spedire al ricevitore un segmento TCP
falso, con un sequence number settato sul valore del più alto ACK number passato. Il contenuto del payload del “fake segment”
non è rilevante (es. tutti zero).
(4) L’emissione di “fake ACK” richiede che il router d’ingresso (A) tenga traccia non solo dell’ultimo ACK number passato, ma
anche dell’ultimo IP identification number passato (o generato). Questo secondo campo deve essere aggiornato (a cura di A) in
ogni pacchetto scambiato tra i due host in questione.
Il m eccanism o d i “T C P C h eating ”: prim i test
Pochi esperimenti sono stati condotti al momento sulla prima versione del
meccanismo di TCP Cheating (che imbroglia la sorgente TCP ma non
ancora il ricevitore). I primi risultati sono:
• Il carico di questo meccanismo dipende linearmente dal numero di
connessioni TCP e cresce rapidamente quando si aggiunge una
connessione tra una nuova coppia di host (questa seconda caratteristica
sussiste soltanto se l’IP identification number deve essere aggiornato).
• Il cheating sul sender TCP funziona bene: il rate di trasmissione non
diminuisce anche quando viene creata congestione sulle interfacce di uscita
lungo il path e una tecnologia di networking half-duplex riflette gli effetti della
congestione sul reverse path (causando perdite e ridardi sugli ACK).
D ifferen tia ted S ervices
Attività nel contesto dei DiffServ:
❋
integrazione del trial DiffServ
❋
Configurazione
❋
implementazione di un modulo statistico
❋
test funzionali e prestazionali del PHB EF
C o nfigurazion e de l tria l d i b ase
Background traffic source
Stanley (192.168.5.3) SUN
Solaris 2.5.1 (plain IP host)
Brockman (131.114.32.168)
Linux 2.2.6 (plain IP host)
192.168.5.2
131.114.32.130
Bart Linux 2.2.10
+ DS6 patch
+ Jack’s Patch
(DiffServ Marker
and Internal
Router)
Moleman (192.168.5.4)
Linux 2.2.10 + DS6
Background traffic
destination
E F e B E : m o du li di T raffic C ontrol co involti
tc_index
filter
tc_index
0x2e (EF)
Expedited Forward
Class
pFIFO queue
RED queue
Best Effort
Class
CBQ 2:0
DS mark 1:0
Il m od ulo sta tistico (1 /2)
DS router
qdisc_restart
do_gettimeofday
do_gettimeofday
timestamp1
timestamp2
net_if_rx
eth (in)
stats eth (out)
Per ogni classe e disciplina di coda:
• Tempo di coda per ogni pacchetto
• Timestamp di uscita per N pacchetti
• Lunghezza di N pacchetti
• Contatore byte complessivi
Il m od ulo sta tistico (2 /2)
Alcune caratteristiche del meccanismo di misura:
❋
acquisizione dati statistici provenienti dal kernel mediante applicazione a linea
di comando (TC), passati tramite RT-NetLink
❋
calcolo di tempi di coda e rate a livello di applicazione
❋
due diversi metodi per la misura del rate, attualmente
❋
richiede la modifica della q_dequeue per ogni disciplina di coda da analizzare
under test
(per ora solo in CBQ)
❋
statistiche ottenute per ogni disciplina e per ogni classe
C o nfigurazion e di alcuni test su ll’E F P H B
Background traffic source
Stanley (192.168.5.3) SUN
Solaris 2.5.1 (plain IP host)
Brockman (131.114.32.168)
Linux 2.2.6 (plain IP host)
marking
scheduling
& statistics
192.168.5.2
131.114.32.130
Bart Linux 2.2.10
+ DS6 patch
+ Jack’s Patch
(DiffServ Marker
and Internal
Router)
Hans_moleman (192.168.5.4)
Linux 2.2.10 + DS6
Background traffic
destination
N o te sui test
Tipologie di prove effettuate:
❋
verifica dell’isolamento tra classi CBQ in presenza di più traffici contemporanei
in competizione sull’interfaccia di uscita:
– isolamento tra i rate
– corretta limitazione sul rate
❋
analisi prestazioni dello schema “EF”
– classificazione dei pacchetti già marcati dalla sorgente
– limitazione dei tempi di coda per la classe EF grazie al
pfifo
– isolamento rispetto alle classe best effort
❋
streaming di due video MPEG-1 in presenza di disturbo
– stream MPEG-1 marcati “EF”
– traffico di disturbo
best effort
– verificato il corretto isolamento degli stream
G ra fici rela tivi ad a lcun i te st: rate di servizio E F /B E
G ra fici rela tivi ad a lcun i te st: rita rd o m ed io/m assim o B E
G ra fici rela tivi ad a lcun i te st: rita rd o m ed io/m assim o E F
P rim i risultati “co m po rtam enta li” su l C B Q di Linu x
Problemi
:
• Il meccanismo di limitazione del rate di servizio (“bounded class”) applicato a 1
o piu’ classi, in presenza di 3 o piu’ classi attive contemporaneamente (es. EF, AF
e BE), causa un significativo “ripple” sul rate di servizio concesso a ciascuna
classe.
• Occasionalmente, il CBQ non garantisce il rate di servizio minimo a una classe
nei primi secondi seguenti il suo istante di attivazione.
Possibile causa
:
• il meccanismo di limitazione del rate di servizio è basato sul rinvio dell’istante
di schedulazione di un pacchetto per una certa classe; la decisioni di scheduling
sono possibili in conseguenza di eventi ben precisi (arrivo o partenza di un
pacchetto al router). -> Questo comporta errori nella posticipazione dello
scheduling, che vengono compensati in modo da rispettare mediamente il rate di
servizio accordato
P ro ssim e ta ppe nell’e vo luzio ne d el trial
BB
BB
DS domain #1
DS domain #2
Prossime tappe:
❋
implementazione di un Data-plane funzionalmente completo e corretto
❋
CAC sulle connessioni entranti nel dominio da parte dell’
❋
Monitoraggio e controllo sullo stato della rete da parte del
❋
Comunicazione tra BB appartenenti a domini diversi, negoziazione degli SLA
❋
Configurazione dinamica degli SLA
Edge Router
Bandwidth Broker