Résumé

  • Le RFC 1152, publié en avril 1990, rapporte un atelier du groupe de pilotage de la recherche Internet. David Clark y soutenait que les protocoles existants pouvaient atteindre le gigabit si le débit constituait l'unique exigence ; distance, nombre d'usagers et nouveaux services compliquaient la décision.
  • Keith Lantz insistait sur la faible latence et la synchronisation du multimédia. Craig Partridge examinait l'attente des appels distants. Une mesure préliminaire sur Nectar montrait enfin un écart entre ce que les cartes de communication échangeaient et ce que les processus hôtes recevaient.

La question arrive avant la vitesse

L'atelier était organisé sous l'égide de l'Internet Research Steering Group, lié à l'IRTF. Craig Partridge a composé le rapport à partir des comptes rendus des présidents de séance, relus par les participants. Le document a le mérite de garder les désaccords en vue. On y cherche des réseaux très rapides sans faire semblant que tous les intervenants souhaitent la même architecture.

Dans la séance consacrée aux protocoles, David Clark résumait le piège du chiffre rond. Atteindre un gigabit par seconde, disait-il, n'exigeait pas nécessairement de remplacer les protocoles existants si c'était la seule cible. Les projets visaient aussi de longues distances, beaucoup d'utilisateurs et des services tels que la réservation de bande passante. Pour comparer des propositions, il fallait d'abord préciser ce que l'on demandait au réseau. D'autres exposés exploraient des processeurs spécialisés, de nouvelles interfaces et des implémentations plus habiles.

Le gigabit ouvrait un débat d'ingénierie ; il ne le tranchait pas.

Keith Lantz prit ensuite le problème par le poste de travail. Son « bureau portable » désignait un accès continu aux personnes et aux services depuis le bureau, la maison ou un lieu éloigné. L'intérêt ne tenait pas au poids de l'ordinateur. Une conférence sur écran mobilisait texte, graphiques, son et vidéo, avec des besoins en débit fort différents. Plusieurs flux devaient arriver vite, parfois avec peu de variation dans le délai, et rester synchronisés. Une image qui devance la voix de son interlocuteur offre une démonstration assez cruelle des limites d'un joli débit.

Lantz réclamait aussi des protocoles capables de s'adapter : une partie du trajet pouvait être plus lente, le réseau pouvait saturer, la qualité de l'image pouvait changer. Les applications ne vivent pas uniquement sur le tronçon le plus rapide. Elles traversent des capacités inégales et doivent décider comment dégrader le service sans casser la conversation.

La distance présente toujours sa facture

La séance sur les systèmes distribués apporta un autre délai. Partridge observa que les machines gagnaient de la vitesse tandis que le temps d'aller-retour sur un réseau distant restait soumis à la distance et à la vitesse de la lumière. Un appel de procédure à distance coûtait donc de plus en plus de cycles de processeur en attente. Lancer plusieurs appels à la fois pouvait occuper la machine, mais chaque chaîne de requêtes dépendantes devait encore recevoir une réponse avant de poursuivre.

Son examen des remèdes avait un humour involontaire. Accumuler des caches accélère certaines lectures ; il faut ensuite synchroniser ces caches, et l'on risque de créer des appels distants pour éviter d'autres appels distants. Partridge préférait rassembler plusieurs opérations destinées à la même machine dans une transaction plus large. D'autres intervenants défendaient l'anticipation ou des modèles de programmation asynchrones. Le rapport garde ces pistes distinctes : elles répondaient au même temps d'attente par des coûts différents.

Le réseau Nectar de Carnegie Mellon fournit une image encore plus matérielle. D'après les résultats préliminaires rapportés à l'atelier, les processus sur ses cartes de communication échangeaient à 70 Mbps, tandis que ceux des machines hôtes atteignaient environ 25 Mbps, limités par l'interface VME. Il s'agissait d'un prototype précis. Il suffisait à rappeler que la capacité du réseau doit encore franchir le bus et parvenir au programme. Jeff Mogul évoqua à son tour le coût de faire entrer les paquets dans le cache du processeur et d'avertir le processus utilisateur.

Le rapport ne couronne aucun protocole miracle. Il déplace la question vers le trajet complet d'une tâche : délai aller-retour, synchronisation des médias, adaptation au segment lent et coût de livraison à l'application. Le lien pouvait courir ; le travail attendait parfois à l'accueil.