Zusammenfassung

  • RFC 3133 definierte Zustellraten für Nutzdaten-Oktette und Frames in einer Richtung einer einzelnen Frame-Relay-Virtual-Connection; zugesicherte und überschüssige Last blieben getrennt.
  • Das Dokument warnte selbst: Der Verlust einer kleinen Bestätigung kann viele Datenwiederholungen auslösen. Die Kennzahl bleibt in ihrem Bereich richtig, beweist aber kein gutes Anwendungsergebnis.

Eine kleine Lücke mit großer Wirkung

Viele Daten-Frames laufen in eine Richtung, eine kurze Bestätigung kommt zurück. Treffen fast alle Daten ein und geht nur die Bestätigung verloren, verändert sich der Anteil zugestellter Oktette kaum. Auch die Frame-Quote kann nahezu makellos aussehen. Dem Sender fehlt jedoch der Nachweis, mit dem er Zustand freigibt, sein Fenster weiterschiebt oder eine Übertragungsphase beendet.

RFC 3133 stellte genau diesen Fall neben Data Delivery Ratio und Frame Delivery Ratio. Ein verworfenes kleines Acknowledgement könne die erneute Übertragung einer großen Zahl von Daten-Frames auslösen. Die Quote melde einen guten Wert, während der Benutzer schlechte Leistung erfahre.

Die Rechnung war nicht falsch. Sie beantwortete, welcher Anteil einer definierten Population eine definierte Grenze überschritt. Die Anwendung hing von der Funktion einzelner Elemente ab. Eine Zählung nach Bytes oder Frames bewahrt nicht automatisch die kausale Bedeutung eines Kontrollsignals.

Leitungsgeschwindigkeit war kein Leistungsversprechen

Frame Relay kannte mehrere Größen, die im Alltag leicht zu „Bandbreite“ verschmolzen. Der Access Channel war der physische Zugang, seine Access Rate die maximale Geschwindigkeit, mit der ein Nutzer Daten einspeisen konnte. Der Vertrag konnte deutlich weniger zusichern.

Die Committed Information Rate, CIR, bezeichnete die Transportgeschwindigkeit, welche das Netz zwischen Serviceorten aufrechterhalten sollte. Bc war die zugesicherte Datenmenge im Messintervall Tc. Be bezeichnete eine nicht zugesicherte zusätzliche Burst-Menge, deren Zustellung das Netz mit geringerer Wahrscheinlichkeit versuchte.

Tc war kein periodischer Zeitschlitz. RFC 3133 beschrieb ein durch eingehende Daten ausgelöstes gleitendes Fenster, berechnet als Bc/CIR. Für die Einordnung als zugesicherte oder überschüssige Last brauchte man daher Vertrag und Zeitverlauf, nicht nur ein Portetikett.

Das Discard-Eligible-Bit, DE, war eine Präferenz für den Verlustfall unter Überlast, kein Beleg für einen erfolgten Drop. RFC 3133 trennte discardable von discarded. Ein markiertes Frame konnte überleben, wenn die Überlast endete. Ein unmarkiertes Frame konnte durch PVC- oder höherliegende Regeln zum Kandidaten werden. Ein fehlerhaftes Frame konnte aus Integritätsgründen verworfen werden.

Zusage, Klassifikation, Verwerfbarkeit und tatsächlicher Verlust waren verschiedene Ereignisse. Ein gemeinsamer Zähler löschte diese Verantwortungsfolge.

Die Kennzahl hatte Richtung und Adresse

RFC 3133 übernahm das Definitionsschema aus RFC 1242 und unterschied Terminologie von Methodik. Das eine Dokument benennt die Messgröße, das andere legt das Verfahren zur Erhebung fest. Eine Formel ist noch kein durchgeführter Benchmark.

DDR setzte erfolgreich zugestellte Nutzdaten-Oktette zu angebotenen Nutzdaten-Oktetten ins Verhältnis; Adressfeld und FCS gehörten nicht zur Nutzlast. Die Frame Delivery Ratio verglich erfolgreiche Frame-Empfänge mit Übertragungsversuchen. Beide galten für eine Richtung einer einzigen Virtual Connection.

