Résumé

  • Plutarch reconnaissait les mérites de l’Internet homogène et ne cherchait pas à le remplacer. L’IPv4 mondial restait intact, mais comme un contexte susceptible de coexister avec des réseaux aux règles différentes.
  • Dans un contexte, les noms et les mécanismes de communication ont une signification locale. Une fonction interstitielle doit réétablir cette signification à la frontière ; elle devient donc un point de contrôle, pas un simple tuyau.
  • L’article de 2003 présentait un cadre de recherche. Il laissait ouverts la sécurité, l’audit, les capacités d’administration, la découverte à grande échelle, la notification des pannes et la politique de choix des chaînes.

Le nom n’arrivait pas seul de l’autre côté

Supposons qu’un capteur porte l’identifiant 17 dans un petit réseau économe en énergie. Pour un ordinateur connecté à l’Internet, « 17 » n’est ni une adresse globale ni la preuve d’une identité. Il faut savoir dans quel espace cet identifiant a été attribué, quelle passerelle connaît sa correspondance et ce que la communication perd ou gagne en franchissant cette passerelle.

Plutarch partait de cette difficulté plutôt que de la cacher sous une adresse universelle. Un contexte désignait à la fois une région homogène sur un aspect utile et l’ensemble de liaisons dans lequel un nom pouvait être résolu. Cette homogénéité pouvait concerner les adresses, le format des paquets, le transport, le service de nommage, le lien physique ou le domaine administratif.

Le nom était donc relatif au contexte. Pour entrer dans un autre, son référent devait être lié de nouveau. Cette opération obligeait l’architecture à montrer ce que les déploiements réels faisaient déjà au moyen de NAT, de mandataires, de passerelles de signalisation ou de routage.

La pluralité ne signifiait pas que tous les noms se valaient. Elle signifiait qu’aucun nom ne pouvait réclamer un sens mondial sans publier le mécanisme qui lui donnait ce sens ailleurs.

L’Internet gardait sa force sans garder le monopole du modèle

Les auteurs ne racontaient pas l’échec d’IP. Ils rappelaient au contraire que la simplicité d’une couche homogène, un jeu de protocoles fortement défini et peu de mécanismes internes avaient rendu possible une croissance exceptionnelle. Ce succès restait un acquis.

Le déplacement était conceptuel. L’Internet IPv4 mondial devenait lui-même un contexte, avec ses propres règles. Il pouvait continuer à évoluer sans modification délibérée. D’autres contextes pouvaient apparaître au-dessus de lui sous forme d’overlay, à côté de lui avec un autre protocole, sous lui dans un réseau privé, ou à sa périphérie.

Un réseau non-IP cessait alors d’être une anomalie située autour d’un centre véritable. Il devenait un pair. L’Internet pouvait lui servir de transit ou de support sans absorber sa manière interne de nommer, router ou transporter.

Cette solution abaissait le seuil d’adoption. Il n’était plus nécessaire d’attendre une migration coordonnée de tous les hôtes. Un petit contexte pouvait être installé, relié, testé puis abandonné sans convertir le reste du monde. L’expérience locale n’était pas un référendum planétaire.

La fonction interstitielle n’était pas une douane neutre

La pièce décisive s’appelait fonction interstitielle, ou IF. Elle possédait logiquement une face vers chacun des deux contextes et un mécanisme interne capable de transformer les données de l’un pour l’autre. Plusieurs IF pouvaient former une chaîne.

Quatre familles de traduction structuraient l’argument. Pour l’adressage, il fallait établir et maintenir des correspondances. Pour le nommage, il fallait résoudre entre plusieurs systèmes, au lieu de supposer une seule hiérarchie universelle. Pour le routage, relier un réseau radio à la demande à un domaine OSPF/BGP exigeait de filtrer et reformuler des informations dont la volatilité n’avait pas la même signification. Pour le transport, une optimisation adaptée à une technologie ne devait pas être imposée à toutes les autres.

Les exemples allaient d’un NAT ou d’un routeur BGP à la conversion vidéo et à l’ajout de correction d’erreur. Cette amplitude révèle le vrai statut de l’IF. Elle ne se contente pas de transmettre. Elle peut terminer un comportement, en commencer un autre, conserver de l’état, réduire une fidélité, masquer une instabilité ou promettre un service modifié.

Son reçu devrait donc décrire l’entrée, la sortie, la règle d’équivalence, l’autorité qui a permis la transformation, l’état conservé et les propriétés abandonnées. Une communication réussie ne prouve pas, à elle seule, que la même identité ou le même contrat a traversé la frontière.

Une chaîne pouvait être simple à utiliser et difficile à contester

Le modèle permettait d’abstraire toute une suite de contextes et d’IF sous la forme d’un nouveau contexte. Une application peu exigeante pouvait demander seulement si son correspondant était joignable. Une autre pouvait recevoir plusieurs chaînes, comparer leurs propriétés et choisir.

Ce choix était puissant : l’extrémité retrouvait une partie de la décision que le milieu homogène avait absorbée. Mais l’abstraction avait un prix. Si l’application ne voyait que « joignable », elle ignorait peut-être qu’un proxy avait coupé le transport, qu’un transcodeur avait modifié le contenu ou qu’un service de réparation avait remplacé une chaîne en panne par une autre sous une administration différente.

L’article envisageait un service distribué de découverte et plusieurs « Plutarchies » administrées séparément. Des capacités devaient limiter l’inspection et la configuration. Pourtant, leur gestion n’était pas spécifiée. Le chemin pouvait être pluriel tout en dépendant d’un nouveau distributeur de droits.

Les omissions indiquaient le périmètre réel du résultat

L’article dit clairement ne pas traiter l’allocation des ressources, les délais, les garanties, la sécurité ou l’audit. Les interfaces décrites sont des maquettes conceptuelles. Aucun chiffre de performance n’est fourni. L’hypothèse d’un petit nombre de types de contextes et de chaînes courtes n’est pas une mesure de production.

Restent à résoudre le routage entre contextes à grande échelle, la découverte des IF, la notification des pannes, la sélection politique d’une chaîne, l’interface destinée aux programmeurs, l’adaptation du transport et le passage à l’échelle du nommage. Plutarch n’est donc pas la preuve qu’un réseau pluriel fonctionne sûrement. C’est une manière plus honnête d’énoncer ce qu’il faudrait prouver.

Une architecture peut rendre l’hétérogénéité explicite sans rendre ses traducteurs fiables. Elle peut éviter une racine mondiale tout en créant un passage obligé local. Elle peut proposer une réparation automatique sans dire qui a le droit de choisir la voie de secours. Ces tensions ne réfutent pas le modèle ; elles empêchent de transformer un programme de recherche en victoire rétrospective.

Crowcroft appartient à un argument collectif

L’Université de Cambridge présente aujourd’hui Jon Crowcroft comme professeur Marconi des systèmes de communication, après plus de quatre décennies de travaux liés à l’Internet. Plutarch correspond à cette trajectoire par son intérêt pour les protocoles, les systèmes répartis et la composition.

Mais l’attribution doit rester exacte. Le texte est signé par Crowcroft, Hand, Mortier, Roscoe et Warfield. Il s’inscrit aussi dans une histoire du nommage contextuel, du late binding, de l’argument de bout en bout et des architectures futures. En faire l’invention solitaire de Crowcroft effacerait précisément la pluralité intellectuelle que l’article cherche à rendre productive.

La contribution durable est un changement de regard : la diversité n’est pas le bruit entourant le vrai réseau. Elle est l’objet que l’interconnexion doit savoir composer.

Sources