Zusammenfassung

  • Erst der leere Transportparameter reset_stream_at des Peers erlaubt RESET_STREAM_AT. Die Verhandlung betrifft die Drahtsyntax, nicht die Bedeutung eines Anwendungsheaders.
  • Reliable Size ist eine Mindestmenge, keine exakte Schnittkante. Sie darf nur sinken; ein verspätetes altes Frame kann einen größeren Wert nicht wieder einsetzen.
  • WebTransport schützt seine Sitzungskennung mit einer eigenen Muss-Regel. Ohne diese Anwendungsvorgabe könnte ein abgebrochener Stream ankommen, ohne noch einer Sitzung zuordenbar zu sein.

Freigegeben heißt noch nicht als RFC veröffentlicht

Marten Seemann und Kazuho Oku reichten Revision 11 von QUIC Stream Resets with Partial Delivery am 6. September 2026 ein. Der Datatracker führt sie als Standards-Track-Internet-Draft der QUIC Working Group. Als Zustände erscheinen Submitted to IESG for Publication, IANA OK — Actions Needed und Approved-announcement to be sent. Die IESG-Entscheidung ist damit gefallen; offizielle Mitteilung, redaktioneller Abschluss und RFC-Nummer sind noch nicht dasselbe. Dieser Bericht nennt das Dokument weiterhin Entwurf.

Der Schritt folgt auf die IESG-Telekonferenz vom 3. September und enthält mehr als ein neues Ablaufdatum. Gegenüber Revision 10 stehen nun ein ausdrückliches Verbot unvereinbarter Nutzung, „minimum“ in der Definition, präzisere Sprache zur erneuten Übermittlung aktueller Information, getrennte Konsistenzprüfungen, eine engere Regel für umgeordnete Frames und die Null-Empfehlung nach STOP_SENDING.

Damit werden mehrere Entscheidungsflächen sichtbar. Der Peer öffnet die Erweiterung. Der Absender erklärt Fehler, Endgröße und gegenwärtige Lieferpflicht. Die Anwendung kennt den semantischen Wert der ersten Bytes. Der Empfänger kann sein Interesse widerrufen. Der Name „reliable reset“ darf diese Rollen nicht verschmelzen.

Der Peer erteilt die Berechtigung

Unterstützung wird mit reset_stream_at, Wert 0x1d, angekündigt. Der Wertkörper muss leer sein; andernfalls folgt TRANSPORT_PARAMETER_ERROR. Revision 11 ergänzt die normative Schranke: Ohne Ankündigung durch den Peer darf ein Endpoint Frame 0x24 MUST NOT senden.

Vorhandener Bibliothekscode, eine frühere Verbindung oder die Vermutung, unbekannte Frames würden toleriert, sind keine Autorisierung. Maßgeblich ist der vom Gegenüber im aktuellen Handshake erzeugte Zustand. Wer ein Format serialisieren kann, besitzt damit keine Verfügungsgewalt über den Parser des anderen.

Bei 0-RTT wird diese Autorität erinnert. Beide Seiten speichern, ob der Server die Erweiterung angeboten hatte. Akzeptiert er Early Data, darf er sie auf der wiederaufgenommenen Verbindung nicht abschalten. Er kann 0-RTT ablehnen; er kann nicht dessen alten Kontext akzeptieren und zugleich die darin vorausgesetzte Fähigkeit entziehen.

Auch eine korrekte Verhandlung sagt nur: Das Frame ist zulässig. Sie bezeichnet weder den unverzichtbaren Präfix noch garantiert sie, dass ein erster positiver Wert positiv bleibt.

Eine Untergrenze, die nur fallen kann

RESET_STREAM_AT enthält Stream ID, Application Protocol Error Code, Final Size und Reliable Size. Final Size erhält die vollständige QUIC-Abrechnung. Reliable Size benennt den kleinsten Präfix, der trotz Reset an die empfangende Anwendung geliefert werden muss. Ist er größer als Final Size, entsteht FRAME_ENCODING_ERROR.

Unterhalb dieser Grenze müssen verlorene STREAM-Daten erneut gesendet werden. Oberhalb sollte der Sender nicht weiter retransmittieren; bereits eingetroffene Bytes darf der Stack trotzdem ausliefern. Reliable Size ist somit weder Obergrenze noch Löschbefehl. Die beobachtete Lieferung kann größer sein.

Ein späteres Frame darf die Zahl reduzieren. Ein gewöhnliches RESET_STREAM ist für die Zustellung gleichbedeutend mit null. Die Bewegung ist monoton abwärts: Senken ja, Erhöhen nein. Aktuelle Größeninformation und geschützte Bytes bleiben bis zur Bestätigung in der Wiederholungslogik.

Der Sender besitzt ein einseitiges Rückzugsrecht. Er kann einen Teil der früheren Pflicht aufgeben, aber eine größere Garantie nach der Reduktion nicht zurückholen. Die Betriebswahrheit des Empfängers ist der kleinste gültige Wert, nicht das großzügigste historische Versprechen.

Umordnung erneuert kein altes Versprechen

Ein Sender kann zuerst 64 und danach 10 Bytes zusagen. Das Paket mit 10 darf früher eintreffen. Kommt anschließend das alte 64er-Frame, bleibt die Untergrenze 10. Netzwerkreihenfolge darf die nur abwärts zulässige Entscheidung nicht umkehren.

