Zusammenfassung

  • RFC 1077 war ein informatorisches Forschungsprogramm, keine Spezifikation eines bereits eingesetzten Gigabit-Netzes. Es ordnete die Arbeit zwischen optischer Kapazität und nutzbarem Zugang.
  • Die Grundannahme drehte sich um: Trunks wurden schneller als die Schaltelemente. Knappheit konnte vom Übertragungsmedium in Elektronik, Paketverarbeitung, Speicher und Host-Schnittstellen wandern.
  • Spätere RFCs trennten Gerätebenchmark, Dienstzusage und Pfadbeobachtung. Keine dieser Aussagen ist mit der nominellen Leitungsrate identisch.

Die Faser lieferte einen Rohstoff, kein Ergebnis

RFC 1077 sah in der bereits verlegten Glasfaser aggregierte Gigabit-Kapazität und rohe Bandbreite bis nahe an Terabit pro Sekunde. Der Bericht machte daraus jedoch keine Leistungszusage. Er fragte, wie einzelne Nutzer mehrere Gigabit erhalten und zugleich sehr große Nutzerzahlen mit einigen Megabit kostengünstig bedient werden könnten.

Rohbandbreite beschreibt eine physische Übertragungsmöglichkeit. Ein Dienst muss diese Möglichkeit durch Geräte, konkurrierende Last, Zugänge und Anwendungsanforderungen hindurch realisieren.

Die von DARPA einberufene Gigabit Working Group schrieb einen Informationsbericht. Gigabit-Backbone, Verbundnetze mit Management und eine Zugangsarchitektur waren vorgeschlagene Forschungs- und Demonstrationsfelder. Die Beispiele sollten Fragen klären, nicht eine bestimmte Lösung festschreiben. Das Dokument belegt weder flächendeckenden Betrieb noch eine Normarchitektur.

Seine Stärke liegt gerade im unfertigen Zustand: Es zeigt, welche Systemarbeit eine eindrucksvolle physische Zahl nicht erledigt.

Der Engpass zog in die Elektronik um

Frühere Weitverkehrsnetze behandelten Bandbreite als teure, knappe Ressource. Die Vermittlung sollte den Kanal möglichst effizient verwenden. RFC 1077 beobachtete nun, dass die Trunk-Geschwindigkeiten schneller stiegen als die Geschwindigkeiten der Schaltelemente.

Licht transportierte die Bits, doch Elektronik musste Ziele bestimmen, puffern, steuern und abrechnen. Klassische Paketvermittlung verursachte Arbeit pro Paket. Mehr Bit pro Sekunde bedeutete daher nicht automatisch mehr verarbeitete Pakete pro Sekunde. Kleine Pakete konnten die Logik auslasten, während die beworbene Bitrate noch frei aussah.

Danach konnte der Host begrenzen. Der Bericht erwartete, dass Paketverarbeitung im Rechner hohe Datenströme von Anwendungen fernhielt, obwohl der Backbone insgesamt große Mengen trug. Speicherkopien, Protokollarbeit, Peripherie und Netzwerk-Frontend gehörten zum Lieferweg.

Die Knappheit verschwand nicht. Ein schnelleres Medium legte offen, welches nächste Bauteil nun den Durchsatz bestimmte.

Derselbe Gesamtwert konnte völlig andere Last bedeuten

RFC 1077 unterschied wenige Geräte mit sehr hohem Einzelbedarf von Millionen moderater Nutzer, deren Verkehr sich zu derselben Größenordnung addierte. Statistik, Burst-Verhalten und Steuerbarkeit waren verschieden.

Auch Anwendungen verlangten mehr als Durchsatz. Der Bericht trennte Verzögerung, Verzögerungsstreuung, Zuverlässigkeit und geordnete Zustellung. Massentransfer kann warten, interaktive Simulation nicht. Sprache und Video brauchen Regelmäßigkeit. Netzsteuerung belegt wenig Bandbreite, darf aber nicht beliebig verdrängt werden.

Verbindungsorientierte, verbindungslose und synchrone Kommunikation erhielten unterschiedliche Rollen. Für den synchronen Strom beschrieb RFC 1077 eine Reservierung, die eine konstante Bandbreite bereitstellt. Diensttyp, Richtlinie, Fairness und Vorabreservierung gehörten ebenfalls in die Aufgabe.

Damit entstand eine eigene Zuteilungsebene. Die Anwendung sollte ihren Bedarf ausdrücken, das Netz darüber entscheiden. Doch Anwendungen waren nicht daran gewöhnt, „schnell“ in Rate, Verzögerung, Verlusttoleranz und Dauer zu übersetzen. Die verfügbare Leitungskapazität formulierte keinen korrekten Antrag.

Management war kein nachträgliches Bedienfeld

RFC 1077 nannte die nächste Architektur zuallererst eine Managementarchitektur. Wenn Leitungen, Prozessoren und Speicher einfache Leistungsprobleme lösten, konnten größere Systeme komplexere Leistungs-, Zuverlässigkeits- und Sicherheitsprobleme erzeugen.

Zum Management zählten Abrechnung, Sicherheit, Leistungsüberwachung, Fehlerisolierung und Konfiguration. Abrechnung erfasste etwa zugeteilte Bandbreite, Pakete oder Ports, um eine Nutzungsrichtlinie umzusetzen. Sie belegte Zuteilung oder Kosten, nicht den Empfang bei der Anwendung.

