Zusammenfassung

  • RFC 1046 wollte die Low-Delay-Queue so klein halten, dass aufgenommene Datagramme eine knotenbezogene Wartegrenze einhalten konnten. Überlauf wurde verworfen; zugleich blieb der Linkanteil der Klasse begrenzt, damit sie andere Dienste nicht ausschloss.
  • Mehrere Type-of-Service-Wünsche waren bei Knappheit Alternativen, keine addierten Ansprüche. Ein Knoten wählte eine Queue; ein Ausweichen konnte die Aufnahmechance erhöhen, aber Reihenfolge, Einwegverzögerung und Zuverlässigkeit verändern.

Die entscheidende Größe in RFC 1046 steht nicht im IP-Header. Es ist die Zahl der freien Pufferplätze am Ausgang. Erst dort entscheidet sich, ob „low delay“ eine beobachtbare Behandlung erhält oder nur ein gesetztes Bit bleibt.

W. Prue und J. Postel veröffentlichten das Memo im Februar 1988 ausdrücklich als Ideenpapier. Es formulierte keine nachgewiesene Internetpraxis und ließ die wichtigsten Zahlen offen. Sein historischer Wert liegt in der präzisen Kostenrechnung eines guten Namens.

Der Wunsch wurde erst unter Last wirksam

RFC 791 definierte IPv4-Precedence sowie Wünsche nach niedriger Verzögerung, hohem Durchsatz und hoher Zuverlässigkeit. Schon dort galten die drei Eigenschaften als Abwägung; eine Verbesserung konnte eine andere verschlechtern.

RFC 1046 setzte voraus, dass die Nachfrage die aktuelle Leistungsfähigkeit übersteigt. Ohne nennenswert wachsende Queue war eine besondere Disziplin überflüssig. Die Klassifizierung wurde also nicht wegen des Bits wichtig, sondern wegen der Konkurrenz um endlichen Speicher und Sendezeit.

Ein Mitschnitt des Headers belegt deshalb nur die Äußerung des Senders. Für einen Dienstnachweis braucht es zusätzlich Klassifizierung, Queueaufnahme, Bedienung und Ausgangsergebnis.

Die MGD-Grenze galt hinter dem Aufnahmetor

Für die Low-Delay-Klasse schlug das Memo eine Maximum Guaranteed Delay pro Knoten vor, falls das Datagramm das Internet erfolgreich durchquert. Das war weder eine Liefergarantie noch eine RTT-Zusage. Die Klasse galt in einer Richtung; die Antwort konnte anders markiert sein.

Die Formel lautete:

Max Delay = N / (P × R)

N war die Queuegröße, P der der Klasse zugeteilte Linkanteil und R die Linkrate in Datagrammen pro Sekunde. Bei gleichbleibendem Ziel musste N schrumpfen, wenn Linkrate oder Anteil sanken. Physische Linkverzögerung verbrauchte zusätzlich einen Teil des Budgets.

Die Grenze gehörte somit zur lokalen Konfiguration. Das Datagramm brachte weder Puffer noch Bandbreite mit.

Der kurze Puffer bezahlte Zeit mit Verlust

Die Low-Delay-Queue sollte klein sein und mit einer Rate bedient werden, die keinen übermäßigen Ressourcenverbrauch zuließ. War sie voll, wurde der neue Verkehr verworfen. Für eine so kleine Queue hielt das Memo Source Quench für zu träge und sah es im Grundentwurf nicht vor.

High Reliability verwendete den gegenteiligen Tausch: eine längere Queue, früheres Source Quench und kein Verwerfen bis zur Füllgrenze. Das verringerte Verlust durch Stau, erhöhte aber mögliche Wartezeit und half nicht gegen fehlerhafte Leitungen.

High Throughput erhielt im Beispiel die höchste Bedienrate und einen größeren Puffer. Der mittlere Knotendelay stieg. Das Zusammenhalten von Bursts blieb eine vorsichtige Idee, weil die Queue damit Annahmen über das übergeordnete Protokoll machte.

