Zusammenfassung

  • Mit cm_request meldete eine Anwendung Sendebedarf, ohne dem Congestion Manager einen Puffer zu übergeben; cmapp_send gewährte eine begrenzte Menge, gewöhnlich bis zur PMTU, und nur für kurze Zeit.
  • Die Freigabe bewies weder ein eingereihtes Paket noch dessen Zustellung. Die Anwendung wählte oder paketierte den Inhalt neu, meldete lokal gesendete Bytes mit cm_notify und lieferte Empfängerrückmeldungen getrennt über cm_update.

Ein Engpass, viele Gedächtnisse

Ein Internetrechner konnte um 2001 mehrere Verbindungen zu demselben Ziel halten und zugleich Browser-, Audio- und Videoanwendungen ausführen. Jede lernte Round-Trip-Zeit und Verluste selbst. Eine neue Verbindung wusste unter Umständen nichts von den Messungen einer Nachbarverbindung. Der Engpass war gemeinsam, das Wissen darüber blieb verteilt.

RFC 2140 hatte bereits das Teilen ausgewählter TCP-Zustände zwischen Verbindungen eines Hostpaars beschrieben. RFC 3124, im Juni 2001 auf dem Standards Track veröffentlicht, vergrößerte die Reichweite. Der Congestion Manager, kurz CM, war ein Modul im Endsystem. Er gruppierte Flows zu Macroflows, teilte Congestion-State und Algorithmen und stellte auch Nicht-TCP-Anwendungen eine Schnittstelle bereit.

Das Konzept war keine zentrale Warteschlange für sämtliche Daten. Es teilte die Entscheidung: Der CM wusste, wann der gemeinsame Congestion-State eine Gelegenheit erlaubte. Die Anwendung wusste, welche Information in diesem Augenblick wertvoll war.

Die Anfrage enthielt keine Nutzdaten

cm_request erklärte Bedarf, übergab aber keinen Buffer. Der CM speicherte daher kein Anwendungspaket, untersuchte keinen Payload und versprach nicht, eine bestimmte Nachricht später zu versenden.

Wenn Controller und Scheduler eine Gelegenheit erkannten, rief der CM cmapp_send auf. Der Callback nannte eine Obergrenze, üblicherweise eine Path MTU. Erst dann konnte die Anwendung ihren Inhalt wählen. Ein Videoprogramm konnte ein veraltetes Bild verwerfen, die Qualität senken oder Daten passend zur Freigabe neu paketieren.

Diese späte Auswahl verband zwei Wissensbereiche, ohne sie zu vermischen. Der gemeinsame Dienst sah konkurrierende Anforderungen und das Congestion-Fenster. Die Anwendung verstand Aktualität und Bedeutung ihrer Daten. Eine gewöhnliche Queue hätte den Inhalt zu früh festgeschrieben.

Der Callback war deshalb kein Sendebeleg. Danach mussten Daten noch erzeugt, an IP übergeben und über eine Schnittstelle ausgegeben werden. Eine Anwendung konnte die Gelegenheit ungenutzt lassen oder erst nach ihrem Ablauf bearbeiten.

Eine Freigabe verfiel und musste abgerechnet werden

Die Gültigkeit endete nach dem größeren Wert aus einer RTT und einem implementationsabhängigen Schwellwert. Ein abgelaufener Callback durfte nicht verwendet werden. Eine Entscheidung aus altem Congestion-State war kein dauerhaftes Guthaben.

Nach dem Versuch meldete cm_notify(nsent), wie viele Bytes tatsächlich am IP-Output eingereicht worden waren. Konnte die Anwendung nichts senden, sollte sie null melden und die Gelegenheit zurückgeben. Anforderung, Freigabe und Nutzung bildeten getrennte Buchungen.

Die Spezifikation rechnete mit Fehlern. Ein Prozess konnte abstürzen, bevor er null meldete. Der CM musste sich davon erholen, damit andere Requests nicht für immer blockierten. Das erlaubte ihm aber nicht, jeden Callback nachträglich als fiktive Sendung zu verbuchen.

nsent sagte nur, was der Host ausgegeben hatte, nicht was der Peer empfangen hatte. Empfängerinformation kam über cm_update, wobei Empfang, Verlust, explizite Congestion-Meldung und fehlendes Feedback unterscheidbar blieben. Freigabe, lokaler Akt und entfernte Beobachtung waren drei Evidenzschichten.

Ein Macroflow blieb eine Arbeitshypothese

Flows in einem Macroflow teilten Zustand und Scheduling. Die Anwendung durfte die Gruppierung beeinflussen, weil sie Beziehungen zwischen ihren Sitzungen kennen konnte. Eine gemeinsame Kennung bewies jedoch keinen gemeinsamen Pfad. Routingänderungen, mehrere Interfaces oder eine zu breite Regel konnten die angenommene Gemeinsamkeit zerstören.

