Résumé

  • RFC 3148 ne définit pas un chiffre universel de capacité réseau. Il traite la Bulk Transport Capacity comme une famille de mesures dont le comportement de transport doit être décrit.
  • Les pertes, temporisations de retransmission et réactions de l’horloge d’accusés de réception peuvent expliquer des débits différents, sans transformer un flux de test en verdict sur toutes les applications et tous les utilisateurs.

Le chiffre paraissait plus simple que l’expérience

Imaginons deux hôtes qui transfèrent un gros fichier sur le même chemin. Chaque essai remplit le même goulot d’étranglement et rapporte les données utiles par unité de temps. Les deux résultats sont en bits par seconde. Pourtant, le premier algorithme récupère vite après une série de pertes ; le second perd son horloge d’accusés de réception et attend l’expiration d’une temporisation. Le chemin n’a pas changé. Le débit mesuré, lui, change.

Ce n’est pas une erreur de calcul. C’est précisément le problème que RFC 3148 voulait rendre visible. Publié en juillet 2001 comme RFC Informational, « A Framework for Defining Empirical Bulk Transfer Capacity Metrics » décrit la Bulk Transport Capacity (BTC) comme le débit moyen à long terme d’une connexion de transport unique, sensible à la congestion, souvent TCP. Le document donne une formule simple — bits de données uniques envoyés divisés par le temps écoulé — puis avertit que ce résultat dépend de choix d’implémentation.

Le mot « capacité » fait penser à une propriété fixe du lien. RFC 3148 est plus prudent. Sa référence intuitive est le débit moyen d’une implémentation TCP idéale sur un chemin. Mais les spécifications IETF permettent plusieurs algorithmes de contrôle de congestion et une certaine latitude au sein de chacun. Si ces choix autorisés produisent des résultats non comparables, « la BTC de ce chemin » n’est pas un chiffre qui se suffit à lui-même. Il faut lui associer une méthode.

Un TCP conforme n’est pas un instrument figé

Les normes de transport établissent un comportement partagé sans fixer chaque détail d’implémentation. RFC 5681, par exemple, décrit le contrôle de congestion de TCP tout en laissant des choix pertinents pour la mesure. RFC 3148 demande donc à chaque méthode BTC de préciser ses décisions : progression de la fenêtre de congestion, comportement au seuil de démarrage lent, algorithme de récupération, taille des segments, temporisation des retransmissions et réglage de l’horloge de mesure.

Ces paramètres ne sont pas décoratifs. Le débit de l’émetteur dépend du retour des accusés de réception. Une perte peut déclencher une retransmission rapide, ou laisser l’émetteur attendre une minuterie. La récupération SACK, NewReno, le délai d’expiration, les tampons d’émission, la fenêtre du récepteur et la taille maximale de segment modifient tous le volume transporté par un flux au cours d’un intervalle. Ces mécanismes sont documentés dans RFC 5681, RFC 6298, RFC 2018, RFC 6582 et RFC 6675. Leur existence ne rend pas toutes les implémentations équivalentes ; elle rend le comportement choisi partie intégrante du résultat.

RFC 3148 distingue une « Congestion Avoidance Capacity » plus étroite d’une mesure BTC plus complète. La première exclut les périodes où interviennent l’expiration du délai de retransmission et le démarrage lent. Elle peut décrire le régime permanent de l’évitement de congestion, mais omettre des phases qui comptent dans un vrai transfert massif. Le document ne dit pas qu’une mesure est toujours supérieure. Il dit que le nom et le chiffre ne doivent pas dissimuler les comportements inclus ou écartés.

Conserver les traces qui expliquent l’écart

Un débit affiché ne révèle pas pourquoi deux méthodes divergent. RFC 3148 recommande de recueillir des mesures auxiliaires ou assez d’informations — par exemple une trace de segments — pour pouvoir les reconstituer. Elles peuvent porter sur les séries de pertes, le réordonnancement, les expirations, l’évolution de la fenêtre de congestion, la préservation de l’horloge d’accusés de réception, les pertes et files d’attente dans l’hôte de test, la taille des segments et la charge du chemin retour.

L’horloge d’accusés de réception en donne un exemple utile. TCP envoie souvent de nouvelles données en réponse aux accusés de réception des données déjà livrées. Si cette cadence se rompt, la récupération par temporisation et démarrage lent peut consommer du temps qu’un chiffre de régime permanent n’inclut pas. Deux méthodes peuvent donc afficher des débits différents parce qu’elles réagissent différemment aux mêmes pertes. Une trace permet d’enquêter ; elle ne désigne pas automatiquement le routeur, la file ou l’opérateur responsable.

