ECN · CNP · RoCEv2

DCQCN:RDMA 向け Quantized Congestion Control

DCQCN は、RoCEv2 ファブリックが PFC ポーズに頼り続けることなくロスレスを維持する仕組みです。 スイッチが早期に ECN をマークし、受信側が CNP をエコーし、送信側がレートを量子化することで、キューがあふれる前に送信側は速度を落とします。OcNOS-DC は xCCL コレクティブワークロード(NCCL、RCCL、oneCCL)向けに事前チューニングされたデフォルトを出荷し、逸脱が必要なファブリックのためにあらゆるしきい値を公開します。

Closed loopECN マーク、CNP、レート低減
Before PFCポーズに先立つ ECN マーク
xCCL事前チューニング済みの OcNOS-DC デフォルト
DC-PLUSOcNOS-DC ライセンスティア
その仕組み

DCQCN クローズドループ

送信側 NIC、輻輳したスイッチ、受信側 NIC。スイッチの WRED ECN マーカーは、キューが PFC ポーズしきい値に達する前に発動します。受信側は輻輳通知パケット(CNP)を生成し、送信側のリアクションポイントがレートを低減した後、再び上昇させます。ロスレス、PFC 圧力なし、高速収束。

DCQCN クローズドループ輻輳制御 左から右へ3つのボックス:送信側NIC(リアクションポイント)、WRED ECNマーカーを備えた輻輳スイッチ、受信側NIC(通知ポイント)。順方向の矢印は、パケットが左から右へ流れ、スイッチによってマーキングされる様子を示します。逆方向の矢印は、CNPが右から左へ送信側に戻る様子を示します。ラベルは、ECN K-min、K-maxのしきい値とCNPフィードバックパスを示しています。 データ+ECN 対応 ECN = CE(マーク付き) CNP:Congestion Notification Packet 送信側NICリアクションポイントα-update · cut · ramp OcNOS-DCスイッチWRED ECNマーカーK-min · K-max · P-max レシーバー NIC通知ポイントCNP every 50 µs DCQCN · WRED MARKING · CNP FEEDBACK · QUANTIZED RATE LIMIT · LOSSLESS RoCEv2
その働き

AIファブリックにおいてDCQCNが担う役割

RoCEv2 には輻輳を処理する 2 つの方法があります。ホップごとに伝播するバックプレッシャーである PFC ポーズと、エンドツーエンドのレート制御ループである DCQCN です。PFC 単独でも機能しますが、輻輳を上流へ押しやり、ポーズストームやヘッドオブラインブロッキングのリスクを招きます。DCQCN は PFC に先立って機能し、キューがポーズしきい値に達する前にパケットを ECN でマークするため、スイッチがポーズを発動せざるを得なくなる前に送信側が速度を落とします。

うまく設計すれば、ファブリックの運用時間の大半を DCQCN フィードバックのみで過ごし、PFC は安全策として機能します。設計が不適切だと、ECN しきい値が PFC ヘッドルームと整合せず、DCQCN を設定していてもポーズストームが発生します。 閾値チューニングこそがすべての鍵、OcNOS-DC は xCCL コレクティブトラフィック向けにチューニング済みのデフォルト値を提供しつつ、固有のトラフィックパターンを持つファブリック向けにすべてのパラメータを公開します。

リアクションポイント

送信側 NIC がレートを量子化

CNP を受信し、DCQCN を実行 α 更新、乗算的減少、加算的増加 ループにより送信レートを量子化します。

輻輳ポイント

スイッチが早期に ECN をマーク

ECN 対応パケットにマークを付与し CE キュー深度が K-min を超えると WRED カーブを用い、マーキング確率は K-max で P-max まで線形に上昇します。

通知ポイント

受信側が CNP をエコー

マークされた各フローについて送信側へ CNP を生成し、およそ次にレート制限されます フローあたり 50 µs に 1 回.

輻輳を処理する 2 つの方法

PFC ポーズと DCQCN の対比

どちらも RoCEv2 をロスレスに保ちますが、作用する地点が異なります。チューニングの目標は、ファブリックの稼働寿命を DCQCN フィードバックで過ごし、PFC はバックストップとして予備に留めることです。

Axis PFCポーズbackstop DCQCN主制御
Mechanism上流へ伝播するホップごとのバックプレッシャー。送信側から受信側へのエンドツーエンドのレート制御ループ。
トリガーポイントキューがポーズしきい値に達すると発動します。キューがポーズしきい値に達する前に ECN をマークします。
障害モードポーズストームやヘッドオブラインブロッキングのリスクを招きます。スイッチがポーズを発動せざるを得なくなる前に送信側が速度を落とします。
ファブリックにおける役割バッファがなお満杯になった場合のための、安全バックストップのみ。ファブリックの稼働寿命の大半における主制御。
Scopeリンクレベル、一度に 1 ホップ。エンドツーエンド、送信側から受信側まで。
In OcNOS-DC

OcNOSのDCQCN実装

箱から出してすぐ使える xCCL クラスのデフォルト。あらゆるしきい値が YANG モデル化されたパスとして公開され、適用前に PFC ヘッドルームに照らして検証され、立ち上げ時にはテレメトリとしてストリーミングされます。

WRED曲線

K-min, K-max, P-max

プライオリティキューごとに WRED ECN マーキング、K-min/K-max 閾値と P-max マーキング確率を設定可能。xCCL 級のデフォルトを標準搭載、YANG パスとして調整可能な形で公開。

Per-Priority

PFC 非依存

