Fw: [Bda] Traffic Control Party

Phantom phantom@neodym.dyndns.org
Sat, 30 Dec 2000 13:35:27 +0100


Phantom
ICQ N° 37940289
----- Original Message -----
From: "Phantom" <phantom@neodym.dyndns.org>
To: <skaya@yoda.isnpro.com>
Sent: Saturday, December 30, 2000 1:34 PM
Subject: Re: [Bda] Traffic Control Party


> Bon comme vous le savez j'ai un grand garage ... c'est d'ailleurs lą que
je
> fais des rezos quand j'en fait.
> Si ca doit se passer fin janvier fevrier ca rulez :)
> En plus j'ai un petit cable de 50m qui va de la passerelle au garage donc
> adsl rulez ;)
> Pour ce qui est du matos qui est chez moi :
> y'a moyen d'avoir un serveur (voir deux avec lythium mais il va falloir
que
> je coupe la carte mere compaq en 6 pour pouvoir la faire marcher avec ces
> putains de procs arghhh) + 2 stations
> j'ai tj mon hub 12 ports 10.
> Voilą
>
> Phantom
> ICQ N° 37940289
> ----- Original Message -----
> From: <skaya@yoda.isnpro.com>
> To: "adrien bourland" <adrien.bourland@epita.fr>
> Cc: <cycom@hermes.epita.fr>; <bda@enix.org>
> Sent: Saturday, December 30, 2000 12:52 PM
> Subject: Re: [Bda] Traffic Control Party
>
>
> > [traffic control & limite de bande passante]
> > > la derniere fois que jen ai parle, la reponse de skaya fut que ce
> n'etait
> > > pas realisable tout le temps car cela demandait trop de temps proc.
> > > pourquoi du temps proc? pour analyser le trafic reseau.
> >
> > c'est un peu plus complique.
> > analyser le traffic en effet c'est couteux en temps proc, et on ne le
> > fait presque plus (sauf de temps en temps pour detecter les problemes).
> > controler le traffic par contre c'est autre chose. ca prend un peu de
> > temps CPU aussi, donc quand on veut maximiser les debits, on leve toutes
> > les limites et ca carbure sans taxer de CPU inutilement. quand on
> > active le traffic control, ca charge un peu les serveurs, mais si
> > c'est pour avoir jusqu'a disons 10 mbps par interface, c'est
negligeable.
> > par contre, mettre du TC pour avoir 80 mbps par interface ca commence
> > a taxer un peu plus (en fait, c'est surtout parceque pour l'instant,
> > y a 2 regles de TC donc ca carbure ; si on fait du TC plus complexe
> > il risque d'y avoir plus de regles donc ca risque d'etre plus couteux)
> >
> > => conclusion : quand on veut se lacher sur les downloads, on leve
> > tous les controles histoire que ca speede de partout (par contre,
> > le ping peut augmenter), et quand on veut avoir un ping nickel on
> > limite tout, mais alors avec tout pas de megabits.
> >
> > > je demande donc une limite fixe sur tous les ftp cycom,
> > > d'environ 50ko/s, en absence d'analyse de trafic.
> >
> > c'est pas si simple. je n'ai plus de FTP (enfin, il y a 3 packages
> > debian dessus, donc on ne va pas appeler ca un FTP, de toute facon
> > il y a 100 ko/s par user), donc je ne me sens plus trop concerne.
> > va convaincre krystal, phantom, albator, et tous ceux que j'oublie
> > qui ont un FTP, de mettre en place des limites efficaces.
> >
> > le probleme, c'est qu'il ne suffit pas d'intervenir au niveau du
> > serveur. si tu mets 50 ko/s par connexion, les gens vont faire
> > du leechftp ou equivalent. si tu mets 50 ko/s par IP, ils vont
> > faire "wouah ca pue, voisinage rezo power" et ca va ramer pour
> > tout le monde. si tu mets 2000 ko/s au total (par exemple), ca
> > va ramer pour les leechers, donc cf cas precedent, et en plus,
> > si il y a un mister sur un hub 10 qui download tout seul, il
> > pourrit le segment de son hub. d'ou l'idee de limiter sur les GW,
> > et en affectant des classes de traffic (par exemple : la machine
> > du type qui passe les films a droit a 1000 ko/s, ou encore : le
> > reseau 192.168.42.0/24 est en 100 mbps switche donc pour eux c'est
> > 1000 ko/s aussi, ou que sais-je ...)
> >
> > ce que je veux, c'est organiser une reunion avec les gens qui
> > ont soit des gateways, soit des serveurs FTP, et qui en tous cas
> > s'y connaissent suffisemment pour comprendre se qu'on va raconter
> > sur le TC, les queuing disciplines, les classifiers, et le shaping.
> > (c'est d'ailleurs pour ca que le mail d'annonce a ete envoye sur
> > la ML bda et non pas au cycom@epita.fr).
> >
> > le but, c'est qu'on arrive together (ouh yeah) a un compromis,
> > enfin qu'on tombe d'accord sur ce qu'on va faire afin d'eviter
> > d'avoir un mister qui limite comme ci, un autre comme ca, et qu'au
> > final ce soit le bronx...
> >
> > petit rappel : lorsqu'on active le TC sur une passerelle, tous
> > les gens connectes a la passerelle en profitent. c'est a dire
> > que lorsque j'active le TC sur nemesis, les gamers qui sont derriere
> > ont des bons pings - a condition que le serveur soit sur la dorsale
> > bien sur, parceque quand on quitte la dorsale il n'y a plus de TC...
> >
> > > Skaya, j'etais a l'origine dans la mailing list BDA et tu men as
retire
> > > sans m'en avertir j'aimerais avoir une explication.
> >
> > ouye, je n'ai jamais retire personne moa :(
> > il y a peut etre eu un poliotage quand j'ai fait le transfert
doors->yoda
> > mais en tout cas rassure toi, il n'a jamais ete question de retirer
> > personne de mes ML (tu connais ma position sur la question).
> > je ne savais meme pas que tu avais ete inscrit sur la ML bda...
> >
> > pour se reinscrire : http://lists.enix.org/listinfo/bda
> >
> > [la TCP (traffic control party) : skaya dit "pas a l'epita, y a pas de
> labo"]
> > > La je m'indigne.
> > > Mais s'il y a un autre point sur lequel je ne changerais pas de
> position,
> > > c'est le fait que le local est d'abord dedie a tous les travaux de
> cycom.
> > > C'est un lieu d'experimentation autant pour les gamers que pour les
> admins
> > > et je n'ai aucune envie que le BDA parte faire une petite reunion
> secrete
> > > en denigrant le local
> >
> > c'est pas ca la probleme, c'est que si on veut faire un TP qui tienne
> > la route, il faut au moins 3 machines (2 clients et une gateway),
> > voire 4 (2 gateways dorsale et 2 clients), voire un peu plus.
> > si je fais la TCP, je pense mobiliser le Krystal Network Lab', et on
aura
> > donc a nous deux 3 ou 4 passerelles (au moins 2 cartes rezo chacune!)
> > et autant de PCs, en deplacant un minimum de matos (j'ai chez moi une
> > piece qui est disponible et qui fait a peu pres 2 fois la taille du
> > local cycom, avec tout le matos dispo)
> >
> > > pour les interfaces reseau, gate en a plusieurs et ce serait cool de
> > > ramener kangaroo nemesis ou platyn.
> >
> > gate n'a qu'une carte rezo.
> >
> > l'interet si la TCP se fait chez moi ou chez seb, c'est qu'il n'y
> > a presque rien a deplacer.
> >
> > si seb ou phantom est ok pour ramener son matos (+ eventuellement
> > le mien, afin qu'on ait au moins 2 gateways), ca peut se passer
> > n'importe ou. de toute facon, la TCP n'aura pas lieu avant fevrier
> > je pense, et d'ici la certains nouveaux elements viendront surement
> > changer la donne (mais je t'en parlerai au next rezo ou a une
> > prochaine descente au local).
> >
> > > Merci a titor de m'avoir PERMIS de lire ce mail
> > les archives de la ML BDA sont dispo sur
> http://lists.enix.org/listinfo/bda
> > si tu veux voir un peu de quoi on y parle.
> >
> > d'ailleurs, tous les gens qui veulent se tenir au courant des petites
> > affaires du bda sont invites a s'inscrire la liste, sachant qu'il n'y
> > a pas que des discussions profondes sur l'etre et le devenir des
> > techniques reseau.
> >
> > voila! bonne annee a tous!
> >
> > --------------------------------------------
> > While money can't buy happiness, it certainly lets you choose your own
> > form of misery.
> >
> >
> > _______________________________________________
> > Bda mailing list
> > Bda@the-doors.enix.org
> > http://the-doors.enix.org/cgi-bin/mailman/listinfo/bda
> >
>
>