Zusammenfassung

  • RFC 5136 behandelt eine Kapazitätszahl ohne Protokollschicht, Paketpopulation, Endpunkte und Messintervall als unvollständig.
  • Die nominale physische Link-Kapazität ist eine theoretische Obergrenze, nicht die verfügbare IP-Kapazität eines Flusses.
  • IP-Kapazität zählt korrekt empfangene IP-Bits am Ziel und beweist nicht die Nutzbarkeit durch eine Anwendung.
  • Type P benennt die gemessenen Pakete, weil Markierung, Queue, ACL, Routing und Lastverteilung die Behandlung verändern.
  • Nutzung ist tatsächlich empfangener Verkehr; Auslastung ist dieses Volumen geteilt durch eine ebenfalls qualifizierte Kapazität.
  • Verfügbare Kapazität ist der ungenutzte Anteil im Intervall; beim Pfad zählt das kleinste Link-Ergebnis.
  • Der narrow link mit kleinster Kapazität und der tight link mit kleinster verfügbarer Kapazität müssen nicht identisch sein.
  • Ohne T und I ist weder ein sicherer Vergleich noch eine Aussage über den aktuellen Zustand möglich.
  • Periodisches Sampling kann sich mit periodischer Last synchronisieren und denselben Bias immer wieder bestätigen.
  • Duplikate, Header und Wiederholungen belasten das Netz, ohne zwingend einzigartige Nutzdaten zu liefern.
  • Bulk Transfer Capacity misst einzigartige Daten eines stauabhängigen Transports und entspricht nicht den IP-Größen aus RFC 5136.
  • Führung muss physische Möglichkeit, IP-Beobachtung, aktuelle Reserve, vertraglichen Anspruch und Anwendungsergebnis trennen.

Eine richtige Zahl kann die falsche Frage beantworten

Ein Inventar nennt 10 Gbit/s. Für den Portmodus kann diese Zahl präzise sein. Sie sagt noch nicht, wie viele IP-Bits zwischen den betreffenden Endpunkten korrekt ankommen, welche Paketklasse welchen Pfad erhält oder welche Reserve während der Hauptverkehrszeit besteht.

RFC 5136 nennt das physische Maximum NomCap(L). Es ist der theoretische Höchstwert des Links und dient als Obergrenze. Es bestimmt nicht automatisch die späteren IP-Größen. Codierung, Framing, Fehler, Paketlängen und Geräteverarbeitung liegen zwischen physischem Etikett und IP-Empfang.

Der Inventarbeleg bleibt notwendig. Er darf nur nicht ohne neue Evidenz zum Pfadbeleg, zur Reservierung, zum Kundenanspruch und zum Anwendungserfolg werden. Jeder dieser Schritte fügt eine Behauptung hinzu, die der Port nicht gemessen hat.

Die Stärke des RFC liegt deshalb nicht in einer besseren Einzelzahl. Er gibt der Zahl ihr Subjekt zurück: welche Schicht, welche Pakete, welche Quelle und welches Ziel, welcher Start und welche Dauer.

Was ein IP-Zähler anerkennt

IP-Bits sind achtmal die Oktette korrekt empfangener IP-Pakete vom ersten Header-Oktett bis zum Ende der Nutzlast. Gemessen wird am Ziel D von T bis T+I. Start und Intervall sind Bestandteil des Ergebnisses.

Unterhalb von IP beschädigte und nicht weiterleitbare Daten zählen nicht. Pakete mit ungültigem IP-Header ebenfalls nicht. Die Gültigkeit höherer Schichten ist jedoch nicht gefordert. Verarbeitbare Fragmente zählen, selbst wenn keine vollständige Anwendungseinheit entsteht.

Damit kann eine grüne IP-Messung neben einem roten Anwendungsergebnis stehen. Header, Fragmente, wiederholte Nutzlast und Duplikate verbrauchen echte Ressourcen, sind aber nicht zwangsläufig neue Nutzinformation. Die IP-Metrik ist nicht falsch; ihre Verallgemeinerung wäre falsch.

