Introduction
BBN nous a remis les commentaires ci-joints sur le NWG/RFC 33, mais n'a pas voulu les publier, craignant de nous embarrasser. L'embarras mis à part, nous avons trouvé ces commentaires particulièrement utiles et avons décidé de les partager avec nos amis. L'auteur est Bill Crowther.
J'ai trouvé deux erreurs substantielles dans le Host Protocol Paper, qui était par ailleurs un excellent article. Toutes deux concernent une méprise sur la nature de l'IMP en tant que dispositif de communication, et en particulier sur la nature de la mise en tampon qu'un IMP doit effectuer. Les auteurs considèrent le réseau comme un dispositif dans lequel on pousse un message qui circule un moment, attend dans des tampons pendant des durées considérables, puis ressort à destination. En réalité, un meilleur modèle serait que le message ressort aussitôt après y avoir été inséré. S'il est vrai qu'il existe un délai, celui-ci est imposé pour l'essentiel par le matériel des lignes téléphoniques. La mise en tampon dans l'IMP est minime et consacrée au contrôle des erreurs et aux pointes de trafic momentanées.
Comme nous ne pouvons pas forcer un hôte à prendre un message, nous avons construit un mécanisme RFNM élaboré pour suspendre toute nouvelle entrée jusqu'à ce qu'il le fasse. Ce mécanisme est une tentative imparfaite de résoudre un problème de communication très difficile. Le souhait est de réguler le trafic de telle sorte que, au moment où l'hôte retire son message de l'IMP, le message suivant arrive sur la ligne téléphonique, et qu'aucune mise en tampon ne se produise.
En réalité, nous ne pouvons pas y parvenir, et nous avons donc intégré une mise en tampon pour faire face aux pointes de trafic. Ces tampons sont inutiles à l'usage auquel ils sont destinés s'ils ne sont pas vides. Seuls des tampons vides sont disponibles pour absorber une pointe de trafic.
Les deux erreurs précises se trouvent aux pages 5 et 23. À la page 5, les auteurs déclarent : « Une hypothèse implicite de cet objectif est qu'un utilisateur n'utilise pas de liaisons multiples pour obtenir une large bande. » En réalité, l'un des principaux objets des liaisons est d'obtenir une bande plus large.
Nous souhaitons autoriser une largeur de bande aussi grande que possible. Nos difficultés ne viennent pas de la large bande, mais d'un déséquilibre entre l'entrée et la sortie. Les auteurs ont justement remarqué que les liaisons multiples compromettent le mécanisme RFNM, ce qui complique notre tâche, mais ils ont mal désigné la nature du problème.
Toujours à la page 5 : « Une hypothèse encore plus fondamentale, bien sûr, est que la charge du réseau provient de certains utilisateurs qui transmettent des séquences de messages, plutôt que de nombreux utilisateurs qui transmettent des messages isolés par coïncidence. » Nous sommes très bien armés contre les utilisateurs de messages isolés lorsque leurs messages n'ont entre eux qu'une relation aléatoire. Les statistiques nous sont toutes favorables et nous disposons de procédures spéciales pour les coïncidences (rares). Nos problèmes viennent des coïncidences non aléatoires, et nous avons pris des précautions particulières contre les utilisateurs qui transmettent des rafales (séquences) de messages. Nous supposons toutes sortes d'utilisateurs et nous nous protégeons en conséquence.
Aux pages 23 et 24 figurent 4 phrases essentielles qui donnent à penser que la conception du système aurait pu être améliorée en permettant à l'hôte de préciser laquelle de plusieurs entrées en attente il souhaite accepter. Nous admettons que l'hôte doit mettre ces messages en tampon pour ses utilisateurs, mais nous contestons vivement que l'IMP ait la capacité d'effectuer cette mise en tampon.
Si nous fonctionnons en mode idéal, nous n'aurions qu'un seul message au maximum pour l'hôte à tout instant. Si nous en avons plus d'un, nous avons instamment besoin que l'hôte accepte ces messages, car notre capacité à faire face aux pointes de trafic est alors en dessous de la norme. À l'heure actuelle, nous autorisons trois messages de longueur complète dans un IMP pour son hôte avant de commencer à faire remonter le trafic dans le réseau. « Trois » ne suffit pas pour aider l'hôte tout en conservant une réserve pour les pointes de trafic.
Mais si une mise en tampon est nécessaire, pourquoi ne pas ajouter de la mémoire et la faire dans l'IMP ? Parce que la mise en tampon est une fonction de l'hôte, qu'elle diffère d'un système à temps partagé à l'autre, qu'elle est difficile à contrôler sur un canal série occupé, qu'elle peut être totalement inutile à certains endroits, et qu'il vaut mieux la faire là où la mémoire supplémentaire peut être partagée efficacement par le système d'exploitation de l'hôte.
Je le répète : les tampons de l'IMP doivent être vides, sinon ils ne remplissent pas leur rôle de communication.
Les phrases fautives sont les suivantes :
Paragraph 2 sentence 3
" 3 all
" 4 sentences 1 and 2 (80ms is hardware screw adjustable)
" 4 sentence last
Note: Ce RFC a été mis sous forme lisible par machine pour être versé dans les archives RFC en ligne par Jeff & Christy McClellan 2/98.