[isf-wifidog] trafic shaping

[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/
-------------- section suivante --------------
Une pièce jointe non texte a été nettoyée...
Nom: non disponible
Type: application/pgp-signature
Taille: 189 octets
Desc: non disponible
Url: http://listes.ilesansfil.org/pipermail/wifidog/attachments/20051106/908226c8/attachment.pgp