Dominique Rousseau wrote:
Dans un contexte où a de la saturation de lien à gérer (savoir si on cherche à éviter ce contexte, c'est une autre question), il est normal, je pense, de prioriser les flux "interactifs", pour lesquels une latence plus élevée dégrade le "ressenti". Et donc, les webmails, banques en ligne, ... ça rentrerait dans ces applications prioritaires. Et c'est relativement facile à différencier, une application "interactive", ce sont celles où on a un aller-retour permanent de connexions de (relativement) courte durée (chacune individuellement). Les application moins prioritaires seraient tous les transferts "bulk", qu'ils soient en bittorrent, ftp, http, ... On peut sans doute aussi y ranger le smtp, quand il se fait entre serveurs. (quand c'est entre le Thunderbird et le SMTP du fai, ça joue sur le ressenti, si ça rame)
C'est intéressant comme réflexion. C'est exactement le même principe que les schedulers CPU, qui sont capables d'estimer si un processus est de type "interactif" ou de type "batch" et priorise les tâches interactives (qui consomment peu mais qui ont besoin du CPU tout de suite) par rapport aux tâches batch (qui consomment le maximum pendant un certain temps).
Je sais pas si y'a eu des recherches pour adapter ça au réseau : si un flux consomme peu, alors il est considéré interactif et ses paquets passeront avant ceux des flux qui consomment le maximum. En théorie, distinguer les deux est très simple : dans le cas de l'interactif c'est majoritairement constitué de petits paquets, dans le cas du batch c'est constitué uniquement de gros paquets (= MTU).
En fait on peut même faire ça avec une box Linux et le traffic control assez simplement. On utilise une queuing discipline de type PRIO et on classifie les paquets taille < MTU dans une première queue et les paquets taille = MTU dans une deuxième (bon, avec une marge pour le MTU). Le résultat c'est que les paquets < MTU passent avant les autres, et comme ce sont généralement des paquets liés à des applications interactives, bingo.
Bon c'est assez simpliste, et ça ne couvre pas le cas de HTTP parce que en pratique, HTTP serait considéré comme du batch. J'imagine qu'il serait mieux de faire des statistiques sur une conversation (stateful donc), auquel cas, comme la connexion HTTP serait inutilisée la plupart du temps (vu que l'utilisateur ne change pas tout le temps de page), elle serait priorisée par rapport au Bittorrent par exemple qui lui utilise toute la capacité tout le temps. Par contre ça va scaler beaucoup moins bien évidemment.
Faudrait que j'expérimente là dessus, mais j'imagine que quelqu'un y a déjà pensé avant ?
-- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29
<<attachment: e-t172.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
