Zusammenfassung

  • Umordnung beschreibt eine geänderte Ankunftsreihenfolge; Resequencing hält spätere Frames aktiv zurück, um die Sendereihenfolge wiederherzustellen.
  • Eine Sicherungsschicht kann mehrere Transportkontexte gemeinsam tragen und kennt deren jeweilige Verlustlogik meist nicht.
  • RACK und QUIC stützen Verlustentscheidungen stärker auf Zeit; ESP und ROHC besitzen eigene begrenzte Fenster und Zustände.
  • Der Entwurf verlangt klare Evidenz dafür, dass der Nutzen des Wartens größer ist als zusätzliche Latenz und Jitter.
  • Revision 00 ist ein aktiver Informational-Entwurf zur möglichen Aktualisierung von RFC 3819, kein RFC und kein Nachweis eines Einsatzes.

Eine Schutzmaßnahme ohne Fähigkeitsablauf

Der Link wurde einst so konfiguriert, dass er Umordnung vor TCP verbirgt. Damals konnte eine Folge doppelter ACKs leicht eine falsche Verlustentscheidung auslösen. Jahre später verwenden die Endpunkte RACK. Der Link wartet weiterhin, weil seine Kompatibilitätsannahme kein Ablaufdatum hat.

Das Problem ist nicht, dass die alte Entscheidung irrational war. Es fehlt der Mechanismus, der sie neu bewertet. Eine Schutzfunktion wird zum Lock-in, wenn sie weder einen Fähigkeitsnachweis noch eine Widerrufsbedingung besitzt.

draft-ietf-intarea-reordering-00 macht genau diese Trennung sichtbar. Das Subnetz weiß, dass es verfügbare Frames verzögert. Es weiß im Regelfall nicht, ob der konkrete Empfänger durch die beobachtete Umordnung geschädigt worden wäre.

Was RACK verändert—and was nicht

Frühere TCP-Verlustlogik nutzte unter anderem drei doppelte ACKs. Umordnung konnte deshalb eine unnötige Retransmission und eine Reduktion des Congestion Window auslösen. RFC 8985 definiert mit RACK zeitbasierte Schlussfolgerungen. RFC 9002 gibt QUIC Zeit- und Paketschwellen.

Damit wandert Interpretationswissen zum Endpunkt, der den Zustand der Verbindung sieht. Die Sicherungsschicht sieht Sequenznummern, Pfade und Lücken, aber nicht die gesamte Transporthistorie.

Ein Standardtext ist jedoch kein Laufzeitbeleg. Der Betreiber muss Version, aktivierten Algorithmus, Schwellwerte und beobachtetes Verhalten kennen. „TCP“ oder „QUIC“ als Inventarfeld reicht nicht. Auch ältere Stacks können begrenzte Umordnung korrekt verarbeiten, nur möglicherweise langsamer. Korrektheit, Leistung und Anwendungswirkung bleiben verschiedene Aussagen.

Eine Lücke kann fremde Verbindungen blockieren

Bei Link-Aggregation treffen Frames wegen unterschiedlicher Kapazitäten oder Laufzeiten versetzt ein. Bei Funkübertragung können spätere Frames im ersten Versuch ankommen, während ein früherer Frame wiederholt werden muss.

Ein Layer-2-Kontext kann dabei Pakete vieler Layer-4-Verbindungen enthalten. Fehlt ein Frame aus einer Verbindung, hält die Resequencing-Queue womöglich Frames aus anderen Verbindungen zurück. Die sichtbare Ordnung wird mit einer unsichtbaren Umverteilung von Latenz bezahlt.

Ein belastbarer Receipt muss deshalb nicht nur „Gap geschlossen“ enthalten. Er braucht ursprüngliche Sequenz, Mitgliedspfad, Retransmission, Ankunft, Queue-Eintritt, Wartezeit, Freigabegrund, Endpunktfähigkeit, Transportreaktion und Anwendungsankunft. Erst dann lässt sich der Gegenfall bewerten.

Sicherheit und Kompression begrenzen die Freigabe

Bei Wi-Fi werden Paketnummern auch für Replay-Schutz verwendet. Ein legitimer, spät retransmittierter Frame kann eine kleinere Nummer tragen als bereits freigegebene Frames. Ohne angepasstes Replay-Fenster würde die Latenzoptimierung echte Daten verwerfen.

ESP akzeptiert gemäß RFC 4303 Umordnung innerhalb eines gleitenden Fensters. Außerhalb dieses Fensters ändert sich das Urteil. ROHC und ROHCv2 hängen von Profil und Kontextzustand ab. „Umordnungstolerant“ ist daher ohne Fenstergröße, Profil und Implementierung unvollständig.

Auch NAT- und Fragmentierungsanforderungen zeigen die Differenz zwischen Soll und Ist. Eine normative Pflicht ist keine Messung eines installierten Geräts.

Die Linkbeispiele haben begrenzte Reichweite

Der Entwurf behandelt HARQ, RLC und Dual Connectivity in Mobilfunknetzen, TID-bezogene Wi-Fi-Puffer sowie kanalgebundenes DOCSIS. Das sind unterschiedliche Kontrollflächen.

Für ein zitiertes Wi-Fi-Szenario mit sieben weiteren konkurrierenden Stationen nennt der Text mehr als 75 Millisekunden zusätzliche Verzögerung am P90 und mehr als 400 am P99. Diese Werte gehören zu diesem Szenario. Sie sind weder universelle Wi-Fi-Werte noch eine BTW-Messung.

DOCSIS-Pufferanforderungen belegen, dass Resequencing Ressourcen benötigt. Sie belegen nicht, dass jede Wartezeit einer Anwendung geholfen hat.

Die vorgeschlagene Zuständigkeit

Unnötige Umordnung soll vermieden werden. Ist Umordnung aber unvermeidbare Folge einer nützlichen Mehrpfadnutzung oder Link-Retransmission, soll sie grundsätzlich am Endpunkt sichtbar werden. Resequencing im Subnetz bleibt für Fälle, in denen klare Evidenz seinen Nutzen gegenüber Latenz und Jitter zeigt.

Das ist kein absolutes Verbot. Es ist eine Beweislastregel. Wer die Kosten sicher kennt und den semantischen Nutzen nicht kennt, darf Wartezeit nicht als zeitlose Voreinstellung ausgeben.

Dokumentstatus

Revision 00 erschien am 27. August 2026, läuft am 28. Februar 2027 ab und ist als Informational vorgesehen. Bei Annahme würde sie Abschnitt 15 von RFC 3819 aktualisieren. Es gibt keine IANA-Anforderung.

Es ist ein aktiver Internet-Draft und kein RFC.

Dieser Artikel bestätigt keine Änderung bei IEEE, 3GPP oder CableLabs und keinen benannten Einsatz. Der Entwurf kann sich ändern, ersetzt werden oder ablaufen.