Projet agregation » Historique » Version 32
Version 31 (Laurent GUERBY, 22/12/2011 22:19) → Version 32/225 (Jocelyn Dealande, 29/12/2011 18:43)
h1. Projet agregation
* [[Bibliographie du projet]]
* [[L'installation de gitolite]]
* http://pad.rhizome-fai.net/U7HSgxYvDM | Le code du tunnel tun réalisé avec python
* http://pad.rhizome-fai.net/TS2HBLkTnN | Spécification de l'iperf (de quel manière on détecte la capacité d'un lien de manière opportuniste ? Monitoring ?)
* http://lists.tetaneutral.net/listinfo/projet-agregation
* http://chiliproject.tetaneutral.net/issues/16
* discussion sur le sujet http://www.spinics.net/lists/lartc/msg21455.html
h2. Prototype v1
http://lists.tetaneutral.net/pipermail/projet-agregation/2011-November/000023.html
h2. Test de tunproxy.py
On utilise "tunproxy.py":http://www.secdev.org/projects/tuntap_udp/files/tunproxy.py. Entre 2 machines
* client-adsl (une machine chez nous)
* gateway (la VM)
h3. Sur la gateway (= VM ttn)
Démarrer le tunnel, il crée lui-même une interface _toto0_ (détruite à la sortie).
<pre>
./tunproxy.py -s 6000
ifconfig toto0 10.0.0.1/24 mtu 1468
</pre>
La MTU est calculée comme suit :
MTU de l'iface virtuelle = MTU de l'iface physique - taille_max(header IP) - taille(header UDP)
MTU de l'iface virtuelle = 1500 - 24 - 8
http://www.commentcamarche.net/faq/7185-introduction-au-mtu
h3. Sur le client
<pre>
./tunproxy.py -c rhizome-fai.tetaneutral.net:6000
ifconfig toto0 10.0.0.2/24 mtu 1468
</pre>
Tout le trafic vers les adresses en 10.0.0.x passera par le tunnel.
* http://lists.tetaneutral.net/listinfo/projet-agregation
* http://chiliproject.tetaneutral.net/issues/16
Un test de perf sur un téléchargement d'un fichier de 40Mio donne :
* avec tunnel : 909kb/s
* sans tunnel : 942kb/s
h1. Détection de la saturation d'un lien / bufferbloat
Un des points sur lesquels nous nous penchons est la détection de la capacité d'un lien et de son évolution, ceci 1) pour utiliser au mieux des liens de capacité différente et éventuellement changeante.
Tout le challenge est de détecter (passivement) plutôt que de mesurer (activement) la capacité du lien, sans induire de trafic supplémentaire.
Nous avons fait des mesures sur deux liens :
h2. Mesure ADSL Free (Freebox)
Il semble que de la QoS soit appliquée⦠l'effet de bufferbloat n'est pas vraiment visible : on passe d'un ping de 40 à 70/80ms⦠(TODO: prendre le temps de collecter des résultats des deux côtés du tunnel un peu plus sérieusement que juste l'impression donnée ceci-dit). Tous les paquets de ping arrivent, même lorsque le lien est saturé.
h2. Lien ADSL (OVH)
L'effet de la saturation se fait clairement ressentir sur le ping : on passe de 70 à plus de 300ms de ping lorsque le lien est saturé.
Données du test et graphiques : attachment:saturation_et_ping___uplink_seulement__udp_sctp.ods
h3. Conditions du test :
* Tunnel tap basé sur tunproxy.py (cf dépôt git), qui est le seul à utiliser la connexion
* Données collectées toutes les secondes, chaque peer enregistre :
** timestamp
** stats des paquets entrants
** ping
* On teste la connection au repos en la saturant par moments avec iperf
** en UDP : en metant l'option -b à une valeur supérieure à la capacité d'uplink
** en TCP
* Les données des 2 peers sont fusionnées à posteriori (script merge_tunproxy_csv.py) en fonction des timestamp.
* Les données sont graphées sur un tableur (ouais je sais, beurk ;-) ).
Le comptage du volume sortant n'est pas pertinent puisque la moitié des paquets peuvent-être dropés en routeâ¦
h3. Analyse des résultats
(voir document joint)
* On note systématiquement une corrélation forte entre lien saturé et augmentation du ping. Que le lien soit saturé en UDP ou TCP.
* En UDP, on peut saturer le lien complètement. Il en résulte qu'une part des pings se perd -> Prendre non seulement en compte le RTT mais également le taux de pings perdus.
* En TCP, on observe aussi une montée du ping significative, mais jamais de pings perdus. On constate d'ailleurs que TCP se rend compte qu'il sature le lien et divise sa fenêtre (trou dans le graphe).
* -> Quid de la réalité de la saturation d'un lien par rapport à ces deux exemples simples ?
h2. Demi-délai
Nous pouvons donc corréler une saturation du lien (qu'elle soit effectuée par un protocole qui gère la congestion ou non) avec une augmentation du ping. Reste un autre problème, nous voulons détecter dans quel sens a lieu la saturation. Or un ping nous donne le temps d'aller retour (RTT, Round-Trip-time). Il n'est en outre pas possible de mesure la durée absolue d'une trame entre deux sites, les horloges n'étant pas synchronisées. Deux approches sont envisagées
h3. Synchronisation par NTP
NTP est un protocole permetant de synchroniser via le réseau les horloges de machines distantes. Si NTP fournit une précision suffisante, il serait intéressant pour pouvoir effectuer des demi-ping :Â
* On maintient les horloges synchronisées grace à NTP entre machine 1 et machine 2
* Machine1 envoie un paquet à machine2 contenant un timestamp
* Machine 2 peut connaître le temps de trajet machine1->machine2 en comparant ce timestamp avec sa propre horloge.
On mesure des ping entre 20 et 100ms en général, soit des demi-ping entre 10 et 50ms. Or, les études sur NTP (ex: http://www.eecis.udel.edu/~mills/database/brief/perf/perf.pdf) montrent qu'à travers un réseau WAN (ex: l'ADSL que nous utilisons), l'erreur de NTP est autour de *10ms*. Soit une erreur relative entre 10% et 50%, ce qui n'est pas acceptable. La seule solution viable, selon l'étude mentionnée, pour synchroniser réellement des équipements serait d'avoir une source GPS qui permet d'avoir une erreur en-dessous de la milliseconde. Cela nécessite de l'équipement supplémentaire et n'est souhaitable.
Voir aussi http://www.frameip.com/ntp/
h3. Par évolution du délai relatif
Une autre approche discutée est de mesurer non pas le délai absolu mais la variation de celui-ci.
On mesure timestamp_envoi_site1 - timestamp_reception_site2 pour chaque paquet, la valeur absolue n'a aucun sens (on utilise deux horloges différentes).
Un autre problème est alors la dérive relative des horloges des deux machines qu'il ne faut pas négliger (exemple donné dans l'article sur UTP de 17ms de dérive en 10 minutes)
Cette idée est d'ailleurs reprise dans le protocole UTP de bittorrent : http://www.rasterbar.com/products/libtorrent/utp.html
h1. Petits points techniquesâ¦
h2. Que mesure iperf et comment (en UDP) ?
Iperf mesure le débit du client vers le serveur (dans un seul sens). En UDP, il envoie à une vitesse nominale (par défait 1M). Le résultat donné par le client n'est pas une mesure mais correspond à cette vitesse nominale. *Seul le _server repport_ correspond à la "vraie" mesure.*
La saturation d'un lien générant des pertes, pour mesurer les pertes liées à la qualité du lien (et non à sa capacité), il faut demander au client d'émettre un peu en-dessous de la vitesse à laquelle peut recevoir le serveur.
h2. Quelques outils réseaux bien pratique
* tcpdump | http://openmaniak.com/fr/tcpdump.php
<pre bash>
tcpdump -D #Interfaces réseaux disponibles pour la capture
tcpdump port 80 -i eth0 -w capture.log #Enregistre le trafic Web vers le fichier capture.log pouvant être ouvert avec Wireshark
tcpdump icmp #Affiche tout le trafic associé au protocole icmp
</pre>
* ping | http://www.bortzmeyer.org/ping-taille-compte.html
** Permet de tester un problème de MTU grâce à l'option -s de ping permettant de fixer une taille de paquet
* hping3
<pre bash>
hping --syn -p 80 --data 1200 10.0.0.1 #Envoie de paquet tcp syn sur le port 80 de taille 1200
</pre>
*tracepath* pour découvrir le PMTU
h1. TODO étapes suivantes
* Chercher relation entre variations de latence et saturation de lien. Concrètement, être capable de détecter *l'évènement "mon lien est saturé"* et de mémoriser la capacité max. du lien
* Finir de lire/comprendre le code de Fernando (linkagreg)
* Lire/comprendre le bout de script python de Laurent (multi-UDP pour contourner les QoS)
h1. Journal (Ã partir du 28 oct)
Activités du projet de Yanick & Jocelyn (TX)
h2. 5 déc.
* Détection de saturation :
* Output CSV en direct vers le fichier plutôt que statiquement au bout de 3 minutesâ¦
* Ãcriture d'un outil de script de logs CSV
* Collecte de mesures sur l'effet sur le ping de la saturation d'un lien en UDP et TCP
* Analyse basique des résultats
h2. 27 nov.
* Lecture et utilisation de linkagreg (outil d'agrégation de Fernando)
* Faire fonctionner linkagreg sur une architecture 64bits
* Faire fonctionner linkagreg avec une connection sur le client //Fonctionnel
* Faire fonctionner linkagre avec n connection sur le client //Non fonctionnel
** Test avec une connection filaire et WiFi //Non fonctionnel car perte (important) de paquet sur le lien WiFi
** Test avec des connections virtuelles //Non fonctionnel car QoS inapplicable sur des interfaces virtuelles
** Test avec deux interfaces physiques //Non fonctionnel car QoS déficiente
* Ajout de la collecte de données sur les temps de réponse (ping) périodiquement.
* Export des données en CSV (pour exploitation/graphe⦠etc.)
* Premier jeu de mesure (mauvais) sur une ligne adsl.
*
h2. 11 nov.
* Debuggage du problème de MTU (c'est honteux mais c'est bêtement la taille des buffers qui n'était pas assez grande dans le programme. Notamment dû aux pseudo en-têtes, cf plus bas).
* Configuration auto des adresses IP de chaque côté du tunnel (plus besoin d'ifconfig à la main)
* Ajout sur tunproxy.py de compteurs de débit
* mémorise le traffic sur les x dernières tranches de n secondes (défaut 10 tranches de 1 seconde)
* Affiche les moyennes et les max.
* Compréhension de ce qui passe dans TUN : bien qu'étant un tunnel de niveau 3, il y a une pseudo-en-tête de L2, cf "doc officielle":http://www.mjmwired.net/kernel/Documentation/networking/tuntap.txt#102 (merci Laurent!)
* discussion avec Laurent sur les intérêts de faire un tunnel L2 (qui rajoute pourtant l'overhead de l'en-tête L2), en bref :
* évite de gérer les soucis spécifiques du niveau IP
* TUN ne supporte pas IPV6 par exemple â¦
h2. 5 nov.
* Mise en place d'un dépôt git (gitolite) pour partager du code avec Fernando Alves de Sames Wireless :
# Dépot public : (lecture-seule)
git clone git://rhizome-fai.tetaneutral.net/agregation.git
h2. 28 oct.
* Initiation python (découverte pour Yanick)
* Commentaire intégral du tunproxy.py et premiers tests de ce dernier
** ping ok (+1ms)
** iperf à travers le tunnel : BP ~= celle de l'uplink ADSL. Le dernier datagrame ne reçoit pas d'ACK
<pre>
[ 3] local 10.0.0.2 port 50191 connected with 10.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec
[ 3] Sent 893 datagrams
[ 3] WARNING: did not receive ack of last datagram after 10 tries.
</pre>
h2. 2 novembre
* Modification de la MTU pour éviter la fragmentation de paquet
h1. Fonctionnalité
* Ajouter plusieurs sockets sur le tunnel pour éviter le traffic shaping de la part d'un opérateur
* [[Bibliographie du projet]]
* [[L'installation de gitolite]]
* http://pad.rhizome-fai.net/U7HSgxYvDM | Le code du tunnel tun réalisé avec python
* http://pad.rhizome-fai.net/TS2HBLkTnN | Spécification de l'iperf (de quel manière on détecte la capacité d'un lien de manière opportuniste ? Monitoring ?)
* http://lists.tetaneutral.net/listinfo/projet-agregation
* http://chiliproject.tetaneutral.net/issues/16
* discussion sur le sujet http://www.spinics.net/lists/lartc/msg21455.html
h2. Prototype v1
http://lists.tetaneutral.net/pipermail/projet-agregation/2011-November/000023.html
h2. Test de tunproxy.py
On utilise "tunproxy.py":http://www.secdev.org/projects/tuntap_udp/files/tunproxy.py. Entre 2 machines
* client-adsl (une machine chez nous)
* gateway (la VM)
h3. Sur la gateway (= VM ttn)
Démarrer le tunnel, il crée lui-même une interface _toto0_ (détruite à la sortie).
<pre>
./tunproxy.py -s 6000
ifconfig toto0 10.0.0.1/24 mtu 1468
</pre>
La MTU est calculée comme suit :
MTU de l'iface virtuelle = MTU de l'iface physique - taille_max(header IP) - taille(header UDP)
MTU de l'iface virtuelle = 1500 - 24 - 8
http://www.commentcamarche.net/faq/7185-introduction-au-mtu
h3. Sur le client
<pre>
./tunproxy.py -c rhizome-fai.tetaneutral.net:6000
ifconfig toto0 10.0.0.2/24 mtu 1468
</pre>
Tout le trafic vers les adresses en 10.0.0.x passera par le tunnel.
* http://lists.tetaneutral.net/listinfo/projet-agregation
* http://chiliproject.tetaneutral.net/issues/16
Un test de perf sur un téléchargement d'un fichier de 40Mio donne :
* avec tunnel : 909kb/s
* sans tunnel : 942kb/s
h1. Détection de la saturation d'un lien / bufferbloat
Un des points sur lesquels nous nous penchons est la détection de la capacité d'un lien et de son évolution, ceci 1) pour utiliser au mieux des liens de capacité différente et éventuellement changeante.
Tout le challenge est de détecter (passivement) plutôt que de mesurer (activement) la capacité du lien, sans induire de trafic supplémentaire.
Nous avons fait des mesures sur deux liens :
h2. Mesure ADSL Free (Freebox)
Il semble que de la QoS soit appliquée⦠l'effet de bufferbloat n'est pas vraiment visible : on passe d'un ping de 40 à 70/80ms⦠(TODO: prendre le temps de collecter des résultats des deux côtés du tunnel un peu plus sérieusement que juste l'impression donnée ceci-dit). Tous les paquets de ping arrivent, même lorsque le lien est saturé.
h2. Lien ADSL (OVH)
L'effet de la saturation se fait clairement ressentir sur le ping : on passe de 70 à plus de 300ms de ping lorsque le lien est saturé.
Données du test et graphiques : attachment:saturation_et_ping___uplink_seulement__udp_sctp.ods
h3. Conditions du test :
* Tunnel tap basé sur tunproxy.py (cf dépôt git), qui est le seul à utiliser la connexion
* Données collectées toutes les secondes, chaque peer enregistre :
** timestamp
** stats des paquets entrants
** ping
* On teste la connection au repos en la saturant par moments avec iperf
** en UDP : en metant l'option -b à une valeur supérieure à la capacité d'uplink
** en TCP
* Les données des 2 peers sont fusionnées à posteriori (script merge_tunproxy_csv.py) en fonction des timestamp.
* Les données sont graphées sur un tableur (ouais je sais, beurk ;-) ).
Le comptage du volume sortant n'est pas pertinent puisque la moitié des paquets peuvent-être dropés en routeâ¦
h3. Analyse des résultats
(voir document joint)
* On note systématiquement une corrélation forte entre lien saturé et augmentation du ping. Que le lien soit saturé en UDP ou TCP.
* En UDP, on peut saturer le lien complètement. Il en résulte qu'une part des pings se perd -> Prendre non seulement en compte le RTT mais également le taux de pings perdus.
* En TCP, on observe aussi une montée du ping significative, mais jamais de pings perdus. On constate d'ailleurs que TCP se rend compte qu'il sature le lien et divise sa fenêtre (trou dans le graphe).
* -> Quid de la réalité de la saturation d'un lien par rapport à ces deux exemples simples ?
h2. Demi-délai
Nous pouvons donc corréler une saturation du lien (qu'elle soit effectuée par un protocole qui gère la congestion ou non) avec une augmentation du ping. Reste un autre problème, nous voulons détecter dans quel sens a lieu la saturation. Or un ping nous donne le temps d'aller retour (RTT, Round-Trip-time). Il n'est en outre pas possible de mesure la durée absolue d'une trame entre deux sites, les horloges n'étant pas synchronisées. Deux approches sont envisagées
h3. Synchronisation par NTP
NTP est un protocole permetant de synchroniser via le réseau les horloges de machines distantes. Si NTP fournit une précision suffisante, il serait intéressant pour pouvoir effectuer des demi-ping :Â
* On maintient les horloges synchronisées grace à NTP entre machine 1 et machine 2
* Machine1 envoie un paquet à machine2 contenant un timestamp
* Machine 2 peut connaître le temps de trajet machine1->machine2 en comparant ce timestamp avec sa propre horloge.
On mesure des ping entre 20 et 100ms en général, soit des demi-ping entre 10 et 50ms. Or, les études sur NTP (ex: http://www.eecis.udel.edu/~mills/database/brief/perf/perf.pdf) montrent qu'à travers un réseau WAN (ex: l'ADSL que nous utilisons), l'erreur de NTP est autour de *10ms*. Soit une erreur relative entre 10% et 50%, ce qui n'est pas acceptable. La seule solution viable, selon l'étude mentionnée, pour synchroniser réellement des équipements serait d'avoir une source GPS qui permet d'avoir une erreur en-dessous de la milliseconde. Cela nécessite de l'équipement supplémentaire et n'est souhaitable.
Voir aussi http://www.frameip.com/ntp/
h3. Par évolution du délai relatif
Une autre approche discutée est de mesurer non pas le délai absolu mais la variation de celui-ci.
On mesure timestamp_envoi_site1 - timestamp_reception_site2 pour chaque paquet, la valeur absolue n'a aucun sens (on utilise deux horloges différentes).
Un autre problème est alors la dérive relative des horloges des deux machines qu'il ne faut pas négliger (exemple donné dans l'article sur UTP de 17ms de dérive en 10 minutes)
Cette idée est d'ailleurs reprise dans le protocole UTP de bittorrent : http://www.rasterbar.com/products/libtorrent/utp.html
h1. Petits points techniquesâ¦
h2. Que mesure iperf et comment (en UDP) ?
Iperf mesure le débit du client vers le serveur (dans un seul sens). En UDP, il envoie à une vitesse nominale (par défait 1M). Le résultat donné par le client n'est pas une mesure mais correspond à cette vitesse nominale. *Seul le _server repport_ correspond à la "vraie" mesure.*
La saturation d'un lien générant des pertes, pour mesurer les pertes liées à la qualité du lien (et non à sa capacité), il faut demander au client d'émettre un peu en-dessous de la vitesse à laquelle peut recevoir le serveur.
h2. Quelques outils réseaux bien pratique
* tcpdump | http://openmaniak.com/fr/tcpdump.php
<pre bash>
tcpdump -D #Interfaces réseaux disponibles pour la capture
tcpdump port 80 -i eth0 -w capture.log #Enregistre le trafic Web vers le fichier capture.log pouvant être ouvert avec Wireshark
tcpdump icmp #Affiche tout le trafic associé au protocole icmp
</pre>
* ping | http://www.bortzmeyer.org/ping-taille-compte.html
** Permet de tester un problème de MTU grâce à l'option -s de ping permettant de fixer une taille de paquet
* hping3
<pre bash>
hping --syn -p 80 --data 1200 10.0.0.1 #Envoie de paquet tcp syn sur le port 80 de taille 1200
</pre>
*tracepath* pour découvrir le PMTU
h1. TODO étapes suivantes
* Chercher relation entre variations de latence et saturation de lien. Concrètement, être capable de détecter *l'évènement "mon lien est saturé"* et de mémoriser la capacité max. du lien
* Finir de lire/comprendre le code de Fernando (linkagreg)
* Lire/comprendre le bout de script python de Laurent (multi-UDP pour contourner les QoS)
h1. Journal (Ã partir du 28 oct)
Activités du projet de Yanick & Jocelyn (TX)
h2. 5 déc.
* Détection de saturation :
* Output CSV en direct vers le fichier plutôt que statiquement au bout de 3 minutesâ¦
* Ãcriture d'un outil de script de logs CSV
* Collecte de mesures sur l'effet sur le ping de la saturation d'un lien en UDP et TCP
* Analyse basique des résultats
h2. 27 nov.
* Lecture et utilisation de linkagreg (outil d'agrégation de Fernando)
* Faire fonctionner linkagreg sur une architecture 64bits
* Faire fonctionner linkagreg avec une connection sur le client //Fonctionnel
* Faire fonctionner linkagre avec n connection sur le client //Non fonctionnel
** Test avec une connection filaire et WiFi //Non fonctionnel car perte (important) de paquet sur le lien WiFi
** Test avec des connections virtuelles //Non fonctionnel car QoS inapplicable sur des interfaces virtuelles
** Test avec deux interfaces physiques //Non fonctionnel car QoS déficiente
* Ajout de la collecte de données sur les temps de réponse (ping) périodiquement.
* Export des données en CSV (pour exploitation/graphe⦠etc.)
* Premier jeu de mesure (mauvais) sur une ligne adsl.
*
h2. 11 nov.
* Debuggage du problème de MTU (c'est honteux mais c'est bêtement la taille des buffers qui n'était pas assez grande dans le programme. Notamment dû aux pseudo en-têtes, cf plus bas).
* Configuration auto des adresses IP de chaque côté du tunnel (plus besoin d'ifconfig à la main)
* Ajout sur tunproxy.py de compteurs de débit
* mémorise le traffic sur les x dernières tranches de n secondes (défaut 10 tranches de 1 seconde)
* Affiche les moyennes et les max.
* Compréhension de ce qui passe dans TUN : bien qu'étant un tunnel de niveau 3, il y a une pseudo-en-tête de L2, cf "doc officielle":http://www.mjmwired.net/kernel/Documentation/networking/tuntap.txt#102 (merci Laurent!)
* discussion avec Laurent sur les intérêts de faire un tunnel L2 (qui rajoute pourtant l'overhead de l'en-tête L2), en bref :
* évite de gérer les soucis spécifiques du niveau IP
* TUN ne supporte pas IPV6 par exemple â¦
h2. 5 nov.
* Mise en place d'un dépôt git (gitolite) pour partager du code avec Fernando Alves de Sames Wireless :
# Dépot public : (lecture-seule)
git clone git://rhizome-fai.tetaneutral.net/agregation.git
h2. 28 oct.
* Initiation python (découverte pour Yanick)
* Commentaire intégral du tunproxy.py et premiers tests de ce dernier
** ping ok (+1ms)
** iperf à travers le tunnel : BP ~= celle de l'uplink ADSL. Le dernier datagrame ne reçoit pas d'ACK
<pre>
[ 3] local 10.0.0.2 port 50191 connected with 10.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec
[ 3] Sent 893 datagrams
[ 3] WARNING: did not receive ack of last datagram after 10 tries.
</pre>
h2. 2 novembre
* Modification de la MTU pour éviter la fragmentation de paquet
h1. Fonctionnalité
* Ajouter plusieurs sockets sur le tunnel pour éviter le traffic shaping de la part d'un opérateur