Zusammenfassung

  • RFC 872 widersprach der Vermutung, TCP sei für ein schnelles, fehlerarmes lokales Netz grundsätzlich ungeeignet. Der Dienst, den die Anwendung brauchte, gab die entscheidende Frage vor.
  • Padlipsky sah Einsatzfälle für UDP oder einen direkten lokalen Weg. Ein zweiter Protokollstapel für das LAN kostete allerdings Entwicklung und Pflege, wenn dieselben Rechner auch andere Netze erreichen mussten.

Ein kurzes Kabel, ein schnelles LAN: TCP konnte dort aussehen wie ein Gast, der für einen Besuch im Nachbarzimmer einen Überseekoffer mitbringt. Michael A. Padlipsky sah in seiner RFC 872 vom September 1982 genauer in den Koffer. Die Sorge über „TCP auf einem LAN“ war durch Wiederholung gewachsen. Er verglich sie mit einem erdachten Wesen, dessen Spuren sich als die eigenen herausstellen. Seine Pointe traf einen technischen Kurzschluss: Aus den Eigenschaften der Leitung wurde auf die Bedürfnisse der Programme geschlossen.

Zuerst definierte Padlipsky das LAN seines Arguments. Es übertrug Daten auf kurzer Strecke mit hoher Rate und wenigen Fehlern; unterschiedlich gebaute Rechner konnten darüber Informationen und Ressourcen austauschen. Medium und Form des Netzes waren variabel. Entscheidend war die Kommunikation zwischen den Hosts. Eine Anlage, in der Terminals lediglich Zugang zu mehreren Rechnern hatten, ohne dass die Rechner selbst über Host-Protokolle miteinander sprachen, fiel für ihn unter einen anderen Begriff. Das schnelle Übertragen von Bits lieferte noch keine Antwort darauf, welche Dienste eine Anwendung an den Enden erwartete.

TCP stellte für passende Anwendungen eine zuverlässige logische Verbindung bereit, regelte den Datenfluss und lieferte in der richtigen Reihenfolge. Eine Datei blieb auch dann eine Datei mit Anfang, Mitte und Ende, wenn der Empfänger im selben Gebäude stand. Ein fehlerarmer Link half beim Transport. Er gab einem Programm keinen Grund, fehlende oder vertauschte Teile plötzlich hinzunehmen. Die Entfernung zwischen den Geräten unterschrieb keine Änderung des Anwendungsvertrags.

IP hatte eine eigene Aufgabe. Padlipsky trennte es von TCP: IP bestimmte, ob ein Ziel auf dem nahen Netz lag oder ein Gateway nötig war. Es berücksichtigte verschiedene Paketgrößen auf dem weiteren Weg und kennzeichnete, welchem oberen Protokoll Daten am Empfangsort zu übergeben waren. Durch die Trennung konnten auch andere Host-Protokolle diese Arbeit nutzen. Für einen Rechner, der neben lokalen Partnern auch entfernte Hosts erreichen sollte, war das LAN die erste Etappe einer längeren Reise. Selbst eine perfekte erste Etappe verringerte die Entfernung bis zum letzten Ziel um keinen weiteren Meter.

Andere Wege blieben offen. Paketisierte Sprache konnte einen Dienst mit geringerer Verzögerung höher schätzen als die Zuverlässigkeit von TCP; dafür nannte der Text UDP. Eine Anwendung für einen bestimmten Standort konnte Eigenschaften des lokalen Netzes direkt verwenden. Padlipsky fragte jedoch, was geschah, wenn dieselben Rechner zusätzlich einen eigenen Stapel für das LAN und TCP/IP für die Verbindung nach draußen betrieben. Zwei Sätze Software mussten geschrieben, getestet und gepflegt werden. Der Versuch, einem vermuteten Protokollgewicht auszuweichen, konnte den Betrieb mit echtem Zusatzgewicht beladen.

Die Leistungsfrage verlangte eine Messung. Auf einem Link mit wenigen Übertragungsfehlern mochte die TCP-Prüfsumme überflüssig wirken. Padlipsky berichtete über Messungen an mehreren Host-Typen aus der Forschungsgemeinschaft, bei denen diese Berechnung nur einen Teil der Verarbeitungszeit pro Sendung beanspruchte. Der Befund gehörte zu diesen Implementierungen von 1982. Für die Entscheidung zählte die ganze Kette: Daten vom Datenträger holen, Prozesse einplanen, Pakete bearbeiten, die Anwendung versorgen und eine Alternative unter denselben Bedingungen testen. Eine schnelle Leitung kann geduldig auf einen langsamen Rechner warten.

Die RFC führte laufende TCP/IP-Implementierungen und passende Anwendungsprotokolle an. Padlipsky forderte trotzdem sorgfältige Messungen im LAN. Eine besondere lokale Lösung konnte sich bei einer konkreten Aufgabe und einem nachgewiesenen Vorteil lohnen. Gleichwertige Funktionen und spätere Wartung gehörten dann in den Vergleich. Die auf dem Kabel angegebene Geschwindigkeit war eine wichtige Zahl, aber nur eine von mehreren.

Die RFC 872 überliefert einen Streit aus dem Jahr 1982 mit brauchbaren Fragen: Welche Eigenschaften verlangt die Anwendung? Muss der Host über das LAN hinaus sprechen? Wo wurde die Grenze tatsächlich gemessen? Sobald die Antworten auf dem Tisch liegen, verliert das Monster seine Schattenfläche.