要約

  • 相手が空のreset_stream_atトランスポート・パラメーターを通知した後でなければ、RESET_STREAM_ATは送れない。許可されるのはワイヤ形式であり、アプリケーション上の意味ではない。
  • Reliable Sizeは最低配信量であって正確な切断位置ではない。後続情報で小さくでき、遅れて届いた古い大きな値が約束を復活させることもない。
  • WebTransportはセッション識別子を含むヘッダーを別のMUSTで保護する。QUICの協商だけでは、打ち切られたストリームを正しく帰属できる保証にならない。

承認待ちの文書であり、まだRFCではない

Marten Seemannと奥一穂は2026年9月6日、QUIC Stream Resets with Partial Deliveryの第11版を提出した。DatatrackerではQUICワーキンググループのStandards Track Internet-Draftであり、IESGへの出版提出済み、IANA審査は「OK—作業必要」、IESG状態は「承認済み、告知送信待ち」と表示される。承認判断はあっても、正式告知とRFC編集・番号付与は別工程だ。本稿は文書をドラフトとして扱う。

第11版は日付の更新だけではない。9月3日のIESG telechat後、査読で示された曖昧さを処理した。未協商利用の禁止、Reliable Sizeが「minimum」であること、フレームそのものではなく現在情報を再送する説明、フィールド整合性の分離、並べ替え時の処理、STOP_SENDING後のゼロ推奨が加わった。

ここには四つの判断主体がいる。相手は拡張を開く。送信側はエラーとFinal Sizeと現在の配信下限を宣言する。アプリケーションは先頭バイトの意味を知る。受信アプリケーションは後から不要だと通知できる。「reliable reset」という一語でまとめると、誰が何を決めたのかが見えなくなる。

フレームの権限は相手から来る

対応は値0x1dのreset_stream_atで通知し、値部分は空でなければならない。理解できる実装が非空値を受け取ればTRANSPORT_PARAMETER_ERRORで接続を閉じる。第11版はさらに、相手が通知しない限りタイプ0x24を送ることをMUST NOTとした。

ライブラリにコードが入っていること、同じ製品の別接続で動いたこと、未知フレームが無視されるという期待は許可にならない。当該接続のハンドシェイクで相手が作った状態だけが根拠になる。送信側は仕様を知っているという理由で受信側の能力を推定できない。

0-RTTでは時間をまたぐ記憶が必要になる。双方はサーバーが前回この拡張を通知したかを覚える。サーバーがearly dataを受理するなら、再開接続で拡張を無効にしてはならない。0-RTT自体を拒否することはできるが、古い文脈を受け入れながら、その文脈に基づく送信権限だけを消すことはできない。

それでも分かるのは「解釈可能」という事実だけだ。先頭何バイトがセッションの生命線なのか、最初の正数が維持されるのかは決まらない。

Reliable Sizeは下方へ動く床である

RESET_STREAM_ATにはStream ID、Application Protocol Error Code、Final Size、Reliable Sizeが並ぶ。Final Sizeは送信側が最終的に生成したバイト数をQUICの会計に残す。Reliable Sizeはリセット後も受信アプリケーションへ届ける最低プレフィックスを示す。Reliable SizeがFinal Sizeより大きければFRAME_ENCODING_ERRORになる。

「最低」という語が重要だ。下限未満で失われたSTREAMデータは再送する。下限より上は再送すべきではないが、すでに到着したバイトをスタックがアプリケーションへ渡すことは妨げない。つまり値は厳密な切断線でも削除命令でもない。

初回値も固定されない。後のRESET_STREAM_ATで小さくでき、通常のRESET_STREAMは配信上ゼロへ縮めるのと同じである。値は減らすことだけができ、増やせない。現在の最小値を運ぶ情報と、その下のデータは確認されるまで再送対象になる。

送信側には一方向の撤退権がある。以前引き受けた配信を一部放棄できる一方、縮小後に大きな保証を復元できない。受信側が採用すべき現実は、履歴上最大の宣言ではなく、これまで見た最小の有効値である。

パケットの遅着は古い決定を復活させない

