Résumé

  • RFC 1306 rapporte qu'un projet Cray de 1992 pouvait transformer le résultat d'une recherche de route en demande de connexion auprès d'un commutateur externe.
  • Tant que la connexion était incomplète, TCP ne devait pas y transférer de données et une tentative de transfert ne devait pas déclencher seule le circuit.
  • Le rapport a isolé un délai d'établissement au moyen d'une minuterie distincte, afin que le recul du temporisateur de retransmission ne décrive pas des données qui n'avaient jamais été envoyées.

Analyse

Une demande adressée à l'extérieur

Le mécanisme décrit par RFC 1306 ne donne pas à la route un pouvoir magique. Le système source connaît l'existence d'un lien à la demande et sait quel contrôleur solliciter. Après la recherche de route, le noyau peut donc produire un message de contrôle. Le contrôleur peut établir une connexion quelque part entre les deux hôtes s'il le peut. Chacune de ces propositions a son sujet propre : le noyau demande ; le contrôleur peut agir ; le circuit peut ensuite devenir complet.

Cette grammaire est l'essentiel. Dire que « la route a créé le circuit » efface l'acteur externe, sa capacité, son éventuel refus et le temps qui sépare la demande de l'état utilisable. Le document ne le fait pas. Il parle d'une connexion commutée et routée dynamiquement, non d'un raccourci conceptuel où une entrée de route constituerait une preuve d'existence.

Les alias de route rendent le point encore plus net. Ils donnaient à la source accès à plusieurs routes alternatives par une interface de routage familière. Mais RFC 1306 laisse les questions de politique et de routage en dehors de son objet. Une alternative visible n'est pas une attribution de capacité ; elle n'établit pas non plus quelle partie peut demander, obtenir ou employer une connexion.

Le premier octet devait attendre

La phrase opérationnelle la plus importante du rapport est négative : une tentative de transfert sur une connexion incomplète ne devait pas activer automatiquement le circuit. TCP ne devait pas envoyer de données sur cette route avant que le circuit soit complet. Le système ne devait donc pas déduire une action de contrôle de la simple pression d'une application qui souhaite transmettre.

Cette séquence protège l'interprétation des événements. Avant l'achèvement, on peut savoir qu'une demande a été faite. On ne peut pas, sur cette seule base, affirmer que le commutateur a trouvé les ressources, que le circuit est actif ou qu'un paquet est entré dans une voie de données. Après l'achèvement, on peut parler d'un circuit complet ; il reste encore à observer l'envoi, l'accusé de réception et ce que l'application en a réellement obtenu.

Le rapport décrit aussi deux messages au contrôleur : demander une connexion et l'annuler. La possibilité d'annuler rappelle qu'une demande peut être retirée avant de devenir la réalité qu'elle vise. Une intention de chemin n'est pas un chemin.

Une minuterie qui disait autre chose

La première version du noyau a révélé un piège : les temporisateurs TCP ordinaires de retransmission pouvaient reculer pendant que le commutateur établissait la connexion, avant tout envoi de données. La correction fut une minuterie séparée pour l'attente d'établissement.

Il ne s'agit pas seulement de rendre les graphiques plus propres. Une minuterie de retransmission porte normalement sur l'absence de réponse à une donnée expédiée. Si elle progresse lorsque rien n'a encore franchi une connexion complète, elle prête au délai de commutation le sens d'une défaillance de transport. Elle fabrique une histoire de perte ou de lenteur là où le système ne dispose que d'une attente de contrôle externe.

La minuterie distincte garde à chaque signal son objet. Elle ne garantit ni circuit ni livraison. Elle permet simplement de ne pas présenter un état en attente comme un résultat de transport. Cette séparation est précisément ce qui rend une exploitation vérifiable : le diagnostic peut dire « établissement en cours » plutôt que simuler un échec de données déjà parties.

Une leçon historique, non une promesse contemporaine

RFC 1306 est un mémo informationnel de mars 1992, tiré d'une expérience de projet. Il ne recense pas les déploiements actuels et ne garantit aucun comportement d'un réseau moderne. Son apport durable est une discipline de preuve. Une route choisie peut justifier une demande ; la demande n'établit pas le circuit ; le circuit n'établit pas à lui seul une livraison ; la livraison n'établit pas un résultat de service.

Cette chaîne évite que le vocabulaire de contrôle usurpe celui de la réalité. Elle est particulièrement utile là où une interface rend visible la première étape et masque toutes les autres. Le rapport conserve les étapes séparées ; l'exploitation devrait en faire autant.

Sources

RFC 1306 décrit une expérience de 1992 ; il ne prouve ni déploiement actuel, ni droit de capacité, ni circuit établi, ni livraison de paquets, ni effet pour un utilisateur.