On 11/26/2010 12:56 PM, e-t172 wrote: > Mon opinion, qui n'engage que moi, est que tu te trompes de problème. > Ton problème n'est pas que tes utilisateurs ne peuvent pas faire de la > VoIP pendant qu'ils ont Rapidshare qui tourne à plein régime. Ton > problème c'est que tes utilisateurs puissent se marcher sur les pieds, > c'est-à-dire que quelqu'un qui fait du DDL puisse faire chier son voisin > qui lui n'a rien demandé et ne demande qu'à faire son entretien > d'embauche via VoIP. > > Autrement dit, tu veux nous parler de différenciation par service, moi > je veux te parler de différenciation par utilisateur. > > Pour moi, la meilleure solution à ton problème consiste à rétablir la « > justice » (Fair Queuing) entre les utilisateurs. C'est-à-dire quelqu'un > qui ouvre 1000 téléchargements ne puisse pas mettre tous les autres à > genoux sous la congestion. Ça devrait même être une règle élémentaire de > sécurité : un individu qui empêche tous les autres d'utiliser le réseau, > on appelle ça un Denial of Service, non ? > > La solution est simple : au lieu de faire des queues par type de service > (ToS), tu fais des queues par utilisateur (IP source). C'est possible > sous Linux avec ESFQ, je ne sais pas pour les autres plateformes. > > Avec cette solution, tu as la garantie que la bande passante est > découpée de manière équitable entre les différents hôtes de ton réseau. > Imaginons que ton tuyau fait 10 Mbits, et que deux utilisateurs font du > DDL. Eh bien les deux auront 5 Mbits chacun, même si l'un ouvre 100 > connexions et l'autre 2. Plus intéressant : si quelqu'un fait du DDL et > qu'un autre veut faire de la VoIP, la VoIP aura toujours priorité par > rapport au DDL car elle consomme beaucoup moins de bande passante et > n'atteindra donc jamais le quota. La VoIP passera donc comme sur des > roulettes, et toute la bande passante nécessaire sera prise sur le > téléchargement du voisin (qui l'aura bien cherché). Dans tous les cas > l'utilisation du tuyau est optimale : par exemple le téléchargeur aura 9 > Mbits et la VoIP en aura 1, car elle ne demande pas plus. Par contre, le > point important ici, c'est que ces 1 Mbits sont *garantis* par le système. > > Le principal avantage est qu'il est impossible de tricher : > l'utilisateur aura beau tenter de tunelliser ou de forger les champs ToS > de ses paquets IP, ça ne changera strictement rien car tout est basé sur > son adresse IP, qu'il est impossible de falsifier (enfin, j'espère). > > Un problème persiste cependant : si tu es vraiment fauché au niveau de > la taille de ton tuyau, tu pourrais te retrouver avec 100 téléchargeurs > sur un tuyau de 1 Mbits, ce qui fait que chaque personne se retrouve > avec 10 kbits… et là, c'est l'horreur et même la VoIP ne passe plus. > Comme cela a déjà été dit sur ce fil la vraie solution est d'augmenter > la taille du tuyau, mais si ce n'est pas une option, je suggèrerais > d'ajouter un burst qui permettrait à chaque utilisateur de dépasser son > quota à condition qu'il ne le fasse pas trop longtemps. > > Ainsi les téléchargeurs auraient le burst épuisé en permanence car ils > pompent en continu, mais par contre ceux qui font autre chose auraient > du burst en réserve et gagneraient donc la priorité sur les > téléchargeurs, jusqu'à un certain point. Par exemple avec un burst de 50 > Mo, c'est plus que suffisant pour y caser une longue conversation en > VoIP, qui passera comme sur des roulettes même avec 10000 téléchargeurs > fous à côté. En d'autres termes, le système « punit » automatiquement > ceux qui pompent en continu sur le tuyau. >
Bon, avant toute chose j'aimerais préciser que dans mon mail de base je ne parlais absolument pas d'optimiser mon cas particulier, mais bien de lancer le débat sur l'intérêt de considérer le HTTP comme un protocole de transport dans les firewalls, par ce que le web change toussa, et mon cas particulier de débit trop faible n'était là que pour expliquer d'où me venait l'idée, que j'ai considérablement élargie depuis. Bref je l'ai dit assez de fois. Je suis entièrement d'accord avec le fait qu'il faille limiter la bande passante par utilisateur et non par connexion ! Et merci beaucoup pour tes arguments ainsi que tes informations, car c'est bien plus développé que ce que j'ai trouvé jusqu'à présent, ça va m'aider à avancer :) . @Rémi: oui nos utilisateurs sont authentifiés, donc on a une IP (enfin un subnet) par utilisateur. -- Rémy Sanchez
signature.asc
Description: OpenPGP digital signature
