Résumé

  • La RFC 1272 estimait que les adresses IP des extrémités ne permettaient pas à un fournisseur de savoir quel domaine administratif voisin avait transporté le trafic au-delà de sa frontière.
  • Des compteurs placés aux frontières pouvaient faciliter le rapprochement des comptes, mais le niveau utile dépendait de la topologie, de la granularité, du stockage, du coût de collecte et de la sécurité.
  • Le mémo distinguait le signalement d’usage de la facturation et de l’application des règles, et laissait ouverte la question du comptage à l’entrée ou à la sortie du routeur.

Le nom manquant était celui du voisin

Un paquet IP contient une adresse source et une adresse de destination. On peut donc compter les échanges entre extrémités, mais ces champs ne disent pas à eux seuls quel réseau voisin a fait entrer le paquet dans le domaine d’un fournisseur. Si le trafic d’un même système final peut arriver par plusieurs domaines adjacents, connaître les extrémités ne répond pas à la question plus précise du fournisseur : quel réseau a franchi ma frontière avec ce trafic ?

La RFC 1272 ne cherchait pas à faire comptabiliser par chaque réseau l’usage de tous les internautes. Son modèle se concentrait sur le domaine propre à une administration et sur les domaines voisins directement connectés. Un fournisseur pouvait mesurer le trafic qui traversait sa frontière avec un voisin et échanger un relevé avec lui. Si ce voisin devait répartir ses propres coûts plus loin dans la chaîne, cela relevait de sa responsabilité. Le modèle était récursif : chaque administration rendait compte de la relation qu’elle pouvait observer, sans prétendre détenir une vue globale de l’utilisateur final.

Cette distinction change l’endroit où le compteur est utile. Un hôte observe le trafic à l’extrémité. Un routeur placé à une frontière voit le trafic qui entre dans le domaine local ou en sort et peut fournir des éléments sur une interconnexion adjacente. Le mémo précisait que les en-têtes IP ne contenaient pas à eux seuls l’identité de ce système intermédiaire ; des informations de couche inférieure ou la configuration des équipements de frontière pouvaient être nécessaires. Les adresses aux extrémités et la frontière comptable répondaient à des questions différentes.

La mesure avait son propre coût

L’emplacement du compteur n’était qu’un choix parmi d’autres. La RFC 1272 décrivait des moniteurs dédiés, des compteurs de ligne, des logiciels de mesure intégrés aux routeurs et des ensembles coordonnés de « router spiders ». L’emplacement pratique dépendait de la topologie et du service mesuré. La frontière pouvait aider fournisseur et client à confronter leurs relevés, mais le texte ne prescrivait pas d’instrumenter chaque routeur.

Le mémo traitait le niveau de détail comme une décision technique et économique. Un compteur pouvait dénombrer par port, réseau ou hôte, ajouter des attributs de paquets, conserver des compteurs ou des horodatages et transmettre ses données à des intervalles différents. Chaque combinaison d’entité et d’attribut pouvait demander un enregistrement de flux supplémentaire. Plus de granularité mobilise davantage de mémoire et de traitement ; des rapports plus fréquents consomment bande passante et capacité du collecteur. Si l’on exige une exactitude et une fiabilité complètes, chaque paquet doit être examiné.

Pour d’autres objectifs — comprendre le comportement, régler le réseau ou estimer une part de coûts — l’échantillonnage peut suffire à moindre coût. Ces méthodes ne répondent pas au même niveau de preuve.

La collecte devait elle-même être protégée. Les auteurs considéraient les données d’usage comme sensibles et citaient la confidentialité, l’intégrité et le contrôle de la collecte. Ils évoquaient les accusés de réception avec retransmission, plusieurs collecteurs ou un stockage de secours sur le compteur. Une valeur relevée à un routeur ne devient pas automatiquement un compte fiable et complet parce que l’instrument se trouve à la frontière.

Un relevé n’était ni une facture ni une règle

La RFC 1272 limitait explicitement son ambition. C’était un mémo d’information préparant une architecture de signalement d’usage, et non une norme Internet. Les rapports pouvaient aider un abonné à comprendre son comportement, un fournisseur à mesurer le respect d’une politique ou contribuer à une répartition des coûts. Mais le signalement ne suffisait pas à appliquer une politique, et le document ne recommandait pas de pratiques de facturation. Il ne tranchait pas la question de savoir qui devait payer les retransmissions.

Une autre question restait ouverte : faut-il compter un paquet lorsqu’un routeur le reçoit ou seulement lorsqu’il le transmet ? Sous congestion, un routeur peut abandonner des paquets. Compter à l’entrée reflète les ressources consommées par le trafic offert ; compter à la sortie évite de facturer un trafic non transmis. La RFC 1272 demandait que l’architecture puisse appliquer l’une ou l’autre convention, car le choix dépendait du contexte et de la politique, pas d’une vérité technique universelle.

Plus tard, la RFC 2722 a spécifié une architecture de mesure des flux. Cette évolution appartient à l’histoire des systèmes de mesure ; elle ne prouve pas qu’un régime de facturation particulier, ni l’ensemble de la vision comptable de 1991, soit devenu opérationnel. La question durable de la RFC 1272 est plus limitée : que peut réellement savoir une administration à sa frontière et combien vaut la mesure ? Il faut préserver la chaîne entre flux observé, voisin identifié, rapport, puis éventuelle décision de prix ou de contrôle. Rien de tout cela ne découle automatiquement des adresses IP aux deux bouts.

Sources : RFC 1272 ; RFC 2722 ; RFC 2990.