[isf-wifidog] trafic shaping

Dim 6 Nov 14:43:12 EST 2005

Hey guys,

hope, you'll have a lot of fun at the hacking day ...

Would be nice to get a reply tommorow what you did and what the plan  
for the next steps is ...

Cheers, Max!

Am 06.11.2005 um 06:42 schrieb Benoit Grégoire:

> On November 5, 2005 08:17 pm, Mina Naguib wrote:
>> I'd really like to make it but I'm not sure (yet) if I'll be able to
>> or not.
>>
>> I'm mostly interested in traffic shaping for the client; and from
>> that stems a need for a protocol improvement.  The current "1" or "0"
>> reply is simply not going to cut it.
>
> Sorry, didn't have time to read the whole thing (we are in the  
> middle of the
> night), but I am sending a brain dump I sent to Philippe two weeks  
> ago that
> may be very relevent.
>
> Do try to make it, we'll move the discussion on shaping as late as  
> we can.  We
> miss your input...
>
> ----------------------
>>>> général pas à ce niveau.  Par contre j'aimerais bien qu'on arrive
>>>> au moins
>>>> avec un roadmap clair pour le gateway.  J'ai parfois peur que ça
>>>> devienne un
>>>> chillispot, et le facteur majeur de succès du gateway est sa
>>>> simplicité.
>>>>
>>>
>>> J'aimerais que tu élabores pour me faire une idée de ce à quoi tu
>>> penses, ce dont tu as peur particulièrement...
>>>
>>
>> J'ai peur du feature creep, genre que l'on puisse faire telle ou
>> telle chose
>> soit dans le gateway, soit sur le auth server.  (genre kicker un
>> usager,
>> blacklister un mac, définir le bandwidth permis pour un usager
>> quelconque,
>> etc.).  Bref que l'on se retrouve avec un thick client sur un thick
>> server,
>> et donc que l'on fasse rien de vraiment bien, que ce soit difficile à
>> documenter et expliquer, etc.
>>
>> Chilispot c'est un thick client avec un thin server
>> Wifidog c'est un thin client avec un thick server
>>
>> Je trouve ça  bien, chacun a sa niche.
>>
>> Évidemment, faut pas en faire un dogme, e serait vraiment cool de
>> supporter
>> WPA, et on peut faire des chosses pour le shaping que Chillispot
>> pourra
>> jamais faire.
>>
>>
>>> Il est simple, et ça reste que c'est simple parce que tout a été
>>> quand même bien implanté comme on l'a dit au début et tout. Il y a
>>> quand même des choses majeures (ie. quotas/throttling) qui doivent
>>> être pensé, et qui doit fonctionner indépendamment du central server
>>> d'après-moi pour une certaine partie...
>>>
>>
>> Je voulais pas trop en dire pour ne pas teinter la discussion.
>> Mais puisque
>> tu demandes.
>>
>> Tout d'abord, j'aimerais reformuler en un peu plus granulaire les
>> use case de
>> shaping sur SF:
>>
>>
>> 1-Avertir un usager qui approche de son quota mensuel (défini par
>> hotspot,
>> globalement, les deux ou whatever) en le mettant dehors, et en lui
>> sortant un
>> message.  Puis on le laisse réembarquer jusqu'à ce qu'il épuise son
>> quota au
>> complet.
>> 2-Ralentir un usager qui approche son quota mensuel plutôt que
>> bêtement le
>> kicker out.
>> 3-Ralentir tous les usagers lorsque le hotspot approche de son
>> quota mensuel
>> de bande passante.
>> 4-S'assurer que les usagers auent tous la même quantité de bande
>> bassante,
>> donc que si l'autre tata dans le café ouvre 173 connexion, ton
>> download en
>> ftp ne soit pas réduit à 1/174 de la bande passante.
>> 5-S'assurer que les buffer du modem cable ou DSL restent vide, pour
>> minimiser
>> te temps de latence.
>>
>> Maintenant y'a plein de façon de diviser la job.  Normalement, 5
>> devrait être
>> fait par qqchose d'externe (WonderShaper, ou qqchose de meilleur et
>> plus
>> récent), 4 peux en théorie très bien être fait par le gateway tout
>> seul, 1
>> peux pas vraiment être fait en dehors du auth server, et 2 et 3
>> nécessitent
>> un interaction entre le gateway et le auth server.
>>
>> Mais je ne pense plus que ce soit la bonne manière.  Supposons que
>> l'on
>> implante une seule fonctionnalité dans le gateway:  La capacité de
>> limiter la
>> bande passante d'un jeton (le gateway peut le traduire en IP ou en
>> mac selon
>> ses besoins) à une valeur X, et que X soit mis à jour en réponse à
>> un update
>> de compteurs.  C'est pas vraiment plus compliqué (en théorie) que
>> de faire
>> seulement 4, mais on a un système hyper flexible.
>>
>> Supposons que le auth server connaisse:
>>
>> Bmen: la bande passante mensuelle du client disponible pour ISF
>> Vmax:  la vitesse réelle atteignable par son modem (on pourrait même
>> automatiser ça par un test quotidien)
>>
>> Il connait déjà (ou peut calculer)
>>
>> Nuser:  nombre d'usager en ligne (y'a une subtilité avec le splash-
>> only, mais
>> c'est pas la fin du monde).
>> Bspent:   Bande passante utilisé par le hotspot au cours de la
>> période de
>> facturation
>>
>> Quelques autres variables:
>> Vtot:  Vitesse maximale pour l'ensemble de usagers
>> Vuser:  Vitesse max d'un usager
>>
>> Alors pour 3:
>>
>> Vtot = plus petit de: (Bspent - Bmen)/temps restant ou Vmax
>>
>> En remplaçant Vmax par 0.95 x Vmax, on l'obtient "gratuitement"
>> sans script
>> externe.
>>
>> Pour 4:  Vuser = Vtot/Nuser
>>
>> Pour 2, Ça se calcule bien, mais faut réajuster tous les autres
>> usagers si on
>> ne veut pas perdre de bande passante.  C'est un peu long à écrire,
>> mais pas
>> compliqué.
>>
>> Quelques problèmes:
>>
>> a) Si tous les usagers n'utilisent pas leur connexion au complet,
>> il faut
>> ajuster tous les chiffres d'un facteur Vuser_new = Vuser + Vuser *
>> (Vmax -
>> Vutilisée)/Vmax, ce qui impliique que le gateway connaisse Vmax
>>
>> b) Pour que ça fonctionne bien, il faut que tout passe par wifidog,
>> incluant
>> les adresse MAC whitelisté ou les autres interface du routeur.
>> Sinon, Vmax
>> n'est pas disponible,   et l'algorithme ne fait pas 5 correctement
>> (ce qui
>> peut être solutionné en n'utilisant en plus un autre script
>> "classique"), 4
>> est légèrement biaisé vers les usagers ayant un plus grand nombre de
>> connexion, et evidemment on espère que le hotspot a tenu compte de
>> cette
>> utilisation "externe" dans le calcul de Bmem.
>>
>> c) L'autre problème est si on veux donner priorité à certains
>> usagers.  Tant
>> que ça passe par wifidog, ça va, le auth server n'a qu'à calculer un
>> ajustement.  Par contre, si genre iTechnique veux que ses
>> ordinateurs aient
>> priorité sur 80% de la bande passante, on est un peu fourré, à
>> moins de
>> whitelister tous leurs MAC address en l'associant au owner.  Mais
>> je n'ai pas
>> encore de solution clean à ça, même si le gateway prends une plus
>> grande part
>> de responsabilité.
>>
>> Une solution à ces trois problèmes serait qu'un plugin du gateway
>> puisse
>> fournir Vmax réellement disponible en temps réel.  Ça solutionne
>> tous les
>> problèmes, et la seule autre modification est de multiplier tous
>> les Vuser
>> par Vmax réel/Vmax pour solutionner b) et c).  Pour solutionner
>> aussi a), on
>> multiplie tous les Vuser par:  1 + ((Vmax - SUM(Vuser))/Vmax)
>>
>> Fin du braindump.
> ------------------------------
> -- 
> Benoit Grégoire, http://benoitg.coeus.ca/
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog