Zusammenfassung

  • RFC 1272 argumentierte, dass IP-Endpunktadressen nicht erkennen ließen, welche benachbarte Verwaltungseinheit den Verkehr über eine Netzgrenze transportiert hatte.
  • Messpunkte an Grenzen konnten den Abgleich unterstützen; der sinnvolle Detailgrad hing jedoch von Topologie, Granularität, Speicher, Erhebungskosten und Sicherheit ab.
  • Das Memo trennte Nutzungsberichte von Abrechnung und Durchsetzung und ließ offen, ob Pakete am Routereingang oder -ausgang gezählt werden sollten.

Der fehlende Name war der des Nachbarn

Ein IP-Paket enthält Quell- und Zieladresse. Damit lässt sich Verkehr zwischen Endpunkten zählen. Daraus folgt aber nicht, welches Nachbarnetz das Paket in den Verwaltungsbereich eines Anbieters eingespeist hat. Wenn Daten eines Endsystems über verschiedene Nachbardomänen eintreffen können, beantwortet selbst eine vollständige Endpunktaufzeichnung nicht die engere Frage des Anbieters: Über welches Netz hat dieser Verkehr meine Grenze passiert?

RFC 1272 verlangte nicht, dass jedes Netz die Nutzung aller Internetnutzer abrechnet. Das Modell richtete den Blick auf den eigenen Verwaltungsbereich und die unmittelbar angeschlossenen Nachbardomänen. Ein Anbieter konnte den Verkehr über die Grenze zu einem Nachbarn messen und mit ihm eine Nutzungsaufstellung austauschen. Wollte dieser Nachbar seine eigenen Kosten weiter stromabwärts verteilen, lag das in seiner Verantwortung. Die Abrechnung war rekursiv: Jede Verwaltung behandelte die Beziehung, die sie beobachten konnte, statt eine globale Sicht auf den Endnutzer vorzutäuschen.

Damit ändert sich die Bedeutung des Messorts. Ein Host beobachtet den Verkehr an einem Endpunkt. Ein Router an einer Verwaltungsgrenze sieht den Verkehr, der in den lokalen Bereich hinein- oder hinausgeht, und kann Hinweise zu einer benachbarten Verbindung liefern. Das Memo hielt fest, dass IP-Header allein keine Identität dieses Zwischensystems enthalten; Informationen niedrigerer Schichten oder die Konfiguration der Grenzkomponenten konnten erforderlich sein. Endpunktadressen und Abrechnungsgrenze beantworteten verschiedene Fragen.

Messen verursachte eigene Kosten

Der Messort war nur eine Designentscheidung. RFC 1272 beschrieb dedizierte Netzwerkmonitore, Leitungsmessgeräte, Softwarezähler im Router und koordinierte „router spiders“. Der geeignete Ort hing von Topologie und Messaufgabe ab. Eine Messung an der Grenze konnte Anbieter und Kunde beim Abgleich unterstützen, war aber keine pauschale Aufforderung, jeden Router auszurüsten.

Das Memo behandelte Detail als technische und wirtschaftliche Entscheidung. Ein Messgerät konnte nach Port, Netz oder Host zählen, Paketattribute ergänzen, Zähler oder Zeitstempel speichern und in unterschiedlichen Intervallen berichten. Jede Kombination aus Einheit und Attribut konnte einen zusätzlichen Flow-Datensatz erfordern. Höhere Granularität beanspruchte Speicher und Rechenleistung; häufigere Berichte kosteten Bandbreite und Kollektorkapazität. Wenn vollständige Genauigkeit und Zuverlässigkeit gefordert waren, musste jedes Paket untersucht werden.

Für Verhaltensanalyse, Netzoptimierung oder eine ungefähre Kostenquote konnte Sampling günstiger und ausreichend sein. Das sind unterschiedliche Beweismaßstäbe.

Auch die Sammlung selbst musste geschützt werden. Die Autoren behandelten Nutzungsdaten als sensibel und nannten Vertraulichkeit, Integrität und Kontrolle der Erhebung als Probleme. Sie diskutierten Bestätigungen mit erneuter Übertragung, redundante Kollektoren oder Sicherungsspeicher am Messgerät. Ein an einem Grenzrouter erfasster Wert ist nicht allein deshalb vollständig und vertrauenswürdig.

Ein Bericht war weder Rechnung noch Regel

RFC 1272 begrenzte den eigenen Zweck ausdrücklich. Das Memo lieferte Hintergrund für eine Architektur zur Nutzungsberichterstattung und spezifizierte keinen Internetstandard. Berichte konnten Nutzern helfen, ihr Verhalten zu verstehen, Anbietern die Messung der Richtlinieneinhaltung ermöglichen oder eine Kostenverteilung unterstützen. Berichterstattung allein setzte jedoch keine Richtlinie durch; das Dokument empfahl auch keine Abrechnungspraxis. Ebenso wenig entschied es, wer für erneut gesendete Pakete zahlen sollte.

Eine Frage blieb bewusst offen: Soll ein Paket gezählt werden, wenn ein Router es empfängt, oder erst, wenn er es weiterleitet? Bei Überlast kann ein Router Pakete verwerfen. Eine Zählung am Eingang bildet die durch angebotenen Verkehr verbrauchten Ressourcen ab; eine Zählung am Ausgang vermeidet die Abrechnung nicht weitergeleiteter Pakete. RFC 1272 verlangte, beide Möglichkeiten vorzusehen, weil die Wahl von Kontext und Richtlinie abhing und nicht von einer universellen technischen Wahrheit.

Später spezifizierte RFC 2722 eine Architektur zur Messung von Verkehrsflüssen. Diese spätere Arbeit gehört zur Geschichte der Messsysteme, beweist aber weder die Einführung eines bestimmten Abrechnungsmodells noch die Umsetzung der gesamten Abrechnungsvorstellung von 1991. Die dauerhafte Frage aus RFC 1272 ist enger: Was kann eine Verwaltung an ihrer Grenze tatsächlich wissen, und welche Messkosten lohnt es zu tragen? Die Beweiskette vom beobachteten Flow über den identifizierten Nachbarn und den Bericht bis zu einer späteren Preis- oder Kontrollentscheidung muss erhalten bleiben.

Nichts davon folgt automatisch aus den IP-Adressen an den Paketenden.

Quellen: RFC 1272; RFC 2722; RFC 2990.