Leistungsüberwachung erzeugte eine andere Beobachtung. Der Bericht wollte von Beschwerden und Reaktion zu früher Diagnose und dynamischer Ressourcenzuteilung gelangen. Zugleich sagte er eine Flut roher Managementdaten voraus. Schwellen, Filter und Warnungen sollten den Menschen entlasten, ohne den diagnostischen Zugriff abzuschneiden.

Mehr Geschwindigkeit brachte also auch mehr Zustand, der erklärt und gesteuert werden musste.

Gerätefähigkeit braucht eine Versuchsbeschreibung

RFC 1242 definierte später den Durchsatz eines Kopplungsgeräts als höchste angebotene Frame-Rate, bei der kein Frame verloren geht. Das ist nicht die nominelle Rate des Mediums.

Frame-Größe, Richtung, Routing oder Bridging, Prüfsummen und Nebenaufgaben verändern das Ergebnis. Latenz, Verlust, Überlast, Zusatzverarbeitung und Bursts wurden getrennt behandelt. Ein Gerät kann große, gleichmäßige Frames bewältigen und bei kleinen Paketen oder Routing-Updates anders reagieren.

RFC 2544 machte die Prüfung vergleichbar: theoretische Medienrate und gemessenen Durchsatz gegenüberstellen, Latenz bei der ermittelten Rate messen und Verlust über Lasten und Frame-Größen berichten. Ein herausgehobener Werbewert sollte die vollständigen Bedingungen nicht verdrängen.

Das Ergebnis charakterisiert ein isoliertes Gerät in deklarierter Konfiguration. Es ist noch keine Messung eines Produktionspfads, keine Anwendungsdauer und kein Service-Level.

Eine Zusage bleibt etwas anderes als eine Ankunft

RFC 1633 widersprach später der These, reichlich Glasfaser mache explizites Ressourcenmanagement überflüssig. Günstig wirkende Rohbandbreite ist nicht überall als günstiger, konfliktfreier Netzdienst verfügbar.

Integrated Services verband Reservierung und Zulassungskontrolle. Klassifikation, Scheduler und Zulassungsentscheidung bestimmten die Behandlung eines Flows. Das war eine Steuer- und Zusageebene, nicht die physische Faser und nicht die spätere Beobachtung.

RFC 2212 beschrieb eine starke bedingte Garantie. Hält der Flow seine Verkehrsparameter ein und unterstützen die Pfadelemente den Dienst, lässt sich die Warteschlangenverzögerung begrenzen und Überlaufverlust vermeiden. Feste Pfadverzögerung blieb separat. RSVP, manuelle Konfiguration oder Management konnten die Reservierung einrichten.

Eine angenommene Reservierung belegt eine Zusage im Modell. Sie belegt nicht allein, dass der Pfad gleich blieb, jedes Element konform blieb oder der Empfänger das Ergebnis sah.

Der Pfad musste selbst beobachtet werden

RFC 2679 definierte Einwegverzögerung mit Quelle, Ziel, Pakettyp und Zeitpunkt. Einzelwert, Stichprobe und Statistik blieben getrennt. Uhrensynchronität, Messunsicherheit und die Grenze zwischen sehr spät und verloren gehörten zur Interpretation.

RFC 3393 definierte Paketverzögerungsvariation als Differenz ausgewählter Einwegverzögerungen. Sie hilft bei Wiedergabepuffern und beim Verständnis von Warteschlangen, ist aber weder Kapazität noch mittlere Verzögerung oder universeller „Jitter“-Wert.

Aus der Forschungsfrage ergeben sich vier Beweisebenen:

  1. Rohkapazität des Mediums unter bestimmten Annahmen;
  2. Verarbeitungsfähigkeit von Schaltern und Hosts unter einer Last;
  3. Dienstbehandlung, die zugeteilt oder bedingt garantiert wurde;
  4. gelieferte Leistung, die Beobachter auf einem Pfad und in einem Zeitraum maßen.

Die Ebenen beeinflussen einander, dürfen einander aber nicht vertreten. Glasfaser ist kein Benchmark; ein Benchmark ist keine Reservierung; eine Reservierung ist keine beobachtete Zustellung.

Die gefährlichste Bandbreite hat kein Etikett

RFC 1077 vollendete kein Gigabit-Internet. Es hinterließ die genauere Regel, das schnellste Bauteil nicht als Dienst auszugeben. Technische Fülle an einer Stelle kann Systemmangel an einer anderen sichtbar machen.

Jede Geschwindigkeitszahl braucht deshalb Schicht, Verantwortlichen, Richtung, Paketform, Last, Pfad und Zeitfenster. Ist sie Kapazität, Fähigkeit, Zusage oder Ergebnis?

Die Glasfaser war schnell. Der Dienst blieb bis zum Empfänger ein ganzes System.

Quellen und Beweisgrenzen

RFC 1077 liefert die Forschungsagenda von 1988; RFC 1242 und RFC 2544 die Grenze der Geräteprüfung; RFC 1633 und RFC 2212 die Dienstzusage; RFC 2679 und RFC 3393 die Pfadbeobachtung. Sie belegen veröffentlichte Modelle, nicht universelle Einführung, heutige Produktleistung oder eine direkte Abstammung von RFC 1077.