要約

  • 9月30日更新のMASQUE作業部会草案は、QUIC DATAGRAMの実効容量を超えるEthernetフレームを廃棄し、そのフレームをDATAGRAMカプセルへ回してはならないと定める。受信後に復元したフレームが出口インターフェース、接続先ネットワークまたは受信側の上限を超える場合も廃棄し、過大フレームの廃棄数を記録するよう勧める。
  • 第14版は元のFrame Check Sequence（FCS）を含めて運ぶ記述だった。第15版のContext ID 0のペイロードはFCS直前で終わる。通常のネットワーク機器が入力時にFCSを取り除き、出力時に新たに付けるためだ。これはIESG審査中のInternet-Draftであり、公開済みRFCでも、現場の障害を裏づける報告でもない。

二つの確認を分けて考えたい。一つはHTTPトンネルを確立できたか。もう一つは、そのトンネルが実際に受け取るフレームの大きさを処理できるか。前者は接続の応答で分かるが、後者は小さな試験フレームを一枚通しただけでは分からない。第15版が追加した規範は、会話の成立と個別フレームの受け入れを切り離す。

HTTP/3とQUIC DATAGRAM拡張を使う構成では、Ethernetフレームは分割できないDATAGRAMに収まらなければならない。その最大値からHTTP Datagramの識別情報などのオーバーヘッドを引いた残りが実際の予算となる。到着したフレームが予算を超えれば、端点は廃棄する。ここで第15版は、同じフレームをDATAGRAMカプセルに載せ替えて送ることも禁止する。経路MTUの探索や接続中のインターフェースMTU調整は今後の設定を助けるが、すでに入らなかったフレームを成功扱いにはできない。

カプセルを使う運用モードそのものは残る。HTTP/1.1とHTTP/2、またはQUIC DATAGRAMを使わないHTTP/3では、カプセルが信頼性のあるストリームを通り、一つのフレームを複数のTCPまたはQUICパケットにまたがって運べる。この方式なら経路の一パケット分のMTUより大きなフレームも扱える。しかし「別のモードが大きなフレームを運べる」という事実は、DATAGRAMモードで過大になった一枚を黙って救済してよいという意味ではない。この取り違えは、設計レビューで最も避けたい。

出口側にも独立した上限がある。トンネルを通ったフレームを復元しても、接続するインターフェースやネットワーク、受信端末の最大フレーム長を超えるなら廃棄しなければならない。草案は過大フレームの廃棄カウンターを推奨する。入口でのQUIC DATAGRAM容量不足と出口での再送出不能を別々に数えれば、失敗した場所を絞り込める。ただし、その数値だけでアプリケーションの不調全体の原因まで証明することはできない。

FCSについては、旧版との比較が欠かせない。第14版はプロキシが運ぶEthernetフレームにFCSを含め、両端での再計算を避けると説明した。第15版は宛先アドレスからFCS直前までをContext ID 0のペイロードとし、FCSを除いた。一般的なインターフェースでは受信時に元のFCSを外し、送信時に新しいFCSを生成するからだ。Ethernetリンクで誤り検出が不要になったわけではない。元のリンクで付いたFCSを、プロキシを越えて保全される一枚の証拠と呼べないということだ。将来の拡張が別の符号化を定める可能性は残る。

草案の仮想リンクはポイント・ツー・ポイントとして描かれる。外部のブロードキャストドメインに接続するなら、ブリッジ処理、ループ防止、マルチキャストやPAUSEフレームへの対処などは端点または委任された構成要素の仕事になる。VLANタグは原則として透過的に転送されるが、両端が解釈するなら整合した取り決めが必要で、その手順を本草案は定めない。VLAN別のURIも選べる手段であって、無条件の隔離や配送の保証ではない。

Datatracker上ではMASQUE作業部会の文書がIESGへ提出され、AD Followupの状態にあり、DISCUSSも残っている。意図する位置づけはProposed Standardだが、現時点ではRFCではない。改訂は運用条件を明確にしたのであって、特定の実装が損失を起こしたことや、どの程度普及したかを示していない。問うべきなのは、サービス提供者の計測が「つながった」と「そのフレームを渡せた」を別の事実として扱えるかである。

出典