[projet-agregation] mesurer la capacité d'un lien sans en gêner le fonctionnement.

Laurent GUERBY laurent at guerby.net
Mer 12 Oct 11:33:01 CEST 2011


On Wed, 2011-10-12 at 10:58 +0200, Jocelyn Delalande wrote:
> Bonjour,
> 
> Merci pour tes réponses Laurent,
> 
> > Dans le cadre du projet on va principalement regarder l'ADSL car
> > il sera le facteur limitant en débit, les equipements ubiquity
> > etant au dessus d'un ADSL en debit sauf dans des cas de liens
> > tres mauvais.
> 
> Ok, ceci-dit, les deux (xDSL et wifi) ne sont pas totalement décorélés à 
> mon avis. Il s'agit d'un problème de routage et de propagation de 
> métriques à travers le réseau radio.
> En cherchant sur le sujet, on a de plus en plus l'impression que faire 
> de l'agrégation dans le cas où les points de sortie sont répartis sur un 
> réseau radio revient à étendre la problématique du routage dynamique 
> utilisant du load-balancing (ce routage étant bien sûr guidé par des 
> métriques).

Le cas de lignes ADSL sur plusieurs sites est le cas "compliqué",
autant commencer par le cas simple de deux lignes ADSL sur le meme
site :). 

On peut passer de maniere relativement simple du cas mono site au cas
multi site en reservant une route statique entre les deux sites : le
logiciel de tunnel est alors configuré avec comme gateway non pas les
deux IP des routeurs ADSL locaux mais une IP routeur ADSL locale et une
IP qui est routée statiquement sur l'autre site vers le routeur ADSL. Si
le lien wifi d'interconnection des sites a une  capacité deux fois
superieure a celle de l'ADSL on ne perdra rien en debit final. L'ADSL
vue a travers le wifi aura bien sur des caracteristiques de latence
et perte de paquet legerement differente de l'ADSL locale, mais
on peut esperer peu d'impact.

> > Un effet
> > connu sur une liaison ADSL est qu'une saturation de l'upload                                    
> > a un impact significatif sur l'upload, de meme en saturation
                                 le download
> > download la latence devient tres grande.


> Tu veux dire en détectant les pics de manière "opportuniste" ? 
> Grosso-modo on considère que la capacité d'un lien ADSL à un instant t 
> est le pic de débit obtenu pendant une période (pour s'ajuster aux 
> fluctuations de débit) ?
> 
> Je suppose qu'on peut détecter qu'un pic est "écrasé" lorsque des 
> paquets sont dropés par l'interface ppp, tu confirmes ?

Au niveau du tunnel UDP tu vas constater une perte de paquet
et/ou une latence plus grande lors d'une saturation, ceci presuppose que
tu as un a priori sur un regime "normal". A priori on va rester au
niveau "utilisateur" sans regarder la partie interface comme ppp & cie.

> >
> > Est-ce que vous avez regardé le lien ajouté sur
> >
> > http://chiliproject.tetaneutral.net/issues/16
> >
> > http://www.secdev.org/projects/tuntap_udp/
> >
> > => le code en python est facilement exploitable pour jouer :).
> 
> 
> Oui, on a regardé ça, je suis pressé de jouer avec du tuntap et du 
> python :D… 

Pour commencer je pense qu'il faut se faire une idée via des prototypes
du comportement d'une ligne ADSL en charge dans un sens, puis
l'autre, puis les deux et ce code python permets de faire un
iperf maison facilement :). Il faut faire une specification
du format de paquet avec des compteurs & cie et de la gestion de file
envoi et reception avant de se lancer

> Mais pour l'instant on se documente, on bouquine des 
> articles, on crawle, on cogite et on prend quelques notes, Voir 
> http://chiliproject.tetaneutral.net/projects/tetaneutral/wiki/Bibliographie_du_projet
> 
> Niveau recherches, on est pas mal partis sur l'idée de tout faire par 
> routage, de proche en proche (un AP ne sait pas quelle sortie internet 
> il va utiliser, juste à quel voisin il vaut mieux qu'il envoie son 
> paquet) mais n'hésitez pas à nous dire si vous voyez d'autres pistes à 
> creuser :-).

Le routage mesh est extraordinairement compliqué, typiquement
les gens font des theses dessus donc 3 ans a temps plein en partant de
BAC+5 :).

C'est un sujet interessant mais si vous voulez realiser quelque chose
sur ce projet il faudra se limiter a de la lecture de généralités sur le
mesh.

> Vu que le problème est certes d'une part de collecter des métriques sur 
> les liens ADSL mais aussi de les propager sur le réseau, on est en train 
> d'étudier B.A.T.M.A.N en se disant qu''il serait peut-être intéressant 
> de l'étendre :
>   - d'une part pour qu'il puisse appliquer des métriques aux liens xDSL 
> de manière pertinente et sans bouffer la moitié de la BP en signaling ;
>   - d'autre part pour qu'il puisse faire de la répartition de charge.
> 
> Les évolutions récentes de BATMAN (annonce de point de sortie internet, 
> multi-interfaces…) pourraient fournir un bon socle non ? Après, je dis 
> ça, on commence tout juste avec Yanick à étudier les entrailles de la 
> chauve-souris.
> 
> D'ailleurs si certains d'entre vous ont des expériences/connaissances 
> intéressantes sur la pertinence BATMAN (ou autre) dans notre cas de 
> figure, nous sommes bien évidement preneurs.

A ma connaissance BATMAN ni aucune de ses variantes ne sait agreger de
lien : comme la plupart des protocoles de routage il se borne a etablir
un jeu de routes complet et sans boucles, il n'est donc pas pertinent
pour nos cas d'etude dont l'objectif est l'agregation.

Sincerement,

Laurent




More information about the projet-agregation mailing list