Résumé

  • Avec cm_request, une application signalait qu’elle avait quelque chose à envoyer sans confier son tampon au Congestion Manager ; cmapp_send accordait ensuite une occasion limitée, généralement plafonnée au PMTU.
  • Cette permission n’était ni un paquet en attente, ni une réservation imposée à tout l’hôte, ni un accusé de réception. cm_notify comptabilisait l’émission locale réelle et cm_update apportait séparément les informations du destinataire.

Le goulot partagé, les mémoires dispersées

Au début des années 2000, un même ordinateur pouvait ouvrir de nombreuses connexions vers une destination et faire tourner plusieurs applications sensibles au débit. Chacune réapprenait l’état du chemin. Une session récente pouvait démarrer prudemment alors qu’une autre venait de mesurer le même aller-retour ; deux boucles de contrôle pouvaient aussi accroître leur charge sans coordination. La congestion était commune, mais sa mémoire restait dispersée.

La RFC 2140 avait proposé de partager certains éléments d’état TCP entre connexions d’une paire d’hôtes. Publiée sur la voie des normes en juin 2001, la RFC 3124 élargit le projet. Son Congestion Manager, module installé sur l’hôte terminal, réunissait des flux dans un « macroflow », maintenait une vue commune de la congestion et pouvait ordonnancer leurs occasions d’émettre. Les applications non TCP pouvaient participer sans renoncer à la logique propre de leurs médias.

Le dispositif ressemblait de loin à une file centrale. C’est précisément ce qu’il ne fallait pas en déduire. La RFC divisait la décision en étapes observables afin que la rareté du réseau soit gérée en commun sans transférer la maîtrise du contenu au contrôleur.

La demande ne transportait aucun tampon

Lorsqu’une application appelait cm_request, elle déclarait une demande. Elle ne remettait pas au CM un paquet déjà formé. Le gestionnaire ne conservait donc pas de données applicatives et ne promettait pas qu’un message particulier serait transmis plus tard.

Quand son algorithme l’autorisait, il déclenchait le rappel cmapp_send. L’application recevait le droit d’envoyer jusqu’à une quantité indiquée, normalement un PMTU. Elle pouvait alors retenir l’information la plus utile à cet instant. Une source vidéo pouvait préférer une image récente à une image devenue obsolète, réduire la qualité ou reformer un bloc plus petit. Le dernier choix restait proche de la sémantique du service.

Cette organisation protégeait deux compétences différentes. Le CM connaissait la fenêtre de congestion et les demandes concurrentes. L’application connaissait la valeur relative de ses données. Une file opaque aurait figé trop tôt le contenu ; un ordonnanceur sans coopération n’aurait pas coordonné les émetteurs.

Le rappel n’attestait pourtant aucune émission. Entre la permission et la sortie IP, le programme pouvait ne rien produire, tomber en panne ou découvrir que la permission avait expiré. Une trace de cmapp_send seule est donc une trace de décision, pas une trace de paquet.

Une permission périssable exigeait un retour

La durée du droit d’émettre était bornée par le maximum entre un aller-retour et un seuil choisi par l’implémentation. Passé ce délai, l’application ne devait plus s’en servir. Une ancienne occasion ne devenait pas un crédit permanent : la fenêtre de congestion qui l’avait justifiée pouvait avoir changé.

Après la tentative, cm_notify(nsent) indiquait combien d’octets avaient réellement été remis à la sortie IP. Si l’application ne pouvait rien envoyer, elle devait appeler la fonction avec zéro afin de restituer l’occasion. Ce zéro n’était pas un échec de capacité ; il refermait proprement une décision inutilisée et permettait à l’ordonnanceur de progresser.

La RFC prévoyait aussi l’imperfection. Une application pouvait disparaître sans envoyer cette notification. Le CM devait survivre à ce silence au lieu de bloquer toutes les demandes. Cette robustesse ne l’autorisait pas à transformer automatiquement chaque permission en émission : elle imposait une politique de récupération explicite.

nsent mesurait ce que l’hôte avait présenté au chemin IP, pas ce que le destinataire avait reçu. Le retour distant arrivait par cm_update, avec des catégories distinguant réception, perte, notification explicite de congestion ou absence de retour. Permission, émission et observation distante formaient ainsi trois registres.

Le macroflow restait une hypothèse de chemin

