Résumé
- Dans son rapport BBN de 1989, Craig Partridge soutenait qu’un débit d’un gigabit ne suffisait pas à imposer une nouvelle architecture. Il fallait d’abord identifier la limite concrète : décisions par seconde, travail par paquet, circulation en mémoire, tampon ou délai de contrôle.
- La démonstration reposait sur des hypothèses déclarées — paquets moyens plus grands, processeurs de 60 à 70 MIPS, chemins de 64 bits et mémoire disponible. La propagation, elle, ne gagnait aucune vitesse : plus de bits restaient simplement en vol.
- En 1998, l’équipe du MultiGigabit Router de BBN a publié un reçu matériel : fond de panier à 50 Gb/s et jusqu’à 32 millions de paquets par seconde. Ce résultat collectif restait borné par l’état d’achèvement et par une latence encore estimée.
Le seuil annoncé n’indiquait pas la panne
Le rapport 7080 de BBN, daté du 5 juin 1989 et conservé dans les actes de l’IETF 14, partait d’une croyance très répandue. Le passage des réseaux locaux à 10 Mb/s vers le gigabit allait, disait-on, mettre à nu l’incapacité des architectures à datagrammes. Pourtant, le seuil précis où cette incapacité devait apparaître restait rarement formulé.
Partridge n’a pas défendu le statu quo par principe. Il a demandé si la vitesse introduisait des problèmes assez extraordinaires pour obliger à changer d’architecture. Son texte cherchait même à rester neutre entre circuit virtuel et datagramme. Si les deux pouvaient atteindre le débit visé, la préférence pouvait dépendre du service voulu; elle ne pouvait plus se présenter comme une fatalité technique.
Cette nuance définit l’article. Il ne s’agit pas de dire que toute architecture survit à toute échelle. Il s’agit d’exiger que l’échelle désigne la ressource qui casse.
Le routeur recevait une échéance, pas un gigabit abstrait
Deux hypothèses portaient le calcul. Les paquets moyens d’un futur réseau gigabit ne seraient pas plus petits que ceux de l’Internet contemporain, notamment parce que le trafic massif et des MTU plus grands prendraient davantage de place. Et le matériel déjà en production d’essai permettrait d’estimer les capacités du début des années 1990. Partridge retint comme repères un processeur RISC de 60 à 70 MIPS et des chemins de données de 64 bits.
Pour le routeur, la grandeur pertinente était le nombre de paquets. En extrapolant les 6 000 à 10 000 paquets par seconde alors attendus entre quelques Ethernet, le rapport arrivait à 600 000–1 000 000 de paquets par seconde au gigabit. Un processeur de 60 MIPS disposait donc d’environ 60 à 100 instructions, ou de 1 à 1,6 microseconde, avant l’arrivée du paquet suivant.
Le calcul n’était pas une certification. Un chemin de circuit virtuel pouvait amortir sa mise en place. Le traitement IP de l’époque réclamait environ 100 à 150 instructions sur des processeurs 32 bits, auxquelles s’ajoutait le pilote. Des opérations plus larges, un pipeline ou une aide matérielle pouvaient réduire la charge. Une pluie de petits paquets pouvait au contraire épuiser le budget. Le même débit binaire recouvrait plusieurs machines économiques : l’une vendait des octets, l’autre devait financer un million de décisions.
L’hôte devait lire ce que le routeur pouvait laisser passer
Le routeur inspectait surtout l’en-tête; l’application recevait le contenu. Pour l’hôte, Partridge distingua traitement du protocole, système d’exploitation et travail applicatif. À partir de mesures antérieures de TCP, il construisit une enveloppe illustrative d’environ mille instructions fixes, puis ajouta une part liée à la longueur du paquet divisée par la largeur du mot machine.
En faisant varier la taille moyenne, son graphique montrait qu’un hôte de 60 MIPS pouvait remplir le gigabit autour de 3 Ko par paquet. Avec 512 octets, il approchait un quart du lien; avec 100 octets, environ 50 Mb/s. Ces valeurs sont historiques et conditionnelles. Leur intérêt est méthodologique : le débit de ligne, le débit de paquets et la cadence d’accès aux données ne constituent pas la même preuve.
RFC 1071, cosignée par Bob Braden, David Borman et Partridge, proposait justement de calculer la somme de contrôle pendant une copie mémoire afin de ne charger les octets qu’une fois. Le coût ne résidait pas seulement dans l’addition; il résidait dans le trajet des données. Bien plus tard, RFC 4297 a rappelé une mesure du travail de Clark sur Sun-3/60 : 64 % du temps mesuré venait des opérations touchant les données, dont 48 % de la copie. Il ne faut attribuer ni ces pourcentages à Partridge ni leur valeur au matériel actuel.
Ils illustrent pourquoi un inventaire des passages mémoire vaut mieux qu’un décompte abstrait des fonctions du protocole.
La fibre gardait son temps de trajet
La bande passante augmentait, pas la vitesse de propagation. Le réseau devait donc conserver davantage d’octets en vol. L’exemple de plus longue distance du rapport produisait environ 5,9 Mo de produit bande passante-délai. Une hypothèse de transporteur menant à au moins 120 ms aller-retour portait ce stock à 15 Mo. Ces chiffres montraient un engagement de mémoire plausible en 1989, non une recommandation universelle de tampon.
Partridge sépara aussi ce délai du passage dans les équipements. Cent éléments de commutation respectant le budget calculé n’ajoutaient qu’environ 12,5 à 20 Ko au besoin de tampon. La géographie pesait bien davantage que la somme de décisions locales rapides.
Le contrôle de flux ajoutait un autre coût : combien d’allers-retours avant de connaître la capacité? Dans l’expérience de pensée, un émetteur à datagrammes partant de huit octets et doublant à chaque tour pouvait atteindre l’échelle du gigabit en moins de deux secondes. Pour un transfert long, c’était court; pour certaines applications, deux secondes restaient prohibitives. Le besoin d’un signal plus rapide pouvait être réel sans démontrer l’échec de l’architecture entière.
Le reçu de 1998 portait le nom d’une équipe
Neuf ans plus tard, un groupe nombreux de BBN, avec Partridge comme premier auteur et responsable technique, décrivit le MultiGigabit Router. Le papier annonçait un fond de panier bidirectionnel de 50 Gb/s et jusqu’à 32 millions de paquets par seconde. Il précisait qu’environ un quart de la capacité du fond de panier servait au trafic de contrôle et d’enveloppe.
Le dessin évitait de faire voyager inutilement le corps du paquet. La carte d’entrée gardait les données, envoyait l’en-tête à un moteur de transfert et recevait en retour un en-tête mis à jour et une décision. Les moteurs contenaient une table de transfert complète, de sorte qu’une consultation centrale beaucoup plus chère ne bloque pas le chemin. Un commutateur remplaçait le bus partagé; cartes de ligne et moteurs étaient dissociés; chaque carte traduisait son en-tête local vers un format abstrait; la classification de qualité de service était séparée de l’ordonnancement en sortie.
Le statut de la preuve était précis. Au moment de publier, le matériel avait été fabriqué et testé sauf les cartes d’interface, et la majorité du logiciel fonctionnait. La latence de sept à huit microsecondes pour un datagramme de 128 octets était encore une estimation combinant logiciel mesuré, observations de débogage et simulation. Ce n’est pas un défaut à masquer. C’est la frontière qui permet au lecteur de distinguer le prototype, son modèle et un service achevé.
L’équipe concluait que l’examen de chaque en-tête IP restait praticable à haut débit et que le routeur n’était pas devenu inutile. Elle n’accordait pas à ce résultat un droit d’extension sur tous les mélanges de paquets, toutes les tables ou toutes les vitesses futures.
Une méthode pour refuser le faux mandat
L’Internet Hall of Fame associe Partridge au routage du courrier par noms de domaine, à l’anycast, à la mesure RTT de TCP et au premier routeur multigigabit. Colorado State University le présente aujourd’hui comme professeur travaillant sur le transport des bits, paquets, blocs et fichiers entre machines.
Le fil commun n’est pas la célébration de la vitesse. C’est le choix du bon reçu. Un débit se transforme en paquets par seconde; le paquet en instructions et accès mémoire; la distance en octets en vol; l’ouverture d’un flux en tours avant le travail utile; le prototype en états fabriqué, mesuré, simulé ou absent.
Dans la logique de Running-Code Primacy, une grandeur spectaculaire n’accorde aucun mandat. Celui qui demande aux opérateurs d’abandonner compatibilité, capital ou contrôle doit montrer le chemin exécutable qui échoue. Partridge n’a pas prouvé que l’Internet ne changerait jamais. Il a montré qu’en 1989 le gigabit n’avait pas encore produit cette preuve.
Sources
- Actes de l’IETF 14 — rapport BBN no 7080
- Partridge et al. — A 50-Gb/s IP Router
- RFC 1071 — calcul de la somme de contrôle Internet
- RFC 4297 — problème posé par RDMA sur IP
- Internet Hall of Fame — Craig Partridge
- Internet Hall of Fame — portrait public de Craig Partridge
- Colorado State University — équipe de Computer Science
- Heng Lu — primauté du code en fonctionnement
- Heng Lu — pourquoi la réalité, et non le plaidoyer, est le produit
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