Revision 10 forderte, ein Frame mit erhöhter Reliable Size zu ignorieren. Das konnte so gelesen werden, als entfielen auch Prüfungen eines geänderten Error Code oder Final Size. Revision 11 ignoriert nur die Erhöhung. Der Fehlercode muss über Reset-Frames gleich bleiben; Final Size muss zudem mit einem STREAM-FIN übereinstimmen. Abweichungen führen zu STREAM_STATE_ERROR oder FINAL_SIZE_ERROR.

Die Felder teilen einen Container, aber nicht dieselbe zeitliche Gültigkeit. Ein veralteter Mindestwert entwertet nicht die übrigen Behauptungen. Feldgenaue Zustandsführung bewahrt den Konflikt, den ein pauschales „alt“ verdecken würde.

Den unaufgebbaren Präfix bestimmt die Anwendung

Der QUIC-Entwurf erlaubt Anwendungen ausdrücklich, einen Schwellenwert festzulegen, unter den Reliable Size nicht sinken darf. Der Transport kennt Offsets, nicht ihren Zweck. Er weiß nicht, ob dort eine Sitzungskennung, ein Abonnement oder optionaler Nutzinhalt liegt.

WebTransport over HTTP/3 Revision 16 verlangt beim Reset eines Datenstreams RESET_STREAM_AT mit mindestens der Länge des WebTransport-Headers. Dessen ID ordnet den Stream einer Sitzung zu. Fehlt sie, kann die Gegenseite einen Abbruch sehen, ohne Fehler und Ressourcen der richtigen Sitzung zuweisen zu können.

Media over QUIC Transport Revision 17 wählt eine verwandte, schwächere Vorgabe. Reliable Size sollte den Subgroup-Stream-Header einschließen, damit das Abonnement erkannt und der Reset bei PUBLISH_DONE verbucht wird. Ein unzureichender Präfix kann Zustand bis zum Timeout binden.

MUST und SHOULD dürfen nicht gleichgemacht werden. Sie drücken unterschiedliche Anwendungsentscheidungen aus. QUIC liefert die veränderliche Untergrenze; das übergeordnete Protokoll definiert, welche Identität niemals verloren gehen darf.

STOP_SENDING macht Zuverlässigkeit zur Rückzugsfrage

STOP_SENDING bedeutet, dass die empfangende Anwendung keine weiteren Daten wünscht. Revision 11 empfiehlt bei einer Antwort mit RESET_STREAM_AT Reliable Size null. Ein positiver Präfix nach diesem Widerruf würde Staukontrolle, Flow-Control-Kredit, Speicher und Zeit beanspruchen, obwohl der vorgesehene Empfänger nicht mehr verarbeiten will.

Null ist der definierte Weg zurück zum normalen Reset und zeigt, dass der Anfangswert keine ewige Schuld ist. Braucht ein Vermittler dennoch einen Header, um einen Fehler weiterzugeben oder hopübergreifend abzurechnen, muss die Anwendung Ausnahme, Nutznießer, Länge und Frist benennen.

Zuverlässigkeit ist kein Vorrangrecht über Abbruch. Ohne klaren Eigentümer und Endzustand wird eine nützliche Zusage zur Bindung fremder Ressourcen.

Nach dem Reset bleibt Arbeit übrig

Final Size unterliegt weiter Stream- und Connection-Flow-Control. Fehlt Kredit, kann selbst das Reset-Frame warten müssen. Eine Überschreitung erzeugt FLOW_CONTROL_ERROR. Das Frame ist ack-eliciting; seine Information und verlorene Bytes unter dem aktuellen Minimum werden erneut gesendet.

Data Recvd tritt beim Sender erst nach Bestätigung der kleinsten aktuellen Größe und ihres Präfixes ein. Der Empfänger wartet auf dieselben Bytes. Bis dahin bestehen Ressourcenbindung und Erschöpfungsrisiko fort.

Telemetry muss daher Peer-Ankündigung, Erstwert, Minimum, Final Size, Wiederholungsbytes, Blockierung, Zeitpunkt von STOP_SENDING, Abschlussdauer und bis zum Timeout gehaltenen Zustand verbinden. Eine bloße Reset-Zählung misst das Etikett, nicht die Restschuld.

Grenzen der Feststellungen

Die Quellen belegen Text, Revision und Prüfbegründung. Sie belegen keine Verbreitung, Leistung, Interoperabilität oder Produktionsstörung. Kein Browser, CDN, Relay, QUIC-Stack oder Mediendienst wurde getestet. Der IANA-Status verlangt noch Handlungen; daraus wird keine bereits endgültige Registrierung abgeleitet.

Auch die zitierten WebTransport- und MoQ-Versionen sind Entwürfe. Ihre Normsprache zeigt Anwendungsmöglichkeiten, nicht zwangsläufig den künftigen Wortlaut. Revision 11 kann sich im Publikationsprozess weiter ändern.

Beständig ist nur die Trennung: Frame-Berechtigung, gegenwärtige Mindestlieferung, unverzichtbarer Anwendungsheader und Abbruchwunsch gehören verschiedenen Autoritäten. Running Code muss sie als getrennte, prüfbare Zustände erhalten.

Quellen