Rémi Bouhl wrote:
Je schématise: on a un tuyau à 1 Gb/s, avec dessus 500 utilisateurs qui ont jusqu'à 20 Mb/s chacun. Tant que le tuyau n'est pas saturé, chacun peut utiliser le maximum de sa ligne. Dès l'instant où le tuyau commence à saturer (un peu avant, en fait, dès que la latence augmente de façon sensible), on garantit à chaque utilisateur 1Gb/500 = 2Mb/s. Ce qui signifie que ceux qui prennent 20Mb/s se feront légèrement diminuer le débit, afin de garantir un tuyau à 2Mb/s pour madame Michu. Et si tout le monde veut utiliser le tuyau à fond, alors on bride tout le monde à 2Mb/s. Autrement dit, faire passer en priorité les utilisateurs qui consomment peu, par rapport à ceux qui consomment beaucoup, afin de garantir une latence faible aux usages qui consomment peu et demandent une latence faible. Et si l'utilisateur veut faire du BT à fond _et_ jouer en ligne, le fait que BT rende son jeu injouable devient son problème à lui. Ça paraît plus simple de trier les paquets par utilisateur (donc par IP) plutôt que de faire du DPI, non? Ce n'est pas faisable, ça? Garantir la même latence et le même débit à chaque utilisateur, et le laisser se démerder avec, plutôt que de prioriser le trafic de type machin de l'utilisateur A au détriment du trafic truc de l'utilisateur B?
En fait, pour faire ça, je pense qu'il suffirait de modifier légèrement SFQ pour qu'il se base sur l'adresse source et non pas sur la conversation. Ainsi, la capacité est répartie de manière équitable entre les sources. D'ailleurs j'ai pour projet de patcher SFQ sous Linux parce que je vais bientôt me retrouver dans une situation dans laquelle je vais avoir besoin de faire ça sur une passerelle Linux pour un petit réseau (50+ hôtes). La solution parfaite serait un mélange des deux : d'abord on partage équitablement selon la source, PUIS en "bonus", on priorise l'interactif par rapport au batch. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29
<<attachment: e-t172.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