ECN マーキングは PFC のポーズしきい値とは独立して設定されます。両者の不整合は最も一般的な DCQCN 設定エラーです。OcNOS は適用前に、K-max、ヘッドルーム、ポーズアサートの関係を検証します。

VXLAN 対応

VXLAN上のECN

ECN ビットは VXLAN のカプセル化およびカプセル化解除を通じて保持されるため、DCQCN はアンダーレイ上だけでなく、EVPN-VXLAN オーバーレイ全体でエンドツーエンドに機能します。

テレメトリ

キュー単位のECNカウンター

出力キューごとのECNマーク付きパケット、キュー深度分布、CNPトリガレートをgNMIでストリーミング。クラスタ立ち上げ時のクローズドループチューニングが可能です。

Diagnostics

コミットする前に検証

K-min、K-max、および PFC ヘッドルームが、ロスレスプライオリティに割り当てられたバッファ空間と数学的に整合していることを CLI で健全性チェックします。設定ミスは早期に失敗させます。

Scope

DC-PLUSライセンスティア

OcNOS-DC PLUSスキューの一部です。同一のイメージ、同一のサポートで提供され、ロスレスRDMAスタックを有効化するための機能別アドオンは不要です。

障害モード

これが見かけ以上に重要である理由

「RoCEv2 が正しく動作しない」というサポートケースの大半は、DCQCN しきい値の不整合に帰着します。この誤りの両極端は正反対に見えますが、いずれもファブリックのチューニングを狂わせます。

  • ECN は設定されているがマークされない(K-min が高すぎる)。PFC が輻輳制御の負担をすべて担います。
  • ECN が過度に積極的にマークする(K-min が低すぎる)。実際の輻輳が生じる前に送信側がレートを低減します。
  • OcNOS-DC は、大半の TH4 および TH5 ファブリックで機能するデフォルトを出荷します。ファブリックが逸脱を必要とする場合、あらゆるパラメーターは YANG モデル化され、検証可能です。

それらのデフォルトが稼働する leaf-spine 階層をサイジングするには、次をお試しください AI Fabric サイジングツール、または次をご確認ください AIファブリックトポロジー デフォルト設定が最適化されている対象です。

IP Infusion の見解

DCQCN が負荷を担い、PFC はバックストップに徹する

健全な RoCEv2 ファブリックは ECN フィードバックで動作し、PFC にはほとんど触れません。OcNOS-DC はそのバランスをデフォルトとして提供し、ワークロードが異なる設定を必要とする際にはあらゆる閾値へ手が届く状態を維持します。

DCQCN が負荷を担う

ECN マーキングと CNP フィードバックが送信側を早期に減速させるため、健全なファブリックは動作時間の大半を DCQCN で過ごし、PFC ポーズに至ることはめったにありません。

xCCL 向けに初期状態でチューニング済み

OcNOS-DC は xCCL コレクティブトラフィック向けに事前チューニングされたデフォルトを提供するため、ほとんどのファブリックは閾値に触れることなく TH4 および TH5 で良好に動作します。

あらゆる設定項目がモデル化

K-min、K-max、P-max は YANG でモデル化され検証可能なため、特定のトラフィックパターンを持つファブリックでも安全に逸脱可能です。

よくある質問

DCQCN、その答え

DCQCN とは何ですか。
DCQCN(Data Center Quantized Congestion Notification)は、Ethernet の AI およびストレージファブリック上で RoCEv2 RDMA トラフィックをロスレスに保つ輻輳制御アルゴリズムです。キューがオーバーフローする前に送信側を抑制するため、GPU およびストレージのフローはパケット破棄やストールを回避できます。
DCQCN はどのように機能しますか。
DCQCN は閉ループで動作します。キューがしきい値を超えるとスイッチがパケットに ECN マーキングを施し、受信側は Congestion Notification Packet(CNP)を送信側に返送します。送信側は送信レートを引き下げ、その後、輻輳が解消するにつれて段階的に回復させます。
DCQCNとPFCはどのように連携して動作しますか。
DCQCNが主たる制御であり、PFCは最後の砦です。ECNマーキングとCNPフィードバックが送信側を早期に減速させるため、フローがポーズに至ることはめったにありません。PFCはそれでもバッファが埋まる場合にのみ発動し、パケット損失を防ぎます。チューニングは、fabricをECN制御下に保ち、PFCポーズの継続を回避することを目的とします。
DCQCN における ECN の K-min および K-max のしきい値とは何ですか。
K-min と K-max は、ECN マーキングを制御するキュー深度のしきい値です。K-min を下回るとパケットはマーキングされず、K-max を上回るとすべてがマーキングされます。その間ではマーキング確率が設定された最大値に向かって上昇するため、輻輳シグナリングは急激に作動するのではなく、キューの増大に応じて段階的に変化します。
DCQCN には RoCEv2 が必要ですか。
はい、DCQCN は RoCEv2 RDMA トラフィック向けに設計されており、RoCEv2 エンドポイントが CNP フィードバックを生成し、それに応じて動作することを前提としています。ネットワーク内の ECN と RoCEv2 送信側でのレート制御を組み合わせるため、RoCEv2 fabric における標準的な輻輳制御の選択肢となっています。

実際のワークロードに合わせて DCQCN をチューニングしますか?トレースをお寄せください

ECN カウンターとキュートレースをお送りいただければ、IP Infusion のエンジニアが K-min、K-max、PFC ヘッドルームを調整します。あるいは AI Fabric Design Suite でリーフスパインの初回レイアウトから始めることも可能です。