Projet

Général

Profil

Projet agregation » Historique » Version 40

Yanick Delarbre, 08/01/2012 16:47

1 1 Laurent GUERBY
h1. Projet agregation
2 1 Laurent GUERBY
3 2 Yanick Delarbre
* [[Bibliographie du projet]]
4 18 Yanick Delarbre
* [[L'installation de gitolite]]
5 3 Yanick Delarbre
* http://pad.rhizome-fai.net/U7HSgxYvDM | Le code du tunnel tun réalisé avec python
6 17 Yanick Delarbre
* 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 ?)
7 1 Laurent GUERBY
8 1 Laurent GUERBY
* http://lists.tetaneutral.net/listinfo/projet-agregation
9 1 Laurent GUERBY
* http://chiliproject.tetaneutral.net/issues/16
10 4 Jocelyn Dealande
11 31 Laurent GUERBY
* discussion sur le sujet http://www.spinics.net/lists/lartc/msg21455.html
12 31 Laurent GUERBY
13 22 Laurent GUERBY
h2. Prototype v1
14 22 Laurent GUERBY
15 22 Laurent GUERBY
http://lists.tetaneutral.net/pipermail/projet-agregation/2011-November/000023.html
16 4 Jocelyn Dealande
17 4 Jocelyn Dealande
h2. Test de tunproxy.py
18 4 Jocelyn Dealande
19 4 Jocelyn Dealande
On utilise "tunproxy.py":http://www.secdev.org/projects/tuntap_udp/files/tunproxy.py. Entre 2 machines
20 4 Jocelyn Dealande
* client-adsl (une machine chez nous)
21 4 Jocelyn Dealande
* gateway (la VM)
22 4 Jocelyn Dealande
23 4 Jocelyn Dealande
h3. Sur la gateway (= VM ttn)
24 4 Jocelyn Dealande
25 4 Jocelyn Dealande
Démarrer le tunnel, il crée lui-même une interface _toto0_ (détruite à la sortie).
26 4 Jocelyn Dealande
27 4 Jocelyn Dealande
<pre>
28 4 Jocelyn Dealande
 ./tunproxy.py -s 6000
29 11 Jocelyn Dealande
 ifconfig toto0 10.0.0.1/24 mtu 1468
30 4 Jocelyn Dealande
</pre>
31 1 Laurent GUERBY
32 15 Jocelyn Dealande
La MTU est calculée comme suit : 
33 1 Laurent GUERBY
34 11 Jocelyn Dealande
  MTU de l'iface virtuelle  = MTU  de l'iface physique - taille_max(header IP) - taille(header UDP)
35 15 Jocelyn Dealande
  MTU de l'iface virtuelle = 1500 - 24 - 8
36 11 Jocelyn Dealande
37 17 Yanick Delarbre
http://www.commentcamarche.net/faq/7185-introduction-au-mtu
38 11 Jocelyn Dealande
39 4 Jocelyn Dealande
h3. Sur le client
40 4 Jocelyn Dealande
41 4 Jocelyn Dealande
42 4 Jocelyn Dealande
<pre>
43 4 Jocelyn Dealande
 ./tunproxy.py -c rhizome-fai.tetaneutral.net:6000
44 12 Yanick Delarbre
 ifconfig toto0 10.0.0.2/24 mtu 1468
45 4 Jocelyn Dealande
</pre>
46 4 Jocelyn Dealande
47 4 Jocelyn Dealande
Tout le trafic vers les adresses en 10.0.0.x passera par le tunnel.
48 4 Jocelyn Dealande
49 4 Jocelyn Dealande
* http://lists.tetaneutral.net/listinfo/projet-agregation
50 1 Laurent GUERBY
* http://chiliproject.tetaneutral.net/issues/16
51 1 Laurent GUERBY
52 15 Jocelyn Dealande
Un test de perf sur un téléchargement d'un fichier de 40Mio donne :
53 15 Jocelyn Dealande
54 15 Jocelyn Dealande
* avec tunnel : 909kb/s
55 15 Jocelyn Dealande
* sans tunnel : 942kb/s
56 15 Jocelyn Dealande
57 29 Jocelyn Dealande
h1. Détection de la saturation d'un lien / bufferbloat
58 30 Jocelyn Dealande
59 29 Jocelyn Dealande
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.
60 29 Jocelyn Dealande
61 29 Jocelyn Dealande
Tout le challenge est de détecter (passivement) plutôt que de mesurer (activement) la capacité du lien, sans induire de trafic supplémentaire.
62 29 Jocelyn Dealande
63 29 Jocelyn Dealande
Nous avons fait des mesures sur deux liens :
64 29 Jocelyn Dealande
65 29 Jocelyn Dealande
h2. Mesure ADSL Free (Freebox)
66 29 Jocelyn Dealande
67 29 Jocelyn Dealande
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é.
68 29 Jocelyn Dealande
69 29 Jocelyn Dealande
h2. Lien ADSL (OVH)
70 29 Jocelyn Dealande
71 29 Jocelyn Dealande
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é.
72 1 Laurent GUERBY
73 30 Jocelyn Dealande
Données du test et graphiques : attachment:saturation_et_ping___uplink_seulement__udp_sctp.ods 
74 30 Jocelyn Dealande
75 1 Laurent GUERBY
h3. Conditions du test :
76 30 Jocelyn Dealande
77 1 Laurent GUERBY
* Tunnel tap basé sur tunproxy.py (cf dépôt git), qui est le seul à utiliser la connexion
78 1 Laurent GUERBY
* Données collectées toutes les secondes, chaque peer enregistre : 
79 30 Jocelyn Dealande
** timestamp
80 30 Jocelyn Dealande
** stats des paquets entrants
81 30 Jocelyn Dealande
** ping
82 29 Jocelyn Dealande
* On teste la connection au repos en la saturant par moments avec iperf
83 30 Jocelyn Dealande
** en UDP : en metant l'option -b à une valeur supérieure à la capacité d'uplink 
84 30 Jocelyn Dealande
** en TCP
85 1 Laurent GUERBY
* Les données des 2 peers sont fusionnées à posteriori (script merge_tunproxy_csv.py) en fonction des timestamp.
86 30 Jocelyn Dealande
* Les données sont graphées sur un tableur (ouais je sais, beurk ;-) ).
87 29 Jocelyn Dealande
88 29 Jocelyn Dealande
Le comptage du volume sortant n'est pas pertinent puisque la moitié des paquets peuvent-être dropés en route…
89 29 Jocelyn Dealande
90 29 Jocelyn Dealande
91 29 Jocelyn Dealande
h3. Analyse des résultats
92 30 Jocelyn Dealande
93 29 Jocelyn Dealande
(voir document joint)
94 29 Jocelyn Dealande
* On note systématiquement une corrélation forte entre lien saturé et augmentation du ping. Que le lien soit saturé en UDP ou TCP.
95 29 Jocelyn Dealande
* 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.
96 29 Jocelyn Dealande
* 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).
97 29 Jocelyn Dealande
* -> Quid de la réalité de la saturation d'un lien par rapport à ces deux exemples simples ?
98 11 Jocelyn Dealande
99 11 Jocelyn Dealande
100 32 Jocelyn Dealande
h2. Demi-délai
101 32 Jocelyn Dealande
102 32 Jocelyn Dealande
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
103 32 Jocelyn Dealande
104 32 Jocelyn Dealande
105 32 Jocelyn Dealande
h3. Synchronisation par NTP
106 32 Jocelyn Dealande
107 32 Jocelyn Dealande
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 : 
108 32 Jocelyn Dealande
109 32 Jocelyn Dealande
*  On maintient les horloges synchronisées grace à NTP entre machine 1 et machine 2
110 32 Jocelyn Dealande
*  Machine1 envoie un paquet à machine2 contenant un timestamp
111 32 Jocelyn Dealande
*  Machine 2 peut connaître le temps de trajet machine1->machine2 en comparant ce timestamp avec sa propre horloge.
112 32 Jocelyn Dealande
113 32 Jocelyn Dealande
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.
114 32 Jocelyn Dealande
115 32 Jocelyn Dealande
Voir aussi http://www.frameip.com/ntp/
116 32 Jocelyn Dealande
117 32 Jocelyn Dealande
h3. Par évolution du délai relatif
118 32 Jocelyn Dealande
119 32 Jocelyn Dealande
Une autre approche discutée est de mesurer non pas le délai absolu mais la variation de celui-ci.
120 32 Jocelyn Dealande
On mesure timestamp_envoi_site1 - timestamp_reception_site2 pour chaque paquet, la valeur absolue n'a aucun sens (on utilise deux horloges différentes).
121 32 Jocelyn Dealande
122 32 Jocelyn Dealande
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)
123 32 Jocelyn Dealande
124 32 Jocelyn Dealande
Cette idée est d'ailleurs reprise dans le protocole UTP de bittorrent : http://www.rasterbar.com/products/libtorrent/utp.html
125 32 Jocelyn Dealande
126 33 Jocelyn Dealande
Un outil faisant ce type de mesure a été implémenté dans le dépôt : _delta_half_trip_time.py_ 
127 33 Jocelyn Dealande
128 33 Jocelyn Dealande
Côté serveur :
129 33 Jocelyn Dealande
130 33 Jocelyn Dealande
    ./delta_half_trip_time.py -s 2244