Schneidet eine Intervallgrenze ein Paket, wird der partielle Anteil ausgeschlossen. In kurzen oder dünn belegten Fenstern kann das den Mittelwert verzerren. Wer nur die Rate speichert, löscht die Grundlage für eine spätere Prüfung.

Type P macht die Netzpolitik sichtbar

Pakete zwischen denselben Endpunkten können verschieden behandelt werden. Markierungen wählen Queues, ACLs filtern Protokolle, Routing-Regeln ändern den Pfad und Hashing verteilt Flüsse. Type P beschreibt die Population, auf die sich das Ergebnis bezieht.

Ein Anbieter kann einen breiten Typ für die Ressourcensicht wählen. Ein Anwendungsnutzer kann einen engen Typ wählen, der dem Produktivfluss entspricht. Beide Perspektiven sind legitim. Eine bevorzugte Sonde spricht aber nicht automatisch für normalen Verkehr, und ein enger Anwendungstest nicht für den gesamten Link.

Auch konkurrierender Verkehr gehört zum Kontext. Ein Test bei leerer Prioritätsklasse ist keine ewige Eigenschaft. Ändern sich Mischung, Politik oder Route, ändert sich der operative Gegenstand trotz unveränderter Portbeschriftung.

Paketgröße verändert den Unterbau-Overhead. Kompression kann weniger physische Bits senden, obwohl die IP-Metrik die expandierte Länge zählt. Der Unterschied ist eine Schichttransformation und muss dokumentiert werden.

Kapazität, Nutzung und Reserve

C(L,T,I) bezeichnet die maximale Rate von Type-P-IP-Bits, die S sendet und D über Link L korrekt empfängt. Die Pfadkapazität ist das Minimum der Link-Kapazitäten. Dieser Link ist der narrow link.

Used(L,T,I) ist dagegen tatsächlich empfangener IP-Verkehr beliebiger Quellen. Auslastung ist Used/C. Ein Prozentwert ohne qualifizierten Nenner verschweigt daher einen Teil seiner Bedeutung.

Verfügbare Link-Kapazität ist C*(1-Util). Beim Pfad gilt erneut das Minimum. Der zugehörige Link ist der tight link. Ein langsamer, leerer Link kann mehr Reserve besitzen als ein schneller, stark belegter Link; narrow und tight fallen dann auseinander.

Das verändert Ausbauentscheidungen. Ein Upgrade am narrow link erhöht womöglich das Maximum, aber nicht die aktuelle Reserve. Verkehrsverlagerung kann die Reserve erhöhen, ohne die Hardware zu ändern. Beides pauschal „mehr Bandbreite“ zu nennen, verwischt Ursache und Wirkung.

Zeit ist Teil der Messung

Verfügbare Kapazität schwankt mit der Nutzung. RFC 5136 verlangt T und I und empfiehlt Messreihen. Eine Einzelmessung ist nicht wertlos, sondern begrenzt. Die Begrenzung darf nicht entfernt werden.

Eine Messreihe kann trotzdem irreführen. Ist die Frequenz ein Vielfaches eines Lastzyklus, trifft die Sonde stets dieselbe Phase. Viele konsistente Werte können viele Wiederholungen desselben Bias sein. Zeitplan, Jitter, Ausfälle, Uhren, Routenwechsel und Wartung müssen erhalten bleiben.

Aktualität ist eine eigene Entscheidung. Der gestrige Wert kann gestern ausgezeichnete Evidenz gewesen sein. Nach Queue-, Pfad-, Last- oder Softwareänderung beweist er nicht automatisch die Gegenwart. „Letzter Wert“ ist keine Gültigkeitsgarantie.

Das Duplikat erhöht Arbeit, nicht Nutzen

In der allgemeinen Definition können zwei korrekt empfangene Hardwarekopien zweimal zählen. Für Ressourcenverbrauch ist das richtig. Für einzigartige Information ist die zweite Kopie wertlos. Eine Type-P-Bedingung oder separate Metrik muss die Eindeutigkeit festlegen.

