要約

  • draft-xiao-fann-fast-cnp-with-proxy-05では、輻輳ノードがUDP通知をプロキシへ送り、プロキシがRoCEv2送信者向けの標準CNPを新たに構成する。
  • そのCNPは送信速度を下げるには有効でも、使用したQP対応表の版、元の輻輳点、ローカル制限で捨てた入力通知の数は示さない。

送信者の目には、いつものCNPが一つ届く。Source QPの速度を落とす判断には十分だ。だが、そのパケットを輻輳ルーターが直接送ったとは限らない。別形式の第一通知を受けたプロキシが、過去に観測した双方向トラフィックから対応を引き、第二のパケットを作ったのである。

9月29日付のFast Congestion Notification Packet with Proxy第05版は、この間接経路を提案する。VPNのPルーターと送信者が別のルーティング領域にいる場合や、輻輳ノードが標準RoCEv2 CNPに必要なSource QPを知らない場合に、プロキシが到達性と状態を補う。

CNPは対応表から再構成される

形式1は、原因トラフィックのIP 5-tupleと24ビットのDestination QPを、提案中のUDPポートTBD1へ運ぶ。送信元アドレスが送信者を示し、プロトコルと宛先ポートがRoCEv2なら、プロキシは標準CNPを生成しなければならない。

ただし第一通知にはSource QPがない。プロキシは送信元・宛先アドレスの文脈で、Source QPとDestination QPの対応表を参照する。第05版は、その表を学習するにはプロキシがRoCEv2の往路と復路の両方を通過位置で観測する必要がある、と明確にした。

形式2は別のTBD2を使い、5-tupleとNRP Selector IDを運ぶ。プロキシは選択子からSource QPまたはVPN IDを探す。この識別子は検索キーであって、対応表の鮮度や正しさを証明する署名ではない。

PNC広告は能力の所在だけを示す

輻輳ノードは、送信者プレフィックスを担当するプロキシを先に知る必要がある。提案はProxy Node Capabilityをプレフィックスに付け、IS-ISとOSPFではPフラグ、BGPではプロキシアドレスを持つNext Hop Dependent Characteristic TLVを使う。

それで分かるのは第一通知の送り先である。プロキシが両方向を最近見たか、正しいQPを保持するか、制限に達していないか、機能が有効か、第二通知が到着したかは分からない。エリア間でPフラグを正しく保存しても、データ面の表まで検証したことにはならない。

制御面とデータ面の時間軸は別だ。プレフィックス広告が残ったまま実経路が変わり、学習表だけが古くなることがある。NRPやVPNの関係が変わっても能力フラグは同じである。PNCをそのまま「正常」と表示する設計は、このずれを隠す。

防御のための破棄は完全性を失わせる

通常は第一通知一つにつき第二通知一つを送る。ところが受信頻度がプロキシの上限を超えれば、ローカル方針に従って一部を捨ててもよい。セキュリティ節も生成・受信のレート制限、領域境界での入出力遮断、既定で無効という設定を求める。

DoS対策としては合理的だが、送信者が見る列は上流イベントの完全な列ではなくなる。十件の第一通知が三件のCNPになるかもしれない。標準CNPには元イベントID、破棄数、方針理由、表の版、輻輳点IDがない。届かなかった七件を沈黙から復元することはできない。

無通知には複数の意味がある。輻輳なし、プロキシ選択の失敗、古いPNC、対応なし、境界フィルター、機能無効、入力制限、第二経路の損失である。逆に一つ届いても、全件数やボトルネック位置までは確定しない。

互換パケットを完全な受領証にしない

変換CNPには明確な価値がある。新しい内部形式を実装していない送信者にも、どのSource QPを減速するか伝えられる。問題はそれを来歴証明に格上げすることだ。

UDPの形式とチェックサムは、第一通知のバイト列、元ノード、受信時刻、使用表、ローカル破棄を第二通知へ結び付けない。送信者が実際に減速したことや、キューが回復したことも証明しない。

運用では複数の証拠を結ぶ必要がある。輻輳点のキュー/ECNカウンターと第一通知数、当時のPNC経路、プロキシの対応表世代と学習時刻、受理・拒否・制限・送信数、ホストの受信CNPとレート変化、そしてスループットや完了時間である。単一のCNPはその一部にすぎない。

第05版は非RoCE送信者一般への広い説明を削り、標準RoCEv2経路と双方向観測要件を絞り込んだ。またECNマーク付きデータパケットをプロキシ入力に使う実装にも触れるが、範囲外としている。これは第三の規格形式でも相互運用結果でもない。

文書はstreamも担当ADも正式なIETF上の地位もない個人Internet-Draftである。ポート、ビット、BGPコードは提案段階で、凍結資料に導入、性能、障害の証拠はない。

経営判断としては、互換性によってプロキシが新しい制御主体になる点を認めるべきだ。自動化が単に減速する以上の判断、たとえば障害帰属や顧客措置を行うなら、変換判断そのものを別の受領証として残す必要がある。

出典