http://www.bortzmeyer.org/6789.html
---------------------------- Auteur(s) du RFC: B. Briscoe (BT), R. Woundy (Comcast), A. Cooper (CDT) ---------------------------- Premier RFC du groupe de travail CONEX <http://tools.ietf.org/wg/conex> de l'IETF, ce documentt expose les principes de bases du m�canisme de ��publication de la congestion�� ("CONgestion EXposure"). L'id�e est d'indiquer dans les paquets la congestion pr�vue, pour que les �quipements r�seaux puissent prendre des d�cisions appropri�es. Une fois normalis�e (ce RFC 6789 n'est qu'une toute premi�re �tape), ce sera une des nombreuses techniques permettant de g�rer la congestion dans les r�seaux TCP/IP et notamment l'Internet. Il n'y a pas encore de protocole normalis� pour cette ��publication de la congestion�� (les deux premiers utiliseront une option IPv6 et une option de TCP). Pour l'instant, notre RFC s'en tient � des usages�: � quoi cela pourrait servir. La congestion est clairement une des plaies du r�seau. La force de TCP/IP est de multiplexer la capacit� des liens au niveau des paquets et pas des circuits. Cela permet une utilisation bien plus efficace du r�seau. Mais cela ne cr�e pas magiquement de la capacit��: quand trop de paquets rencontrent trop peu de capacit�, la congestion survient. Elle se manifeste par des pertes de paquets (le routeur, n'arrivant pas � suivre, abandonne certains paquets), mais aussi par des retards (si les tampons du routeur amortissent la congestion, ils augmentent les d�lais d'acheminement), et par le marquage ECN (RFC 3168) de certains paquets. Le r�cepteur des donn�es est cens� d�tecter ces signaux (un trou dans la s�quence TCP, des RTT qui augmentent, les marques ECN) et il doit alors dire � l'�metteur de ralentir. Ce fonctionnement o� seules les machines terminales agissent (les routeurs interm�diaires, � part �ventuellement des marques ECN, n'ont pas grand'chose � faire, ils se contentent de router) est typique de l'Internet mais, dans certains cas, expos�s dans ce RFC, il est insuffisant. L'id�e de base de ConEx est que l'�metteur mette dans les paquet IP qu'il envoie des indications sur la congestion qu'on lui a signal�. Ainsi, des �quipements qui sont purement de niveau 3 sur le trajet peuvent �tre inform�s de la congestion (ECN les informe aussi mais ne concerne que les �quipements en *aval* du point o� est d�tect�e la congestion, cf. figure 1 du RFC). Ainsi, le r�seau pourra avoir une meilleure vision de la congestion, comptant les paquets qui vont rencontrer de la congestion aussi facilement qu'il compte aujourd'hui les paquets ou les octets. Pourquoi est-ce important de conna�tre les paquets qui vont circuler dans des parties du r�seau o� il y a congestion�? D�j�, cela a une importance �conomique�: un r�seau ne co�te pas plus cher qu'il soit utilis� ou pas. Un trafic qui emprunte le r�seau � un moment o� celui-ci est peu charg� ne co�te donc rien � l'op�rateur du r�seau. Par contre, la congestion co�te cher puisqu'elle est le signe qu'il faut sortir son carnet de ch�ques pour mettre � jour le r�seau, vers des capacit�s plus grandes. Ainsi, ConEx pourrait �tre une brique de base pour un syst�me qui p�naliserait uniquement les flots de donn�es qui contribuent � la congestion. La section 2 pr�sente en d�tail les concepts et la terminologie ConEx. D'abord, �videmment, la *congestion*. Tout le monde en parle mais il n'y a pas de d�finition rigoureuse et unique pour ce concept. Pour une analyse de ce terme, voir ��"The Evolution of Internet Congestion <http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_2009.pdf>"�� de S. Bauer, S., D. Clark et W. Lehr. Dans ConEx, la congestion est d�finie comme la probabilit� de perte de paquet (ou de marquage par ECN). Un autre effet de la congestion, le retard, n'est pas pris en compte (donc, ConEx ne mesurera pas l'effet du "bufferbloat"). Deuxi�me concept, le *volume de congestion*. Il s'agit du nombre d'octets perdus suite � la congestion. L'id�e est de rendre les �metteurs responsables�: envoyer 10 Go sur un lien congestionn� n'est pas la m�me chose que d'y envoyer quelques octets. Par exemple, si Alice envoie un fichier d'un Go sur un lien o� la probabilit� de perte est de 0,2�%, son volume de congestion est de 2 Mo. Si, plus tard dans la journ�e, elle envoie un fichier de 30 Go alors que la ligne, moins encombr�e, ne perd plus que 0,1�% des paquets, elle ajoutera 3 Mo � son volume de congestion (donc, 5 Mo en tout). L'un des int�r�ts de cette m�trique est qu'elle est tr�s facilement mesurable par un routeur�: il lui suffit de compter le volume total des paquets qu'il a d� jeter (ou marquer avec ECN, s'il utilise cette technique). C'est donc quasiment la m�me chose que les compteurs de volume actuels. Troisi�me concept important, la *congestion aval* ("Rest-of-path congestion" ou "downstream congestion" dans la langue de Van Jacobson). C'est celle que le flot de donn�es va supporter entre le point de mesure et sa destination (la congestion amont �tant �videmment celle entre la source et le point de mesure�: aujourd'hui, elle est bien plus difficile � mesurer si on n'utilise pas ECN). La section 3 d�crit ensuite le principal sc�nario d'usage envisag� pour ConEx. Si vous vous demandez ��mais � quoi sert ce truc�?�� depuis tout � l'heure, vous allez bient�t avoir une r�ponse. Soit un op�rateur r�seau qui a des clients. La plupart consomment peu mais certains sont des acharn�s et font passer en permanence des gigaoctets � travers le r�seau. L'op�rateur voudrait que les mesures d�sagr�ables qu'il va prendre pour limiter la congestion frappent en priorit� ces gros consommateurs. Il va pour cela placer un �quipement qui regarde les indications de congestion ConEx et va ensuite limiter le trafic en fonction de ces indications (en fonction du volume de congestion). (Les limitations de trafic habituelles visent le d�bit, pas la participation � la congestion. Or comme on l'a vu, d�biter 100 Mb/s sur un r�seau vide n'est pas du tout la m�me chose que de le d�biter sur un r�seau charg�. Il est donc dommage de limiter le d�bit dans tous les cas.) L'article ��"Policing Freedom to Use the Internet Resource Pool <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.159.7151&rep=r ep1&type=pdf>"�� de B. Briscoe, A. Jacquet et T. Moncaster, d�taille ce m�canisme. La force de cette m�thode est qu'aucune limite, aucune mesure contraignante et d�sagr�able, n'est prise lorsqu'il n'y a pas de congestion (car, dans ce cas, l'usage du r�sau ne co�te rien). Avec ConEx, un bit n'est plus �gal � un bit�: celui envoy� pendant la congestion co�te plus cher au r�seau et doit donc, d'une certaine fa�on, �tre ��pay頻 par l'utilisateur. Si l'op�rateur est un FAI ADSL, un bon endroit pour mettre cette supervision de la congestion et cette limitation du trafic est sans doute le BRAS. (Voir le rapport du DSL Forum ��"Technical Report TR-059: Requirements for the Support of QoS-Enabled IP Services"�� mais il ne semble pas en ligne.) Ainsi, les utilisateurs seront encourag�s � utiliser des protocoles que notre RFC appelle ��charognards�� dans la mesure o� ils n'utilisent que la capacit� dont personne ne veut (le charognard a une mauvaise image de marque mais c'est bien � tort�: il consomme les ressources n�glig�es par tous les autres). Ces protocoles n'envoient du trafic que lorsque le r�seau est inutilis�. Leur co�t est donc � peu pr�s nul pour l'op�rateur. Le RFC 6297 d�crit ces protocoles. Pour encourager leur usage, on ne peut pas seulement compter sur des exhortations citoyennes, dont l'�cologie montre le peu d'efficacit�. Il faut aussi des motivations plus pratiques. Mais il existe d'autres approches, d�j�, pour ce genre de gestion (ralentir les gros consommateurs, ceux qui sortent franchement du rang), non�? La section 3.3 les examine�: * On l'a vu, il est courant de limiter le d�bit, ou bien d'imposer un total de donn�es transf�r� maximum (cette derni�re technique est courante en 3G). Cette approche est tr�s grossi�re car elle m�ne � sous-utiliser ou sur-utiliser le r�seau. S'il n'y a pas de congestion, on va sous-utiliser le r�seau, alors qu'il est libre (pire, on d�courage l'utilisation de protocoles ��charognards�� puisque leur utilisateur serait p�nalis� pour le volume envoy�, au lieu d'�tre r�compens� pour le soin qu'il met � ne l'envoyer qu'en l'absence de congestion). S'il y a congestion, on risque de sur-utiliser le r�seau car, tant que le quota n'est pas atteint, l'utilisateur n'a pas de raison de se g�ner. * Les techniques de "fair queuing" visent � �galiser le trafic entre les diff�rents utilisateurs. Agissant en temps r�el et n'ayant pas de m�moire, elles favorisent, sur le long terme, les plus gros consommateurs alors qu'on voudrait le contraire. * Plus subtile, la technique d�crite dans le RFC 6057 ne mesure le d�bit que lorsqu'il y a congestion et donc effectivement g�ne pour le r�seau. Mais, lors de la congestion, tout le trafic est compt� comme y contribuant et cette technique, comme les deux pr�c�dentes, n'encourage absolument pas � utiliser les protocoles ��charognards��. * Derni�re m�thode possible, un examen plus ou moins pouss� du paquet (allant jusqu'� la DPI) pour d�cider quelle est l'application utilis�e, suivi d'une d�gradation du service pour cette application particuli�re (par exemple BitTorrent). Elle est �videmment incompatible avec des techniques de s�curit� comme IPsec et elle soul�ve de s�rieuses questions politiques <http://www.bortzmeyer.org/neutralite.html>. ConEx, lui, est neutre par rapport � l'application utilis�e. Toutes ces solutions ont un autre d�faut en commun�: elles laissent l'utilisateur dans l'incertitude des performances qu'il obtiendra. Le principal int�r�t des tarifs forfaitaires pour l'acc�s Internet (je parle des vrais forfaits, ceux o� le prix est connu d'avance, pas de ce que les commerciaux menteurs de la t�l�phonie mobile appelent ��forfait��) est la certitude�: pas de mauvaises surprises au moment de l'arriv�e de la facture. Mais cette certitude ne porte que sur les prix. Les performances, elles, peuvent varier, par exemple si le trafic �mis �tait tel qu'on est d�sormais limit�. Au contraire, avec Conex, l'utilisateur est en mesure de voir sa propre contribution � la congestion, et peut ajuster son comportement en fonction de cela. (� mon avis, c'est une vision un peu id�ale, car elle suppose que le r�seau n'agit sur les performances qu'en r�ponse aux indicateurs ConEx.) Ce sc�nario d'usage de la section 3, informer l'op�rateur sur la contribution des utilisateurs � la congestion, est le principal but de ConEx � l'heure actuelle. Les versions initiales de ce RFC traitaient sur un pied d'�galit� plusieurs sc�narios mais le groupe de travail, apr�s bien des discussions, a d�cid� de prioritiser celui qui semblait le plus prometteur. Ceci dit, la section 4 pr�sente quelques autres cas d'usage�: * Mesurer la contribution � la congestion non pas par utilisateur mais par op�rateur. Comme les indicateurs ConEx sont vus par tous les routeurs interm�diaires (y compris les routeurs de bordure entre op�rateurs), chaque op�rateur peut savoir ce que chacun de ses voisins va lui apporter comme congestion (et r�ciproquement). De beaux d�bats sur la r�partition des investissements � pr�voir�! * Avoir de meilleures indications sur l'utilisation globale du r�seau, pour mieux planifier l'avitaillement ("provisioning") en capacit�. La section 5 se penche ensuite sur le d�ploiement de ConEx. Ce syst�me ne n�cessite pas un accord simultan� de tous les acteurs (heureusement). ConEx est donc utile m�me si certains routeurs du trajet ne marquent pas et m�me si certains ne lisent pas l'information ConEx. Par contre, il faut qu'au moins deux acteurs bougent�: au moins un routeur doit marquer les paquets et au moins une machine doit r�agir et signaler la congestion dans les paquets qu'elle �met. Les d�veloppeurs d'une application Ledbat (voir RFC 6297), par exemple, peuvent se lancer en esp�rant que cela motivera les routeurs pour s'y mettre. Si certains paquets sont marqu�s par ConEx et d'autres non, que va faire le routeur�? Pour le d�ploiement de ConEx, il serait pr�f�rable que les paquets marqu�s soient favoris�s d'une mani�re ou d'une autre. Mais comme la raison du marquage est leur contribution � la congestion, ce n'est pas forc�ment id�al... En outre, cela soul�ve un probl�me de s�curit� (le marquage n'est pas authentifi� et une machine peut mentir) sur lequel ce RFC 6789 est compl�tement muet (le probl�me sera trait� dans les futurs RFC, plus concrets). Comme ConEx va tripoter dans la couche 3, cœur de l'Internet, il risque de perturber le fonctionnement d'IP. Il faut donc consid�rer ConEx comme plut�t exp�rimental et la section 6 fait la liste des questions encore ouvertes, par exemple�: * ConEx est actuellement limit� � IPv6, l'id�e est que le d�lai de d�ploiement sera de toute fa�on tel qu'IPv6 sera largement dominant lorsque ConEx sera g�n�ralis�. �tait-ce une bonne id�e�? * ConEx ne fait pas de diff�rence entre l'auto-congestion (un utilisateur qui se g�ne lui-m�me) et la congestion inflig�e aux autres (lorsqu'on encombre des ressources partag�es). Moralement, il serait int�ressant de s�parer les deux mais n'est-ce pas trop complexe�? * ConEx est plus ambitieux qu'ECN et s'appuie sur lui. Mais le d�ploiement d'ECN est tr�s limit�. Est-ce que ConEx sera quand m�me utile si le d�ploiement d'ECN en reste o� il est maintenant�? --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
