[Ran] Maison collective

[OB]

> Oui il peut trés bien fournir un routeur supplementaire charger avec un
> roadrunner pour faire du dualwan par contre que ca soit pas payant, je
> vois pas pourquoi on favoriserai un client non respectueux des lois en
> lui ouvrant deux lignes alors que les autres qui jouent le jeu et payent
> leur abonnements n'aurait pas droit au dualwan. A mon sens c'est un
> service supplémentaire donc faut le payer.

Oui oui je me suis mal exprimé !
Bien sur le client en question devrais payer le routeur supplémentaire, voire
même 2 si il établi un point, voire même participer à la location d'une ligne
DSL supplémentaire upstream (sinon c'est là que ça va coincer).

Ma remarque sur le "sans faire de fric sur son dos" visais le mail d'attila
précédant, qui justement disais qu'il ne voulais pas faire "sur-vendre"
justement pour ne pas plonger dans cette dérive. Mais payer pour le matériel,
bien sur !

> Oui il est évident que si tu fais dans le progressif sur ta régulation,
> tu n'es plus obligé d'aller dans les extremes, et comme je l'ai dit plus
> haut, la tendance chez les téléchargeurs va vers la connection PPTP
> distante, donc il nous serra plus facile de réguler ceci sans pour
> autant pourrir la bp des autres, puisqu'il ne reste plus qu'a réguler le
> Port 1723 sur la QOS du Point0 sans risque d'utilisation du port 80 par
> les clients P2P puisque encapsuler dans le pptp. ;) (la je crois qu'on
> va respirer un bon coup)

On est donc d'accord :-) (Bien que le n° de port ne soit pas un bon critère,
j'ai bien un OpenVPN en écoute sur le 443... :-)

Mais c'est clair que en france, le télé-chargement "à l'ancienne" se dirige
rapidement vers les vpn.

(Ce qui a mon avis a long terme est une connerie: D'abord parce que ça va
inciter les pouvoirs publics à se pencher dessus avec la seule arme qu'ils
connaissent, mais aussi parce que du point de vue technique, c'est très con que
tout le monde aille se connecter aux US pour rapatrier les MEME séries...)
Si t'a 100 personnes qui le font, bah t'a transporté 100x la même chose sur
plein de même routeurs sur le chemin :-( )

> Ben ca irait a l'encontre du mesh adhoc lui-meme, puisqu'il n'y a aucune
> notion client serveur a proprement dit. La régulation QOS intervient
> sous tous les noeuds dans ce cas...donc dificile de cibler un noeud
> pécisément pour le pourrir sans pourrir tous le reste(Enfin je crois,
> parceque j'ai pas beaucoup d'expérience sur les mesh Adhoc...juste du
> théorique)

Je suis d'accord, ça serais délicat.

C'est pas pour tout de suite, mais en ce moment B.A.T.M.A.N est en train d'être
nettoyé un peu, en particulier il lui sera possible de remonter pleins d'infos
sur les routes et les paquets en transit (IPs, tailles, fréquence, ...) via
netlink. A mon avis il sera possible , à terme, de créer une application
au-dessus de ça qui monitore et applique de la QoS dynamiquement.
(La QoS sous linux prend effet juste avant la sortie du paquet sur les
interface, donc ca s'appliquerais en ad-hoc. par contre, je pense que ca
marcherais pas en WDS ou en 802.11s vu que les paquets remontent pas a linux.)

OB+