Mon blog

Ce RFC définit un concept important en matière de métrologie du réseau, le concept de capacité qui remplace celui, ambigu, de bande passante.

Le groupe de travail IP Performance Metrics de l'IETF continue à ajouter au savoir commun d'intéressants RFC normalisant notamment les concepts utilisés, afin que des comparaisons puissent être faites entre les mesures effectuées par des équipes différentes. Ce RFC s'attaque au concept de capacité (capacity), qui a vocation à remplacer celui, flou et peu exact, de bande passante.

Une des raisons du flou est la volontée délibérée par certains acteurs de présenter des chiffres plus favorables. On voit ainsi souvent, sur le marché de l'accès Internet par ADSL des chiffres donnés en débit de la couche physique, pas en débit des couches plus hautes, pourtant les seules qui intéressent les utilisateurs. Le concept de bande passante avait aussi d'autres défauts, comme son origine dans le monde de l'analogique qui faisait que, même utilisé correctement, son étymologie était source de confusion. Ainsi, la section 3.4 donne l'exemple d'un lien 802.11b où l'électronicien annoncera une « bande passante » de 25 Mhz, l'ingénieur réseaux une « bande passante » de 11 Mbps, alors que l'utilisateur final ne pourra pas obtenir plus de 8 Mbps de débit.

La section 1 de notre RFC donne d'autres exemples des différences de capacité selon les couches. Par exemple, le codage Manchester de l'Ethernet classique fait perdre une bonne partie de la capacité théorique. Tout mécanisme de somme de contrôle consomme également des bits qui sont perdus pour les couches hautes. Les mécanismes d'accès au réseau peuvent encore réduire la capacité théorique. C'est ainsi que le CSMA/CD de l'Ethernet classique ne permet pas d'utiliser toute la capacité théorique. Des chiffres de 35 % d'utilisation maximale de l'Ethernet avaient circulé à une époque mais ils ne reposaient, ni sur un calcul théorique, ni sur des expériences ; et ils étaient totalement faux. Ceci dit, on ne peut pas atteindre les 100 %.

Bref, la capacité ne peut être sérieusement définie que pour une couche donnée.

La section 2 s'attaque aux définitions proprement dites. Reprenant les notions de lien et de chemin du RFC 2330, ainsi que la notion de « paquets de type P » (paquets d'un type donné, pour tenir compte du fait que le débit mesuré peut dépendre du type de paquets, TCP plutôt que UDP, par exemple) notre RFC définit :

• La capacité physique théorique du lien (Nominal physical link capacity). Elle est mesurée à la couche 1 et vaut donc, par exemple, 155,52 Mbps pour un OC-3.
• La capacité IP du lien (IP-type-P link capacity ). Elle est mesurée à la couche 3 et elle inclus donc dans son calcul les bits de l'en-tête des paquets IP. Les applications, dans les couches plus hautes, ne pourront donc pas utiliser toute cette capacité.
• La capacité IP du chemin (IP-type-P Path Capacity). Attention, c'est IP et pas TCP donc, en cas de retransmission de paquets erronés, la capacité TCP sera plus faible.
• L'utilisation du lien (IP-type-P Link Usage et IP-type-P Link Utilization) qui indique l'usage effectif qui est fait du lien.
• La capacité disponible (IP-type-P Available Link Capacity et IP-type-P Available Path Capacity), qui est simplement la capacité moins l'utilisation.

La section 3 est ensuite consacrée à discuter de cette terminologie et des difficultés de mesure. C'est là par exemple qu'est traité le cas de la compression (par exemple avec ROHC, RFC 3095) ou bien le rapport entre la capacité et les grandeurs définies par le RFC 3148 (ce dernier RFC traite de la capacité utile, c'est-à-dire des données effectivement transmises par le protocole de transport).