Zusammenfassung

  • Die Tagesordnung von NANOG 1 kündigte an, dass die Tagung am 2. und 3. Juni 1994 in Ann Arbor über das MBONE übertragen werden sollte.
  • Juni-Nachrichten halten unterschiedliche Erfahrungen fest: An einem Standort war keine Sitzung zu finden, eine Person bat um ein Bild der Leinwand, und bei CERN kamen Pakete ohne Verlust an, während viele Fragen unhörbar blieben.
  • Multicast-Zustellung, das Auffinden einer Sitzung und verständlicher Ton aus dem Raum sind verschiedene Teile eines Mediendienstes. Die Nachrichten belegen weder die Gesamtzahl der Teilnehmenden noch eine allgemeine Erfolgsquote.

Mikrofon und Bildausschnitt lagen außerhalb des Routings

Nach dem Netzübergang blieb eine zweite Kette: Kameraposition, Sicht auf die Leinwand, Mikrofonaufnahme, mögliche Mischung oder Codierung und Wiedergabe am Ziel. Die Bitte, die Leinwand zu zeigen, verweist auf eine praktische Entscheidung darüber, was entfernte Zuschauer sehen konnten. Martins Nachricht von CERN zeigt eine andere Trennung: Der Paketempfang konnte störungsfrei sein, während Fragen aus dem Saal trotzdem schwer verständlich blieben.

Nichts belegt, dass die Übertragung eine Beteiligung aus der Ferne ermöglichen sollte. Die Tagesordnung kündigt eine Übertragung an, aber kein fernes Mikrofon, keine Fragenwarteschlange und kein Rederecht. Die Nachrichten sagen auch nicht, ob Fragen außerhalb der Mikrofonreichweite gestellt wurden, ob sich der Bildausschnitt änderte oder ob der Ton später korrigiert wurde. Ihr Wert liegt darin, begrenzte Beobachtungen festzuhalten, nicht in einer vollständigen Rekonstruktion der Produktion.

Das Programm machte den Netzbetrieb zum Thema

Die erste NANOG-Tagung fand am 2. und 3. Juni 1994 in Ann Arbor, Michigan, statt. Eine am 26. Mai an die Mailingliste gesendete Tagesordnung hielt fest, dass die Organisatoren die Veranstaltung aus dem Chrysler Center über das MBONE übertragen wollten. Das Programm behandelte konkrete Fragen des Netzbetriebs: technische Anschlüsse an Network Access Points (NAPs), deren Dienste und Betrieb, Routing in einem ATM-Testnetz, Verwaltung von Route-Servern, PRDB und Routing-Registries.

Das passt zusammen. Im Saal ging es darum, wie sich Providernetze verbinden und betreiben ließen. Wer die Tagung von außen verfolgen wollte, war ebenfalls darauf angewiesen, dass mehrere Netze den Stream transportierten. Die Übertragung war ein weiterer Betriebsdienst mit eigenen Abhängigkeiten: Die Sitzung musste angekündigt und gefunden werden, Multicast musste auf dem Weg funktionieren, und die Medienaufnahme im Raum musste brauchbares Material liefern.

Das Juni-Archiv ist kein durchgehender Ende-zu-Ende-Messbericht. Es bewahrt voneinander getrennte Nachrichten auf. Am 2. Juni fragte Dave Sincoskie, ob die Tagung über das MBONE gesendet werde. Er habe mit einer Teilnahme gerechnet, schrieb er, finde aber keine übertragene Sitzung. In einer anderen Nachricht am selben Tag bat Hans-Werner darum, die Kamera auf die Leinwand statt auf den Sprecher zu richten und ruhig zu halten. Am folgenden Tag berichtete Olivier Martin von CERN, dort sei kein Paket verloren gegangen, viele Fragen seien jedoch nicht zu hören gewesen.

Das sind weder drei Messungen desselben Empfängers noch eine gemeinsame Fehlerdiagnose. Sincoskies Nachricht betrifft die Sitzungssuche, Hans-Werners die Bildgestaltung und Martins die Differenz zwischen Paketempfang und Verständlichkeit der Fragen. Das Archiv nennt weder die verwendete Anwendung noch die Mikrofonanordnung im Raum oder die genaue Ursache dieser Erfahrungen.

Der MBONE war kein allgemeiner Internetdienst

IP-Multicast ermöglicht es einem Sender, Datagramme an eine Hostgruppe zu richten, ohne für jeden Zuhörer zwingend eine eigene Kopie des Streams zu erzeugen. RFC 1112 von 1989 beschreibt dynamische Gruppenmitgliedschaften und weist die Weiterleitung zwischen Netzen Multicast-Routern zu. Die Zustellung bleibt Best-Effort: Weder vollständiger Empfang noch die ursprüngliche Reihenfolge der Datagramme sind garantiert. „Multicast“ bedeutete also nicht, dass jedes Gerät mit Internetanschluss die Übertragung automatisch erhielt.

1994 war diese Einschränkung praktisch relevant. RFC 1633 vom Juni 1994 beschreibt Audio- und Video-Multicasts von IETF-Tagungen als groß angelegte Internetexperimente. IP-Multicast sei in kommerziellen Routern noch nicht allgemein verfügbar gewesen; das vorläufige MBONE habe diese Funktion bereitgestellt. Das Dokument nennt außerdem variable Warteschlangenverzögerungen und Verluste durch Überlast als Probleme für Echtzeitanwendungen. Es beschreibt den damaligen technischen Rahmen, aber nicht nachträglich den konkreten NANOG-Stream.

Ein Empfänger musste außerdem wissen, welcher Sitzung er beitreten sollte, und einen lokalen Pfad haben, der Gruppenverkehr annahm. Sincoskies Nachricht klärt nicht, ob eine Ankündigung fehlte, die lokale Konfiguration nicht passte, die Multicast-Reichweite endete oder ein anderer Grund vorlag. Sie belegt nur, dass er die erwartete Sitzung an seinem Standort nicht fand.

Analyse

Die ursprüngliche NANOG-Charta vom Januar 1994 beschreibt ein Forum für technischen Informationsaustausch und Implementierungsfragen, die Zusammenarbeit zwischen Netzanbietern erfordern. Die Tagesordnung der ersten Tagung entspricht diesem Rahmen: NAP-Anschlüsse und -Betrieb, Routing im Testnetz und Route-Server-Verwaltung waren konkrete Koordinationsaufgaben. Der MBONE-Stream stellte ein verwandtes Betriebsproblem: Damit die Tagung aus der Ferne nutzbar wurde, musste man die angekündigte Sitzung finden, multicastfähige Netze durchqueren und Medien empfangen, die mehr als das Bild des Vortragenden enthielten.

Die Belege tragen nur eine begrenzte Schlussfolgerung. Ein Zuhörer bei CERN meldete keinen Paketverlust, aber unvollständigen Ton der Fragen; eine andere Person fand die Sitzung nicht; eine dritte bat um einen anderen Bildausschnitt. Das beweist weder ein allgemeines Scheitern der Übertragung noch einen vollständigen Fernzugang. Sichtbar werden mehrere Kontrollpunkte, die ein Paket-Zähler allein nicht beschreiben kann.

Aus dem Archiv lässt sich ebenso wenig ableiten, wer teilnahm, wer vertreten war, was der Saal entschied oder ob ein abwesender Netzbetreiber eine Position autorisiert hatte. Ein erreichbarer Stream belegt einen technischen Pfad, nicht die Befugnis des Forums oder die Erfahrung jeder Person, die man erreichen wollte.

Quellen