要約

  • FALCONの00版は、往路パケットが記録したリンクを高優先度の復路パケットで逆にたどり、往路側のキューとフロー制御バッファを採取する。早い証拠であって、経路変更命令ではない。
  • ノード／インターフェースと隣接SIDの対応、未対応区間、対象クラス、採取時刻、欠損値によって、根本原因について言える範囲は限定される。
  • レート低減や迂回には、実際に適用されたことを示す記録と、その後にサービスが改善したことを示す独立測定が必要になる。

写真ではなく、移動する走査

通常のフィードバックでは、混雑の観測が残りの往路を進み、受信側に着いてから送信側へ戻る。混雑を生んだキューが警告そのものを遅らせることもある。FALCONは、この時間配置を変える。

往路パケットPはノードと入出力インターフェースの識別子を記録する。受信側はその記録からSRv6のセグメントリストを組み立て、高優先度のP'をリンクの逆順に送る。対応ノードは、P'が到着したインターフェースに対応する往路側の出力キューを採取する。遠いノードの値は、そのノードから送信側までの片方向遅延に近い時間で届き得る。

ただし、P'の行は同じ瞬間の状態ではない。遠いノードを先に、近いノードを後に測る移動走査である。鮮度とは各サンプルの採取から送信側到着までの時間であり、採取頻度とは異なる。「RTT未満」という表現だけでは、この時間差を説明できない。

00版は2026年9月28日に提出され、2027年4月1日に失効する。Datatracker上ではActiveかつI-D Existsの個人提出で、stream、Area Director、shepherd、標準化段階、RFC番号はいずれもない。実装、相互接続試験、配備、性能測定、実事故を報告した文書でもない。現時点の速度評価は提案設計の分析である。

復路を作る台帳

ルータ名の列だけでは、元のリンクを逆にたどれない。ECMPや並列リンクではノードSIDはノードまでしか指定せず、Pが出たインターフェースを確定できない。受信側には、記録されたノード／インターフェースの組を隣接SIDへ対応付ける台帳が要る。台帳を運用者が設定するか制御プレーンから学習するか、その配布方法は00版の範囲外だ。

したがって、検証可能な記録には元の識別子、セグメントリスト構築に用いた対応表の版、LAGのメンバーリンク、対象トラフィッククラス、時刻が必要になる。フローが再ハッシュまたは再経路化されたら、旧経路の状態は捨てなければならない。

部分配備では、非対応ノードが記録されず、観測できない区間が残る。その区間の通常転送が往路の厳密な逆を再現する保証もない。空白をゼロで埋めず、観測不能として残すことが、原因推定の境界になる。

同じ「詰まり」ではない

Forward Queueは、対象クラスが使う往路インターフェースの出力キューである。Flow-Control Bufferは受信側の別の会計で、PFCなどのホップ単位の抑制を起動し得る。動的なしきい値を使う場合もある。出力キューが深いという事実だけでは、上流を止めるまでの余裕を示せない。

両者が揃えば、下流から抑制されていない大きなキューを混雑源の候補とし、バックプレッシャーで止まった上流キューを被害側とする推定が可能になる。それでも結論は、採取した経路、クラス、時点、利用できたフィールドに限られる。値を提供できないノードはunavailableと明記すべきで、無言をゼロと扱ってはならない。

パケット内集約はP'の大きさを抑える代わりに詳細を失う。合計は経路のキュー遅延を、最大値はボトルネックの値とノードを、最小値は最少ヘッドルームを残せる。しかし破棄したホップ別記録は後から復元できない。集約方式は、将来答えられなくなる問いも決める。

通知と行動の間

FALCONはホップ別状態や遅延を輻輳制御または負荷分散機能へ渡すが、送信側の反応を明示的に範囲外とする。関連するFANNフレームワークも、検出、生成、配送、消費、行動、回復を分け、通知を行動中立に置く。

同じ通知を受けても、レートを下げる、リンクを避ける、フローを移す、追加サンプルを待つ、何もしないという選択肢がある。アプリケーション優先度、経路多様性、費用、安定性が答えを変える。複数の送信側が一斉に同じ代替経路へ移れば、新たなホットスポットを作る可能性もある。最速の警告がルーティングテーブルを所有するわけではない。

優先レーンを無制限にしない

P'は復路の待ち時間で鮮度を失わないよう、高優先度・低遅延のPHBを受ける。そのDSCPのローカル対応には、容量予約、policing、レート制限が要る。そうしなければ一般トラフィックが優先レーンを偽装し、通知の集中が別の重要通信を圧迫する。

偽造または改変されたP'は、不必要なレート低下や悪い経路変更を引き起こせる。送信側はnonceなどで未完了のPとの対応を確認し、受信側は全SIDがローカルドメイン内にあること、元の送信元が最終宛先であることを検証し、生成量を制限すべきだ。IOAMの完全性保護は改変を抑えても、推定や行動の妥当性までは証明しない。

適用範囲は一つのSR・IOAM管理ドメインである。境界フィルタ、信頼方針、トポロジーやバッファ情報の開示制御は、後付けの運用項目ではなく成立条件だ。