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

Un outil faisant ce type de mesure a été implémenté dans le dépôt : _delta_half_trip_time.py_ 

Côté serveur :

    ./delta_half_trip_time.py -s 2244

Côté client:

    ./delta_half_trip_time.py -s <ip_serv>:2244

Le script mesure en permanence les délais toutes les secondes. Il ne prend pas en compte la dérive d'horloge pour l'heure. La sortie est du CSV contenant les délais dans les deux sens (de chaque côté). Le format est :

    pkt_type,sequence number,delay

_pkt_type_ vaut *'t'* (comme _timer_) pour les mesures entrantes (download) et *'d'* (comme _delay_) pour les réponses aux paquets sortants (upload).

h4. mesures

Pour l'instant, seules des mesures avec iperf en TCP : attachment:one-way_delay.ods

Note sur ces mesures (iperf TCP) : correspond peut-être au cas le plus difficile à détecter (une unique connection TCP qui sature le lien) étant donné que le backoff de TCP va essayer d'éviter de saturer le lien en permanence.

h4. dérive

Le fichier attachment:one-way_delay.ods présente également une mesure de la dérive sur 40 minutes entre 2 machines. L'enjeu est de savoir si il est nécessaire de mettre en place un mécanisme pour détecter et prendre en compte la dérive des horloges qui rendraient la comparaison de deux délais relatifs peu pertinents si elle était trop importante.

Bien que l'expérience ne porte que sur un cas et ne fasse pas loi, elle nous expose une dérive de 0.5ms sur 40 minutes d'observation (dérive relative de ~1.4%). Ne souhaitant garder pour nos mesures de capacité de lien qu'une fenêtre glissante que de quelques minutes ou dizaines de minutes tout au plus, il n'apparaît pas nécessaire de prendre en compte cette dérive.

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. multy.py

peer_: Liste des sockets du clients basés sur ses interfaces physiques

peer_d: sous forme de dictionnaire

peer_l: sous forme de liste

La structure:

Liste < . . . > Dictionnaire

0->A  < . . . > <A,None>

1->B  < . . . > <B,None>

2->C  < . . . > <C,None>

!!

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. 8 janvier.

* Compréhension du script multy.py de Laurent Guerby

* Documentation du script multy.py

** Schéma graphique du fonctionnement de multy.py

* Adaptation de l'algorithme de round robin avec des métriques

** Ajout d'un coefficient pour "plus" utiliser une connexion qu'une autre

h2. 28/29 déc.

* Détection de saturation : nouvel outil pour mesurer les délais dans un sens

** Création de l'outil, qui fonctionne de manière bidirectionelle et rapporte les informations aux deux pairs

** Première mesure rapide sur un iperf en TCP, dans un sens puis dans l'autre, simplement pour valider la détection.

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