要約

  • FQ-PIE は可視の 5 タプルを有限個のキューにハッシュし、キューごとの PIE と DRR 派生スケジューラで処理する。
  • 目標遅延、バースト許容量、キュー訪問は局所制御の事実であり、顧客、アプリケーション、トンネル、完了時間の公平性を直接示さない。
  • 分類、測定、輻輳判断、スケジューリング、送信側反応、利用者結果を別々の証跡として保存する必要がある。

猶予は故障ではない

短い到着バーストがキューを押し上げ、推定遅延が目標値を超えたとする。それでもバースト許容量が残っていれば、到着パケットはランダム廃棄の判断を迂回できる。画面上では目標超過と無廃棄が同時に起きる。この一枚だけを見れば、制御器が働かなかったようにも、すべてが正常だったようにも説明できる。

どちらも証拠を読み過ぎている。PIE は短いバーストを吸収しながら、持続するキュー遅延を制御するよう設計されている。目標値は各パケットに対する期限ではない。バースト許容量は無制限の免除でもない。したがって評価には、目標、更新間隔、許容量の残量、測定時刻、判断時刻、後続の回復を同じ時間軸で並べる必要がある。

2026 年 7 月 6 日付の IETF TSVWG Internet-Draft 第 02 版は、Flow Queue PIE をフローキューイングと PIE の組み合わせとして記述する。期限は 2027 年 1 月 7 日。Datatracker 上は作業部会文書で IESG 状態は I-D Exists、本文の想定ステータスは Experimental であり、RFC ではない。

有限のバケットは主体名簿ではない

入力パケットはプロトコル番号、送信元と宛先のアドレス、送信元と宛先のポートからなる可視の 5 タプルで分類され、有限個のキューバケットへハッシュされる。実装可能性のために有効な方法だが、ハッシュ値は顧客 ID でもアプリケーション ID でもない。

異なる 5 タプルが同じバケットへ衝突することがある。その瞬間、無関係なフローは同じ PIE 状態とスケジューリング処遇を共有する。反対に、一人の利用者が複数接続を開けば、多数のバケットで独立したサービス機会を得られる。全バケットに公平に訪問しても、顧客間の合計配分が公平だとは限らない。

証跡には、入力キー、ハッシュ方式と摂動の世代、テーブル数、選択バケット、衝突の兆候を残すべきだ。キュー番号だけでは、永続的な主体と一時的な実装上の住所を区別できない。

トンネルは見える単位を変える

暗号化された VPN やその他の不透明なカプセル化では、多数の内部セッションが一つの外側フローに見えることがある。一方、暗号化されていないアプリケーションは複数の 5 タプルに分かれる。境界によってはトンネル単位が適切だが、加入者単位やアプリケーション単位を意図していたなら測定対象がずれている。

内部識別子を無理に露出させることはプライバシーと安全性の別の問題を生む。必要なのは、フローという語を道徳的な公平性の同義語にすることではない。観測点で可視の単位と、組織が保護したい単位を明示的に結び、結べない場合は不確実性として記録することである。

測定点が結論を決める

PIE はキュー遅延の目標からの差と変化方向を使って廃棄確率を更新する。RFC 8033 の例では目標と既定の更新間隔はいずれも 15 ミリ秒である。遅延は Little の法則に基づきキュー長とデキュー速度から推定することも、パケットのタイムスタンプから直接得ることもできる。

FQ-PIE 草案はキューごとのデキュー速度推定が不安定になり得ると説明する。ホストのキューからデバイスドライバの送信リングへ移った時刻は、回線上で実際に送信された時刻とは限らないからだ。そのため直接タイムスタンプを使うべきだとしている。

直接測定でも、最新にデキューされたパケットの値が現在の到着群を代表するとは限らない。サンプルは真正でも、リンク速度や負荷構成が急変した後には古い。測定点、サンプル時刻、年齢、前回値、更新時刻、オフロード状態を欠く「現在遅延」は、再現可能な事実にならない。

マークと廃棄は局所判断である

ECN 対応パケットには廃棄の代わりにマークを付けられる。これは局所ノードが特定の設定と確率の下でフィールドを変更した証拠になる。しかし受信側が反映し、送信側がレートを下げ、下流のボトルネックが解消し、アプリケーションが改善したことまでは示さない。

総パケット容量がすでに飽和していれば、新しい到着はそれ以上の処理なしに廃棄される。これは非収容の証拠であって、どの顧客が原因かを示す責任証明ではない。草案は FQ-CoDel のように最大バイトキューを探して大量廃棄する方式を採らず、PIE がエンキュー時に働く状況でのリンク未使用を懸念する。この差も判断記録に必要だ。

キューへのサービスと成果は別物だ

DRR 派生スケジューラは量子と deficit を使い、アクティブなキューを巡回する。訪問、正の deficit、送出バイト数は、そのバケットがサービスを受けたことを強く示す。しかしフロー完了時間の平等は示さない。パケット長、往復時間、輻輳制御、需要、下流ボトルネック、一主体あたりのフロー数が結果を変える。

高いリンク利用率も分配の証明ではない。出力が常に忙しい間に、疎なフローが衝突し、巨大なトンネルが一つのキューに入り、一つのアプリケーションが多数のキューを占めることは可能だ。平均遅延、利用率、アクティブキュー数、顧客体験を単一の「公平」指標に畳むべきではない。

草案が Linux、FreeBSD、ns-3 の実装を挙げていることは running code の証拠である。しかし対象インターフェースが FQ-PIE を選んだこと、同じパラメータで動くこと、オフロード境界、利用者結果までは証明しない。BBR との相互作用、マークと廃棄の閾値、短いフロー、代替ハッシュなどは引き続き実験課題として挙げられている。

出典