要約

  • RFC 10055はApple、Linux、Windows上でChromiumにUDP ECNを実装した際のAPIを記録するInformational文書であり、各OSを拘束する仕様ではない。
  • アプリケーションが信号を使うには、ソケットで受信を有効化し、データグラムごとの補助データを読み、OSごとの形式を正しく解釈する必要がある。

ネットワークが輻輳を示すコードポイントを付けても、その情報がトランスポートの制御ループに届くとは限らない。RFC 10055は、IP層とUDPアプリの間にあるソケットAPIを、実装上の独立した制御点として可視化した。

このRFCはChromiumでUDP上のECNを動かすため、Apple、Linux、Windowsの実験結果を記録している。IETF Informational文書であり、Internet Standards Trackの仕様ではない。プラットフォームに特定APIを義務付けず、内容は執筆時点のスナップショットなので、現行動作は各OSの資料で確認するよう促している。

ECNはIPヘッダーの2ビットを使う。RFC 3168が基本機構を定義し、RFC 9330はL4Sのアーキテクチャで明示的な輻輳信号を活用する。UDP上のQUICについてはRFC 9000が経路ごとのECNカウンター検証を定め、異常が見つかればその経路でECNを止める。検証の前提は、受信した印をアプリケーションが観測できることだ。

RFC 10055は受信の設定と取得を別の処理として説明する。まずソケットにECN通知を有効にし、各データグラムに付随する補助データを recvmsg() で読む。Linux、Apple、FreeBSDではIPv4に IP_RECVTOS、IPv6に IPV6_RECVTCLASS を用いる。LinuxのIPv6ソケットがIPv4も受け取るデュアルスタック構成では、IPv4のECNを得るために IP_RECVTOS も必要になる。文書のAppleとFreeBSDの手順には、この追加設定はない。

Windowsでは WSASetRecvIPEcn() が推奨され、WSARecvMsg の制御データとして値が返る。しかし、RFCはデュアルスタックやIPv4-mapped IPv6アドレスで別処理が要るケースを記す。ソケットをIPv6として作った、というだけでは、全パケットで同じ受信能力があると判断できない。

補助データの中身も同一ではない。Linux、Apple、FreeBSDではDSCPとECNを含むDSフィールド全体が返る場合がある。Windowsの IP_ECN と IPV6_ECN はECNコードポイントのみを返す。共通コードがOSごとのデータ形状を区別しなければ、同じビット操作が異なる意味になる。

送信側でもソケット単位とパケット単位の選択がある。Apple、FreeBSD、Linuxではソケット全体の印を設定できる一方、異なる接続を1つのソケットで扱うサーバーはパケットごとの指定を必要とすることがある。RFC執筆時点でWindowsにはソケット単位の設定方法がなかった。また、一部のOSでは IP_TOS や IPV6_TCLASS の変更がDSCPも変える。ECNだけのつもりの書き込みが他のコンポーネントのサービス区分を消さないよう、既存値の保持と同時更新への対策が要る。

見落とした受信設定、欠けた制御メッセージ、誤ったパースは、輻輳信号がない状態と見分けにくい。RFC 10055は、OSごとにECN対応が異なると相手がOSを推定する手掛かりになり、プライバシーに影響し得るとも述べる。ただし、その発生頻度や実測可能性は示していない。

能力の証跡は、OSバージョン、IPファミリー、デュアルスタック状態ごとに分けて残すべきだ。記録対象はオプションの成否、制御メッセージの型と長さ、抽出されたコードポイント、DSCPの保持、QUICなどトランスポートでの検証結果である。ソケットがCEを渡した事実は、送信側の応答や利用者体験の改善を証明しない。

IETFのInformational文書がここで担う役割は、OSに設計変更を命じることではない。プラットフォームごとの接続方法を明らかにし、他の実装が追試できる材料を与えることだ。共通化するのはAPI名ではなく、ECNを正しく上位へ届け、DSCP設定を壊さないという試験可能な結果である。OS固有のAPIはその契約の実装方法として残せる。

出典