Einleitung
BBN hat uns die beigefügten Kommentare zu NWG/RFC 33 übergeben, wollte sie aber nicht veröffentlichen, um uns nicht in Verlegenheit zu bringen. Von der Verlegenheit abgesehen fanden wir die Kommentare besonders nützlich und beschlossen, sie mit unseren Freunden zu teilen. Autor ist Bill Crowther.
Ich habe zwei wesentliche Fehler in dem Host Protocol Paper gefunden, das ansonsten ein ausgezeichneter Beitrag war. Beide betreffen ein Missverständnis der Natur des IMP als Kommunikationseinrichtung und insbesondere der Natur der Pufferung, die ein IMP vornehmen muss. Die Autoren betrachten das Netz als eine Einrichtung, in die man eine Nachricht hineinschiebt, die darin eine Weile umherwandert, in Puffern beträchtliche Zeit wartet und dann am Zielort wieder auftaucht. Tatsächlich wäre ein besseres Modell, dass die Nachricht einen Augenblick nach dem Einspeisen wieder herauskommt. Zwar gibt es eine Verzögerung, doch wird sie zum größten Teil von der Hardware der Telefonleitungen auferlegt. Die Pufferung im IMP ist minimal und dient der Fehlerkontrolle und kurzzeitigen Verkehrsspitzen.
Da wir einen Host nicht zwingen können, eine Nachricht anzunehmen, haben wir einen aufwendigen RFNM-Mechanismus gebaut, der neue Eingaben aussetzt, bis er dies tut. Dieser Mechanismus ist ein unvollkommener Versuch, ein sehr schwieriges Kommunikationsproblem zu lösen. Das Ziel ist, den Verkehr so zu regeln, dass in dem Augenblick, in dem der Host seine Nachricht aus dem IMP entnimmt, die nächste Nachricht auf der Telefonleitung eintrifft und überhaupt keine Pufferung auftritt.
Tatsächlich erreichen wir das nicht und haben deshalb eine Pufferung für Verkehrsspitzen eingebaut. Diese Puffer sind für ihren vorgesehenen Zweck nutzlos, wenn sie nicht leer sind. Nur leere Puffer stehen zur Verfügung, um eine Verkehrsspitze aufzufangen.
Die beiden konkreten Fehler finden sich auf den Seiten 5 und 23. Auf Seite 5 sagen die Autoren: „Diesem Zweck liegt die Annahme zugrunde, dass ein Benutzer nicht mehrere Verbindungen nutzt, um eine breite Bandbreite zu erzielen.“ In Wirklichkeit ist eines der Hauptziele von Verbindungen, eine breitere Bandbreite zu erzielen.
Wir möchten eine möglichst große Bandbreite zulassen. Unsere Schwierigkeiten treten nicht bei großer Bandbreite auf, sondern bei einem Ungleichgewicht von Eingabe und Ausgabe. Die Autoren haben richtig bemerkt, dass mehrere Verbindungen den RFNM-Mechanismus untergraben und unsere Aufgabe erschweren, haben aber die Natur des Problems falsch bezeichnet.
Wieder auf Seite 5: „Eine noch grundlegendere Annahme ist natürlich, dass die Last des Netzes von einigen Benutzern stammt, die Folgen von Nachrichten senden, und nicht von vielen Benutzern, die zufällig einzelne Nachrichten senden.“ Wir sind gegen Benutzer einzelner Nachrichten sehr gut gerüstet, wenn ihre Nachrichten in zufälliger Beziehung zueinander stehen. Die Statistik spricht ganz für uns, und für die (seltenen) Zufälle haben wir besondere Verfahren. Unsere Probleme entstehen bei den nicht zufälligen Zusammentreffen, und wir haben besondere Vorkehrungen gegen Benutzer getroffen, die Schübe (Folgen) von Nachrichten senden. Wir nehmen alle Arten von Benutzern an und schützen uns entsprechend.
Auf den Seiten 23 und 24 stehen 4 entscheidende Sätze, die nahelegen, dass das Systemdesign hätte verbessert werden können, indem man den Host angeben lässt, welche von mehreren wartenden Eingaben er annehmen möchte. Wir geben zu, dass der Host diese Nachrichten für seine Benutzer puffern muss, bestreiten aber entschieden, dass der IMP die Fähigkeit hat, diese Pufferung vorzunehmen.
Wenn wir im idealen Modus arbeiten, hätten wir zu jedem Zeitpunkt höchstens eine Nachricht für den Host. Haben wir mehr als eine, brauchen wir dringend, dass der Host diese Nachrichten annimmt, weil unsere Fähigkeit, Verkehrsspitzen zu bewältigen, dann unter dem Standard liegt. Derzeit lassen wir drei Nachrichten voller Länge in einem IMP für seinen Host zu, bevor wir beginnen, den Verkehr im Netz aufzustauen. „Drei“ reicht nicht, um dem Host zu helfen und zugleich eine Reserve für Verkehrsspitzen zu behalten.
Aber wenn eine Pufferung nötig ist, warum nicht mehr Speicher beschaffen und sie im IMP vornehmen? Weil die Pufferung eine Aufgabe des Hosts ist, in jedem Teilnehmersystem anders ausfällt, über einen stark belasteten seriellen Kanal schwer zu steuern ist, an manchen Stellen vielleicht gar nicht gebraucht wird und besser dort erfolgt, wo der zusätzliche Speicher vom Betriebssystem des Hosts effizient mitgenutzt werden kann.
Ich wiederhole: Die Puffer des IMP müssen leer sein, sonst erfüllen sie ihren Kommunikationszweck nicht.
Die beanstandeten Sätze sind:
Paragraph 2 sentence 3
" 3 all
" 4 sentences 1 and 2 (80ms is hardware screw adjustable)
" 4 sentence last
Hinweis: Dieses RFC wurde von Jeff & Christy McClellan 2/98 für die Aufnahme in die Online-RFC-Archive in maschinenlesbare Form gebracht.