7 Performance

Politecnico di Milano
Corso di Telematica D.U.

Lucidi delle lezioni
Parte VII
Cenni al calcolo delle prestazioni delle reti
Prof. Giuseppe F. Rossi
Copyright Ing. Giuseppe Federico Rossi
(vedi nota a pag.2)
Nota di Copyright
Questo insieme di trasparenze (detto nel seguito "slide") protetto dalle leggi sul copyright e dalle disposizioni dei trattati
internazionali. Il titolo ed i copyright relativi alle slide (ivi inclusi, ma non limitatamente, ogni immagine, fotografia, animazione,
video, audio, musica e testo) sono di propriet degli Autori indicati a pag. 1.
Le slide possono essere riprodotte ed utilizzate liberamente dagli Istituti di ricerca, scolastici ed universitari afferenti al Ministero
della Pubblica Istruzione e al Ministero dell'Universit e Ricerca Scientifica e Tecnologica, per scopi istituzionali e comunque non
a fine di lucro. In tal caso non richiesta alcuna autorizzazione esplicita.
Ogni altra utilizzazione o riproduzione (ivi incluse, ma non limitatamente, le riproduzioni su supporti magnetici, su reti di
calcolatori e su supporti cartacei di vario tipo) in toto o in parte vietata, se non esplicitamente autorizzata per iscritto, a priori,
da parte degli Autori.
L'informazione contenuta in queste slide fornita per scopi meramente didattici e non per essere utilizzata in progetti di impianti,
prodotti, reti, ecc. In ogni caso essa soggetta a cambiamenti senza preavviso. Gli Autori non assumono alcuna responsabilit
per il contenuto di queste slide (ivi incluse, ma non limitatamente, la correttezza, completezza, applicabilit, aggiornamento
dell'informazione).
In ogni caso questa nota di copyright non deve mai essere rimossa e i riferimenti ad essa ed agli Autori devono sempre essere
riportati in ogni slide anche nel caso di utilizzi parziali.
Prof. GiuseppeF. Rossi Politecnico di Milano Corso di "Telematica D.U."
Parte VII 1-2/ 75 Copyright: vedi nota a pag.2
Il sistema "Rete"
Una rete pu essere considerata un "sistema" costituito da sistemi pi semplici (elementi): linee (o
"link"), "nodi intermedi" (o "backbone node"), "nodi finali" (o "end node")
L'analisi quantitativa del comportamento di un sistema "Rete" richiede la definizione di:
Grandezze (note e da calcolare)
Unit di misura delle grandezze
1
2
3
4
5
6 2 Dest
Il sistema "Backbone" = Link + Nodi intermedi
Un sistema "Link" Un sistema
"Nodo intermedio"
Un sistema
"Nodo finale"
Le "unit di lavoro" (J ob) svolte da un sistema
E' possibile affrontare i problemi di definizione di una grandezze e della sua misura attraverso una
impostazione generale
DEFINIZIONE di "J ob"
Unit di lavoro eseguita da un sistema
Per ogni specifico tipo di sistema il "J ob" assume precisi significati
Per il sistema "Nodo intermedio" di una rete a commutazione di pacchetto
J ob = pacchetto inoltrato (a seguito di una operazione di "forwarding")
Esempio: pacchetto IP inoltrato da un router
Per il sistema "link" (o linea di comunicazione)
J ob = simbolo (di norma "bit") trasmesso da un capo all'altro
Esempio: trasmissione di un bit su una linea leased (es. CDN)
La grandezza "tempo di latenza"
DEFINIZIONE di "Tempo di latenza" di un sistema
Tempo necessario ad un sistema per eseguire un "job"
Unit di misura utilizzate: s, ms, ls, ns
E' determinato da varie componenti: hardware, software, protocolli di comunicazione, utilizzo
delle risorse da parte degli altri "job", ...
DEFINIZIONE DI "Tempo di latenza a sistema scarico"
Tempo necessario ad un sistema per eseguire l'unico "job" presente
Normalmente il minimo "tempo di latenza" del sistema
La grandezza "throughput"
DEFINIZIONE di "Throughput" di un sistema
Numero di "J ob" elaborati da un sistema nell'unit di tempo (Job/Unit_of_Time)
Alcune unit di misura utilizzate in specifici sistemi
Sistema "Router": packet_per_second (pps)
Sistema "Linea di comunicazione": bit_per_second (bps) o multipli (Kbps, Mbps,
Gbps, ... )
DEFINIZIONE di "Capacit" di un sistema
MAX Throughput
Esempio di linea CDN: la sua "capacit" (in bps) ci che comunemente chiamato "velocit"
La grandezza "utilizzo"
DEFINIZIONE di "Utilizzo" di un sistema
Rapporto tra il tempo in cui un sistema occupato ad eseguire un "job" e il tempo totale di
osservazione
Grandezza adimensionale
Valore massimo: 100 %
Nel caso in cui il sistema sia una linea di comunicazione l'utilizzo viene spesso chiamato
"carico"
Le definizioni delle grandezze viste nelle slide precedenti per un generico "sistema" in linea di
principio possono essere applicate a qualunque dispositivo
Sistema "Nodo intermedio": Router, Bridge, ...
Sistema "Nodo finale": Workstation utente, ...
Sistema "Linea di comunicazione": dedicata, commutata, LAN, ...
Sistema "Backbone" (livello 3): es. Linee + Router IP
Sistema "Servizi di rete" (livello 4): es. Linee + Router IP + Host con protocolli Transport
Sistema globale "visto" dall'utente (quindi comprese le applicazioni): es. Linee + Router IP +
Host con protocolli di Transport e Applicazioni
Applicazioni delle definizioni delle grandezze ai
diversi "sistemi"
Il comportamento prestazionale di un generico nodo di rete (intermedio o end-system)
determinato da:
Funzionalit del nodo
Numero di livelli architetturali coinvolti nella comunicazione
Complessit delle funzioni ai singoli livelli (protocolli e loro configurazioni)
Implementazione (hardware & software) di tali funzionalit
Architettura hardware
Architettura software
Applicazioni delle definizioni delle grandezze
Il generico nodo di rete
Livello 1 (Physical)
Funzione svolta: trasmissione di una sequenza di simboli (di norma '0' e '1') tra 2 stazioni
adiacenti (=collegate sullo stesso link)
Tipo di linea su cui pu avvenire la trasmissione
LAN
WAN
Livello architetturale molto "sottile"
Realizzato via hardware
Introduce un ritardo di elaborazione trascurabile (eventuali attese per l'accesso a linee LAN
determinano accodamenti di frame a livello MAC, non a livello fisico)
Livello 2 (Data Link Control)
Funzioni svolte: trasmissione con alcuni controlli di una sequenza di bit tra 2 stazioni adiacenti;
gestione di buffer per l'accodamento delle frame in attesa di trasmissione
Il comportamento totalmente determinato dallo specifico protocollo di livello 2 utilizzato:
SDLC: connection-oriented, flow-control, error-control
MAC IEEE 802.3: connectionless, NO flow-control, NO ack, error-control limitato
LLC-1: connectionless, NO flow-control, NO ack, NO error-control
LLC-2: connection-oriented, flow-control, ack
Livelli 3-7 (Network, ... , Application)
Il discorso diventa complesso in quanto coinvolge molti protocolli
Nelle strutture comunicative "stile TCP/IP" il livello Network si mantiene semplice, mentre la
complessit inizia dal livello Transport in su. Per esempio:
Transmission Control Protocol (TCP)
Protocolli di colloquio tra applicazioni TCP/IP (Web/HTTP, FTP, ... )
Tempo di Latenza del sistema "Router"
Tempo necessario al router per inoltrare
un pacchetto (Tforwarding)
Puro tempo di accodamento ed
elaborazione (Tqueueing+Tprocessing)
Nessun legame con il bit-rate delle
linee
E' funzione delle caratteristiche del router
e dei traffici attraverso esso
Ti n
Tforwarding
Tout
T
Ti n = tempo di ricezione della frame dal link di ingresso = F/Ci n
Tout = tempo di trasmissione della frame sul prossimo link = F'/Cout
DEF: Tempo di latenza del Router = Tforwarding = Tqueueing+ Tprocessing
Sistemi "nodi intermedi": i "Router"
R
Ci n
Cout
Diagramma temporale di un Router operante in
modalit "store-and-forward"
F
F'
Throughput del sistema "Router"
Numero di pacchetti elaborati da un router al secondo
Capacit di un sistema "Router"
MAX Throughput
Un fattore limitante dato da 1/Tprocessing
Nei router IP commerciali: fino a qualche Mpps
Utilizzodi un sistema "Router"
Di norma non si osserva l'utilizzo della CPU di un router, bens l'utilizzo dei link collegati alle
varie interfacce
Qualche osservazione sul concetto di Tempo di Latenza nei sistemi "Router"
Il tempo Tprocessing in prima approssimazione non funzione della dimensione del pacchetto (i
router analizzano solo le header di livello 3, la cui dimensione costante), mentre funzione
della configurazione del router (numero di righe di routing table, filtri, ... )
Con router molto carichi alcuni fenomeni fanno aumentare Tprocessing
Il tempo di latenza Tforwarding di un router pu aumentare all'aumentare dei traffici che
attraversano il router (si possono formare accodamenti, cio Tqueueing > 0)
Nel funzionamento normale di una rete Tqueueing una variabile casuale, quindi non ha un
valore deterministico
Se si vuole fornire un valore deterministico di Tforwarding necessario porsi in condizioni
particolari di traffico di rete, per esempio con sistema "Router" scarico (Tqueueing = 0). Tale
prova fornisce il tempo minimo di latenza del dispositivo: Tforwarding = Tprocessing
Sistemi "Linee di comunicazione"
Tempo di latenza del sistema "Linea di comunicazione"
Tempo necessario ai simboli per "volare" da un capo all'altro della linea
E' spesso indicato con t ("ritardo" o "tempo di propagazione")
Throughput del sistema "Linea di comunicazione"
Numero di simboli (bit) inviati da un nodo mittente su una linea nell'unit di tempo (s)
Unit di misura: bit-per-second (bps)
Capacit del sistema "Linea di comunicazione"
MAX num. di simboli (bit) inviabili da un nodo mittente su una linea nell'unit di tempo (s)
Spesso chiamata "velocit della linea" o "bit-rate della linea"
Utilizzodel sistema "Linea di comunicazione"
Rapporto tra il tempo in cui una linea impegnata dal nodo mittente nella trasmissione di
simboli e il tempo totale di osservazione
Spesso si esprime in percentuale
Nodo
'A'
Nodo
'B'
T
A B
t1 t2 t3 t4 t7 t8 t5 t6
T
osservazione
100
) ( ) ( ) ( ) (

7 8 5 6 3 4 1 2
+ + +
=
ne osservazio
T
t t t t t t t t
U(%)
Nota sulle unit di misura utilizzate per esprimere la latenza (o ritardo) delle linee di comunicazione
Secondi (o sottomultipli)
Il caso appena visto
Bit
E' ci che prende il nome di "Prodotto Banda Ritardo" e vale Ct
Esprime il numero di bit "in volo" sulla linea (ad un dato bit rate costante C) quando in
corso una trasmissione da parte del nodo mittente
1 0 1 0 0 1 1 1 0 0
Linea di comunicazione
ESEMPIO
C = 10 Kbps
Ritardo (t) = 1ms
Latenza (in bit) = 10000 (bps) x 1/1000 (s) = 10 bit
A B
L'applicazione dei concetti precedenti alle specifiche linee di comunicazione richiede la seguente
distinzione
Linee LAN (Ethernet, Token Ring, ... )
Elevata capacit di canale e bassissimi tempi di latenza (a rete scarica)
Possibili attese per l'accesso al mezzo => aumento delle latenze a livello MAC per
accodamento delle frame
Linee WAN (Leased-line, Switched-line, X.25, Frame-Relay, ... )
Media capacit di canale e latenza abbastanza elevata
Linee full-duplex: canale sempre disponibile
Linee half-duplex: attese per l'accesso al mezzo => accodamenti a liv. DLC
Sistemi "Linee di comunicazione": LAN Ethernet
Una componente della latenza del livello DLC:
accodamento per attesa di accesso al Bus
Latenza (ritardo) t del canale
Vista della LAN Ethernet a livello del canale fisico (coax, doppini+Hub)
Tempi di ritardo di canale estremamente ridotti e costanti: 5 ns/m
Non altro che un semplice conduttore
Il ritardo introdotto dal CSMA/CD (attesa di accesso al mezzo fisico) viene computato a livello
DLC
Staz. A Staz. B
Sistemi "Linee di comunicazione": LAN Ethernet
Vista della LAN Ethernet al di sopra del livello MAC
Il protocollo di livello 2 (MAC) prefissato: IEEE 802.3
Connectionless, NO flow control, NO ack, ...
Al di sopra del livello MAC si osserva un tempo di latenza in genere non costante (a causa del
possibile accodamento per non disponibilit del Bus o per collisioni) e di cui non possibile
dare un valore massimo
E' necessario rispettare un interframe gap di 12 byte
Physical
MAC
Physical
MAC
Latenza della LAN Ethernet al di sopra del MAC
Sistemi "Linee di comunicazione": WAN a circuito
Vista della WAN a circuito a livello del canale fisico
Capacit di canale fissa (19,2 Kbps, 64 Kbps, 128 Kbps, 512 Kbps, 2 Mbps, ... )
Latenza di canale
Costante
Valori (indicativi)
Connessione CDN 1000 km: 10-20 ms
Connessioni via satellite: centinaia di ms
Su una connessione full-duplex il canale sempre disponibile, mentre half-duplex no
Sistemi "Linee di comunicazione": WAN a circuito
Vista della WAN a circuito al di sopra del livello DLC
A differenza dei canali LAN, il protocollo di livello 2 non prefissato
Le performance sono determinate dal protocollo DLC utilizzato
Protocolli semplici con pochi controlli (es. PPP/HDLC)
Procedono alla trasmissione consecutiva delle frame al ritmo permesso dal canale
sottostante (devono solo eventualmente rispettare un interframe gap)
Protocolli sofisticati (es. SDLC, HDLC, ... )
Il ritmo di invio limitato dai vari controlli (finestra di trasmissione, ritorno degli ACK,
controlli di flusso, ... )
Sistemi "Backbone": esempio di dorsale IP
Si supponga di osservare il sistema "Backbone IP" (livello 3) indicato sotto, al quale viene
consegnato messaggio di lunghezza M (bit) attraverso il nodo di ingresso i=1
Pu essere interessante, per esempio, calcolare le grandezze Latenzae Capacit end-to-end in
funzione delle caratteristiche dei singoli sistemi elementari (linee, router, ... ). Il percorso seguito
dal pacchetto indicato dalla sequenza i =1, ... n di nodi attraversati
Physical
DLC
IPv4
Physical
DLC
IPv4
n-1
3
2
Latenza end-to-end al di sopra del livello IP
M
M
Nodo (i=1)
Ingresso
Nodo (i=n)
Uscita
C1, t1
Cn-1, tn-1
Il messaggio M incapsulato nel pacchetto IP procede sul backbone seguendo un percorso
identificato dalla sequenza i =1, ..., n di nodi visitati (si ipotizza che non esistano link paralleli tra
una qualunque coppia di nodi adiacenti). I due colori indicano il messaggio M consegnato all'IP e
gli overhead di incapsulamento Hi subti sui diversi link (Hi =Hip +Hdlci)
Nodo 1
Nodo 2
Nodo n-1
Nodo n
T
. . . . . . . . . . . . . .
tend-to-end
r
1
t1 (M+H1
)/C1
r
2
r
n-1
t n-1 (M+Hn-1
)/Cn-1
r
n
Link 1
Link 2
Link n-1
In generale la latenza end-to-end sperimentata da M una variabile casuale per 2 motivi
I ritardi di forwarding dei router (tforwarding indicato con r
i
) in genere sono variabili casuali (r1e
rn sono i ritardi di elaborazione del livello IP rispettivamente dei nodi di ingresso e di uscita)
Un pacchetto IP potrebbe sperimentare su una linea che connette 2 nodi adiacenti un tempo di
ritardo ti non costante ( il caso delle LAN a causa del protocollo d'accesso)
Per quanto concerne la capacit, senza informazioni aggiuntive possibile dare solo un estremo
superiore (mai raggiunto a causa degli overhead di incapsulamento Hi dei protocolli)
[ ]
) 1 ( ,..., 1 min
) (
1
1
= <
+ + + + =

=

n i C C
r C H M r
i
i
end to end
n
n
i
i i i i i end to end

Sistema visto dall'utente finale
La grandezza percepita dall'utente finale il Tempo di Risposta di una transazione
Intervallo di tempo tra l'immissione di una richiesta di transazione e l'arrivo completo della
risposta: Tempo_Risposta =TResp- TReq
E' determinato dalla modalit di interazione tra i 2 processi applicativi, nonch dallo stato della
rete intermedia
Non deterministico
T
TReq
TResp
Request
Response
Approcci nello studio delle performance delle reti
Modelli deterministici
I traffici che insistono su una rete sono univocamente descritti da funzioni deterministiche nel
dominio del tempo
Anche le situazioni anomale (quali la congestione dei nodi) vengono descritte in tal modo
Sono una drastica semplificazione dei casi reali
Modelli probabilistici
I traffici che insistono su una rete sono descritti da funzioni di distribuzione di una o pi
variabili casuali
Sono pi sofisticati ma anche decisamente pi complessi
Approcci nello studio delle performance delle reti
I contorni del problema
L'ottimizzazione delle prestazioni di una data rete una operazione che, a partire da un insieme di
parametri noti, definisce completamente le restanti grandezze
E' importante chiarire
Quali sono le grandezze note e quali le grandezze da determinare
A quale livello architetturale avviene lo studio, nonch come operano tutti i protocolli
coinvolti
Quali sono le ipotesi semplificative adottate e quanto sono applicabili ai casi reali
In questa trattazione verr sviluppato un semplice esempio
Calcolo della MTU ottima sulla stazione mittente, al fine di minimizzare la latenza end-to-end
nel trasporto di un messaggio M su una dorsale di router IPv4
Studio di una struttura di rete
LAN-to-LAN over WAN
Si tratta di una struttura semplice ma molto utile al fine di studiare l'influenza delle variabili di rete
sui valori prestazionali
Lo studio tratter i casi pi semplici (=> condizioni ideali ma restrittive) per poi fare alcuni cenni ai
casi pi complessi
Si utilizzer come riferimento lo stack protocollare TCP/IP (IPv4)
Stazione A Stazione
B
LAN1 LAN2
Router Router
WAN point-to-point leased
LAN-to-LAN over WAN con protocollo IPv4
Si supponga di disporre di una rete IP con struttura LAN-to-LAN over WAN:
LAN Ethernet a 10 Mbps
Link WAN 2 Mbps leased; protocollo DLC PPP
Si vuole calcolare il tempo di latenza tend-to-end sperimentato da un messaggio M (potrebbe essere un
segment TCP o un datagram UDP) spedito dalla stazione A verso la stazione B
Stazione A
Stazione
B Router Router
Physical
DLC
IPv4
M
Physical
DLC
IPv4
Physical
DLC
Physical
DLC
IPv4
Physical
DLC
Physical
DLC
IPv4
M
LAN 1 LAN 2
Le diverse grandezze di rete sono state indicate con le seguenti notazioni
tlan1 = tempo di latenza sulla rete LAN1
Clan1 = capacit rete LAN1
Hlan1 = overhead di incapsulamento subto del messaggio M nella trasmissione sulla LAN1
rrouter1 = tempo di latenza del Router1
twan= tempo di ritardo della linea WAN CDN
Cwan= capacit linea WAN
Hwan= overhead di incapsulamento subto del messaggio M nella trasmissione sulla WAN
Come 1 caso si studia la trasmissione di un messaggio di lunghezza M (bit) nell'ipotesi che non
subisca alcuna frammentazione nell'attraversamento della rete
Il datagram subisce una serie di store-and-forward sequenziali sui nodi di rete (coppia di router)
che collega le 2 end-station
Stazione A
Stazione
B
Router1 Router2
Physical
DLC
IPv4
M
Physical
DLC
IPv4
Physical
DLC
Physical
DLC
IPv4
Physical
DLC
Physical
DLC
IPv4
M
Grafico del tempo di latenza tend-to-end nel trasporto senza frammentazione attraverso la rete IP di un
messaggio lungo M (bit). Con i 2 colori si sono distinte le testate (Hip + Hdlc) dei protocolli dal
messaggio M
Stazione A
Router1
Router2
Stazione
B
T
t end-to-end
tlan1 tlan2
(M+Hlan1)/Clan1
r1 r2 twan
(M+Hlan2)/Clan2 (M+Hwan)/Cwan
Ipotesi semplificativa
La rete non ha altri traffici diversi da M
In virt dell'ipotesi sopra e dei dati del problema (LAN uguali e router uguali), si ha (tra parentesi
sono stati indicati i valori assegnati alle diverse grandezze)
tlan1 = tlan2 = tlan = cost = tempo di latenza sulla rete Ethernet (0,005 ms)
Clan1 = Clan2 = Clan= capacit rete Ethernet (10.000.000 bps)
Hlan1 = Hlan2 = Hlan= overhead di incapsulamento (MAC+LLC+SNAP+IP) subto del messaggio
M nella trasmissione sulle LAN (440 bit)
rrouter1 = rrouter2 = rrouter = cost = tempo di latenza (tprocessing) dei router (0,01 ms)
twan= tempo di ritardo della linea wan CDN (10 ms)
Cwan= capacit linea wan (2.000.000 bps)
Hwan= header PPP+IP del messaggio M su WAN (224 bit)
L'espressione di tend-to-end quindi data dall'espressione riportata qui sotto. Si noti la diretta
proporzionalit di tend-to-end rispetto alla dimensione di M
4 4 3 4 4 2 1
alit proporzion di fattore
2 2 2 2 1 1 1 1
) 2 1 ( cos
2 2 ) ( 2
: ottiene si fatte ipotesi le Per
) ( ) ( ) (
lan wan
lan lan lan wan wan wan wan router lan end to end
lan lan lan router wan wan wan router lan lan lan end to end
C C M t
C M C H C M C H r
C M H r C M H r C M H
+ + =
= + + + + + + =
+ + + + + + + + + + =

Esempio: si sostituisca l'insieme dei valori delle ipotesi iniziali
tend-to-end (ms) = 10,23 + 0,0007M
Un messaggio di 1000 byte, per esempio, subisce una latenza di 15,83 ms
Nel caso Cwanfosse 64 kbps anzich 2 Mbps, la latenza risulta ovviamente pi "sensibile" alla
dimensione di M
tend-to-end (ms) = 13,618 + 0,01583M
Morale della favola: pi i messaggi sono lunghi, pi tempo impiegano per essere trasportati dall'IP
mittente all'IP destinatario (a causa dei nodi operanti in modalit store-and-forward)
Si cosideri questo 2 caso: si supponga di frammentare il messaggio M in n fragment IP di ugual
dimensione: ciascun fragment IP contiene una parte di M e subisce la stessa serie di
store-and-forward sequenziali vista nel caso precedente senza frammentazione
La frammentazione in pi datagram provoca 2 fenomeni aventi effetto opposto sulla latenza totale:
aumento dell'overhead di imbustamento => tende a far aumentare la latenza
parallelismo delle operazioni store-and-forward => diminuzione della latenza
Physical
DLC
IPv4
M
Physical
DLC
IPv4
Physical
DLC
Physical
DLC
IPv4
Physical
DLC
Physical
DLC
IPv4
M
m1
m2
......
m2
m1
......
Fragmentation Reassembling
Grafico del tempo di latenza nel trasporto con frammentazione attraverso la rete IP di un messaggio
lungo M bit (con rete scarica)
Stazione A
Router1
Router2
Stazione B
T
gap gap
. . . . . . . . .
(frame contigue)
. . . . . . . . .
(fr. contigue)
. . . . . . . . .
(fr. non contigue)
m1 m2 m3
m1 m2 m3
m1 m2 m3
t end-to-end
Alcune considerazioni sul grafico precedente
Sul canale LAN1 i frammenti m1, m2, ... , sono trasmessi senza gap intermedi (per semplicit
si trascurato l'interframe-gap delle LAN) in quanto:
la LAN scarica
il livello DLC (MAC+LLC), nel caso IP, opera in modalit connectionless unacknowledged
(LLC1 => non ci sono degli idle-time per attesa di ACK)
Anche sul canale WAN i frammenti viaggiano senza gap intermedi (sempre trascurando
l'interframe-gap dei protocolli su WAN) poich:
la WAN viene alimentata con i soli pacchetti m1, m2, ... , provenienti da una linea a
capacit pi elevata (la LAN1)
PPP nella fase "Data Transfer" non usa ACK
L'espressione di tend-to-end quindi riportata qui sotto: di questa si cerca il valor minimo rispetto a n
Intero
wan lan wan
lan wan wan
end to end
end to end
wan wan lan
lan wan wan wan wan lan lan router lan end to end
H C C M n
n C M C H
n
n M
n n M
C H n C n M
C n M C M C H n C H r n M
) ( ) ( 2
0 ) ( 2
) , (
: a rispetto ) , ( di minimo il Cercando
) ( 2 cost
) ( 2 ) ( 2 ) , (
*
2
=
= =
+ + =
= + + + + + + =

MTU
Sostituendo i dati del problema
20
) (
) (
in espresso con 560 8
*
*
*
+ =
=
n
byte M
byte MTU
byte M M n
Intero
MAC Header MAC Trailer LLC Header SNAP Header Messaggio
Si supponga di dover trasmettere un messaggio M lungo 1450 byte (11600 bit)
Il valore n* che minimizza la latenza nel trasporto dell'intero messaggio n* = 5
Pertanto nella configurazione della stazione mittente converr imporre una MTU = 310 byte (si
tratta di un risultato teorico che spesso non si riesce a mettere in pratica in quanto sulle reti
Ethernet IEEE 802 la MTU di norma fissa a 1492 byte)
Sostituendo i valori nell'espressione di tend-to-end (si fa notare che tra i termini costanti l'addendo
dominante twan= 10 ms), si ottiene il valore minimo della latenza: tend-to-end = 16,942 ms
Senza alcuna frammentazione (n=1) la latenza sarebbe stata: tend-to-end = 18,35 ms
Dato un messaggio M lungo 1450 byte qui sotto viene riportato il grafico della latenza (tend-to-end) al
variare di n (variazione discreta, essendo n intero).
Si pu notare il punto di minimo N*=5 determinato per via analitica
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
n (fragment)
16
18
20
Latenza (ms)
Grafico della latenza (tend-to-end) al variare di n nel caso di trasmissione di un messaggio M lungo 100
byte (diagr. inferiore), 500 byte (diagr. di mezzo) e 1000 byte (diagr. sup.)
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
n (fragment)
10
12
14
16
18
Latenza (ms)
Visto che n* funzione della dimensione del messaggio M, qui sotto si riporta il grafico che indica
se e come conviene frammentare il messaggio M (naturalmente ferme restando tutte le ipotesi
iniziali)
0
1.000
2.000
3.000
4.000
5.000
6.000
7.000
8.000
9.000
10.000
M (in bit)
0
1
2
3
4
5
n*
I risultati appena visti mostrano che il messaggio M "soffre" gli store-and-forward, la rapidit dei
quali in parte funzione delle capacit delle linee
Si supponga di modificare una ipotesi iniziale: Cwan= 64 kbps (con M=11600 bit)
Ci si potrebbe aspettare un grosso beneficio dalla frammentazione, invece .....
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
n (fragment)
200
250
300
Latenza (ms)
I risultati ottenuti finora hanno mostrato che in alcune situazioni conviene frammentare i datagram
IP
La frammentazione comporta 2 fenomeni aventi effetto opposto sulla latenza totale sperimentata dal
messaggio M:
aumento dell'overhead di imbustamento (aumento della latenza)
parallelismo degli store-and-forward dei messaggi (diminuzione della latenza)
Vista la criticit delle operazioni store-and-forward, risulta interessante studiarne gli effetti in reti a
topologia pi complessa
Studio di una struttura di rete pi complessa
LAN-to-LAN via 3 nodi IP
Si tratta di una struttura pi complessa della precedente, alla quale possono essere ricondotte molte
reti reali
Si utilizza sempre IP come protocollo di livello 3
L'elemento nuovo il router IP intermedio che permette la comunicazione tra i router attestati su
LAN1 e LAN2: si allunga la pipeline per i messaggi
Stazione A Stazione B
LAN1 LAN2
Router1 Router3
Linea WAN1
point-to-point leased
Router2
Linea WAN2
point-to-point leased
La rete oggetto di studio avr le seguenti caratteristiche:
Si vuole calcolare il tempo di latenza sperimentato da un messaggio M per andare da A a B
Per comodit si tratter subito il caso di frammentazione in n sottomessaggi (l'assenza di
frammentazione ricade come caso particolare n=1)
Physical
DLC
IPv4
M
Physical
DLC
IPv4
Physical
DLC
Physical
DLC
IPv4
Physical
DLC
Physical
DLC
IPv4
M
m1
m2
......
m2
m1
......
Fragmentation Reassembling
Physical
DLC
IPv4
Physical
DLC
Come nel caso precedente, le grandezze di rete sono state indicate con le seguenti notazioni
twan1 = tempo di ritardo della linea WAN1 CDN
twan2 = tempo di ritardo della linea WAN2 CDN
Cwan1 = capacit linea WAN1
Cwan2 = capacit linea WAN2
Hwan1 = overhead di incapsulamento subto da M nella trasmissione sulla WAN1
Hwan2 = overhead di incapsulamento subto da M nella trasmissione sulla WAN2
Ipotesi semplificativa
La rete non ha altri traffici diversi da M
In virt dell'ipotesi sopra e dei dati del problema (LAN uguali, WAN uguali e router uguali), si ha
(tra parentesi sono stati indicati i valori assegnati alle diverse grandezze)
tlan1 = tlan2 = tlan = cost = tempo di latenza sulla rete Ethernet (0,005 ms)
Clan1 = Clan2 = Clan= capacit rete Ethernet (10.000.000 bps)
Hlan1 = Hlan2 = Hlan= overhead di incapsulamento (MAC+LLC+SNAP+IP) subto del messaggio
M nella trasmissione sulle LAN (440 bit)
rrouter1 = rrouter2 = rrouter = cost = tempo di latenza (tprocessing) dei router (0,01 ms)
twan1 = twan2 = twan = tempo di ritardo della linea wan CDN (10 ms)
Cwan1 = Cwan2 = Cwan = capacit linea wan (2.000.000 bps)
Hwan1 = Hwan2 = Hwan = header PPP+IP del messaggio M su WAN (224 bit)
Grafico del tempo di latenza nel trasporto con frammentazione attraverso la rete IP di un messaggio
lungo M bit (con rete scarica)
Stazione A
T
gap
. . . . . . . . .
(frame contigue)
. . . . . . . . .
(fr. contigue)
. . . . . . . . .
(fr. non contigue)
m1 m2 m3
m1 m2
m1 m2
Router 1
. . . . . . . . .
(fr. contigue)
m1 m2
Stazione
B
Router 2
Router 3
t end-to-end
Alcune considerazioni sul grafico precedente
Sul canale LAN1 i frammenti m1, m2, ... , sono trasmessi senza gap intermedi (trascurando
l'interframe-gap delle LAN) in quanto la LAN scarica e il livello DLC opera in modalit
connectionless unacknowledged (LLC1)
Anche su entrambi i canali WAN i frammenti viaggiano senza gap intermedi (sempre
trascurando l'interframe-gap dei protocolli su WAN) poich:
le WAN viene alimentata con i soli pacchetti m1, m2, ...
Cwan1 < Clan1
Cwan2 non maggiore di Cwan1 (nelle ipotesi si sono prese uguali)
PPP nella fase "Data Transfer" non usa ACK
Nel caso cada qualcuna delle ipotesi precedenti, necessario adattare il grafico (vedasi
prossima slide)
Grafico di L_tot nel trasporto con frammentazione di un messaggio lungo M bit (con rete scarica),
nell'ipotesi di Cwan2 > Cwan1 (questo grafico viene mostrato solo come esempio; per il calcolo di
tend-to-end verr utilizzato il grafico precedente)
Stazione A
T
gap
. . . . . . . . .
(frame contigue)
. . . . . . . . .
(fr. contigue)
. . . . . . . . .
(fr. non contigue)
m1 m2 m3
m1 m2
m1 m2
Router 1
m1 m2
Stazione
B
Router 2
Router 3
. . . . . . . . .
(fr. non contigue)
gap
t end-to-end
Intero
wan lan wan wan
wan lan wan wan
end to end
end to end
wan wan wan wan lan lan lan wan router lan end to end
C M C M H C n
C n M C n M C H
n
n M
n n M
C M C n M C H n C n M C H r n M
) 2 ( ) (
0 ) ( ) ( 2
) , (
: a rispetto ) , ( di minimo il Cercando
) ( ) 1 ( ) ( 2 2 2 3 2 ) , (
*
2 2
+ =
= =
= + + + + + + + + =

L'espressione di tend-to-end quindi riportata qui sotto: di questa si cerca il valor minimo rispetto a n
Si supponga di dover trasmettere un messaggio M lungo 1450 byte (11600 bit).
Il valore n* che minimizza la latenza nel trasporto dell'intero messaggio dato da: n* = 9
Pertanto nella configurazione della stazione mittente converr imporre una MTU = 181 byte (
un esercizio teorico; nella realt sarebbe impossibile imporre una simile MTU)
Sostituendo i valori nell'espressione di tend-to-end (si fa notare che tra i termini costanti gli
addendi dominanti sono twan= 10 ms), si ottiene il valore minimo della latenza: tend-to-end =
27,95022 ms
Senza alcuna frammentazione (n=1) la latenza sarebbe stata 34,272 ms
Dato un messaggio M lungo 1450 byte qui sotto viene riportato il grafico della latenza (tend-to-end) al
variare di n (variazione discreta, essendo n intero)
Si pu notare il punto n*=9 precedentemente determinato per via analitica
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
n (frammentazione)
28
30
32
34
Latenza (ms)
In questa struttura di rete (1 store-and-forward in pi rispetto al caso LAN-to-LAN via WAN) i
benefici dovuti alla frammentazione sono pi marcati
Il grafico precedente mostra che si perde molto a non frammentare, mentre si perde poco a
sovraframmentare (la funzione tend-to-end(n) cresce lentamente):
tend-to-end (n=1) circa uguale a tend-to-end (n=72)
E' importante considerare la dimensione del messaggio M:
se il messaggio corto la frammentazione peggiora le cose in quanto si fanno sentire gli
overhead di imbustamento dei protocolli (vedasi prossimo grafico)
il valore di soglia di M oltre il quale conviene frammentare inferiore al caso LAN-to-LAN via
WAN (vedasi grafico pi avanti)
Grafico della latenza (tend-to-end) al variare di n nel caso di trasmissione di un messaggio M lungo 40
byte (diagr. inferiore), 500 byte (diagr. di mezzo) e 1000 byte (diagr. superiore)
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
n (frammentazione)
20
22
24
26
28
30
Latenza (ms)
Analogamente all'esempio precedente, data la lunghezza del messaggio M, qui sotto riportato il
grafico che illustra se e come conviene frammentare M
0
1.000
2.000
3.000
4.000
5.000
6.000
7.000
8.000
9.000
10.000
M (in bit)
0
2
4
6
8
n*
Dato M, una volta ricavato n* (numero ottimo di frammenti), possibile ricavare la Maximun
Transmission Unit ottima MTU*. Si noti che MTU* ancora funzione di M.
0
1.000
2.000
3.000
4.000
5.000
6.000
7.000
8.000
9.000
10.000
M (in bit)
300
500
700
900
1.100
1.300
1.500
MTU* (in bit)
L'analisi della struttura LAN-to-LAN via WAN ha mostrato che in quel caso l'abbassamento di
C_wan a 64 kbps portava n*=1 (nessuna frammentazione)
Si supponga di portare anche in questo caso Cwan = 64 kbps (con M=11600 bit).
Si ottiene lo stesso fenomeno ? Per nulla: n*=7 e la frammentazione efficace.
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
n (frammentazione)
250
300
350
400
Latenza (ms)
Il trasporto IP attraverso una catena di router, nell'ipotesi di rete (quasi) scarica, pu essere
ottimizzato procedendo a frammentazione dei datagram
E' necessario conoscere quale sar la dimensione M del messaggio da inviare, in quanto n*
funzione di M. Questo si ricava analizzando come opera l'entit che genera il messaggio M
Nel caso di TCP
M (in byte) = MSS + 20
Il processo di frammentazione viene forzato imponendo (quando possibile) la MTU* al DLC su cui
si appoggia IP
Struttura LAN-to-LAN over WAN, protocollo IP
Rimozione di alcune ipotesi semplificative
Nello studio della struttura LAN-to-LAN via WAN (cos come della struttura con i 3 router IP) si
ipotizzato che attraverso la rete transitasse solo il messaggio M
Tale ipotesi decisamente restrittiva poich solo alcune situazioni sono trattabili (approssimabili)
sotto tale ipotesi
E' pertanto interessante analizzare gli effetti su tend-to-end dovuti al carico di rete, in particolare con
riferimento alla possibilit di frammentare i messaggi. Purtroppo in questo caso il problema diventa
di complessit elevata
E' necessario conoscere l'entit e la distribuzione degli altri traffici
E' necessario valutare l'incremento della latenza dei router (rrouter) dovuto alle code formate da
tutti i pacchetti (messaggio M e altri traffici)
Occorre studiare gli effetti dei traffici LAN sulle trasmissioni tra router e stazioni
Supponendo di conoscere entit e distribuzione dei traffici, risulta molto complesso valutare
l'eventuale comportamento su LAN dei pacchetti m1, m2, ... , frutto di una frammentazione
la lunghezza media (=> tempo d'attesa) delle code presenti nei router, formate da pacchetti in
attesa di essere trasmessi sui link (soprattutto WAN)
Per tali motivi qui di seguito si proceder fornendo solo una trattazione qualitativa del problema, al
fine di comprenderne solo alcuni macroaspetti
La rete oggetto di studio avr le seguenti caratteristiche:
2 reti LAN uguali; 2 router uguali
oltre al messaggio M, vi sono traffici provenienti da altre comunicazioni
Si vuole valutare qualitativamente l'effetto della frammentazione su tend-to-end
Physical
DLC
IPv4
M
Physical
DLC
IPv4
Physical
DLC
Physical
DLC
IPv4
Physical
DLC
Physical
DLC
IPv4
M
m1
m2
......
m2
m1
......
Altri traffici
Altri traffici
Grafico qualitativo del tempo di latenza nel trasporto con frammentazione attraverso la rete IP di un
messaggio lungo M bit (con altri traffici presenti in rete). In questo caso rrouter una variabile
casuale; inoltre viene persa la contiguit delle frame sui link LAN1 e WAN.
Stazione
Router
Router
Stazione
T
gap gap
. . . . .
m1 m2 m3
m1 m2 m3
m1 m2 m3
m4
. . . . . . . . .
. . . . . . . . .
gap
Si supponga di trasmettere il messaggio M frammentato su una rete con elevato traffico
Effetti sulle trasmissioni LAN
La rete LAN un canale condiviso: quando una stazione vi accede, ha tutta la convenienza
a trasmettere un messaggio il pi lungo possibile (soprattuttu nel caso Ethernet)
Effetti sulle WAN e sui router
I vari frammenti di M risultano sempre pi inframmezzati da altri traffici
Il messaggio M arriva a pezzi in un lasso di tempo abbastanza dilatato =>
in queste condizioni la frammentazione in genere aumenta la tend-to-end
Protocolli di comunicazione "confermati"
Fattori limitanti le prestazioni
Sia data la struttura indicata sotto: si tratta di un esempio di rete TCP/IP molto semplice in cui vi
sono 2 host collegati direttamente attraverso una linea di comunicazione
Si vuole studiare la limitazione subita dal throughput, osservato dalle applicazioni al di sopra del
TCP (giallo_chiaro = messaggi_con_dati_applicativi; verde_scuro = ack)
Physical
DLC
IPv4
Nodo A
C, t
TCP
Physical
DLC
IPv4
Nodo B
TCP
Nodo
'A'
Nodo
'B'
T
RTTsegment-ack
C
RTT
W
ne trasmissio
e
: limitanti fattori Due
Generalizzazione del caso particolare considerato prima: le ipotesi
Si consideri una rete a commutazione di pacchetto avente un backbone realizzato con un
protocollo di livello Network di tipo connectionless "non confermato" (es. IP)
Una stazione mittente invia dati ad una stazione destinataria utilizzando i servizi offerti da un
protocollo di livello Transport di tipo "confermato" con invio secondo uno schema a "sliding
window" (es. TCP).
Physical
DLC
Network
Nodo mittente
(i=1, j=m)
Transport
Physical
DLC
Network
Nodo destinatario
(i=n, j=1)
Transport
M
M
Generalizzazione del caso particolare considerato prima (cont.): lo schema temporale
Sequenza di nodi sul percorso di andata del messaggio M: i =1 (mitt), 2, 3, ... , n (dest)
Sequenza di nodi sul percorso di ritorno dell'ACK: j =1 (dest), 2, 3, ... , m (mitt)
Si ipotizza che l'ACK non trasporti traffico di ritorno. In caso contrario vanno aggiunti i tempi
di trasmissione dei messaggi M' che costituiscono il flusso opposto
Nodo (1)
Mittente
Nodo 2
T
RTTsegment-ack
Nodo n-1
Nodo (n)
Destinat.
. . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tack
MSG
ACK
Nodo
j=1
Nodo
j=m-1
Nodo
j=2
Nodo
j=m
rn r'1
r' m r1
ttcp
Generalizzazione del caso particolare considerato prima (cont.): le espressioni analitiche
M = lunghezza in bit del msg consegnato al livello Transport (che genera un pacchetto)
Wtrasm = numero di bit (dati) consecutivi inviabili dal protocollo di Transport
tack = tempo di generazione di un ACK a fronte della ricezione di un messaggio corretto
ttcp = tempo necessario al TCP mittente per elaborare un ACK e decidere il successivo invio
(coerentemente con la finestra di trasmissione)
ri e r'j = (rispettivamente) tempi di latenza IP sperimentati sui nodi dai messaggi M in andata e
dagli ACK in ritorno
ti
e t'
j
= tempi di ritardo sui link (rispettivamente) sul percorso di andata e di ritorno
C
i
e C'
j
= capacit dei link (rispettivamente) sul percorso di andata e di ritorno
H
i
e H'
j
= overhead di incapsulamento (rispettivamente) sul percorso di andata e di ritorno
[ ]
[ ] [ ]
k k i
i
k
tcp m
m
j
j
j j j j ack n
n
i
i i i i i
k k trasm
C H C C
r C H r r C H M r RTT
H M M C RTT W Throughput
con link sul overhead e min
) (
dove ) ( , ( min
1
1
1
1

+ + + + + + + + + + =
+

=
=

Fattori limitanti le prestazioni: il caso del TCP
Physical
DLC
IPv4
Nodo A
C, t
TCP
Physical
DLC
IPv4
Nodo B
TCP
Nodo
'A'
Nodo
'B'
T
RTT
Si consideri il caso di 2 host TCP/IP connessi direttamente attraverso una linea di capacit C e
ritardo t (il caso visto precedentemente)
Qui sotto viene riportato un possibile diagramma temporale (si ipotizza tack=0)
t
1
t
2
t
3
t
4
Fattori limitanti le prestazioni: il caso del TCP
RTT
W
H MSS
MSS
C RTT
C
H MSS
MSS
W
t t
RTT
W
H MSS
MSS
C RTT
C
H MSS
MSS
W
t t
C
H MSS
RTT
H MSS
MSS
C
RTT
W
Throughput
trasm
trasm
trasm
trasm
trasm
Max
<
+
>
+
>
>
+
<
+
<
+
+ =
+
=
43 42 1
3 2 1
limitante Fattore
4 3
limitante Fattore
4 3
...
) (
Se ) 2
...
) (
Se 1)
: casi 2
2
2 dove ) ; min(
Applicando quanto visto nel caso generale, si ottengono le espressioni analitiche del Max
Throughput raggiungibile nel trasferimento tra 2 processi applicativi utilizzanti TCP nel caso di 2
host adiacenti. Nelle formule H =Htcp+Hip+Hdlc

7 Performance

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

7 Performance

Uploaded by

Copyright:

Available Formats

Politecnico di Milano

Corso di Telematica D.U.

You might also like