Résumé

  • RFC 1077 était un programme de recherche, non l’architecture d’un réseau gigabit déjà déployé. Il recensait ce qu’il fallait relier à la fibre : commutation, interfaces hôtes, gestion, allocation et accès.
  • Le rapport observait un renversement : la vitesse des artères augmentait plus vite que celle des éléments de commutation. La rareté pouvait quitter le support et réapparaître dans l’électronique, le traitement par paquet ou la mémoire.
  • Des RFC ultérieures distinguèrent la capacité mesurée d’un équipement, l’engagement de service et l’observation d’un chemin. Aucune de ces preuves n’est synonyme du débit nominal du support.

La capacité était une matière première

Le passage le plus futuriste de RFC 1077 ne promettait pas un service. Il constatait que la fibre déjà installée permettait d’envisager des agrégats au-delà du gigabit et une bande passante brute approchant le térabit par seconde. Le groupe de travail enchaînait aussitôt avec le vrai problème : fournir plusieurs gigabits à quelques utilisateurs tout en agrégeant, à coût raisonnable, des millions de demandes plus modestes.

La nuance entre les deux phrases contient tout le sujet. Une fibre possède une capacité physique. Un service doit traverser des équipements, satisfaire une application, partager des ressources et rester exploitable sous charge.

Réuni à la demande de la DARPA, le Gigabit Working Group publia un rapport d’information. Ses propositions de démonstration — dorsale gigabit, réseaux interconnectés, gestion appropriée et architecture d’accès — formaient un agenda de recherche. Le texte précise même que ses exemples illustrent les problèmes sans imposer une solution. Il ne faut donc lui attribuer ni déploiement général, ni architecture normative.

La pénurie changeait de composant

Les réseaux étendus antérieurs avaient été conçus sous l’hypothèse d’une bande passante chère et lente. La commutation devait économiser le canal. RFC 1077 remarqua que les artères accéléraient désormais plus vite que les commutateurs.

La lumière pouvait transporter le flux, mais l’électronique devait encore décider, mettre en file, mémoriser et traiter. Une commutation par paquets traditionnelle imposait du travail à chaque paquet. Une hausse massive des bits par seconde n’augmentait donc pas automatiquement le nombre de paquets traités par seconde. Avec de petits paquets, l’« intelligence » du commutateur pouvait devenir le goulot.

La contrainte continuait ensuite jusqu’à l’hôte. Le rapport prévoyait que le traitement des paquets côté machine empêcherait une application de recevoir un haut débit, même si la dorsale supportait un agrégat considérable. Copies mémoire, protocoles, périphériques et interface réseau faisaient partie de la chaîne de livraison.

La fibre ne supprimait pas la rareté ; elle en changeait l’adresse. Après une amélioration du support, le système devait découvrir quelle électronique, quel logiciel ou quelle organisation détenait désormais la limite.

Les applications ne demandaient pas toutes la même vitesse

RFC 1077 distinguait deux sources de charge : quelques équipements très rapides, tels que des supercalculateurs, et une immense population d’utilisateurs moyens dont les trafics s’additionnaient. Un même total pouvait donc provenir de statistiques très différentes.

Le débit n’était pas non plus l’unique propriété. Le tableau du rapport sépare délai, dispersion du délai, fiabilité et livraison ordonnée. Un transfert massif accepte parfois l’attente. Une simulation interactive exige une réponse courte. La voix et la vidéo ont besoin d’une arrivée régulière. Le trafic de contrôle consomme peu, mais son éviction peut coûter très cher.

Le document évoquait des services orientés connexion, sans connexion, et des flux synchrones pour lesquels une réservation fournirait une quantité régulière de bande passante. Il ajoutait le type de service, les politiques de routage, l’équité et la réservation anticipée.

À ce stade, « combien le lien transporte » et « quel traitement le réseau attribue » deviennent deux faits distincts. L’application doit exprimer son besoin ; le réseau doit décider s’il l’admet. Or le rapport soulignait déjà que les applications savaient mal traduire « rapide » en débit, délai, durée et tolérance aux pertes.

Gérer la vitesse faisait partie du dessin

RFC 1077 qualifiait la future architecture, avant tout, d’architecture de gestion. À mesure que liens, processeurs et mémoire résolvaient des problèmes simples, les grands systèmes devenaient plus exposés aux interactions de performance, de sûreté et de sécurité.

La gestion couvrait comptabilité, sécurité, suivi de performance, localisation des pannes et configuration. Une comptabilité pouvait enregistrer une allocation de bande passante, des paquets ou des ports afin d’appliquer une politique tarifaire. Elle prouvait une allocation ou une facturation, pas le résultat perçu par l’application.