131 33 Jocelyn Dealande
132 33 Jocelyn Dealande
Côté client:
133 33 Jocelyn Dealande
134 33 Jocelyn Dealande
    ./delta_half_trip_time.py -s <ip_serv>:2244
135 33 Jocelyn Dealande
136 33 Jocelyn Dealande
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 :
137 33 Jocelyn Dealande
138 34 Jocelyn Dealande
    pkt_type,sequence number,delay
139 33 Jocelyn Dealande
140 33 Jocelyn Dealande
_pkt_type_ vaut *'t'* (comme _timer_) pour les mesures entrantes (download) et *'d'* (comme _delay_) pour les réponses aux paquets sortants (upload).
141 33 Jocelyn Dealande
142 33 Jocelyn Dealande
h4. mesures
143 33 Jocelyn Dealande
144 34 Jocelyn Dealande
Pour l'instant, seules des mesures avec iperf en TCP : attachment:one-way_delay.ods
145 33 Jocelyn Dealande
146 33 Jocelyn Dealande
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.
147 33 Jocelyn Dealande
148 36 Jocelyn Dealande
h4. dérive
149 36 Jocelyn Dealande
150 36 Jocelyn Dealande
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.
151 36 Jocelyn Dealande
152 36 Jocelyn Dealande
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.
153 33 Jocelyn Dealande
154 33 Jocelyn Dealande
155 11 Jocelyn Dealande
h1. Petits points techniques…
156 11 Jocelyn Dealande
157 20 Jocelyn Dealande
h2. Que mesure iperf et comment (en UDP) ?
158 1 Laurent GUERBY
159 16 Jocelyn Dealande
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.*
160 17 Yanick Delarbre
161 17 Yanick Delarbre
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.
162 17 Yanick Delarbre
163 17 Yanick Delarbre
h2. Quelques outils réseaux bien pratique
164 17 Yanick Delarbre
165 17 Yanick Delarbre
* tcpdump | http://openmaniak.com/fr/tcpdump.php
166 17 Yanick Delarbre
<pre bash>
167 17 Yanick Delarbre
tcpdump -D #Interfaces réseaux disponibles pour la capture
168 17 Yanick Delarbre
tcpdump port 80 -i eth0 -w capture.log #Enregistre le trafic Web vers le fichier capture.log pouvant être ouvert avec Wireshark
169 17 Yanick Delarbre
tcpdump icmp #Affiche tout le trafic associé au protocole icmp
170 17 Yanick Delarbre
</pre>
171 17 Yanick Delarbre
* ping | http://www.bortzmeyer.org/ping-taille-compte.html
172 17 Yanick Delarbre
** Permet de tester un problème de MTU grâce à l'option -s de ping permettant de fixer une taille de paquet
173 17 Yanick Delarbre
* hping3
174 17 Yanick Delarbre
<pre bash>
175 5 Jocelyn Dealande
hping --syn -p 80 --data 1200 10.0.0.1 #Envoie de paquet tcp syn sur le port 80 de taille 1200
176 15 Jocelyn Dealande
</pre>
177 21 Jocelyn Dealande
178 21 Jocelyn Dealande
179 23 Jocelyn Dealande
*tracepath* pour découvrir le PMTU
180 23 Jocelyn Dealande
181 40 Yanick Delarbre
h1. multy.py
182 40 Yanick Delarbre
183 40 Yanick Delarbre
peer_: Liste des sockets du clients basés sur ses interfaces physiques
184 40 Yanick Delarbre
peer_d: sous forme de dictionnaire
185 40 Yanick Delarbre
peer_l: sous forme de liste
186 40 Yanick Delarbre
187 40 Yanick Delarbre
La structure:
188 40 Yanick Delarbre
Liste < . . . > Dictionnaire
189 40 Yanick Delarbre
0->A  < . . . > <A,None>
190 40 Yanick Delarbre
1->B  < . . . > <B,None>
191 40 Yanick Delarbre
2->C  < . . . > <C,None>
192 40 Yanick Delarbre
193 40 Yanick Delarbre
!!
194 40 Yanick Delarbre
195 23 Jocelyn Dealande
h1. TODO étapes suivantes
196 23 Jocelyn Dealande
197 23 Jocelyn Dealande
* 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
198 23 Jocelyn Dealande
* Finir de lire/comprendre le code de Fernando (linkagreg)
199 1 Laurent GUERBY
* Lire/comprendre le bout de script python de Laurent (multi-UDP pour contourner les QoS)
200 9 Jocelyn Dealande
201 1 Laurent GUERBY
h1. Journal (à partir du 28 oct)
202 23 Jocelyn Dealande
203 29 Jocelyn Dealande
Activités du projet de Yanick & Jocelyn (TX) 
204 33 Jocelyn Dealande
205 39 Yanick Delarbre
h2. 8 janvier.
206 39 Yanick Delarbre
207 37 Yanick Delarbre
* Compréhension du script multy.py de Laurent Guerby
208 37 Yanick Delarbre
* Documentation du script multy.py
209 37 Yanick Delarbre
** Schéma graphique du fonctionnement de multy.py
210 37 Yanick Delarbre
* Adaptation de l'algorithme de round robin avec des métriques
211 37 Yanick Delarbre
** Ajout d'un coefficient pour "plus" utiliser une connexion qu'une autre
212 37 Yanick Delarbre
213 38 Yanick Delarbre
h2. 28/29 déc.
214 33 Jocelyn Dealande
215 33 Jocelyn Dealande
* Détection de saturation : nouvel outil pour mesurer les délais dans un sens
216 33 Jocelyn Dealande
** Création de l'outil, qui fonctionne de manière bidirectionelle et rapporte les informations aux deux pairs
217 33 Jocelyn Dealande
** Première mesure rapide sur un iperf en TCP, dans un sens puis dans l'autre, simplement pour valider la détection.
218 29 Jocelyn Dealande
219 29 Jocelyn Dealande
h2. 5 déc.
220 30 Jocelyn Dealande
221 29 Jocelyn Dealande
* Détection de saturation :
222 29 Jocelyn Dealande
* Output CSV en direct vers le fichier plutôt que statiquement au bout de 3 minutes…
223 29 Jocelyn Dealande
* Écriture d'un outil de script de logs CSV
224 1 Laurent GUERBY
* Collecte de mesures sur l'effet sur le ping de la saturation d'un lien en UDP et TCP
225 24 Yanick Delarbre
* Analyse basique des résultats
226 25 Yanick Delarbre
227 24 Yanick Delarbre
h2. 27 nov.
228 24 Yanick Delarbre
229 24 Yanick Delarbre
* Lecture et utilisation de linkagreg (outil d'agrégation de Fernando)
230 24 Yanick Delarbre
* Faire fonctionner linkagreg sur une architecture 64bits
231 27 Yanick Delarbre
* Faire fonctionner linkagreg avec une connection sur le client //Fonctionnel
232 27 Yanick Delarbre
* Faire fonctionner linkagre avec n connection sur le client //Non fonctionnel
233 27 Yanick Delarbre
** Test avec une connection filaire et WiFi //Non fonctionnel car perte (important) de paquet sur le lien WiFi
234 23 Jocelyn Dealande
** Test avec des connections virtuelles //Non fonctionnel car QoS inapplicable sur des interfaces virtuelles
235 28 Jocelyn Dealande
** Test avec deux interfaces physiques //Non fonctionnel car QoS déficiente
236 28 Jocelyn Dealande
237 28 Jocelyn Dealande
* Ajout de la collecte de données sur les temps de réponse (ping) périodiquement.
238 28 Jocelyn Dealande
* Export des données en CSV (pour exploitation/graphe… etc.)
239 28 Jocelyn Dealande
* Premier jeu de mesure (mauvais) sur une ligne adsl.
240 19 Jocelyn Dealande
* 
241 19 Jocelyn Dealande
242 19 Jocelyn Dealande
h2. 11 nov.
243 19 Jocelyn Dealande
244 19 Jocelyn Dealande
* 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).
245 19 Jocelyn Dealande
* Configuration auto des adresses IP de chaque côté du tunnel (plus besoin d'ifconfig à la main)
246 19 Jocelyn Dealande
* Ajout sur tunproxy.py de compteurs de débit 
247 19 Jocelyn Dealande
  * mémorise le traffic sur les x dernières tranches de n secondes (défaut 10 tranches de 1 seconde)
248 19 Jocelyn Dealande
  * Affiche les moyennes et les max.
249 19 Jocelyn Dealande
* 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!)
250 19 Jocelyn Dealande
* 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 :
251 19 Jocelyn Dealande
  * évite de gérer les soucis spécifiques du niveau IP