Eine Duplex-Verbindung hatte folglich zwei unabhängige Sätze von Werten. Ein guter Vorwärtspfad bewies keinen guten Rückweg für Bestätigungen. Das Ergebnis eines DLCI beschrieb nicht alle Virtual Circuits eines Ports. Und eine Messung zwischen zwei Punkten umfasste nicht automatisch die Vorgänge vor dem Eintritt oder nach dem Austritt.

Außerdem ließ sich die Gesamtquote zerlegen. DDR_c galt für Last innerhalb der CIR, DDR_e für den Überschuss; die Frame-Raten konnten ebenso getrennt werden. Ein korrekter Gesamtwert konnte verdecken, dass gerade der zugesicherte Teil schlechter ausfiel als der opportunistische.

Vor jeder Interpretation standen daher sechs Fragen: welcher Circuit, welche Richtung, welches Intervall, welche Lastklasse, welche Definition der Nutzlast und welche Messgrenzen? Ohne diese Koordinaten hatte eine Nachkommastelle keine belastbare Reichweite.

Kontrollwert folgt nicht der Frame-Länge

Eine Oktettquote gewichtet große Daten-Frames stärker und eine kurze Bestätigung schwächer. Eine Frame-Quote zählt beide als je eine Einheit. Keine der beiden Größen hält fest, dass die Bestätigung ein Sendefenster öffnen, kumulativen Fortschritt bestätigen, einen Timeout vermeiden oder Retransmission-State löschen kann.

Die funktionale Bedeutung stammt aus dem erlaubten Zustandsübergang, nicht aus der Länge. Deshalb kann ein statistisch kleiner Ausfall eine große Wiederholung verursachen.

Man könnte ein Beispiel mit 999 von 1000 Frames konstruieren und 99,9 Prozent ausrechnen. RFC 3133 veröffentlichte aber keinen solchen Versuch. Es nannte weder Produkt noch Anwendung noch gemessenen Verstärkungsfaktor. Die belegte Aussage ist begrenzt: Der Verlust einer kleinen Bestätigung kann viele Datenwiederholungen auslösen.

Ebenso wenig ist jeder Acknowledgement-Verlust verheerend. Eine spätere kumulative Bestätigung, Fensterregeln, Timer und Implementierung verändern den Verlauf. Das Beispiel widerlegt die Gleichsetzung von hoher Quote und guter Anwendung; es begründet kein neues Absolutum.

Der Verzögerungsmittelwert kannte nur Ankömmlinge

Frame Transfer Delay wurde zwischen einem Frame-Exit-Ereignis an einem Messpunkt und dem Frame-Entry-Ereignis am nächsten berechnet. In den Mittelwert gingen empfangene Frames ein. Während des Intervalls gesendete, aber nicht empfangene Frames blieben außen vor.

Diese Definition ist konsistent und zugleich ein Grund, Delay und Loss zusammen zu lesen. Ein niedriger Mittelwert kann nur die Überlebenden beschreiben. Die fehlenden Frames tragen möglicherweise die schlechteste Folge, erscheinen aber nicht in der Statistik.

Frame Transfer Delay Variation war die Differenz zwischen maximaler und minimaler beobachteter Verzögerung. RFC 3133 verband hohe Schwankung mit TCP-Round-Trip-Berechnung und Throughput und nannte Voice over IP als empfindlich gegen übermäßige Verzögerung. Das waren technische Zusammenhänge, keine Messwerte eines benannten Netzes.

Ein Drop konnte vor beschädigten Daten schützen

Der RFC listete Fehlergründe: zu lang, zu kurz, ungültige Bitlänge, unbekannter DLCI, Abort-Sequenz, falsche Flag-Begrenzung oder FCS-Fehler. Ein beschädigtes Frame zu verwerfen konnte besser sein, als es weiterzuleiten, weil eine Wiederholung eine saubere Kopie liefern konnte.

