Résumé

  • Dans la RFC 1190, un agent ST-II pouvait accuser réception de CONNECT, approuver un identifiant local et tenter une réservation avant que l’application cible ne soit consultée.
  • La cible rendait ensuite sa propre décision avec ACCEPT ou REFUSE et renvoyait la FlowSpec réellement obtenue sur sa branche.
  • Le flux multidestination n’était complet qu’après les réponses de toutes les cibles et leur conciliation par l’origine ; même alors, la réception des données restait à prouver.

La demande changeait en traversant le réseau

La RFC 1190, publiée en octobre 1990, décrivit l’Experimental Internet Stream Protocol Version 2, ou ST-II. Son statut était expérimental et d’usage limité. Les notices du RFC Editor et du Datatracker de l’IETF indiquent aujourd’hui son remplacement par la RFC 1819 ; elles ne prouvent ni déploiement général, ni flux réellement établi.

L’origine ne lançait pas un paquet autonome. Elle demandait une arborescence orientée vers plusieurs cibles et joignait une FlowSpec. À chaque embranchement, la fonction de routage choisissait les prochains agents pour un sous-ensemble de la TargetList. L’agent cherchait ensuite les ressources locales et réseau dont cette branche avait besoin.

Les valeurs Desired pouvaient diminuer au passage. Une liaison pouvait offrir moins de débit, ajouter du délai ou imposer un PDU plus petit. Tant que le résultat demeurait dans les Limits fixées par l’origine, l’agent mettait à jour la FlowSpec transmise. La demande initiale, le minimum non négociable et l’allocation obtenue étaient donc trois états, non trois noms du même état.

L’accusé de relais avait un objet précis

Pour que les données ultérieures restent simples à transférer, la version de 1990 négociait un Hop Identifier. L’agent intermédiaire répondait rapidement à CONNECT par ACK, HID-REJECT ou HID-APPROVE, puis poursuivait le routage et la réservation.

HID-APPROVE signifiait que ce voisin pouvait employer le raccourci proposé pour sa fonction locale. Il n’exprimait pas l’accord de la cible. Il ne prouvait même pas qu’une branche plus lointaine obtiendrait les ressources demandées. Un accusé portait sur une relation de contrôle entre deux agents ; l’application distante conservait son propre droit de refus.

Cette précision évite une erreur fréquente dans les chaînes distribuées. Le premier composant qui répond positivement ne parle pas au nom de ceux qu’il n’administre pas. Un routeur peut accepter un état de transfert. Il ne devient pas pour autant le mandataire d’un processus au bout du réseau.

Réserver ne signifiait pas réserver partout

La réservation visée par la RFC englobait davantage que le débit : informations de transfert, capacité de traitement du commutateur, tampons, bande passante et identifiants multicast. Le texte ne normalisait pas une méthode universelle d’allocation. Il reconnaissait que peu de réseaux de l’époque réservaient des ressources et qu’aucun, à la connaissance des auteurs, ne couvrait l’ensemble annoncé.

Une preuve de réservation doit donc rester située. Quel agent l’a demandée ? Quel gestionnaire local l’a accordée ? Pour quelle branche, quelle durée et quelle version de FlowSpec ? La valeur a-t-elle satisfait seulement les Limits ou toutes les valeurs Desired ? Sans ces coordonnées, le mot « réservé » transforme un acte local et conditionnel en promesse mondiale.

ST-II prenait aussi un coût avant l’accord final. Des ressources pouvaient être immobilisées le long d’une branche dont l’application cible allait refuser la connexion. L’architecture échangeait cette dépense provisoire contre un démarrage plus prévisible si la cible acceptait.

L’application cible décidait après les routeurs

Lorsque CONNECT atteignait la machine cible, son agent terminait d’abord la négociation du HID. Il présentait ensuite à l’application le Name du flux, la FlowSpec, les options, le groupe et le sélecteur de service. L’application pouvait accepter, refuser ou demander une réduction de la qualité désirée.

Ce n’est qu’alors que l’agent envoyait ACCEPT ou REFUSE. ACCEPT portait sa propre référence et désignait le CONNECT auquel il répondait. Chaque intermédiaire contrôlait ce lien, accusait réception au prochain agent et propageait une nouvelle réponse vers l’origine sur le chemin inverse.

La boucle de retour fermait une autorité que l’aller n’avait pas. La route appartenait à la fonction de routage, les ressources au gestionnaire local, le raccourci à deux agents voisins, la participation à la cible et l’adoption des conditions à l’origine. Le protocole ne confondait pas leurs pouvoirs.

Une arborescence rendait plusieurs verdicts

Avec plusieurs cibles, l’origine attendait une réponse séparée pour chacune. Elle informait l’application au fur et à mesure, mais l’établissement complet n’arrivait qu’après tous les ACCEPT, REFUSE ou échecs et après la négociation des identifiants.

Les FlowSpec retournées pouvaient être incompatibles. Une branche supportait de gros paquets à faible cadence, une autre de petits paquets plus fréquents. L’origine pouvait supprimer une cible, abandonner l’ensemble ou créer un second flux. Une commande CHANGE devait ensuite libérer les ressources en excès par rapport au compromis retenu.

Un ACCEPT isolé ne constituait donc pas un vote global. Il décrivait une cible et le chemin qui l’avait rejointe. L’état agrégé appartenait à une étape ultérieure, et il pouvait parfaitement être « deux branches retenues, une refusée ».

L’état établi restait soumis au temps

La remontée d’ACCEPT elle-même pouvait échouer. Après plusieurs transmissions sans accusé, un agent devait envoyer REFUSE vers l’origine et DISCONNECT vers la cible. Une réservation déjà établie pouvait aussi être préemptée par un flux de priorité supérieure. NOTIFY signalait alors une garantie révisée ; un CHANGE partiellement réussi pouvait rompre le flux et exiger un nettoyage.

La RFC 1190 précisait en outre que ST ne fournissait pas lui-même de services de sécurité. L’acceptation du protocole ne certifiait ni identité humaine, ni pouvoir juridique, ni autorisation de facturer. Elle ne montrait pas davantage qu’un paquet avait été livré, qu’une voix avait été décodée ou qu’un participant avait perçu une qualité utile.

La révision abandonna le HID, pas la décision de la cible

La RFC 1819 révisa l’expérience en 1995 sous le nom ST2+. Ses notices RFC Editor et Datatracker conservent le dossier. La note de l’IESG dit explicitement qu’aucune des deux versions n’était, ni n’allait devenir, une norme Internet.

ST2+ maintint la chaîne : accusé de CONNECT, consultation du gestionnaire de ressources, propagation vers la cible, décision de l’application et retour d’ACCEPT. En revanche, il supprima les HID, jugés trop complexes et nuisibles à l’interopérabilité. Il supprima aussi les implémentations partielles, dont l’autorisation n’avait pas produit une capacité commune fiable.

L’épisode montre ce qui était durable. Le champ approuvé par un relais pouvait disparaître de la version suivante ; la nécessité d’un accord de la cible demeurait. Compatibilité de mise en œuvre, réservation locale et consentement applicatif n’étaient pas substituables.

La RFC 1077 avait déjà posé les problèmes du haut débit au-delà du support physique. Les RFC 1633 et RFC 2212 ont plus tard défini d’autres cadres de réservation et de service garanti. La parenté des questions ne prouve pas une filiation directe ; elle confirme seulement que capacité, engagement conditionnel et mesure demandent des preuves différentes.

Sources