Première rédaction de cet article le 25 novembre 2009
D'innombrables électrons ont déjà été agités pour discuter de l'architecture actuelle du routage sur l'Internet et des conséquences du multi-homing. La plupart de ces discussions portaient plutôt sur l'aspect technique. Voici un article de mai 2009 qui discute de l'aspect économique.
L'article « Internet Multi-Homing Problems: Explanations from Economics », de Richard Clayton (université de Cambridge) prend la question du multi-homing (qu'il appelle le « problème » du multi-homing, ce qui montre qu'il avait déjà une idée derrière la tête) en évaluant le coût, pour l'infrastructure globale de l'Internet, d'une annonce BGP supplémentaire, due au fait qu'un réseau devient multi-homé. L'article expose d'abord en détail et de maniètre très claire et très correcte le fonctionnement du routage (il cite des documents utiles comme le RFC 4116 ou le RFC 3582). Puis il passe aux applications numériques.
L'auteur (je résume son calcul) arrive à un coût total de l'infrastructure de routage de 23 milliards de dollars US (en additionnant le coût de tous les routeurs de tous les opérateurs). En divisant par le nombre de préfixes annoncés en BGP (près de 300 000), il arrive à 77 000 $ par préfixe. Ce coût est porté par tous les opérateurs de l'Internet et pas par le réseau multi-homé. Une décision locale, par les administrateurs du réseau multi-homé aura donc eu des conséquences globales. L'auteur ne fait donc pas preuve d'originalité en citant pour la millionième fois l'article de Hardin sur la tragédie des biens communs (article presque toujours cité à tort).
En économiste traditionnel, l'auteur demande donc la mise à l'étude d'un mécanisme de paiement permettant de récupérer cet argent auprès du réseau multi-homé. Il ne mentionne guère une autre approche, qui serait de modifier l'architecture de l'Internet (par exemple par une séparation de l'identificateur et du localisateur) pour rendre le multi-homing moins coûteux (seul SHIM6 (RFC 5533) est sérieusement cité, HIP (RFC 7401) est éliminé sans explication).
Une autre idée originale est de demander que l'IETF aie une section Economic Considerations obligatoire dans ses RFC comme c'est déjà le cas pour la sécurité, avec les obligations du RFC 3552. Mais l'IETF, bien qu'ayant souvent discuté de cette approche, a toujours refusé de prendre en compte les questions économiques. Deux raisons à cela : l'IETF n'a pas de compétence particulière dans ce domaine et les questions économiques sont très différentes des questions techniques. On ne peut pas changer la vitesse de la lumière alors que les « lois » économiques sont le résultat de décisions politiques, qui peuvent changer.
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)