I. Introduction

Comme annoncé dans la NEW/RFC #53, nous soumettons ici le protocole à la critique, aux commentaires, etc. Nous souhaitons que ce protocole devienne le premier protocole officiel et serons donc très satisfaits si aucune objection sérieuse n'est soulevée. Néanmoins, nous accueillerons toutes sortes de critiques jusqu'au 13 juillet 1970, et ces critiques devront être publiées sous forme de NWG/RFC ou adressées au premier auteur.

Après le 13 juillet, il sera décidé soit d'adopter ce protocole (ou une légère variante), soit de le reconcevoir et de le soumettre à nouveau à la critique.

Uniquement le protocole

Dans les discussions précédentes sur le protocole, aucune distinction claire n'a été faite entre les spécifications à l'échelle du réseau et les stratégies locales. Nous affirmons ici que les seules questions à l'échelle du réseau sont les formats de message et les restrictions sur le contenu des messages. La mise en œuvre d'un programme de contrôle réseau (Network Control Program, NCP) et le choix des appels système sont des questions strictement locales.

Ce document se limite aux seules questions à l'échelle du réseau et ne traite donc ni des appels système ni des tables du NCP. Néanmoins, un protocole est inutile sans NCP et sans un ensemble d'appels système, c'est pourquoi nous avons consacré beaucoup d'efforts à l'élaboration d'un NCP prototypique. Ce travail est présenté dans la NWG/RFC #55, et le lecteur est invité à mettre en regard le protocole présenté ici avec les suggestions d'utilisation qui y sont formulées. Il importe toutefois de garder à l'esprit que le contenu de la NWG/RFC #55 n'est qu'indicatif et que des propositions concurrentes devraient être examinées avant de choisir une mise en œuvre.

Contrôle de flux

Au cours de la conception du présent protocole, nous avons compris que le contrôle de flux est plus complexe que nous ne l'imaginions. Nous pensons désormais que les techniques de contrôle de flux seront l'un des principaux sujets de préoccupation à mesure que le trafic du réseau augmentera. Nous avons donc tiré parti de certaines idées suscitées par Richard Kaline et Anatol Holt et avons modifié la procédure de contrôle de flux. (Les défauts de notre schéma ne sont, bien entendu, imputables qu'à nous.) Cette nouvelle procédure présente des limites avérées, mais elle a l'avantage d'être plus simple à mettre en œuvre proprement et de permettre une première utilisation du réseau. C'est la seule modification substantielle par rapport au protocole déjà convenu.

Le nouveau mécanisme de contrôle de flux exige que l'hôte récepteur alloue un espace tampon pour chaque connexion et indique à l'hôte émetteur combien d'espace, en bits, est disponible. L'hôte émetteur tient le compte de l'espace disponible et n'envoie jamais plus de texte que ce qu'il estime que l'hôte récepteur peut accepter.

Pour mettre en œuvre ce mécanisme, l'hôte émetteur tient un compteur associé à chaque connexion. Le compteur est initialisé à zéro, augmenté par les commandes de contrôle envoyées par l'hôte récepteur et décrémenté de la longueur du texte de tout message envoyé sur la connexion. Il est interdit à l'hôte émetteur d'envoyer un texte plus long que la valeur du compteur, de sorte que le compteur ne devient jamais négatif.

Idéalement, l'hôte récepteur allouera un certain espace tampon dès que la connexion est établie. La quantité allouée ne doit jamais dépasser ce que le récepteur peut garantir d'accepter. À mesure que le texte arrive, il occupe l'espace tampon alloué. Lorsque le processus récepteur absorbe le texte en attente dans le tampon, le NCP renvoie une nouvelle allocation d'espace pour cette connexion. Le NCP peut allouer de l'espace même si le processus récepteur n'a pas absorbé le texte en attente, s'il estime qu'un espace tampon supplémentaire est approprié. De même, le NCP peut décider de ne pas réallouer l'espace tampon après que le processus récepteur l'a rendu disponible.

La commande de contrôle qui alloue de l'espace est

ALL <link> <space>

Cette commande est envoyée uniquement de l'hôte récepteur vers l'hôte émetteur.

Cette formulation du contrôle de flux rend superflues les commandes RSM et SPD de la NWG/RFC #36, ainsi que le message hôte-vers-IMP de type 10 et les messages IMP-vers-hôte de types 10 et 11 de la révision actuelle du BBN Report 1822.

La limite évidente de ce schéma est que l'hôte récepteur n'est pas autorisé à se fonder sur l'utilisation moyenne des tampons -- le pire cas est toujours supposé. Si seules quelques connexions sont ouvertes, il est peu probable que l'économie soit importante. En revanche, au-delà de quelques connexions, l'utilisation moyenne des tampons sera bien inférieure à l'espace tampon alloué. Nous avons étudié des extensions de ce protocole qui incluraient une allocation adaptative, et nous pensons que cela est réalisable. Pour l'instant, ce schéma limité semble le meilleur, et nous comptons bien discuter ultérieurement de schémas plus élaborés. L'ancien schéma des RFNM spéciaux, etc., reste également en discussion.

Afin de répondre aux questions et de discuter des détails, nous tiendrons deux réunions du réseau. La première aura lieu le 29 juin à Harvard et la seconde le 1er juillet à l'UCLA. Nous demandons qu'un seul programmeur par hôte au plus assiste à une réunion et que chaque hôte ne soit représenté qu'à l'une de ces réunions. Deux d'entre nous (J.N. et S.C.) assisteront aux deux réunions.

Pour réserver une place à la réunion de Harvard, veuillez contacter

   Mrs. Margi Robison
   (617) 495-3989
      or 495-3991

Pour réserver une place à la réunion de l'UCLA, veuillez contacter Mrs. Benita Kirstel (213) 825-2368.