Eine höhere Rate kann somit Verschwendung anzeigen. Roharbeit und einzigartige Lieferung gemeinsam aufzubewahren macht die Duplizierung sichtbar. Nur die Summe zu speichern verwandelt einen Fehler in scheinbare Leistung.

RFC 3148 setzt Bulk Transfer Capacity auf die Transportschicht. Gemessen werden einzigartige Daten einer stauabhängigen Verbindung; Header und wiederholte Daten zählen nicht zum Nutzen. Verlust, Verzögerung, Umordnung und Recovery-Algorithmus beeinflussen das Ergebnis. Es entspricht keiner RFC-5136-IP-Größe.

RFC 9097 konkretisiert später Methoden für Einweg-IP-Kapazität, RFC 9946 ein kontrolliertes UDP-Testprotokoll. Reproduzierbarkeit schafft jedoch weder Reservierung noch Vertragsrecht, SLA-Urteil oder Anwendungserfolg.

Die notwendige Belegkette

Zuerst stehen Medium, Modus, Aushandlung und NomCap(L). Dann Quelle, Ziel, vollständiger Pfad und Links. Danach Schicht, Type P, Größen, Markierungen, Empfangskriterien, Fehler-, Fragment- und Duplikatregeln. Schließlich T, I, Uhr und Sampling-Plan.

Erst auf dieser Grundlage lassen sich Link-Kapazität, Pfadminimum, Nutzung, Auslastungsnenner, Reserve und tight link deuten. Routing, Queues und Lastverteilung gehören zum Ergebnis. Aktive Tests müssen ihre angebotene Last und Schutzgrenzen nachweisen.

Der Vertrag liefert einen separaten Beleg: zugesagte Rate, Burst-Regel, Perzentil, Ausnahmen und Entscheidungsbefugnis. Die Anwendung liefert einzigartige Bytes, Integrität, Wiederholungen, Abschlusszeit und Wirkung. RFC 5136 erfindet diese Ergebnisse nicht.

Widersprüche zwischen den Ebenen helfen. Physik kann gesund sein, während Type P begrenzt wird. IP-Kapazität kann hoch und Reserve niedrig sein. Reserve kann reichen, während der Transport schlecht regelt. Ein Transfer kann fertig werden und dennoch zu spät kommen.

Dünne Koordination, vollständige lokale Evidenz

RFC 5136 stellt gemeinsames Vokabular bereit. Es installiert und reserviert keine Ressource, wählt keinen Pfad, autorisiert keine Testlast und deutet keinen Vertrag. Gerade diese Zurückhaltung macht die Definitionen brauchbar.

Die gemeinsame Ebene bewahrt Vergleichbarkeit. Implementierung, Politik, Messung und Folge bleiben lokal. Jeder Übergang von physischer Möglichkeit zu IP-Beobachtung, Reserve, Transport und Ergebnis braucht einen neuen Beleg.

Führung muss verhindern, dass der Besitzer eines Zählers den gesamten Dienst bewertet. Inventar belegt nominale Möglichkeit, Messtechnik eine qualifizierte IP-Beobachtung, Betrieb die Aktualität, kommerzielle Autorität den Anspruch und die Anwendung den Ausgang.

Der Port darf recht behalten. RFC 5136 verhindert nur, dass seine Zahl für Ebenen spricht, die sie nie gesehen hat.

Quellen

  1. RFC 5136, HTML
  2. RFC 5136, Klartext
  3. RFC-Editor-Eintrag
  4. IETF-Datatracker-Eintrag
  5. Dokumenthistorie
  6. Errata-Suche
  7. RFC 1812
  8. RFC 2330
  9. RFC 2544
  10. RFC 3148
  11. RFC 4656
  12. RFC 6349
  13. RFC 6703
  14. RFC 7312
  15. RFC 8337
  16. RFC 9097
  17. RFC 9473
  18. RFC 9946
  19. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  20. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  21. Running-Code Primary