Les flux regroupés dans un macroflow partageaient état et algorithmes de congestion. L’application pouvait participer au choix du groupe, car elle connaissait parfois mieux les relations entre ses sessions. Mais un identifiant commun ne prouvait pas un goulot commun. Un changement de route, plusieurs interfaces ou un regroupement trop large pouvaient invalider cette hypothèse.

La distinction est utile pour lire l’histoire. La RFC 9040 reviendra bien plus tard sur la mise en cache de métriques de transport, tandis que les RFC 2581, 2861 et 5681 précisent divers comportements TCP. La RFC 3124 ne se réduit pas à cette mémoire partagée : sa nouveauté propre réside dans le dialogue demande–autorisation–notification, ouvert à plusieurs applications et assorti d’un ordonnancement.

Une archive crédible devrait donc conserver la clé de macroflow et les observations de route qui la soutenaient. Sans elles, le groupe montre une décision locale, non l’identité physique du trajet.

« Bien élevée » ne voulait pas dire contrainte

Le texte qualifiait de bien élevée une application qui n’émettait qu’avec le consentement du CM et déclarait fidèlement toutes ses émissions. Il s’agissait d’un contrat de coopération. Le gestionnaire ne pouvait pas empêcher un autre programme de contourner son interface.

La RFC l’affirmait : le CM n’imposait pas son comportement à toutes les applications et ne protégeait pas le réseau contre un hôte compromis. Un policer local ou un mécanisme placé dans un routeur aurait constitué une autre surface de contrôle, hors du document. La présence du module ne prouvait donc ni la discipline générale de la machine, ni l’absence de trafic concurrent non comptabilisé.

L’adoption elle-même était facultative. Un programme qui choisissait l’interface devait en respecter les règles, mais la publication d’une norme ne garantissait aucune implantation particulière. Il faut résister à deux raccourcis symétriques : appeler succès la seule existence du standard, ou appeler échec l’absence de reçu de déploiement.

L’inconnu n’était pas transformé en zéro

L’interface synchrone permettait à une application de conserver son propre ordonnanceur et d’interroger le CM avec cm_query. Elle pouvait recevoir des estimations de débit, de RTT ou d’état de congestion. Lorsqu’une mesure n’était pas valable, une valeur négative le signalait. Zéro restait ainsi disponible pour une véritable valeur nulle.

Ce détail révèle une discipline plus générale. Un système de contrôle doit pouvoir dire « je ne sais pas » sans fabriquer une précision. De même, l’historien ne doit pas convertir une documentation normative en preuve d’usage. Les RFC 2914 et 8085 exposent les responsabilités de contrôle de congestion ; les RFC 2481 et 1191 donnent les contextes ECN et PMTU. Elles expliquent le terrain intellectuel, pas le parc installé de RFC 3124.

Conserver la chaîne plutôt que son dernier mot

Pour reconstituer une décision, il faudrait joindre l’appel cm_request, le macroflow, l’état de l’ordonnanceur, l’heure et la taille du rappel, les paramètres d’expiration, le contenu finalement choisi, cm_notify, l’interface et la route, puis les cm_update issus du destinataire. La qualité perçue demanderait encore d’autres mesures.

Chaque pièce possède une autorité limitée. La demande atteste un besoin déclaré. Le rappel atteste une occasion accordée. La notification positive atteste un compte rendu local d’émission. Le retour du pair renseigne sur le réseau et la réception. Aucun de ces documents ne peut, seul, devenir le récit complet.

La force durable de la RFC 3124 tient à cette frontière. Elle proposait de mutualiser la décision temporelle sans confondre l’ordonnanceur avec le chemin des données. Une autorisation d’émettre n’était pas le paquet, et encore moins son arrivée.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3124.txt
  2. https://www.rfc-editor.org/info/rfc3124
  3. https://datatracker.ietf.org/doc/rfc3124/
  4. https://www.rfc-editor.org/rfc/rfc2140.txt
  5. https://www.rfc-editor.org/rfc/rfc2914.txt
  6. https://www.rfc-editor.org/rfc/rfc2581.txt
  7. https://www.rfc-editor.org/rfc/rfc2861.txt
  8. https://www.rfc-editor.org/rfc/rfc2481.txt
  9. https://www.rfc-editor.org/rfc/rfc1191.txt
  10. https://www.rfc-editor.org/rfc/rfc5681.txt
  11. https://www.rfc-editor.org/rfc/rfc8085.txt
  12. https://www.rfc-editor.org/rfc/rfc9040.txt