Le Tue, 24 Nov 2009 08:25:59 +0000, Thomas Mangin <[email protected]> a écrit :
> > Oula... Si je doutes pas que les systèmes ouverts (le vrai avec de > > la bière en carburant pour coder) auront le support du re-ecn dans > > très peut de temps (comme ça avais déjà été fait avec l'ecn), je > > doute que les OS avec des fenêtres colorées l'aurons et encore > > moins que le park actuel et futur auront cette option rapidement. > > Quid des Fenêtres avec l'eXPérience dedans, ou celle de la Vie ou > > encore celles numéro 7... ? > > Je suis d'accord, je passais les slides car autant que je sache le > nouveau protocol BT utilise le même principe avec la latence (il y a > eu du buffering -> le lien est sature, et packet loss -> le buffer > est plein et perds des packets) comme moyen de detection (je n'ai pas > encore lu les specs du protocole) Çà doit pas être tout a fait çà l'heuristique, parce que çà ne peut marcher que si les RX et TX queue font du tail dropping. Ceci dit, l'idée de changer la 'queuing policy' sur des critères de congestion avérée (re-ecn ou pas) est pas débile. J'ai juste un doute sur le niveau sur lequel c'est le plus souhaitable. Le travail de l'IETF sur DCCP mérite également un coup d'œil (Ils ont carrément pris le point de vue : les protos existants sont trop mal foutus pour gérer la congestion proprement, on va en faire un qui va le faire nativement et proprement : http://www.ietf.org/rfc/rfc4336.txt). Les mécanismes proposés (enfin certains) peuvent être codé au niveau application. a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
pgpyTHS598ssN.pgp
Description: PGP signature
