Zusammenfassung

  • RFC 1152 dokumentiert im April 1990 einen Workshop zu sehr schnellen Netzen. David Clark hielt bestehende Protokolle für gigabitfähig, sofern allein die Übertragungsrate zählte; Entfernung, Nutzerzahl und neue Dienste verlangten weitere Entscheidungen.
  • Keith Lantz stellte Multimedia mit geringem Zeitversatz und synchronen Strömen vor. Craig Partridge untersuchte die Wartezeit entfernter Prozeduraufrufe. Vorläufige Nectar-Messungen zeigten, dass ein Host deutlich weniger Daten an seine Prozesse liefern konnte, als seine Kommunikationskarten austauschten.

Die Anforderung saß am Schreibtisch

Der Workshop wurde von der Internet Research Steering Group gefördert, die zur IRTF gehört. Craig Partridge verfasste den Bericht aus Sitzungsprotokollen, die Teilnehmer überprüften. Darin stehen Experimente, Entwürfe und widersprechende Vorschläge nebeneinander. Gerade dadurch wird sichtbar, dass eine hohe Bitrate noch keine vollständige Aufgabenbeschreibung war.

David Clark eröffnete die Sitzung zur Protokollimplementierung mit einer Trennung, die den Ehrgeiz erdete. Vorhandene Protokolle könnten nach seiner Einschätzung ein Gigabit pro Sekunde erreichen, wenn es nur darum gehe. Künftige Netze sollten aber große Entfernungen überbrücken, viele Nutzer bedienen und Dienste wie reservierte Bandbreite bereitstellen. Erst mit diesen Anforderungen ließen sich Architekturvorschläge beurteilen. Andere Vorträge behandelten ausgelagerte Protokollprozessoren und effizientere Implementierungen. Jeder Vorschlag löste einen anderen Teil des Problems.

Keith Lantz sprach in der Anwendungssitzung vom „portablen Büro“. Er meinte Zugang zu denselben Diensten und Menschen von zu Hause, aus dem Unternehmen oder aus der Ferne, nicht lediglich einen leichteren Rechner. Eine Desktop-Konferenz würde Text, Grafik, Ton und Video gemeinsam befördern. Die Datenströme verlangten sehr unterschiedliche Kapazitäten, meist niedrige Verzögerungen, teils geringen Jitter und immer Abstimmung untereinander. Ein breiter Kanal nützt wenig, wenn das Bild die Lippen bewegt und die Stimme erst später die Sitzung betritt.

Lantz verlangte außerdem Anpassung an überlastete oder langsamere Strecken. Auflösung und Qualität sollten sich ändern können, damit ein Dienst auch bei geringerer Kapazität weiterläuft. Ein Nutzer reist zwischen Netzen; seine Arbeit kann nicht an der schnellsten Teilstrecke festgebunden werden.

Der entfernte Aufruf ließ den Prozessor warten

In der Sitzung zu verteilten Systemen griff Partridge die Zeit eines Remote Procedure Call auf. Rechner wurden schneller, während eine Anfrage und ihre Antwort die Entfernung weiterhin überwinden mussten. Die Lichtgeschwindigkeit ließ sich nicht mit einem neuen Prozessor bestellen. In den zusätzlichen Rechenzyklen gemessen, wurde das Warten immer teurer. Mehrere unabhängige Aufrufe konnten parallel laufen; eine Kette abhängiger Aufrufe blieb an jede einzelne Antwort gebunden.

Partridge sah auch die Rechnung großer Caches. Daten vor Ort zu halten spart manche Anfrage, doch die Kopien müssen untereinander konsistent bleiben. Dann entstehen Synchronisationsaufrufe, um gewöhnliche Aufrufe einzusparen. Er bevorzugte größere gebündelte Arbeiten für denselben Zielrechner. Andere Teilnehmer setzten auf Vorauslesen oder asynchrone Programmiermodelle. Der Bericht bewahrt diese Ansätze als Debatte, statt einen späteren Sieger rückwirkend auszurufen.

Bei Carnegie Mellons Nectar-Prototyp zeigte sich der Engpass im Host. Die im Bericht genannten vorläufigen Ergebnisse lagen bei 70 Mbps zwischen Prozessen auf Kommunikationskarten, aber bei etwa 25 Mbps für Prozesse auf den Rechnern; die VME-Schnittstelle begrenzte sie. Diese Zahlen beschreiben jenes System. Sie illustrieren, warum eine schnelle Verbindung am Gehäuse noch keinen schnellen Dienst im Programm ergibt. Jeff Mogul verwies zudem auf die Kosten, Pakete in den CPU-Cache zu bringen und den wartenden Prozess zu benachrichtigen.

Der Workshop hinterließ keine Wunderlösung. Er legte eine Prüffrage vor: Wann ist die Aufgabe des Nutzers tatsächlich erledigt? Dazu zählen Entfernung, mehrere synchronisierte Medien, langsame Abschnitte und die Übergabe vom Netz an die Anwendung. Ein Gigabit konnte die erste Etappe gewinnen und am Schreibtisch trotzdem verspätet eintreffen.