Mon blog

Beaucoup de FAI se demandent comment limiter la charge qui provient de l'intense activité pair-à-pair de leurs clients. Les plus bas de front tentent l'interdiction (comme dans les conditions générales d'utilisation de SFR pour certaines de ses offres Internet mobile, où le pair-à-pair est explicitement interdit), d'autres cherchent des solutions techniques. L'une de ces solutions, P4P, qui permet au FAI d'informer les logiciels pair-à-pair de la topologie de son réseau, dans l'espoir qu'ils choisiront des pairs plus proches, est activement promue par certaines entreprises comme Pando. Comcast, un gros FAI, a testé P4P pour nous et en fait le compte-rendu dans ce RFC.

Ce gros FAI états-unien connecte essentiellement des particuliers, par le câble. Comcast est un des participants au groupe de travail qui élabore P4P. Le principe du système P4P (Proactive network Provider Participation for P2P) est de déployer des iTrackers qui sont des serveurs informant les clients pair-à-pair de la topologie du réseau, quels sont les liens recommandés, quelles adresses IP sont externes ou internes au dit réseau, etc (section 1 du RFC). Le logiciel peut alors choisir le pair le plus proche, économisant ainsi les ressources.

P4P a été discuté dans des forums comme le IETF workshop on P2P Infrastructure (raconté dans le RFC 5594) ou à la BoF Alto de l'IETF. Le test en vrai grandeur dont notre RFC 5632 rend compte a eu lieu en juillet 2008.

La section 2 du RFC résume le principe du test. Cinq essaims de machines, avec des iTrackers programmés différemment à chaque fois, participaient. Les statistiques étaient enregistrées par chaque client puis rassemblées. Témoignage de la puissance du pair-à-pair, le seeder (la machine qui avait le contenu original) n'a envoyé que dix copies alors qu'il y a eu un million de téléchargements.

Quels étaient les différents types de iTrackers utilisé ? Si, dans le premier essaim, les pairs étaient choisis au hasard, les autres utilisaient les politiques suivantes :

• Grain fin (section 3.1). De loin le plus complexe à configurer, ce iTracker avait toute l'information sur le réseau de Comcast, incluant tous les liens avec l'extérieur. Non seulement l'élaboration et la mise à jour de sa configuration étaient très complexes (le fichier faisait plus de cent mille lignes) mais cet iTracker est très indiscret, permettant aux clients de récupérer une information que le FAI n'a pas forcément envie de livrer.
• Gros grain (section 3.2). Présentant une vue moins précise du réseau (notamment de ses connexions externes), cet iTracker ne faisait plus que mille lignes et surtout (du point de vue de Comcast) était plus discret.
• Pondéré génériquement (section 3.3). Identique au iTracker à gros grain, sauf que les poids attribués aux différents liens étaient définis par une autre équipe.

Qu'est-ce que ça a donné ? La section 4 résume les résultats (mais il faut aussi lire la section 5, qui détaille les pièges d'interprétation possibles) : chaque essaim de machines a réalisé environ 25 000 téléchargements par jour. Le plus gros essaim a atteint une taille de 11 700 machines. Les iTrackers à grain fin ou à gros grain ont vu leur débit de téléchargement (section 4.2) augmenter de 13 % (en moyenne) mais de 57 à 82 % pour les machines de Comcast, qui avaient le plus d'informations. Et la politique à gros grain s'est montrée plus efficace que celle à grain fin, contrairement à ce qu'on aurait pu attendre.

La section 4.2 donnait les résultats individuels, l'amélioration pour une machine qui télécharge. Mais pour le FAI, quel était le résultat ? La section 4.3 les résume : le trafic sortant de Comcast a diminué de 34 %, l'entrant vers Comcast de 80 %. À noter également qu'il y a d'avantage d'annulations (l'utilisateur s'impatiente et arrête le téléchargement) avec le premier essaim, celui qui n'utilisait pas P4P. Il est possible que les débits plus faibles entrainent davantage de découragement et donc d'annulation. En tout cas, le trafic à l'intérieur de Comcast augmente avec P4P : quand ça marche, les utilisateurs s'en servent plus.

La section 6 formule donc une conclusion relativement optimiste et recommande que l'IETF considère sérieusement P4P dans le cadre du groupe de travail Alto.