最初に96バイト、後から12バイトへ下げたとする。12を載せたパケットが先に着くことは普通に起きる。その後96が届いても、受信側は12を維持する。ネットワーク順序が意思決定順序を反転してはならない。

第10版の「増加するフレームを無視する」という表現では、同じフレームにあるError CodeやFinal Sizeの矛盾まで無視する恐れがあった。第11版は、無視する対象を増加だけに限定した。リセット間でError Codeは変えられず、リセットとFIN付きSTREAMの間でFinal Sizeも変えられない。違反はSTREAM_STATE_ERRORまたはFINAL_SIZE_ERRORとなる。

一つのフレームは一つの真偽値ではない。下限だけが古くても、他のフィールドはなお検査すべき証拠だ。状態をフィールド単位で扱うことが、実装差を防ぐ。

失えないプレフィックスはアプリケーションが決める

QUICドラフトは、アプリケーション・プロトコルがReliable Sizeの下限を定められるとしている。トランスポートが理解するのはオフセットまでであり、そこにセッションID、購読情報、オブジェクト分類があるかは知らない。

WebTransport over HTTP/3第16版は、データストリームをリセットするとき、WebTransportヘッダー以上のReliable SizeでRESET_STREAM_ATを使うことを要求する。ヘッダー中のIDがストリームをセッションへ結び付ける。そこを失えば、受信側はエラーを見ても、どのセッションの資源と状態を処理すべきか分からない。

Media over QUIC Transport第17版には近いが異なる規範がある。subgroup streamのヘッダーを下限に含めるべきだとし、購読の識別とPUBLISH_DONEでの会計に使う。不十分なら、購読状態がtimeoutまで残る可能性がある。

WebTransportのMUSTとMoQのSHOULDを同じ強さに読み替えてはいけない。QUICは減少可能な床を提供し、アプリケーションは身元の喪失が許容できるかを決める。機構と方針の分離こそ再利用性の条件である。

STOP_SENDINGは撤退の判断を作る

STOP_SENDINGは受信アプリケーションがそのストリームをもう望まないという信号だ。第11版は、応答にRESET_STREAM_ATを使う場合もReliable Sizeをゼロにすることを推奨する。関心を撤回した相手に正数プレフィックスを再送し続ければ、輻輳制御、flow control、メモリー、時間を受益者なしに消費する。

ゼロは通常リセットへの明示的な帰路であり、初回値が永久債務ではないことを示す。中継が別ホップへエラーを渡すためにヘッダーを必要とするなら、アプリケーションが例外を定義し、誰のために何バイトを何秒維持するかを説明しなければならない。

信頼性はキャンセルより常に上位の価値ではない。受益者と終了条件を欠く義務は、相手資源の拘束へ変わる。

resetという名前の後にも資源は残る

Final Sizeはstream単位とconnection単位のflow controlに従う。creditが足りなければ、送信側はRESET_STREAM_AT自体を延期する。上限違反はFLOW_CONTROL_ERRORだ。フレームはack-elicitingであり、失えば現在情報を再送し、下限内のデータも回復させる。

そのため送信側のData Recvdは、現在の最小値と対応データが確認されるまで来ない。受信側もバイト到着を待つ。安全性の節が資源コミットメントと枯渇への監視を続けるよう求めるのは、この「リセット後の仕事」があるからだ。

運用では、協商、初回値、最小値、Final Size、再送バイト、flow-control待ち、STOP_SENDING時刻、終了までの時間、timeoutまで残った状態を結び付ける必要がある。送信したreset数だけでは、負債の残量が見えない。

検証範囲

今回の資料が確かめるのは仕様、改訂差分、審査理由である。導入率、性能、相互接続、実装品質、実障害は示さない。ブラウザー、CDN、リレー、QUICライブラリ、メディア製品を試験していない。IANA状態は作業必要とするもので、すべての登録が確定済みとは主張しない。

WebTransport第16版とMoQ第17版も作業中である。引用した規範は上位層が境界を作る例であり、最終文言の予言ではない。QUIC第11版も出版工程で変わり得る。

残る結論は小さい。フレームの利用許可、現在の最低配信量、不可欠なアプリケーション・ヘッダー、受信側の停止意思は別々の権限である。running codeはその分離を状態、テスト、観測に残さなければならない。

出典