252 1 Laurent GUERBY
  * TUN ne supporte pas IPV6 par exemple …
253 23 Jocelyn Dealande
254 23 Jocelyn Dealande
255 23 Jocelyn Dealande
h2. 5 nov.
256 35 Jocelyn Dealande
257 23 Jocelyn Dealande
* Mise en place d'un dépôt git (gitolite) pour partager du code avec Fernando Alves de Sames Wireless : 
258 23 Jocelyn Dealande
259 23 Jocelyn Dealande
    # Dépot public  : (lecture-seule)
260 1 Laurent GUERBY
    git clone git://rhizome-fai.tetaneutral.net/agregation.git
261 6 Jocelyn Dealande
262 23 Jocelyn Dealande
h2.  28 oct. 
263 5 Jocelyn Dealande
264 8 Jocelyn Dealande
* Initiation python (découverte pour Yanick) 
265 15 Jocelyn Dealande
* Commentaire intégral du tunproxy.py et premiers tests de ce dernier
266 5 Jocelyn Dealande
** ping ok (+1ms)
267 5 Jocelyn Dealande
** iperf à travers le tunnel : BP ~= celle de l'uplink ADSL. Le dernier datagrame ne reçoit pas d'ACK
268 5 Jocelyn Dealande
269 5 Jocelyn Dealande
<pre>
270 5 Jocelyn Dealande
[  3] local 10.0.0.2 port 50191 connected with 10.0.0.1 port 5001                        
271 5 Jocelyn Dealande
[ ID] Interval       Transfer     Bandwidth                                              
272 5 Jocelyn Dealande
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec                                         
273 5 Jocelyn Dealande
[  3] Sent 893 datagrams                                                                 
274 13 Yanick Delarbre
[  3] WARNING: did not receive ack of last datagram after 10 tries.
275 13 Yanick Delarbre
</pre>
276 13 Yanick Delarbre
277 13 Yanick Delarbre
h2. 2 novembre
278 13 Yanick Delarbre
279 13 Yanick Delarbre
* Modification de la MTU pour éviter la fragmentation de paquet
280 13 Yanick Delarbre
281 13 Yanick Delarbre
h1. Fonctionnalité
282 1 Laurent GUERBY
283 1 Laurent GUERBY
* Ajouter plusieurs sockets sur le tunnel pour éviter le traffic shaping de la part d'un opérateur