Mon blog

À la réunion IETF 72 de Dublin, la création du groupe de travail nommé ALTO pour Application Layer Traffic Optimisation n'est pas allée de soi et ne semble pas garantie.

À quoi sert ALTO ? La majorité du trafic sur Internet est aujourd'hui consacrée aux services pair-à-pair. Ces services remettent en cause bien des suppositions sur lesquelles avait été architecturé le réseau. Ils consomment autant de trafic montant que de descendant (contrairement à des systèmes asymétriques comme le Minitel ou l'ADSL), ils sont bavards, et imprévisibles. Il n'est donc pas étonnant que ces services se retrouvent souvent dans les médias comme à l'occasion du piratage des sessions BitTorrent par Comcast.

Tous ces points sont résumés dans l'expression du problème, l'Internet-Draft, draft-marocco-alto-problem-statement. À l'atelier P2P infrastructure workshop de l'IETF le 29 mai 2008 à Boston (dont le compte-rendu figure dans le RFC 5594), plusieurs mesures ont été étudiées, par exemple de meilleurs systèmes de contrôle de la congestion, mais aussi des mesures visant à améliorer la localité, mesures qui mènent à ALTO.

En effet, contrairement au client/serveur, pour lequel on cherche à accéder à une machine (et on ne peut optimiser que le chemin qui y mène), le pair-à-pair concerne l'accès à une ressource. On peut alors chercher un exemplaire de cette ressource qui soit plus proche. ALTO peut donc se résumer à « Quand on est à Dublin, télécharger le fichier à partir d'un pair à Londres plutôt qu'à Tokyo ».