Cette approche s’inscrit dans la discipline plus large de RFC 2330, qui distingue une métrique soigneusement définie de la méthode utilisée pour la mesurer et demande d’en comprendre l’incertitude. Des travaux ultérieurs, notamment RFC 5166 sur l’évaluation des algorithmes de congestion et RFC 6349 sur les tests de débit TCP, fournissent un contexte voisin. Ils ne transforment pas RFC 3148 en test unique universel et ne prouvent pas qu’un opérateur particulier l’a déployé.

RFC 3148 formule aussi un avertissement économique subtil : comme la dynamique de congestion peut être non linéaire, augmenter le débit d’un lien peut, dans certaines conditions, diminuer le débit TCP ou BTC mesuré. Le texte présente une possibilité et un sujet de recherche, non un incident observé, une loi générale sur les mises à niveau, ni la preuve qu’une hausse de bande passante nuit habituellement aux utilisateurs. Il invite à conserver la méthode et les observations avant de tirer une conclusion commerciale d’un chiffre qui change.

La mesure occupe aussi le réseau

La BTC se mesure avec un transfert important, pas avec quelques observations passives. Un test cherche naturellement à remplir le goulot. RFC 3148 note que certaines méthodes pourraient utiliser des paquets qui ne sont pas du TCP et ressembler à une attaque par déni de service aux yeux des opérateurs. Il recommande donc de coordonner le calendrier, la taille et la fréquence des tests. Le RFC prévient aussi qu’un test peut être reconnu et traité différemment, ou que des paquets imitant le test peuvent être injectés et fausser la mesure.

La surface opérationnelle dépasse donc les deux extrémités. Le testeur choisit l’algorithme, la durée, les tampons et l’instrumentation. Le chemin apporte délai, pertes, réordonnancement et files d’attente. L’opérateur voit un flux agressif qui consomme de la capacité. Un résultat responsable décrit assez ces conditions pour être interprété et répété, et le test est autorisé sur le chemin et pendant la fenêtre retenus.

Ce qu’un résultat permet de dire

RFC 3148 se distingue de l’histoire voisine de RFC 3133. RFC 3133 définit des ratios directionnels de livraison Frame Relay et avertit qu’un bon ratio de couche liaison peut coexister avec de mauvaises performances applicatives si la perte d’un petit accusé de réception déclenche beaucoup plus de retransmissions. C’est un mécanisme précis de comptabilité des livraisons. RFC 3148 pose une autre question : si les transports peuvent légitimement différer, qu’est-ce qui rend comparables deux mesures de débit massif sur un seul flux ?

Sa réponse est la discipline méthodologique : décrire le comportement transport, garder les preuves auxiliaires, vérifier que l’hôte de test n’est pas lui-même le goulot, distinguer si possible les effets aller et retour, puis répéter l’essai dans des conditions explicites. Le résultat soutient alors une proposition bornée : cette méthode spécifiée a transféré cette quantité de données uniques sur ce chemin observé pendant cet intervalle.

À lui seul, ce résultat ne prouve ni le débit physique du lien, ni la capacité totale disponible pour les flux concurrents, ni le débit de chaque implémentation TCP, ni une violation de SLA, ni le temps d’achèvement d’une application ou l’expérience d’un utilisateur. Un chiffre plus haut ou plus bas ne localise pas non plus la cause sans les traces et éléments indépendants nécessaires pour tester cette explication.

La contribution historique est modeste mais durable. RFC 3148 refuse qu’une seule étiquette efface les choix inscrits dans un instrument de mesure. Il conserve le chiffre principal, mais exige que la méthode l’accompagne.

Comme grille d’interprétation, je m’appuie sur la Note 64 de Lu Heng, consacrée à la spécification minimale et au choix local, ainsi que sur sa Note 20, qui distingue les descriptions formelles de la réalité observable. Ce sont des repères éditoriaux, non des affirmations des auteurs de RFC 3148.

Sources

  1. RFC 3148 — A Framework for Defining Empirical Bulk Transfer Capacity Metrics
  2. Notice RFC Editor pour RFC 3148
  3. RFC 2330 — Framework for IP Performance Metrics
  4. RFC 3133 — Terminology for Frame Relay Benchmarking
  5. RFC 5166 — Metrics for the Evaluation of Congestion Control Algorithms
  6. RFC 6349 — Framework for TCP Throughput Testing
  7. RFC 5681 — TCP Congestion Control
  8. RFC 6298 — Computing TCP's Retransmission Timer
  9. RFC 2018 — TCP Selective Acknowledgment Options
  10. RFC 6582 — The NewReno Modification to TCP's Fast Recovery Algorithm
  11. RFC 6675 — A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment
  12. Lu Heng, Note 64 — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  13. Lu Heng, Note 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile