Pchar

Andrea Furegon 812693
 * __PCHAR__**

//__Introduzione__// Pchar è una reimplementazione della particolare utility pathchar, sviluppata da Van Jacobson. Le funzionalità principali di entrambi i programmi sono di misurare la larghezza di banda, la latenza e la perdita di informazioni lungo una comunicazione punto a punto attraverso la rete Internet. Ciò avviene tramite la misurazione del round trip time (RTT) inviato da un singolo host lungo la rete internet. Come traceroute, pchar prende vantaggio dal campo time-to-live (ttl) dei pacchetti IP. Ttl determina in quanti nodi un pacchetto può transitare prima di diventare obsoleto ed essere scartato. Quando un nodo (router) riceve un pacchetto obsoleto, lo scarta e invia un errore ICMP al mittente. L'indirizzo sorgente dell'errore nel pacchetto ICMP corrisponde al router che ha ricevuto il pacchetto e l'ha successivamente scartato. Settando il ttl a //n// è possibile trovare l'indirizzo dell'ennesimo router nel percorso.

//__Funzionamento__//

Pchar funziona inviando una serie di pacchetti con diversi valori di ttl e differenti dimensioni. Per ogni pacchetto viene misurato il tempo dell'arrivo del pacchetto ICMP di errore. Dall'analisi statistica delle misure pervenute, pchar stima la latenza e la banda per ogni nodo nel percorso, la distribuzione delle code di attesa e la probabilità che un pacchetto sia scartato. Pchar funziona sia su protocollo IPV4 sia su IPV6.

L'analisi è effettuata basandosi sul modello di network della figura 1.

Figura 1.

Prima che un pacchetto lasci il nodo //n-1//, aspetta in coda l'instradamento verso il nodo successivo. Il tempo di transito nella rete è una funzione lineare della dimensione del pacchetto:

//latenza + dimensione / banda// Al nodo //n,// il pacchetto aspetta in coda nuovamente fino a quando il router lo processa e genera il pacchetto di errore. Il pacchetto di errore aspetta in coda nel nodo //n//, quindi ritorna al nodo //n-1// con il tempo di trasmissione lat+dim/bw, dove la dimensione del pacchetto di errore è la dimensione del pacchetto ICMP di errore. Infine, esso aspetta in coda al nodo //n-1.//

Il round trip time RTT dal nodo //n-1// al nodo //n// e ritorno è così calcolato:

//rtt = q1 + (lat + dim_packet / bw) + q2 + forward + q3 + (lat + dim_error / bw) + q4// dove i valori di qi sono variabili rappresentanti i tempi delle code e forward è il tempo di processo del pacchetto.

Per semplificare questa espressione sono possibili tre assunzioni:
 * 1) la dimensione del pacchetto di errore è talmente piccola che si può considerare trascurabile. Quindi //dim_error / bw = 0//
 * 2) il tempo di processo è trascurabile
 * 3) se si effettuano un lungo numero di misurazioni di uno stesso percorso, i primi pacchetti inviati faranno in modo che il il ritardo nelle code durante il round trip sia trascurabile.

Eliminando i termini trascurabili:

//rtt = (lat + dim_packet / bw) + lat//

Questa equazione è la base dell'analisi che pchar utilizza per stimare le caratteristiche del collegamento.

//__Analisi statistica__//

La figura seguente mostra un grafico di 2880 pacchetti di 45 differenti dimensioni, da 120 a 1528 byte.

Ogni punto rappresenta un singolo pacchetto, ogni colonna rappresenta un burst di pacchetti della stessa dimensione e l'intero grafico rappresenta l'insieme di pacchetti inviati ad un nodo. In ogni colonna ci sono molti punti vicino al minimo; ciò suggerisce che questi pacchetti hanno molte possibilità di attraversare il percorso senza ritardo. Questa osservazione implica che pchar può trovare il minimo rtt con un minimo numero di pacchetti per ogni variazione di grandezza del pacchetto. Il tempo minimo osservato per ogni colonna nella figura 4, forma una linea retta in accordo con il modello a due parametri del transito temporale (Equazione 2).

