2 Risultati sperimentali

Per verificare sperimentalmente la situazione descritta nel paragrafo precedente, si sono condotte alcune prove di laboratorio sulla rete mostrata in figura 6.1. Per i test si è utilizzato ancora una volta netperf con il test ``TCP stream'', ponendo il client su H1 e il server su H2 (per cui il flusso di dati va da H1 a H2); su G2 è stato attivato NIST Net in modo da simulare la presenza di una rete intermedia con una data probabilità di perdita (in sostanza NIST Net agisce scartando i pacchetti in transito secondo la probabilità fornitagli). La frammentazione è stata ottenuta modificando la MTU dell'interfaccia virtuale di IPsec su H1, scegliendo valori tali da ottenere il numero di frammenti desiderato e frammenti della dimensione massima. Nei test non si è utilizzato il selective acknowledgement (SACK) di TCP⁶⁶ (tale opzione è implementata in Linux ma non in tutti i sistemi) per non alterare il comportamento standard di TCP in presenza di perdite casuali come quelle qui introdotte.

La figura 6.5 mostra l'andamento del throughput di IPsec in funzione del numero di frammenti, per varie probabilità di perdita comprese tra 0 e 1%. Per $p=0$ si nota che la curva cresce rapidamente passando da un valore $X=839$ KB/s per $n = 1$ ad un valore $X=940$ KB/s già per $n=4$, assestandosi poi intorno a questo valore. Tra il caso $n = 1$ e il caso $n=4$ si ha quindi un miglioramento di circa il 12%, che scende a circa il 10% per $n=3$, mentre non sale significativamente per $n>4$. Per $p=0,\!25\%$ si vede che la curva cresce fino a $n=3$ (a cui corrisponde un guadagno di circa il 10% sul rispettivo caso $n = 1$), poi rimane circa costante dopo di che decresce leggermente per $n>6$ (per $n=8$ si ha comunque ancora un guadagno di circa il 7%). La curva corrispondente a $p=0,\!5\%$ ha anch'essa un andamento crescente fino a $n=3$ (con un guadagno di poco più del 5%) dopo di che decresce lentamente. La curva relativa a $p=0,\!75\%$ si mantiene sostanzialmente costante fino a $n=3$ per poi decrescere, infine la curva relativa a $p=1\%$ assume subito una pendenza negativa, presentando nel caso $n=3$ una perdita di poco più del 4% rispetto al caso $n = 1$. Le curve decrescono sempre più rapidamente al crescere di $p$ (come ci si attendeva), per cui si allontanano tra loro al crescere di $n$. Da questi risultati si può concludere che, su una rete affidabile (ovvero con probabilità di perdita media inferiore all'1%), sfruttando la frammentazione dei pacchetti IP si può avere un miglioramento degno di nota delle prestazioni di IPsec. Non appare però conveniente andare oltre i 3 (o al massimo 4) frammenti per ogni pacchetto IP, poiché il maggior guadagno a probabilità di perdita nulla è pressoché insignificante, mentre per probabilità di perdita superiori si può avere un peggioramento.

Figura 6.5: Comportamento di IPsec in presenza di frammentazione. Variazione del throughput in funzione del numero di frammenti.

Rispetto al modello teorico analizzato in precedenza si può notare che l'andamento delle curve è quello previsto. Si nota però che il miglioramento nel caso $p=0$ riscontrato sperimentalmente (12% per $n=4$) è molto maggiore rispetto a quello teorico (6% per $n \rightarrow \infty$). In figura 6.6 sono mostrati gli andamenti (per $p=0$) dell'efficienza teorica e del throughput misurato, quest'ultimo riportato sulla scala dell'efficienza eguagliandone il valore per $n = 1$ alla corrispondente efficienza teorica, e utilizzando poi tale rapporto per tradurre gli altri punti. Come si vede, le due curve si discostano notevolmente: un effetto del genere era stato previsto (attribuendolo essenzialmente agli ack), ma lo scostamento è tanto grande da suggerire l'opportunità di un approfondimento sulla questione.

Figura 6.6: Confronto (nel caso $p=0$) tra l'efficienza teorica e l'efficienza misurata sperimentalmente.

Essendo in assenza di perdite, il secondo degli ``effetti collaterali'' ignorati dal modello (ovvero i meccanismi di ritrasmissione di TCP) non sussiste, per cui ci si può concentrare sul primo, vale a dire la presenza degli ack. Gli ack, come detto, fluiscono in senso opposto ma contribuiscono ad occupare la banda disponibile⁶⁷: poiché viene inviato un ack per ogni pacchetto (e non per ogni frammento) si può pensare di includerli nell'overhead di pacchetto, ovvero in $L_{OP}$. Nelle prove sperimentali, un ack è composto da 104 byte: 20 byte per l'header IP esterno, 8 byte per l'header ESP, 8 byte per l'IV, 20 byte per l'header IP interno, 32 byte per l'header TCP, 2 byte di padding, 2 byte per il trailer ESP e infine 12 byte per i dati di autenticazione. Si può allora inserire nella formula dell'efficienza un valore $L_{OP}=$ 188 byte, anziché 84 byte come considerato in precedenza: in questo caso il valore asintotico rimane pari a circa $0,\!987$, ma il valore per $n = 1$ è pari a circa $0,\!861$ (anziché $0,\!931$), il che comporta un guadagno asintotico di circa il 14,6%, decisamente in linea con il valore ottenuto sperimentalmente.

Si è allora di confrontato il throughput sperimentale con l'andamento dell'efficienza teorica, questa volta calcolata includendo gli ack in $L_{OP}$, anche qui parificando il throughput per $n = 1$ alla corrispondente efficienza teorica e traducendo poi in base a tale rapporto i valori di throughput misurati in valori sulla scala dell'efficienza. Il risultato è mostrato in figura 6.7: come si vede con questa ipotesi l'andamento osservato sperimentalmente è molto vicino a quello teorico.

Figura 6.7: Confronto (nel caso $p=0$) tra l'efficienza teorica includendo gli ack nell'overhead di pacchetto e l'efficienza misurata sperimentalmente.

Per eliminare completamente l'effetto degli ack, e valutare l'adeguatezza del modello, si sono infine condotti dei test su UDP anziché su TCP⁶⁸. L'overhead in questo caso è più basso, infatti, poiché l'header UDP misura solamente 8 byte contro i 32 byte di TCP, in questo caso si ha $L_{OP} = 60$ byte. Questo significa che, sempre per $p=0$, si ha $E(1) \simeq 0,\!947$, e che quindi il guadagno per $n \rightarrow \infty$ è di circa il 4,2% (il valore asintotico dell'efficienza è sempre il medesimo). Come si vede in figura 6.8, la coincidenza tra valori teorici e sperimentali è in questo caso pressoché completa.

Figura 6.8: Confronto (nel caso $p=0$) tra l'efficienza teorica e l'efficienza misurata sperimentalmente per UDP.

Footnotes

... TCP⁶⁶

L'opzione SACK permette a TCP di inviare riscontri selettivi oltre ai normali riscontri cumulativi. Con il TCP standard infatti il riscontro sul byte $x$ comporta implicitamente il riscontro su tutti i byte precedenti $x$.

... disponibile⁶⁷

Il canale è infatti half-duplex.

... TCP⁶⁸

Per effettuare questi test si è abbassata a 10 Mbit/s la velocità di trasmissione sul collegamento tra H1 e G1 per evitare che, in mancanza dei meccanismi di controllo di flusso di TCP, netperf inviasse dati a 100 Mbit/s (con conseguenti enormi e incontrollate perdite su G1).