Introduzione
All'interno delle reti, e in particolare in Internet, sorge il duplice problema di rilevare e identificare la presenza di eventuali bottleneck (colli di bottiglia).Un bottleneck si presenta quando -in un percorso- si attraversa un nodo che ha a disposizione una banda molto minore rispetto ai nodi attraversati in precedenza. Rilevare la presenza di bottleneck è utile per ottimizzare le connessioni di rete, ad esempio se si vuole fornire un servizio si può considerare di implementare soluzioni quali multihoming e overlay routing (discussi in seguito).
Il tool da noi analizzato adotta un approccio particolare chiamato RPT (Recursive Packet Train) che permette di effettuare i test senza la necessità di avere un controllo diretto sull'host di destinazione e con buone probabilità di successo (quasi l'80%).
Funzionamento interno del tool
La tecnica utilizzata dal tool si basa sulla trasmissione di un treno di pacchetti UDP detto RPT (Recursive Packet Train) e sfrutta le risposte ICMP (Time Exceeded Message) dei router per stimare la banda.E' quindi essenziale che i nodi da analizzare inviino i pacchetti ICMP allo scadere dei TTL, pena l'impossibilità di stimare la banda di quel nodo.
Struttura del RPT
Il "treno" è formato da due tipi di pacchetto:- Pacchetti di misura: pacchetti UDP traceroute standard, la loro dimensione di default è di 60B e TTL variabile.
- Pacchetti di carico: pacchetti UDP di grandezza di default di 500B e TTL a 255.
A seguire si trova una sezione centrale composta dai pacchetti di carico che servono a simulare il normale traffico di rete (per questo hanno una grandezza maggiore rispetto a quelli di misura).
Alla fine si trova nuovamente una sezione di pacchetti di misura, dello stesso numero della sezione di testa, questa volta però inseriti in ordine inverso (con TTL decrescente).
Rilevamento di bottleneck
La sorgente invia l'RPT e attende che ogni router nel percorso risponda con due ICMP, relativi ai due pacchetti del treno (il primo e l'ultimo) il cui TTL è scaduto.In questo modo ad ogni hop si può misurare il tempo trascorso tra la ricezione del primo e del secondo ICMP e di conseguenza stimare la banda disponibile per quel nodo.
Naturalmente con la perdita per ogni hop di due pacchetti di misura la dimensione totale del treno diminuisce, ma essendo il peso dei pacchetti di misura relativamente piccolo (default di 60B) la differenza è trascurabile ai fini dell'individuazione di bottleneck.
In altre parole, il gap tra i tempi di arrivo dei 2 pacchetti ICMP permette di stimare il tempo impiegato dal RPT per attraversare un certo nodo; da questo si può avere una approssimazione della banda disponibile nello stesso.
Quando il tool ha calcolato le stime per tutti i nodi del percorso, procede a scegliere dei possibili candidati bottleneck (i choke points).
Un choke point viene rilevato quando il tempo di transito aumenta sensibilmente in un certo nodo, se invece rimane circa invariato, la banda di quel nodo risulta sufficiente a continuare il trasporto dell'RPT. Da notare che se il tempo stimato diminuisce sensibilmente significa che vi sono stati degli errori di misurazione, il tool è tollerante riguardo a questi ed introduce delle approssimazioni ma soltanto fin quando possibile (se ad esempio un pacchetto ICMP di ritorno va perso la misurazione per quel nodo sarà invalida).
All'avvicinarsi della destinazione (e quindi attraversando diversi choke points) la banda a disposizione diminuisce: l'ultimo choke link è quindi la bottleneck.
E' importante notare che Pathneck utilizza un algoritmo che effettua un ranking dei choke point rilevati, segnalando quindi quali siano i più problematici.
Come discusso successivamente è però necessaria una analisi manuale dei risultati (e anche una ripetizione dei test con analisi sulle medie) per poter capire se il problema è costante e su quali nodi intervenire.
Utilizzo del tool
Il tool si può compilare su diversi sistemi operativi, gli autori lo descrivono come testato su sistemi unix like (Linux, Sun, Mac, Bsd). Nel nostro caso lo abbiamo utilizzato su Linux.Il suo utilizzo è molto semplice: preso in ingresso l'indirizzo di destinazione il tool visualizza l'elenco dei nodi (con un output simile a quello di traceroute) con relativi dettagli, stime e choke point individuati.
Con i relativi parametri è inoltre possibile regolare dimensione e quantità dei pacchetti di misura e di carico e regolare l'output (dettagli, risoluzione nomi DNS, ecc.).
Gli autori fanno notare che le prestazioni del tool sono influenzate dalla banda e dalla CPU del nodo da cui vengono fatte le misurazioni, le impostazioni di default sono indicative per un nodo con banda di circa 100Mbps e una CPU > 400Mhz.
Se si effettuano i test avendo a disposizione una banda minore è necessario specificare un numero minore di pacchetti di carico con l'opzione -l ad esempio per una 10Mbps è consigliabile -l 20.
Ecco l'output del programma e il suo significato:
pathneck -xo google.com 1209828260.907427 64.233.167.99 500 60 0 00 1.480 64.142.19.33 3745 3745 . 64.084 ub 64.142.19.33 01 0.635 209.204.191.36 3743 3745 . 64.104 lb 2.ge-1-1-0.gw.sr.sonic.net 02 0.627 209.204.191.37 3761 3761 . 63.812 lb 2.ge-1-1-0.gw2.sr.sonic.net 03 4.379 64.142.0.206 3866 3866 1 62.077 ub 0.ge-1-0-0.gw2.equinix-sj.sonic.net conf = 0.027 rtt = 67.440 ( 64.233.167.99 )La prima riga mostra la configurazione del test: il timestamp, l'ip di destinazione, dimensione dei pacchetti di carico, numero dei pacchetti di carico, ritardo.
Successivamente vengono mostrate le informazioni sui nodi, le colonne stanno ad indicare:
1° colonna: numero di nodo
2° colonna: RTT del nodo
3° colonna: IP del nodo
4° colonna: misura grezza del gap (in microsecondi)
5° colonna: stima del gap (microsecondi)
6° colonna: choke point "1", "2", "3" se è un choke point (in ordine di probabilità) "." altrimenti
7° colonna: stima della banda (in Mbps)
8° colonna: ub->upper bound (la banda stimata è al massimo quella indicata), lb->lower bound (la banda stimata è almeno quella indicata), uk->unknown (sconosciuto) nel caso il nodo non abbia inviato il paccheto ICMP o che il nodo abbia un RTT più basso del precedente (la misurazione viene ritenuta scorretta)
9° colonna: nome del nodo
"conf": affidabilità dei choke point rilevati (in ordine da 1 a 3)
"rtt": RTT di destinazione, IP di destinazione
Evitare le bottleneck
Il tool, come discusso nei capitoli precedenti, aiuta ad identificare la posizione di un bottleneck in un percorso di rete. Questo può essere utile per poi implementare tecniche quali:- Multihoming: consiste nel mettere a disposizione di un host diverse connessioni indipendenti, questo assicura una migliore resistenza ai guasti e ripartisce il traffico in modo da evitare le bottleneck. Nella categoria del "multihoming" vi sono una quantità di tecniche diverse, nel nostro caso ci riferiamo principalmente all'uso di un protocollo di routing (BGP) per fornire ad un certo AS più link. Scegliendo accuratamente i provider con i quali connettersi (evitando ad esempio che utilizzino un path simile) si possono raggiungere buoni risultati. Bisogna notare che questo tipo di tecnica viene usata solitamente per esigenze di medio livello e non è direttamente accessibile a piccoli clienti degli ISP. Esistono comunque soluzioni più semplici (ma meno efficaci) basate ad esempio su multipli record DNS, anche in questo caso si tende a distribuire equamente il traffico per diminuire l'effetto di bottleneck.
- Overlay Routing: prevede l'utilizzo di nodi particolari che prendano decisioni di instradamento basandosi su parametri aggiuntivi rispetto al "semplice" BGP (che non ottimizza automaticamente per banda disponibile, errori e ritardi). Anche in questo caso la tecnica è solitamente riservata ad applicazioni "enterprise'' e frequentemente gestita dagli ISP stessi.
Test effettuati
Tutti i test sono stati effettuati con le opzioni -x e -o verso differenti host.E' importante però saper interpretare i dati e non fermarsi solamente all'output dato dal tool. Infatti, come precisato dagli autori, può accadere che le conclusioni segnalate (ossia la presenza di choke point) non è sempre affidabile. Inoltre la stima della banda viene spesso indicata come uk a causa di errori nella ricezione dei pacchetti ICMP di risposta.
Ecco alcune prove di esempio verso google.com:
pathneck -xo google.com 00 1.893 64.142.19.33 4048 4048 . 59.287 ub 64.142.19.33 01 0.679 209.204.191.36 4405 4400 1 54.483 ub 2.ge-1-1-0.gw.sr.sonic.net 02 0.662 64.142.117.37 4400 4400 . 54.545 lb 3.ge-2-1-0.gw2.sr.sonic.net 03 4.527 64.142.0.206 4472 4472 . 53.667 lb 0.ge-1-0-0.gw2.equinix-sj.sonic.net conf = 0.080 rtt = 79.084 ( 72.14.207.99 ) 00 1.640 64.142.19.33 3375 3375 . 71.110 ub 64.142.19.33 01 0.918 209.204.191.36 3257 3257 2 0.000 uk 2.ge-1-1-0.gw.sr.sonic.net 02 0.906 209.204.191.37 3241 3257 . 74.050 lb 2.ge-1-1-0.gw2.sr.sonic.net 03 4.477 64.142.0.206 3645 3645 1 65.840 ub 0.ge-1-0-0.gw2.equinix-sj.sonic.net conf = 0.106 0.036 rtt = 67.642 ( 64.233.167.99 ) 00 1.869 64.142.19.33 3362 3362 . 71.367 ub 64.142.19.33 01 1.265 209.204.191.36 2863 2880 1 0.000 uk 2.ge-1-1-0.gw.sr.sonic.net 02 1.260 64.142.117.37 2880 2880 . 83.331 lb 3.ge-2-1-0.gw2.sr.sonic.net 03 4.841 64.142.0.206 3250 3250 2 73.843 ub 0.ge-1-0-0.gw2.equinix-sj.sonic.net conf = 0.167 0.114 rtt = 77.393 ( 72.14.207.99 ) 00 1.785 64.142.19.33 3666 3666 . 65.464 ub 64.142.19.33 01 1.244 209.204.191.36 3343 3343 2 0.000 uk 2.ge-1-1-0.gw.sr.sonic.net 02 1.238 209.204.191.37 3318 3343 . 72.331 lb 2.ge-1-1-0.gw2.sr.sonic.net 03 4.574 64.142.0.206 3744 3744 1 64.100 ub 0.ge-1-0-0.gw2.equinix-sj.sonic.net conf = 0.107 0.097 rtt = 64.554 ( 64.233.167.99 ) 00 1.598 64.142.19.33 5573 5573 . 43.065 ub 64.142.19.33 01 1.516 209.204.191.36 4737 4737 1 0.000 uk 2.ge-1-1-0.gw.sr.sonic.net 02 1.480 209.204.191.37 4731 4731 . 50.727 lb 2.ge-1-1-0.gw2.sr.sonic.net 03 5.798 64.142.0.206 4065 4065 2 0.000 uk 0.ge-1-0-0.gw2.equinix-sj.sonic.net conf = 0.176 0.164 rtt = 63.887 ( 64.233.187.99 ) 00 1.429 64.142.19.33 3735 3735 . 64.244 ub 64.142.19.33 01 0.625 209.204.191.36 3716 3735 . 64.569 lb 2.ge-1-1-0.gw.sr.sonic.net 02 0.621 209.204.191.37 3737 3737 . 64.207 lb 2.ge-1-1-0.gw2.sr.sonic.net 03 4.353 64.142.0.206 3849 3849 1 62.338 ub 0.ge-1-0-0.gw2.equinix-sj.sonic.net conf = 0.029 rtt = 67.243 ( 64.233.187.99 ) 00 10.087 64.142.19.33 988 988 . 242.913 ub 64.142.19.33 01 0.674 209.204.191.36 3644 988 . 65.845 lb 2.ge-1-1-0.gw.sr.sonic.net 02 11.433 64.142.117.37 124 988 . 1921.055 lb 3.ge-2-1-0.gw2.sr.sonic.net 03 4.550 64.142.0.206 3654 3654 1 65.681 ub 0.ge-1-0-0.gw2.equinix-sj.sonic.net conf = 0.730 rtt = 78.682 ( 72.14.207.99 ) 00 1.699 64.142.19.33 5350 5350 . 44.859 ub 64.142.19.33 01 1.285 209.204.191.36 4869 4869 2 0.000 uk 2.ge-1-1-0.gw.sr.sonic.net 02 1.254 209.204.191.37 4863 4869 . 49.352 lb 2.ge-1-1-0.gw2.sr.sonic.net 03 4.315 64.142.0.206 5425 5425 1 44.232 ub 0.ge-1-0-0.gw2.equinix-sj.sonic.net conf = 0.102 0.099 rtt = 67.378 ( 64.233.167.99 ) 00 1.478 64.142.19.33 3739 3739 1 64.186 ub 64.142.19.33 01 0.518 209.204.191.36 3940 3740 . 60.912 lb 2.ge-1-1-0.gw.sr.sonic.net 02 0.608 209.204.191.37 3740 3740 . 64.170 lb 2.ge-1-1-0.gw2.sr.sonic.net 03 4.363 64.142.0.206 3839 3839 . 62.500 lb 0.ge-1-0-0.gw2.equinix-sj.sonic.net conf = 1.000 rtt = 67.491 ( 64.233.167.99 ) 00 1.480 64.142.19.33 3745 3745 . 64.084 ub 64.142.19.33 01 0.635 209.204.191.36 3743 3745 . 64.104 lb 2.ge-1-1-0.gw.sr.sonic.net 02 0.627 209.204.191.37 3761 3761 . 63.812 lb 2.ge-1-1-0.gw2.sr.sonic.net 03 4.379 64.142.0.206 3866 3866 1 62.077 ub 0.ge-1-0-0.gw2.equinix-sj.sonic.net conf = 0.027 rtt = 67.440 ( 64.233.167.99 )Come si può notare da questo test, i singoli risultati non sono molto affidabili ma lanciando il tool diverse volte è possibile farsi una buona idea sull'andamento della rete e riconoscere eventuali colli di bottiglia.
In questo caso possiamo dire con una certa tranquillità che non sono presenti bottleneck rilevanti, in quanto una volta scartati i risultati evidentemente errati, si può notare che la differenza di banda tra quella di partenza e quella di arrivo è piuttosto irrilevante.
Conclusioni
L'analisi del tool da noi effettuata ci porta a dire che pathneck è un buon tool per la rilevazione dei bottleneck ma è necessario saper interpretare i dati effettuando molteplici test e non affidarsi esclusivamente a singoli test e alle stime presentate.Uno degli aspetti più negativi del tool sta nella base del suo funzionamento, cioè l'utilizzo dei pacchetti ICMP inviati dai router che possono venir filtrati dagli ISP rendendo così inutilizzabile il tool: è infatti risultato inutilizzabile sulle nostre linee di casa.