L'interpretazione dei di questi parametri cumulativi consente di stimare:
 * la latenza dal primo nodo al nodo ennesimo e ritorno
 * il costo superiore di spedizione di un addizionale byte lungo il percorso

La migliore cosa riguardo ai parametri cumulativi è che permettono di calcolare il prossimo burst di pacchetti tramite la sottrazione. Per esempio, per cercare la latenza del sesto collegamento, è sufficiente sottrarre le intercettazioni della linea 6 e della linea 5. Per cercare la banda, basta sottrarre le due pendenze.

//__Problemi__//

Un problema che affligge il pchar è l'esistenza di collegamenti attraverso la rete fatti di pipes parallele. Se in questo collegamento viene inviato un intero pacchetto in una delle due pipe, invece di spezzarlo, quel link e conseguentemente la banda risulterà uguale a quella della singola pipe. Un altro problema è causato dai pacchetti che superano l'MTU di un collegamento. Un pacchetto che supera l'MTU verrà frammentato in pacchetti più piccoli, e un pacchetto di errore verrà inviato non appena il primo pacchetto arriverà all'ennesimo nodo. La curva rtt risultante nel punto della dimensione MTU, sarà leggermente distorta e tendente ad avere una banda sopravvalutata. Settando il flag “don't fragment” nel pacchetto, ciò non aiuta poiché non appena la dimensione del pacchetto supera l'MTU nel primo nodo, si genera un errore ICMP (Unreachable Errore – Fragmentation required) che viene spedito al mittente.

Un problema che non viene affrontato da pchar e che è causa di problemi significativi, è l'alternanza del percorso. L'alternanza del percorso è la tendenza di modificare il percorso tra 2 host di cambiare nel tempo, tipicamente tra poche possibilità. Paxson ha dimostrato che l'alternanza del percorso attraverso Internet è molto comune. Fortunatamente la maggior parte (91%) dei percorsi in Internet rimane immutato per ore, abbastanza lungo per permettere pchar di fare le misurazioni. Sfortunatamente ci sono molti percorsi di routing che variano molto rapidamente e creano molti problemi. La corrente versione di pchar cerca di fissare il primo percorso trovato e rifiuta i successivi percorsi diversi dal primo. Se capita di analizzare il primo nodo che ha alta probabilità di cambiamento, vi è una probabilità elevata di perdere molti pacchetti. Inoltre se il primo nodo non è il più vicino, la stima per i nodi successivi può essere poco accurata. //__Conclusioni__//

Con l'utilizzo della versione attuale di pchar abbiamo trovato:
 * la stima delle latenze dei collegamenti è relativamente semplice; si basa sulla latenza delle aree interessate e non direttamente calcolabile tramite pchar
 * la stima della banda è più difficile, perchè la differenza dell'rtt tra il pacchetto più grande e quello più piccolo è piccola comparata con la misura degli errori. Maggiore è la banda, più difficile è la sua stima
 * la chiave per avere una buona stima della banda è di inviare abbastanza pacchetti che uno di essi attraversi l'intero percorso, senza incorrere in ritardi delle code. Se la lunghezza del percorso aumenta, il numero di pacchetti da inviare per avere una buona stima aumenta rapidamente

__In pratica__ Il comando principale di pchar viene invocato in questo modo:

./pchar //host// Vengono introdotti una serie di parametri avanzati per permettere test più approfonditi o utilizzando motodologie diverse.

./pchar [-a analysis] [-b burst] [-c] [-d debuglevel] [-g gap] [-G gaptype] [-h] [-H hops] [-I increment] [-m mtu] [-n] [-p protocol] [-P port] [-q] [-R reps] [-s hop] [-t timeout] [-T tos] [-v] [-V] [-w file] -r file | host]