Ein einzelner Discard-Zähler konnte also Vertrags-Policing, Überlastpriorität und Integritätsschutz mischen. Alle drei konnten auf höherer Ebene Recovery auslösen, aber sie hatten verschiedene Ursachen, Zuständigkeiten und Reparaturen.

Eine Untersuchung musste die Herkunft behalten: Wurde das Frame am Eingang gesehen? War es committed oder excess? Trug es DE? Welche Regel klassifizierte es? Warum wurde es tatsächlich verworfen? Wo blieb die Rückbestätigung? Was wiederholte der Transport? Erreichte die Anwendung ihren Abschluss? Der Endwert beantwortete keine dieser Fragen.

Begriffe, keine Produktwertung

RFC 3133 erschien im Juni 2001 als Informational-Dokument der IETF Benchmarking Methodology Working Group. Es erweiterte RFC 1242, RFC 1944 und RFC 2285 und übernahm Begriffe des Frame Relay Forum und der Frame-Relay-Service-MIB.

Es testete kein benanntes Gerät, zertifizierte keinen Carrier und belegte weder verfügbare Counter noch SLA-Erfüllung, Einführung oder Benutzerzufriedenheit. Der letzte Internet-Draft dokumentiert die Textentwicklung, nicht den Betrieb.

RFC 1944, RFC 2544 und RFC 2889 behandeln benachbarte Methodik. RFC 2761 liefert ATM-Kontext, RFC 2954 Managed Objects und RFC 6349 später einen Rahmen für TCP-Throughput-Tests. Keines dieser Dokumente macht aus RFC 3133 einen Feldversuch.

Sein bleibender Wert liegt in der eingebauten Begrenzung: Eine Netzschicht kann nach ihrer Einheit erfolgreich sein, während die abhängige Anwendung nach einer anderen Einheit scheitert.

Drei Belegketten statt einer Ampel

Die Netzakte sollte Access Channel, DLCI, Richtung, Intervall, CIR, Bc, Be und Tc halten; angebotene und zugestellte Oktette und Frames; committed/excess-Aufteilung; DE, Policing, FECN/BECN, Fehler, Discard-Grund und Messpunkte.

Die Transportakte braucht Acknowledgement, Sequenzzustand, Zeiten, Timer, Retransmission-Auslöser, wiederholte Frames und Bytes sowie das Ende der Recovery. Die Anwendungsakte braucht Vorgangs-ID, Erfolgskriterium, Zeitbudget, Wiederholungen, Endzustand und sichtbares Ergebnis.

Fehlende Felder der höheren Akten dürfen nicht aus der unteren Quote ergänzt werden. DDR belegt ein Verhältnis von Nutzdaten-Oktetten. Eine Frame-Quote belegt ein Verhältnis von Frames. Beide sind keine Quittung für Abschluss, Vertragserfüllung oder menschliche Erfahrung.

Frame Relay gehört nicht mehr zum Vordergrund des Netzes, die Versuchung aber blieb. Plattformen aggregieren das billigste Signal und nennen es Gesundheit. RFC 3133 verlangt eine strengere Praxis: Zahl und Zuständigkeitsgrenze bewahren und vor einem Serviceurteil unabhängige Belege aus der betroffenen Ebene verlangen.

Quellen

  1. https://www.rfc-editor.org/rfc/rfc3133.txt
  2. https://www.rfc-editor.org/info/rfc3133
  3. https://www.rfc-editor.org/rfc/rfc3133.html
  4. https://www.rfc-editor.org/rfc/rfc1242.html
  5. https://www.rfc-editor.org/rfc/rfc1944.html
  6. https://www.rfc-editor.org/rfc/rfc2285.html
  7. https://www.rfc-editor.org/rfc/rfc2544.html
  8. https://www.rfc-editor.org/rfc/rfc2761.html
  9. https://www.rfc-editor.org/rfc/rfc2889.html
  10. https://www.rfc-editor.org/rfc/rfc2954.html
  11. https://www.rfc-editor.org/rfc/rfc6349.html
  12. https://datatracker.ietf.org/doc/html/draft-ietf-bmwg-fr-term-06