Le suivi de performance produisait une autre preuve, liée à un point d’observation et à un instant. Le rapport voulait passer de la plainte et de la réaction à la détection précoce et à l’allocation dynamique. Il prévoyait aussi l’excès d’informations de gestion : seuils, filtres et alertes devaient préserver l’accès au détail sans submerger l’opérateur.

Une capacité plus grande créait donc davantage d’état à gouverner, et pas seulement davantage de données à transporter.

Un banc d’essai ne mesure pas le support seul

RFC 1242 donna ensuite un sens précis au débit d’un équipement d’interconnexion : le taux maximal de trames offertes pour lequel aucune trame n’est perdue. Ce n’est pas le débit nominal du média.

Taille des trames, sens, pontage ou routage, contrôle d’intégrité et tâches auxiliaires modifient le résultat. La même RFC traite séparément latence, perte, surcharge, traitement annexe et rafales. Un équipement peut être excellent pour un flux stable de grandes trames et beaucoup moins convaincant devant de petits paquets ou une mise à jour de routage.

RFC 2544 encadra les procédures : comparer la limite théorique du média au débit effectivement soutenu, mesurer la latence au débit établi, puis relever les pertes selon la charge et la taille des trames. Le contexte complet devait accompagner le chiffre choisi pour la publicité.

Ces résultats décrivent un équipement isolé dans une configuration déclarée. Ils ne deviennent pas, par simple copie, la performance d’un chemin de production, une durée d’exécution applicative ou une promesse contractuelle.

L’engagement précède la mesure, mais ne la remplace pas

RFC 1633 répondit plus tard à l’idée selon laquelle l’abondance de fibre rendrait toute réservation inutile. Une bande passante brute peu coûteuse n’est pas forcément disponible partout comme service réseau. Des liens congestionnés et des besoins prévisibles subsistent.

Le modèle Integrated Services associait réservation et contrôle d’admission. Classificateur, ordonnanceur et décision d’admission déterminaient le traitement accordé à un flux. Ce plan de contrôle ne se confondait ni avec le support physique, ni avec le résultat observé.

RFC 2212 formula un engagement plus ferme. Si le trafic respecte ses paramètres et si les éléments du chemin fournissent le service requis, le délai de mise en file peut être borné et les pertes par débordement évitées. Le délai fixe du chemin reste séparé. Le mécanisme d’installation aussi : RSVP, configuration manuelle ou protocole de gestion pouvaient établir la réservation.

Une réservation acceptée est donc la preuve d’un engagement conditionnel. Elle ne prouve pas à elle seule que le chemin n’a pas changé, que tous les éléments sont restés conformes ou que le destinataire a observé le résultat annoncé.

Ce qui arrive doit être observé sur le chemin

RFC 2679 définit le délai aller simple avec une source, une destination, un type de paquet et un instant. Elle sépare une observation unique, un échantillon et les statistiques tirées de cet échantillon. Synchronisation des horloges, incertitude et distinction entre paquet très tardif et paquet perdu bornent l’interprétation.

RFC 3393 définit la variation de délai comme la différence entre les délais aller simple de paquets sélectionnés. La mesure renseigne le dimensionnement des tampons de lecture et la dynamique des files ; elle n’est ni la capacité, ni le délai moyen, ni un score universel de « jitter ».

On peut ainsi tenir quatre registres :

  1. capacité brute du support ;
  2. capacité de traitement des commutateurs et hôtes sous une charge donnée ;
  3. traitement de service alloué ou garanti sous conditions ;
  4. performance livrée observée sur un chemin, depuis des points et pendant une période définis.

Les registres s’influencent, mais ne s’avalent pas. La capacité de la fibre n’est pas un benchmark. Le benchmark n’est pas une réservation. La réservation n’est pas un paquet arrivé.

Le chiffre dangereux est celui qui a perdu son étiquette

RFC 1077 n’acheva pas un Internet gigabit. Il montra pourquoi le composant le plus rapide ne pouvait représenter le service entier. Une abondance technologique peut simplement révéler une pénurie de traitement, d’organisation ou de preuve.

Chaque affirmation de vitesse doit donc préciser sa couche, son propriétaire, la direction, la charge, la forme du trafic, le chemin et la fenêtre d’observation. S’agit-il d’une capacité, d’une aptitude, d’un engagement ou d’un résultat ?

La fibre allait effectivement vite. Le service, lui, devait encore être construit comme un système.

Sources et limites de preuve

RFC 1077 fournit l’agenda de 1988 ; RFC 1242 et RFC 2544, la frontière du benchmark d’équipement ; RFC 1633 et RFC 2212, celle de l’engagement de service ; RFC 2679 et RFC 3393, celle de l’observation du chemin. Ces textes attestent des modèles publiés, non un déploiement universel, des performances actuelles ni une filiation directe depuis RFC 1077.