-a analysis Set analysis type (default is lsq) lsq Least sum of squares linear fit kendall Linear fit using Kendall's test statistic lms Least median of squares linear fit lmsint Least median of squares linear fit (integer computations) -b Burst size (default = 1) -c Ignore route changes -d debuglvl Set debugging output level -g gap Inter-test gap in seconds (default = 0.25) -G gaptype Inter-test gap type (default is fixed) fixed Fixed gap exp Exponentially distributed random -H hops Maximum number of hops (default = 30) -h Print this help information -I increment Packet size increment (default = 32) -l host Set origin address of probes (defaults to hostname) -m mtu Maximum packet size to check (default = 1500) -M mode Operational mode (defaults to pchar) pchar Path characterization trout Tiny traceroute -n Don't resolve addresses to hostnames -p protocol Network protocol (default is ipv4udp) ipv4udp UDP over IPv4 ipv4raw UDP over IPv4 (raw sockets) ipv4icmp ICMP over IPv4 (raw sockets) ipv6icmp ICMPv6 over IPv6 (raw sockets) ipv6tcp TCP over IPv6 ipv6udp UDP over IPv6 -P port Starting port number (default = 32768) -q Quiet output -r file Read data from a file (- for stdin) -R reps Repetitions per hop (default = 32) -s hop Starting hop number (default = 1) -t timeout ICMP timeout in seconds (default = 3) -T tos Set IP type-of-service field (default = 0) -v Verbose output -V Print version information -w file Write data to a file (- for stdout)

//__Esempi pratici__//

./pchar 192.168.1.10 pchar to 192.168.1.10 (192.168.1.10) using UDP/IPv4 Using raw socket input Packet size increments from 32 to 1500 by 32 46 test(s) per repetition 32 repetition(s) per hop 0: 192.168.1.15 (Andrea.local) Partial loss: 0 / 1472 (0%) Partial char: rtt = 2.135705 ms, (b = 0.000721 ms/B), r2 = 0.993529 stddev rtt = 0.008092, stddev b = 0.000009 Partial queueing: avg = 0.000672 ms (931 bytes) Hop char: rtt = 2.135705 ms, bw = 11091.113733 Kbps Hop queueing: avg = 0.000672 ms (931 bytes) 1: 192.168.1.10 (192.168.1.10) Path length: 1 hops Path char: rtt = 2.135705 ms r2 = 0.993529 Path bottleneck: 11091.113733 Kbps Path pipe: 2960 bytes Path queueing: average = 0.000672 ms (931 bytes) Start time: Tue May 19 19:16:46 2009 End time: Tue May 19 19:22:58 2009 ./pchar ka9q.ampr.org 0 localhost 1 ir40gw.lbl.gov (131.243.1.1) 2 er1gw.lbl.gov (131.243.128.11) 3 lbl-lc1-1.es.net (198.128.16.11) 4 gac-atms.es.net (134.55.24.6) 5 CERFNETGWY.GAT.COM (192.73.7.163) 6 sdsc-ga.cerf.net (134.24.20.15) 7 mobydick-fddi.cerf.net (134.24.252.3) 8 qualcomm-sdsc-ds3.cerf.net (134.24.47.200) 9 krypton-e2.qualcomm.com (192.35.156.2) 10 ascend-max.qualcomm.com (129.46.54.31) 11 karnp50.qualcomm.com (129.46.90.33) 12 unix.ka9q.ampr.org (129.46.90.35)
 * 8.7 Mb/s, 292 us (1.97 ms)
 * 29 Mb/s, 132 us (2.64 ms)
 * 91 Mb/s, 189 us (3.15 ms)
 * 25 Mb/s, 6.92 ms (17.5 ms)
 * 11 Mb/s, 424 us (19.4 ms)
 * 7.0 Mb/s, 1.20 ms (23.5 ms)
 * ?? b/s, -263 us (22.8 ms)
 * 46 Mb/s, -51 us (22.9 ms)
 * 9.0 Mb/s, 17 us (24.3 ms)
 * 5.5 Mb/s, 1.04 ms (28.6 ms)
 * 56.7 Kb/s, 6.19 ms (253 ms)
 * 10 Mb/s, -50 us (253 ms), +q 3.32 ms (6.58 KB) *2

rtt 32 ms (253 ms), bottleneck 56.7 Kb/s, pipe 4706 bytes