Résumé

  • RFC 3081 associait une session BEEP à une connexion TCP, mais refusait de confondre le contrôle de flux global de TCP avec une garantie de progrès pour chaque canal multiplexé.
  • Chaque canal naissait avec 4096 octets de crédit. Les trames SEQ déplaçaient cette limite locale avec priorité, tandis qu’un service circulaire empêchait un canal actif de monopoliser les tours.

Une connexion irréprochable, une attente sans fin

Quatre canaux empruntent le même flux TCP. Trois destinataires consomment immédiatement leurs messages. Le quatrième lit lentement, alors que son émetteur possède une longue réponse. TCP peut livrer les octets dans l’ordre, réparer les pertes et rester parfaitement établi. Pourtant, les trois petits échanges peuvent attendre derrière le quatrième.

Ce n’est pas une panne de fiabilité. C’est un conflit d’allocation à l’intérieur d’un transport fiable.

Publié en mars 2001 dans la filière normative, RFC 3081 définissait le transport de BEEP sur TCP. Une session BEEP occupait une connexion TCP et ses trames devenaient les octets de ce flux. Cette simplicité n’effaçait pas les frontières. Le texte nommait explicitement le risque d’affamement et d’interblocage lorsque plusieurs canaux logiques dépendaient du même contrôle de flux TCP.

TCP ne voyait qu’un seul budget

TCP sait protéger une connexion. Il ignore qu’un groupe d’octets appartient à la gestion de session, un autre à une requête brève et un troisième à une réponse massive. Les canaux sont une construction de la couche supérieure.

RFC 3081 a donc donné à chacun une fenêtre glissante distincte. À sa création, un canal pouvait envoyer 4096 octets de charge utile. Le récepteur transmettait ensuite une trame SEQ indiquant le prochain numéro de séquence attendu et la taille de fenêtre acceptée. Ces deux valeurs formaient la borne locale au-delà de laquelle ce canal devait s’arrêter, même si TCP acceptait encore des écritures.

Ce dispositif ne retransmettait rien. TCP assurait déjà l’ordre et la reprise. La fenêtre BEEP répondait à une question différente : quelle quantité supplémentaire ce canal particulier est-il autorisé à introduire dans la ressource commune ?

Les compteurs finissant par boucler, la comparaison devait rester sûre. RFC 3081 s’appuyait sur l’arithmétique des numéros de série de RFC 1982 et limitait les fenêtres afin qu’une ancienne position ne puisse pas se transformer, après débordement, en permission nouvelle.

Le message qui libère ne devait pas rester bloqué

Le crédit n’a de valeur que s’il atteint l’émetteur. Si une trame SEQ attend derrière les données ordinaires qu’elle doit précisément autoriser, la boucle de régulation peut se figer. Le mapping lui accordait donc une priorité supérieure au trafic normal.

Cette priorité n’était pas un jugement éditorial sur la valeur des données. Elle reconnaissait une causalité : le récepteur devait pouvoir annoncer « cette voie peut avancer » avant l’admission de nouveaux octets sur cette voie.

Le document recommandait aussi un service round-robin entre canaux de même priorité. Il ne promettait ni latence identique, ni messages de taille égale, ni justice parfaite dans tous les tampons du système. Il posait un plancher : un canal continuellement chargé ne devait pas être vidé sans fin pendant que ses voisins prêts ne recevaient jamais leur tour.

Le lecteur lent se trouvait au-dessus de TCP

Un octet peut être arrivé par TCP, avoir été admis dans la fenêtre BEEP et rester encore en attente dans l’application. Ces trois constats ne prouvent pas le même résultat. RFC 1122 décrivait déjà TCP comme un service de flux fiable, non comme une garantie de transaction applicative ; RFC 9293 conserve cette séparation.

Les profils ultérieurs rendent cette prudence concrète. RFC 3195 utilisait BEEP pour le transport fiable de syslog. RFC 4744 y plaçait NETCONF. Dans les deux cas, la progression du transport ne prouvait ni le traitement du journal, ni l’application d’une modification réseau. Le protocole applicatif restait maître de l’effet.

Un crédit était une preuve locale

Le récepteur contrôlait la capacité annoncée parce qu’il payait la mémoire et la livraison. L’émetteur choisissait parmi les canaux autorisés, sous la contrainte des crédits et des priorités. TCP contrôlait la congestion de la connexion. L’application décidait si le travail était accompli.

La leçon de RFC 3081 tient dans cette séparation. Donner des numéros à plusieurs voies ne les rend pas indépendantes. Il faut des budgets distincts, un retour de contrôle qui ne puisse être enseveli sous le trafic qu’il gouverne, et une règle de service empêchant un utilisateur légitime de devenir propriétaire silencieux de toute la ressource.

Sources

  1. https://www.rfc-editor.org/info/rfc3081
  2. https://www.rfc-editor.org/rfc/rfc3081.html
  3. https://datatracker.ietf.org/doc/rfc3081/
  4. https://www.rfc-editor.org/rfc/rfc3080.html
  5. https://www.rfc-editor.org/rfc/rfc1982.html
  6. https://www.rfc-editor.org/rfc/rfc1122.html
  7. https://www.rfc-editor.org/rfc/rfc9293.html
  8. https://www.rfc-editor.org/rfc/rfc3195.html
  9. https://www.rfc-editor.org/rfc/rfc4744.html
  10. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  11. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  12. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/