Die Klassen waren keine Qualitätsstufen. Sie verteilten Verlust, Warten und Übertragungsgelegenheiten verschieden.

OR verhinderte drei gleichzeitige Versprechen

Unter Konkurrenz waren mehrere Wünsche als OR, nicht als AND zu behandeln. Nur ohne Knappheit konnten niedrige Verzögerung und hoher Durchsatz gleichzeitig entstehen.

Ein Datagramm nutzte an einem Knoten unmittelbar eine Klassenqueue. Vorgeschlagen war die Reihenfolge Low Delay, High Throughput, High Reliability. War die kurze Queue für ein zugleich zuverlässig markiertes Paket voll, konnte es in die Reliability-Queue fallen. Die zweite Aufnahmechance ersetzte jedoch den ersten Tausch.

Teilte sich ein Burst auf verschiedene Queues auf, konnten abweichende Bedienraten Datagramme umordnen und die Einwegzeit streuen. Die ursprünglichen Bits dokumentierten diese lokalen Verzweigungen nicht.

Precedence durfte überholen, aber nicht unbegrenzt

Acht Prioritätsstufen bildeten eine zweite Ordnung innerhalb der Klasse. Höhere Priorität durfte vorbeiziehen. Jedes überholte Datagramm erhielt jedoch lokale „Frustrationspunkte“, bis es nicht weiter von denselben Neuankömmlingen verdrängt werden konnte.

Dieser Zustand endete am nächsten Hop und änderte das Headerfeld nicht. Priorität warf auch kein bereits aufgenommenes Paket aus einer vollen Queue; der Neuankömmling wurde verworfen.

Die Anti-Starvation-Regel veränderte die MGD-Annahme erheblich. Im Beispiel konnte ein Low-Delay-Paket ohne passende hohe Priorität zwischen dem Einfachen und dem 28-Fachen des ungepriorisierten Werts warten. Ein Status „low delay marked“ unterschlägt damit den maßgeblichen Wettbewerb.

Die Verteilungsgewalt blieb beim Betrieb

17 Prozent Low Delay, 50 Prozent Throughput und 33 Prozent Reliability waren ein Rechenbeispiel. Proportionale „chits“ sollten die Anteile glätten. Das Memo fragte weiterhin, welche MGD sinnvoll sei, wer die Prozente bestimme, wie begehrte Klassen und hohe Prioritäten begrenzt würden und welche Simulationen fehlten.

Bei Mehrfachmarkierung sollte nur die tatsächlich verwendete Queue gezählt werden. Drei Wünsche waren nicht drei erbrachte Dienste.

Offene Parameter sind hier keine Nebensache. Eine Queuepolitik bestimmt, wer früher verliert, wer länger wartet und wer den Link nutzt. Diese Entscheidung braucht einen verantwortlichen Betreiber, Messwerte und eine Rückkehrmöglichkeit.

Spätere RFCs setzen die historischen Grenzen

RFC 1349 bezeichnete TOS später als strikt beratend und ungeeignet, Garantien anzufordern. RFC 2474 und RFC 2475 ersetzten die alte Interpretation durch das DS-Feld und trennten Codepoint, Per-Hop Behavior, Dienst, Conditioning und Implementierungsmechanismus.

Das beweist weder eine Verbreitung von RFC 1046 noch eine direkte technische Abstammung von DiffServ. Es bewahrt die Grenze zwischen transportierter Kennzeichnung und lokaler Ressourcenausführung.

RFC 1016 liefert den damaligen Source-Quench-Kontext. RFC 6633 verbietet später das Senden und die Reaktion und erklärt ausdrücklich, dass der Ansatz aus RFC 1016 nicht implementiert werden darf.

Quellen und Beweisgrenzen

Die Quellen belegen Feld, Vorschlag, Formel, Unsicherheiten und spätere Normgrenzen. Sie belegen keine Implementierung, keinen konkreten Queuewert und keine heutige DSCP-Behandlung. Markierung, Klassifikation, Aufnahme, Wartezeit, Verlust, Zustellung und Anwendungsergebnis bleiben getrennte Tatsachen.