Les machines terminales, celles des utilisateurs, ne sont pas forcément les mieux placées pour sélectionner les « meilleurs » pairs (notons que la définition de « meilleur » est un des sujets les plus chauds dans les discussions sur ALTO). Par exemple, elles n'ont aucune idée des coûts, de quels liens sont du transit cher et desquels sont du peering gratuit. ALTO repose donc sur un système d'« oracle » où le pair demande au serveur ALTO (l'oracle) de lui indiquer les meilleures solutions. Le futur protocole conçu par le futur groupe ALTO ne gérera que l'interface entre le client ALTO (le pair) et le serveur ALTO (l'oracle). Comment l'oracle prend sa décision est hors-sujet pour ALTO. L'oracle a pu utiliser les ICS, Meridian, un flux BGP ou un ensemble de préférences configurées manuellement, par exemple par le FAI.

Ça, c'était le principe. Maintenant, il y a les difficultés pratiques. Par exemple :

• Est-ce que l'oracle doit donner des informations sur la topologie du réseau ou bien juste indiquer quel(s) pair(s) choisir ? Les opérateurs ne sont pas très chauds pour la première solution, car ils ne souhaitent pas distribuer d'informations sur leur réseau.
• Comment le client ALTO trouve t-il l'oracle ?
• Et la question qui ravira les fans de Matrix : le client peut-il faire confiance à l'oracle ? La question n'est pas purement théorique vu le nombre de FAI qui mentent délibérement à leurs clients (par exemple en réécrivant les réponses DNS).

Une fois le problème posé, quelles sont les solutions actuelles ? (Elles sont décrites dans un Internet-Draft, draft-hilt-alto-survey.) Il y a en gros deux catégories :

• Les cas où c'est l'application qui cherche le meilleur pair, par exemple par des ping brutaux vers un ensemble de pairs potentiels (ce qui consomme beaucoup de ressources et ne supporte pas le passage à l'échelle) ou bien par des techniques plus intelligentes comme les ICS.
• Les cas où c'est le réseau qui décide, ce qui est l'idée de base du projet P4P (une expérience P4P a été décrite dans le RFC 5632). ALTO fonctionnera ainsi, l'oracle pouvant utiliser des techniques comme ICS pour récupérer l'information qu'il servira à ses clients.

Naturellement, une des principales motivations pour ALTO est financière, d'où l'amusant exposé de Henning Schulzrinne (par ailleurs auteur de SIP) à Dublin à propos de l'économie de l'Internet. Compte-tenu du caractère fongible qu'à aujourd'hui la capacité des accès Internet, on peut calculer, par exemple, que l'envoi du contenu d'un DVD coûte aujourd'hui 1,05 $ US, uniquement en bande passante. Schulzrinne suggérait de signaler ces coûts à l'utilisateur par exemple « Do you want to watch the movie now (4$) or wait until night (2.5$)? ».

Enfin, le dernier document important dans l'état actuel du développement d'ALTO est le cahier des charges (Internet-Draft draft-kiesel-alto-reqs) que Sebastian Kiesel a présenté à Dublin. ALTO doit, selon ce document :

• Se concentrer sur le protocole entre le client ALTO et le serveur ALTO (les mécanismes, par exemple, de synchronisation des informations entre serveurs ALTO étant ainsi exclus),
• Ne pas mettre tous ses œufs dans le même panier. ALTO ne va pas résoudre tous les problèmes seuls et il est également nécessaire de réagir proprement à la congestion... et de se débrouiller correctement si, pour une raison ou une autre, ALTO n'est pas disponible.

La question délicate des informations que le client ALTO envoie au serveur ALTO n'est pas réglée. Il serait intéressant pour le serveur, afin de prendre une meilleure décision, que le client donne le plus de détails possibles (« Je compte télécharger le dernier album de Carla Bruni, au format zip, soit 631 méga-octets ») mais cela soulève évidemment bien des questions liées à la protection de la vie privée. La plupart des clients ne voudraient pas avouer le nom des ressources qu'ils téléchargent. Même la simple indication de la taille de la ressource pourrait donner trop d'indications à un oracle indiscret.

Il n'existe pas encore de documents sur le protocole lui-même.

C'est dans ce contexte que s'est tenu la réunion de l'IETF à Dublin le 29 juillet. Cette réunion avait le titre de BoF (Birds of a Feather, réunion informelle) puisque le groupe de travail n'est pas encore constitué. Ce fut un grand succès, avec plus de 150 personnes et un agenda chargé. Après les exposés résumés ci-dessus, une importante discussion porta sur la future charte du futur groupe de travail. Plusieurs questions ne posaient pas réellement de problème comme le fait que les questions de légalité du contenu seraient jugées hors-sujet. Les serveurs ALTO ne serviront donc pas à mettre en œuvre les desiderata de Sony ou d'Universal.

Une discussion très technique sur les caches suscita plus d'intérêt mais, gloalement, aucune objection à la charte ou au groupe de travail n'a été soulevée pendant la réunion.

C'est pourquoi ce fut une surprise pour beaucoup de voir une opposition apparaître au moment du « hum ». Le hum est une institution IETF, permettant d'indiquer une préférence, de manière non publique. Il consiste simplement à faire du bruit sans ouvrir la bouche. Le « hum » montra une salle partagée moitié-moitié. Il n'y a donc pas de consensus.

Quel était le problème ? Lisa Dusseault, Area Director (directrice de l'activité Applications à l'IETF), demanda si le problème était jugé inintéressant ? Insoluble ? Ou bien que la solution proposée risquait d'être dangereuse ?

Contrastant avec le silence pendant la réunion (timidité ?), la liste de diffusion ALTO a vu une longue discussion s'ensuivre. Une des objections les plus fréquentes était que les intérêts des utilisateurs et des FAI étaient différents, voire opposés, et qu'il n'y avait aucune chance qu'un oracle géré par le FAI puisse donner des réponses utiles aux utilisateurs.

Une objection plus technique était que le projet de charte ne restreignait pas assez l'ensemble des questions qui pouvaient être posées à l'oracle.

Enfin, encore plus politique, certains craignaient que, une fois déployés, les oracles deviennent plus ou moins obligatoires et qu'il ne soit plus possible à un pair d'un réseau pair-à-pair de ne pas obéir aux « suggestions » de l'oracle...

Finalement, l'IESG a approuvé la création du groupe le 12 novembre, avec une charte modifiée, qui cadre mieux ce que ALTO pourra faire ou ne pas faire, et un calendrier qui prévoit que l'essentiel du travail devra être terminé fin 2009. Le premier RFC a déjà été publié, le RFC 5693.