Sans vouloir engager un troll pro/anti-DPI (je pense que maintenant on connait les arguments de chaque partie par coeur), c'est dommage d'utiliser le DPI pour ce genre d'usages. C'est ce qui pousse les développeurs à tout faire passer au dessus d'HTTP, et qui va pousser bientôt à obfusquer son trafic pour le faire passer pour un protocole plus priorisé. Si ça se trouve on sera bientôt obligés de déployer iodine partout...
Il y a ici une solution qui va dans le bon sens et qui permet aux utilisateurs et aux développeurs de prendre leurs responsabilités, ce serait dommage que de telles propositions partent à la poubelle parce que certains opérateurs se croient plus malins. L'intelligence dans le réseau on ne peut pas dire que cela ait déjà marché... Cordialement Emmanuel Thierry Le 21 déc. 2012 à 12:06, Thomas Mangin <thomas.man...@exa-networks.co.uk> a écrit : > Je ne peux pas parler du marché français :-D mais ... > > Sur le marché anglais les chances d'une remise sont IMHO quasi nulles. Quasi > tous les FAI avec plus de quelques milliers de lignes utilisateurs utilisent > du DPI pour réguler le trafic de leurs clients. > > Il y a 5 ans les courbes de trafic des FAI "eyeballs" avaient cette forme de > cloche, que l'on retrouve toujours chez les fournisseurs de transit. Depuis, > les lignes ont de plus en plus tendance a être utilise a' 100% 100% du temps > et le DPI est utilisé pour faire passer en priorité les protocoles temps > réels ou importants ( voip, email , ... ). Le P2P ( qui a dit Youtube !! ?? > ) est ce qui passe normalement a la poubelle le plus rapidement et rempli ce > qui n'est pas utilisé par les autres protocoles. > > Il semblerait que LEDBAT offre une solution intéressante et moins chère au > même problème de gestion de capacité ... mais avec moins de contrôle pour le > FAI. > > Comme la plupart des solutions DPI peuvent être utilisées pour faire de > l'interception légale de trafic et comme les demandes d'interception ne > disparaitront pas même si tous les clients d'un FAI utilisant LEDBAT, un FAI > ne peut pas espérer faire des économies en remplaçant son DPI par un LEDBAT > cote client. > > je te souhaite donc bonne chance pour obtenir cette réduction .... > Qui sait, mon analyse est peut-être totalement fausse ou le père Noel > écoutera peut-etre ta demande ... > > Thomas > > On 20 Dec 2012, at 08:42, Stephane Bortzmeyer <bortzme...@nic.fr> wrote: > >> La question qui tue : qui ici est prêt à faire une réduction de tarifs >> à ses clients pour des applications « gentilles », qui utiliseraient >> cet algorithme LEDBAT pour ne pas charger le réseau ? >> >> http://www.bortzmeyer.org/6817.html >> >> ---------------------------- >> >> Auteur(s) du RFC: S. Shalunov (BitTorrent Inc), G. Hazel (BitTorrent Inc), >> J. Iyengar (Franklin and Marshall College), M. Kuehlewind (University of >> Stuttgart) >> >> >> >> ---------------------------- >> >> >> Alors que tant d'efforts de recherche ont été dépensés pour faire des >> réseaux informatiques et des protocoles qui permettent d'aller *plus >> vite*, d'attendre moins longtemps avant de voir la page d'accueil de >> TF1, le groupe de travail LEDBAT <http://tools.ietf.org/wg/ledbat> >> ("Low Extra Delay Background Transport ") de l'IETF travaillait à un >> tout autre projet : un protocole de transport de données qui aille >> *moins vite*, de façon à être un bon citoyen du réseau, à n'utiliser >> celui-ci que lorsqu'il est vide et qu'on peut donc faire passer ses >> bits sans gêner personnne. Ce RFC décrit l'*algorithme* LEDBAT, un >> algorithme « développement durable ». >> >> LEDBAT n'est donc pas un protocole complet, mais un algorithme de >> contrôle de la *fenêtre de congestion*, ce mécanisme par lequel les >> protocoles de transport évitent de saturer le réseau. Le plus connu et >> le plus utilisé de ces mécanismes est celui de TCP (RFC 5681) et ses >> objectifs sont d'utiliser le réseau à fond et d'assurer une relative >> égalité entre les flots de données qui se concurrencent sur ce réseau. >> LEDBAT, au contraire, vise avant tout à *céder* la place aux autre >> flots, non-LEDBAT. >> >> Mais pourquoi diable voudrait-on être si généreux ? Cela peut être >> parce qu'on estime les autres flots plus importants : si je télécharge >> Plus belle la vie pendant que je passe un coup de téléphone via SIP, je >> souhaite que le téléchargement ne prenne pas de capacité si SIP en a >> besoin (c'est la différence entre applications d'« arrière-plan » comme >> le transfert de gros fichiers et d'« avant-plan » comme un coup de >> téléphone ou une session SSH interactive). Ou bien cela peut être pour >> profiter de réductions offertes par le réseau : après tout, un routeur >> ou une fibre optique ne coûtent pas plus cher à l'usage, que les octets >> circulent ou pas (contrairement à un autoroute ou une voie ferrée). Il >> serait donc logique que les transports « charognards », comme LEDBAT, >> qui n'utilisent la capacité réseau que lorsque personne n'en veut, >> reçoivent une récompense financière, par exemple une réduction des prix >> (parlez-en à votre FAI). >> >> Pour les détails sur les motivations de LEDBAT et les raisons pour >> lesquelles des technqiues comme le "shaping" ne conviennent pas, voir >> le premier RFC du groupe LEDBAT, le RFC 6297. Ici, je vais me focaliser >> sur l'algorithme spécifié par LEDBAT et qui répond au cahier des >> charges : céder la place le plus vite possible. >> >> Le principe de cet algorithme est simple : utiliser les variations du >> temps de voyage des paquets pour détecter l'approche de la congestion >> et refermer alors la fenêtre de transmission. TCP utilise >> essentiellement le taux de pertes de paquets comme indicateur (ou les >> marques ECN du RFC 3168). Les routeurs ayant des tampons >> d'entrée-sortie, lorsque la ligne de sortie est saturée, les paquets >> commencent à s'entasser dans ce tampon. Lorsqu'il est plein, le routeur >> jette des paquets (et TCP va alors réagir). On voit que l'augmentation >> du temps de voyage (dû au séjour dans le tampon) *précède* la perte de >> paquets. En réagissant dès cette augmentation, LEDBAT atteint son >> objectif de céder la place à TCP. (À noter qu'il existe des variantes >> de TCP qui utilisent également le temps de voyage comme indicateur de >> l'approche de la congestion, par exemple TCP Vegas, documenté dans >> « "TCP Vegas: New techniques for congestion detection and avoidance >> <http://www.cs.umd.edu/class/spring2010/cmsc711/vegas.pdf>" » de >> Brakmo, L., O'Malley, S., et L. Peterson, mais voir le RFC 6297 pour un >> tour d'horizon général.) >> >> Où est-ce que LEDBAT va être mis en œuvre ? Cela peut être dans un >> protocole de transport, par exemple comme une extension de TCP, ou bien >> dans l'application. LEDBAT est un algorithme, pas un protocole précis. >> Il peut être utilisé dans plusieurs protocoles, du moment que ceux-ci >> permettent l'estampillage temporel des paquets, pour que les deux >> machines qui communiquent puissent mesurer le temps de voyage (section >> 4.1). >> >> La section 2 décrit l'algorithme exact. LEDBAT a une fenêtre de >> congestion, notée cwnd qui indique combien d'octets l'émetteur peut >> envoyer avant un nouvel accusé de réception. L'émetteur met dans chaque >> paquet le moment où il a envoyé ce paquet. Le récepteur regarde >> l'heure, en déduit le temps de voyage (aller simple, puisque >> l'encombrement n'est pas forcément le même dans les deux sens, une >> mesure aller-retour ne servirait pas à grand'chose) et retransmet cette >> indication à l'émetteur. Lorsque celui-ci voit le temps de voyage >> augmenter (signe que les tampons des routeurs se remplissent), il >> diminue la fenêtre de congestion. L'émetteur notamment utilise deux >> paramètres, TARGET et GAIN. TARGET est l'augmentation du temps de >> voyage en dessous de laquelle LEDBAT ne fait rien. GAIN (qui vaut entre >> 0 et 1) indique le facteur d'échelle entre l'augmmentation du temps de >> voyage et la réduction de la fenêtre de congestion. Plus il est élevé, >> plus LEDBAT réagit rapidement et vigoureusement. Un GAIN de 1 est >> équivalent à TCP Reno. À noter qu'on pourrait avoir deux valeurs de >> GAIN, une pour augmenter la fenêtre de congestion et une pour la >> diminuer. En mettant un GAIN plus grand pour la diminution de la >> fenêtre, on garantit que LEDBAT cédera très vite la place dès le plus >> petit signal d'un ralentissement. (Pour les amateurs de pseudo-code, >> une description de l'algorithme avec cette technique figure dans le >> RFC.) >> >> Bien sûr, le temps de voyage varie pour tout un tas de raisons et il >> n'est pas forcément souhaitable de refermer la fenêtre de congestion à >> chaque dérapage. LEDBAT filtre donc les "outliers" à l'aide d'une >> fonction FILTER() qui fait partie des paramètres de l'algorithme (elle >> n'est pas imposée par le RFC, on peut tester plusieurs mécanismes de >> filtrage des données.) Un filtre sommaire est NULL (aucun filtrage, on >> accepte toutes les mesures). Un autre plus sophistiqué est EWMA >> ("Exponentially-Weighted Moving Average"). Un bon filtre résiste au >> bruit inévitable, mais reste sensible aux signaux indiquant une vraie >> congestion. >> >> Le temps de voyage se décompose en temps de transmission sur le câble >> (qui dépend de la vitesse du médium, par exemple 100 Mb/s pour du Fast >> Ethernet), temps de propagation (lié à la vitesse de la lumière), temps >> d'attente dans les tampons et temps de traitement à la destination. >> Tous ces temps sont constants ou presque, à l'exception du temps >> d'attente dans les tampons. Ce sont donc ses variations qui déterminent >> l'essentiel des variations du temps de voyage. Pour estimer ce temps >> d'attente dans les tampons, LEDBAT calcule un *temps de base* (section >> 3.1.1) qui est le temps de voyage minimum observé. Il permet de >> connaître la valeur minimale en dessous de laquelle le temps de voyage >> ne pourra pas descendre. Les calculs de fenêtre de congestion se font à >> partir de (temps de voyage - temps de base), une grandeur qui part donc >> de zéro (les méthodes du RFC 6298 peuvent être utiles ici). >> L'algorithme de LEDBAT est linéaire : la fenêtre est réduite ou >> agrandie proportionnellement à cette grandeur, le facteur de >> proportionnalité étant le paramètre GAIN. Autre intérêt du concept de >> temps de base : en cas de changement de la route pendant la session >> (par exemple, panne d'un lien et re-routage par un chemin plus long), >> la mesure du temps de base pendant les N dernières secondes permettra >> de voir que le trajet a changé et que les calculs doivent utiliser le >> nouveau temps de base. (Le choix de N est un compromis : trop petit et >> le temps de base va varier souvent, trop grand et il retardera le >> moment où on détecte un changement de chemin.) >> >> Avec son mécanisme de réduction de la fenêtre de congestion dès que le >> temps de voyage augmente, LEDBAT ne pousse normalemeent jamais jusqu'au >> point où il y aura des pertes de paquets. Néanmoins, celles-ci peuvent >> quand même survenir, et LEDBAT doit alors se comporter comme TCP, en >> refermant la fenêtre (section 3.2.2). >> >> La section 4 du RFC discute ensuite de différents points intéressants >> de LEDBAT. Par exemple, LEDBAT est efficace pour céder rapidement à TCP >> lorsque celui-ci transfère de grandes quantités de données. Mais cela >> laisse le problème des applications qui envoient peu de données mais >> sont très sensibles à la latence, comme la voix sur IP. Si la >> conversation téléphonique envoie peu de données, il n'y aura jamais de >> remplissage des tampons, donc pas d'augmentation du temps d'attente >> dans ceux-ci donc LEDBAT se croira tranquille et enverra autant de >> données qu'il veut. Au moment où un des interlocuteurs parlera, ses >> paquets se trouveront donc peut-être coincés derrière un paquet LEDBAT. >> La seule protection contre ce problème est le paramètre TARGET qui ne >> doit donc pas être mis trop haut. La norme G.114 de l'UIT suggère 150 >> ms comme étant le maximum de retard tolérable pour le transport de la >> voix. LEDBAT doit donc choisir ses paramètres pour réagir avant les 150 >> ms. Le RFC recommande 100 ms pour le paramètre TARGET qui indique >> l'augmentation de délai de voyage à partir de laquelle LEDBAT réagit. >> (Ce paramètre TARGET détermine le temps maximal d'attente >> supplémentaire dû à LEDBAT.) >> >> Autre point subtil, la compétition entre flots LEDBAT. On sait que TCP >> assure la « justice » entre flots TCP : si trois flots sont en >> compétition, chacun aura un tiers de la capacité. LEDBAT, lui, cède à >> TCP. Si un flot LEDBAT et un flot TCP sont en compétition, TCP aura >> toute la capacité. Mais si deux flots LEDBAT parallèles se >> concurrencent ? L'algorithme de LEDBAT ne garantit *pas* de justice. En >> général, c'est le flot le plus récent qui va gagner : arrivant tard, >> dans un réseau déjà bien encombré, il mesure un temps de base très >> élevé et ne voit donc pas d'augmentation due au temps d'attente dans >> les tampons, et ne réduit donc pas sa fenêtre de congestion >> (« "Rethinking Low Extra Delay Background Transport Protocols >> <http://arxiv.org/abs/1010.5623>" » de Carofiglio, G., Muscariello, L., >> Rossi, D., Testa, C., et S. Valenti). Pour corriger cet effet, on ne >> peut compter que sur le bruit : de temps en temps, les tampons se >> videront, le temps de voyage diminuera, et le récent arrivé corrigera >> sa mauvaise estimation du temps de base. >> >> La section 5 du RFC considère les points qui sont encore ouverts à >> expérimentation. Après tout, un protocole comme LEDBAT est quelque >> chose de très nouveau dans le zoo de l'Internet. Par exemple, l'effet >> de changement de routes pendant une session LEDBAT, modifiant le temps >> de base, n'est pas encore vraiment bien connu. Quant à la valeur des >> paramètres comme TARGET ou GAIN, elle aura certainement besoin d'être >> ajustée à la lumière de l'utilisation réelle. Enfin, le filtre des >> mesures, qui permet d'éliminer les mesures jugées anormales, et évite >> donc à LEDBAT d'ajuster brusquement sa fenêtre de congestion pour rien, >> aura certainement besoin de réglages, lui aussi. >> >> Et la sécurité de LEDBAT ? La section 6 rappelle que, même si un >> attaquant arrive à tromper LEDBAT sur les valeurs du temps de voyage, >> dans le pire des cas, il ne pourra pas le faire se comporter de manière >> plus gloutonne que TCP. Par contre, il pourra faire une attaque par >> déni de service en lui faisant croire que le délai de voyage a augmenté >> et que LEDBAT devrait ralentir. Pour l'instant, il n'y a pas de >> mécanisme contre cela. >> >> Le bon fonctionnement de LEDBAT dépend de bonnes mesures. Les fanas de >> métrologie seront donc ravis de l'annexe A, qui parle des causes >> d'erreur dans les mesures. Le principal problème est que, pour mesurer >> les temps de voyage aller-simple dont a besoin LEDBAT, il faut des >> horloges à peu près synchronisées. Si l'émetteur met dans le paquet une >> heure de départ à 13 heures, 37 minutes et 56,789 secondes, que le >> récepteur mesure une arrivée à 13 heures, 37 minutes et 57,123 secondes >> et que le récepteur a 0,5 secondes de retard sur l'émetteur, il >> mesurera un temps de voyage de 0,334 secondes (alors qu'il est en fait >> de 0,834 secondes). Reprenant le vocabulaire de NTP (RFC 5905), on peut >> dire qu'il y a deux sources de problèmes, l'*écart* des horloges par >> rapport à une référence et le *décalage* (la variation de l'écart). >> L'écart entraine une erreur fixe dans la mesure du temps (comme dans >> notre exemple ci-dessus). Mais LEDBAT n'utilise pas directement le >> temps mais la différence entre temps actuel et temps de base. Cette >> erreur s'annule donc et l'écart des horloges par rapport au temps >> correct n'est donc pas importante pour LEDBAT. >> >> Plus embêtant est le décalage puisque lui ne s'annulera pas. Si >> l'horloge du récepteur bat plus vite que celle de l'émetteur, il aura >> toujours l'impression d'un réseau très encombré, puisque ses mesures de >> temps de voyage seront toujours supérieures au temps de base qu'il >> avait mesuré avant. Heureusement, alors que des écarts énormes sont >> souvent vus sur l'Internet (il est fréquent de voir plusieurs minutes, >> voire plusieurs heures de différence entre une machine et le temps >> UTC), les décalages sont typiquement bien plus petits. Les mesures >> citées par le RFC 5905 indiquent des décalages courants de 100 à 200 >> ppm, soit 6 à 12 ms d'erreur accumulée par minute. Comme une machine >> LEDBAT limite sa mémoire (paramètre BASE_HISTORY, pour lequel le RFC >> recommande actuellement une valeur de dix minutes), et n'utilise donc >> que des mesures récentes pour évaluer le temps de base, le problème >> reste donc limité. >> >> Si malgré tout, le problème se pose, il n'affectera que le cas où le >> récepteur a une horloge plus rapide, et en déduira donc à tort qu'il >> doit ralentir. Dans le cas inverse (horloge du récepteur plus lente), >> l'émetteur aura simplement l'impression que le temps de base augmente. >> >> Pour corriger ce problème de décalage, on peut imaginer d'envoyer les >> estampilles temporelles dans les deux sens, pour que chaque machine >> puisse calculer ce que devrait voir l'autre, pour pouvoir détecter >> qu'un pair a une mauvaise mesure. Ensuite, l'émetteur pourrait corriger >> ses propres calculs por s'adapter à ce récepteur erroné. Il peut même >> calculer si le décalage est constant (horloge battant trop vite ou trop >> lentement, mais à une fréquence constante). >> >> Et question mises en œuvre effectives ? LEDBAT a été testé dans des >> logiciels comme uTorrent Transport Protocol library >> <http://github.com/bittorrent/libutp>. Il est l'algorithme utilisé par >> le microTP de BitTorrent (voir la documentation officielle de µTP >> <http://www.utorrent.com/help/documentation/utp>). >> >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