Für eine Prüfung wären Macroflow-Key, Route, Interface, Ziel und zeitgleiche Messungen zusammen aufzubewahren. Ohne diese Belege dokumentiert die Gruppe eine lokale Softwareentscheidung, keine physische Pfadidentität.

RFC 2581, RFC 2861 und später RFC 5681 erläutern TCP-Congestion-Verhalten; RFC 9040 griff gemeinsame Transportmetriken erneut auf. Der besondere Gegenstand von RFC 3124 war die anwendungsseitige Request–Grant–Notify-Folge samt gemeinsamem Scheduler, nicht nur ein Cache für TCP-Metriken.

„Wohlverhalten“ bedeutete Kooperation

Als well-behaved galt eine Anwendung, die nur mit Zustimmung des CM sendete und alle gesendeten Daten korrekt meldete. Das war ein Vertrag mit dem Teilnehmer, keine technische Sperre für jeden Prozess des Rechners.

Die RFC stellte ausdrücklich fest, dass der CM nicht alle Anwendungen zu Congestion-Verhalten zwang und das Netz nicht vor einem kompromittierten Host schützte. Host-Policing oder Router-Enforcement wären andere Mechanismen außerhalb ihres Umfangs. Ein bösartiges oder nicht integriertes Programm konnte die Schnittstelle umgehen.

Ein installiertes CM-Modul beweist daher nicht, dass der gesamte Verkehr ihm folgte. API-Aufrufe einer Anwendung schließen parallelen Bypass-Verkehr nicht aus. Selbst eine korrekte Aufruffolge beweist nicht, dass die Pakete den vom Macroflow angenommenen Pfad nahmen.

Die Teilnahme war optional. Wer den Dienst nutzte, sollte die Spezifikation einhalten; der Standards-Track-Status liefert jedoch keine Einsatzquote und keinen Erfolgsnachweis.

Unbekannt wurde nicht zu null

Anwendungen mit eigenem Scheduler konnten über cm_query Rate, RTT und Congestion-Schätzung abfragen. War eine Schätzung ungültig, lieferte die Schnittstelle einen negativen Wert. Fehlendes Wissen wurde nicht als Kapazität null ausgegeben.

Diese Unterscheidung ist operativ wichtig: Unbekannt und gemessene Null erfordern andere Entscheidungen. Auch historisch darf fehlender Deployment-Beleg nicht als Scheitern gelten, während ein Normtext nicht als Adoption gilt. RFC 2914 erklärt Congestion-Prinzipien, RFC 2481 den damaligen ECN-Kontext, RFC 1191 PMTU und RFC 8085 spätere UDP-Pflichten. Keine dieser Quellen belegt eine konkrete RFC-3124-Installation.

Eine Sendung brauchte mehrere Belege

Eine belastbare Spur enthielte cm_request, Flow und Macroflow, Scheduler-State, Zeitpunkt und Größe des Callbacks, PMTU, RTT und Ablaufberechnung. Hinzu kämen gewählter Inhalt, cm_notify am IP-Output, Interface, Route und jede cm_update-Rückmeldung. Für ein Nutzerergebnis wären weitere Messungen nötig.

Der Request belegt erklärten Bedarf. Der Callback belegt eine befristete Gelegenheit. Eine positive Notification belegt einen lokalen Sendereport. Feedback beschreibt einen späteren Abschnitt des Pfads. Kein Eintrag darf die übrigen ersetzen.

Die bleibende Lehre der RFC 3124 liegt in dieser Trennung. Sie wollte Congestion-Wissen teilen, ohne dem Controller die Datenhoheit zu geben. Die Freigabe ordnete den Zeitpunkt; sie war weder das Paket noch dessen Ankunft.

Quellen

  1. https://www.rfc-editor.org/rfc/rfc3124.txt
  2. https://www.rfc-editor.org/info/rfc3124
  3. https://datatracker.ietf.org/doc/rfc3124/
  4. https://www.rfc-editor.org/rfc/rfc2140.txt
  5. https://www.rfc-editor.org/rfc/rfc2914.txt
  6. https://www.rfc-editor.org/rfc/rfc2581.txt
  7. https://www.rfc-editor.org/rfc/rfc2861.txt
  8. https://www.rfc-editor.org/rfc/rfc2481.txt
  9. https://www.rfc-editor.org/rfc/rfc1191.txt
  10. https://www.rfc-editor.org/rfc/rfc5681.txt
  11. https://www.rfc-editor.org/rfc/rfc8085.txt
  12. https://www.rfc-editor.org/rfc/rfc9040.txt