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

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 ?

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