> [!abstract] 概要(arXiv abstract の日本語訳) > RoCE(RDMA over Converged Ethernet)の登場は、データセンターネットワークにおける RDMA 利用の大幅な増加をもたらした。良好な性能を達成するために、RoCE は Priority Flow Control(PFC)をネットワーク内で有効化することで達成される無損失ネットワークを必要とする。しかし PFC は、head-of-the-line blocking、輻輳の伝播(congestion spreading)、そして時にはデッドロックといった多くの問題を引き起こす。これらの問題を修正しようとする代わりに、我々はこう問う: PFC は Ethernet 上で RDMA をサポートするために根本的に必要なのか? > 我々は、PFC の必要性が現行の RoCE NIC 設計のアーティファクトであり、根本的な要件ではないことを示す。我々は、パケットロスをより適切に処理するために RoCE NIC にいくつかの単純な変更を加えた、改良版 RoCE NIC 設計である IRN を提案する。我々は、IRN(PFC なし)が典型的なネットワークシナリオにおいて RoCE(PFC あり)を 6〜83% 上回ることを示す。したがって IRN は PFC の必要性を排除するだけでなく、その過程で性能を向上させる。さらに我々は、IRN が導入する変更が NIC リソースへのわずか 3〜10% のオーバーヘッドで実装可能であることを示す。我々の結果に基づき、研究および産業界は RDMA のためのネットワークサポートの現在の軌道を再考すべきだと主張する。 ## 論文情報 - タイトル: Revisiting Network Support for RDMA - 著者: Radhika Mittal¹、Alexander Shpiner³、Aurojit Panda⁴、Eitan Zahavi³、Arvind Krishnamurthy⁵、Sylvia Ratnasamy¹、Scott Shenker¹² - 所属: ¹UC Berkeley、²ICSI、³Mellanox Technologies、⁴NYU、⁵University of Washington - 媒体・発表年: ACM SIGCOMM 2018(SIGCOMM '18、2018-08-20〜25、Budapest, Hungary)、pp. 313–326 - DOI: https://doi.org/10.1145/3230543.3230557 - Extended Version: arXiv:1806.08159(付録に詳細評価と実装の議論を含む) ## 概要 現行の RoCE(RDMA over Converged Ethernet)は、良好な性能を得るために PFC(Priority Flow Control)で実現される無損失ネットワークを前提とするが、PFC は head-of-the-line blocking・輻輳伝播・デッドロックといった問題を引き起こす。本論文は PFC の問題を個別に修正するのではなく、そもそも PFC が RDMA over Ethernet に本質的に必要かを問い直す。RoCE NIC に 2 つの小変更(効率的なロス回復・BDP ベースのフロー制御)を加えた IRN(Improved RoCE NIC)を提案し、シミュレーションにより IRN(PFC なし)が RoCE(PFC あり)を上回る性能を発揮すること、および実装オーバーヘッドが小さいことを示す。 ## 問題設定 - **入力**: RoCE NIC の現行トランスポート設計(Infiniband 由来の go-back-N ロス回復、PFC による無損失ファブリック前提)。 - **前提条件**: RoCE は Infiniband の transport 設計をそのまま Ethernet に移植したものであり、NIC は out-of-order パケットを単純に破棄し、送信側は NACK 受信時に go-back-N 再送(最後に確認されたパケット以降の全パケットを再送)を行う。この設計は Infiniband の専用クラスタ(パケットロスが稀)を前提としており、パケットロスを効率的に回復するようには設計されていない。 - **問い**: RoCE NIC の設計を変更すれば、無損失ネットワークファブリック(=PFC)を不要にできるか?(§1) ## 提案手法 ### アーキテクチャ IRN は現行 RoCE NIC への 2 つの重要な変更からなる(§3)。 1. **効率的なロス回復**(§3.1): TCP のロス回復に着想を得た選択的再送(selective retransmission)ベースの機構。受信側は out-of-order パケットを破棄せず、送信側はロスしたパケットのみを選択的に再送する。 2. **BDP-FC(基本的なエンドツーエンドフロー制御)**(§3.2): フローのアウトスタンディングパケット数をネットワークの帯域幅遅延積(BDP)で上限する静的なキャップ。 これら 2 つの変更は、DCQCN や Timely のような明示的輻輳制御メカニズムとは直交しており、IRN と併用してオプションで有効化できる(§3 冒頭)。 ### アルゴリズム/手法の詳細 **ロス回復(§3.1)**: IRN の受信側は out-of-order パケット到着のたびに、累積確認応答(期待シーケンス番号)とトリガーとなったパケットのシーケンス番号(簡易版 SACK)の両方を含む NACK を送信する。送信側は NACK 受信時またはタイムアウト時にロス回復モードに入り、どのパケットが累積的・選択的に確認されたかを追跡するビットマップを保持する。ロス回復モード中は新規パケットでなく、ビットマップが示すロスしたパケットを選択的に再送する。ロス回復に入った際に最初に再送されるパケットは累積確認応答値に対応し、それ以降のパケットはより高いシーケンス番号を持つパケットが選択的確認されて初めてロスとみなされる。ロスしたパケットが残っていなければ、送信側は新規パケットの送信を継続する(BDP-FC が許す限り)。回復シーケンス(ロスパケットの再送前に送信された最後の通常パケット)より大きい累積確認応答を受信するとロス回復モードを終了する。 SACK は複数パケットがフライト中の場合のみ効率的に機能するため、単一パケットメッセージなどではタイムアウトによりロス回復がトリガーされる。IRN 送信側は、フライト中のパケット数が少ない(N 個以下)場合のみ低いタイムアウト値 $RTO_{low}$ を使用し(スプリアス再送を無視できる程度に抑えるため)、それ以外では高い値 $RTO_{high}$ を使用する二段階タイムアウト方式を採る。 **BDP-FC(§3.2)**: ネットワーク中で最長パスの BDP(バイト単位)を RDMA キューペアが設定するパケット MTU(RoCE NIC では通常 1KB)で割った値を BDP キャップとする静的な上限。IRN 送信側は、現在のパケットのシーケンス番号と最後に確認されたシーケンス番号の差(=フライト中のパケット数)がこの BDP キャップ未満の場合のみ新規パケットを送信する。BDP-FC は不要なネットワーク内キューイングを削減して性能を向上させるとともに、out-of-order パケット到着数を厳密に上限することで、NIC でのロス追跡に必要な状態量を大幅に削減する(§6 で詳述)。 **iWARP との設計上の違い**: IRN のロス回復は TCP のロス回復に着想を得ているが、iWARP のように TCP スタック全体を実装するのではなく、(1) ロス回復を輻輳制御から分離し、slow start・AIMD・高度な fast recovery といった TCP 輻輳ウィンドウ制御の概念を組み込まない、(2) TCP のバイトストリーム抽象化ではなく RDMA セグメントに直接作用することで、複数の変換レイヤの複雑さを回避しつつ SACK・ロス追跡機構を単純化する(§3.2 末尾)。 ### 実装上の工夫(§5) IRN を現行 RoCE NIC に段階的に実装する方法を、RDMA のパケットフォーマット拡張(新規フィールド・パケットタイプの導入)により提示。これらの拡張は IP/UDP ヘッダ内にカプセル化される(RoCEv2 と同様)ため、エンドホストの挙動のみに影響しスイッチ側の変更は不要。 - **Read/Atomic のサポート(§5.2)**: RoCE は Write/Send に対して per-packet ACK を既にサポートするが、Read はサポートしない。IRN は Read 応答パケットごとに要求側が送信する read (N)ACK パケットを導入する(RoCE の未使用 opcode を利用)。Read responder(データソース)にもタイムアウト機構を実装する必要がある。 - **Out-of-order(OOO)パケット配送のサポート(§5.3)**: IRN の主要な実装課題。ナイーブな方法(全 OOO パケットを NIC メモリに保存)は BDP キャップ分(デフォルトシナリオで約 110 MTU サイズパケット)のバッファを要し、千フローで 110MB に達し商用 NIC のメモリ容量を超える。そこで IRN は OOO パケットをアプリケーションメモリの最終アドレスへ直接 DMA し、BDP キャップサイズのビットマップで追跡する代替実装戦略を採る(Mellanox ConnectX-5 の adaptive routing 向け部分的 OOO サポートを拡張)。この方式は 4 種類の課題(先頭パケット問題・WQE マッチング問題・末尾パケット問題・アプリケーションレベル問題)に分類され、それぞれに対策(RETH ヘッダの全パケット付与、recv_WQE_SN/read_WQE_SN による WQE 識別、2-bitmap による末尾パケット追跡と早期 CQE 生成 等)を講じる。 - **PSN 空間の分離(§5.4)**: 要求側の送受信パケットを sPSN(送信要求追跡)と rPSN(受信応答追跡)の 2 つのシーケンス番号空間に分割し、ロス追跡・BDP-FC との干渉を回避する。 ## 新規性 既存の RoCE 研究は PFC の問題(head-of-the-line blocking、輻輳伝播、デッドロック)を個別に緩和する方向(DCQCN・Timely 等の輻輳制御、Resilient RoCE[34] 等)に向かっていたが、本論文は「PFC が本当に必要か」という前提そのものを問い直す点で新規性を持つ。 - iWARP は同様の思想(ロスをネットワークでなく NIC で処理する)を長年前から提案していたが、TCP スタック全体をハードウェアに実装するという設計選択のために複雑・高コストとなり市場で RoCE に敗れた。本論文は iWARP と RoCE を rigorously に比較した初めての研究であると主張し(§1)、iWARP の設計思想自体は正しかったが実装が複雑すぎたことを実測で示す。 - 効率的なロス回復と BDP-FC という最小限の変更のみを RoCE NIC に加えることで、無損失ネットワークより優れた性能を達成できることを、本論文が初めて厳密に示したと主張する(§4.2.2)。 ## 実験設定 - **シミュレータ**(§4.1): 商用 NIC ベンダーから入手したシミュレータ。INET/OMNET++ を拡張して Mellanox ConnectX-4 RoCE NIC をモデル化。RDMA キューペア(QP)は RoCE または IRN トランスポートロジックを持つ UDP アプリケーションとしてモデル化。DCQCN は Mellanox ConnectX-4 ROCE NIC の実装どおりに実装し、NIC ベース Timely 実装も追加。スイッチは input-queued・virtual output port・round-robin スケジューリング。 - **デフォルトシナリオ**: 54 サーバの 3 階層 fat-tree トポロジ、45 台の 6 ポートスイッチ・6 ポッド構成、フルバイセクションバンド幅。40Gbps リンク、伝搬遅延 2µs、最長(6 ホップ)パスの BDP は 120KB(約 110 MTU サイズパケット)。フロー到着は Poisson 過程、宛先はランダム、サイズは現実的なヘビーテール分布([19] 由来)。フローの 50% は単一パケットメッセージ(32B〜1KB、小さな RPC を代表)、15% は 200KB〜3MB の大フロー(ストレージ等のバックグラウンドトラフィックを代表)。負荷率 70%。ECMP でロードバランス。 - **パラメータ**: $RTO_{high}$ は輻輳リンク 1 本を仮定した最大 RTT の推定値(デフォルトで約 320µs)。IRN の $RTO_{low}$ は 100µs、N=3。PFC なし RoCE では固定タイムアウト $RTO_{high}$ を使用。PFC 有効時はタイムアウトを無効化。バッファサイズはネットワーク BDP の 2 倍(デフォルトで 240KB)。PFC 閾値はバッファサイズからアップリンクの BDP 分(220KB)のヘッドルームを引いた値。 - **比較対象**: RoCE(PFC あり/なし)、IRN(PFC あり/なし)、DCQCN・Timely 併用時の挙動、Resilient RoCE[34](RoCE + DCQCN + PFC なし)、iWARP(INET 内蔵 TCP スタックで代替評価)。 - **評価指標**: (i) 平均スローダウン(フロー完了時間 / 空ネットワークをライン速度で通過した場合の時間)、(ii) 平均 FCT(フロー完了時間)、(iii) 99%ile(テール)FCT。 ## 実験結果 ### IRN performs better than RoCE(§4.2.1) Figure 1 が示すとおり、デフォルトシナリオで IRN(PFC なし)は RoCE(PFC あり)を 3 指標全てで最大 2.8〜3.7 倍上回る。要因は (i) BDP-FC による不要なキューイングの削減、(ii) IRN は PFC を使わないため輻輳伝播が発生しない点。 **Figure 1: IRN と RoCE の性能比較** ![[_attachments/Revisiting-network-support-for-RDMA/fig01-irn-vs-roce.png]] (Figure 1. デフォルトシナリオでの平均スローダウン・平均 FCT・99%ile FCT を RoCE(オレンジ、実測値は約 30/2.6ms/50ms)と IRN(青、約 7.5/1ms/15ms)で比較した棒グラフ。IRN が全指標で大幅に優れる。) ### IRN does not require PFC(§4.2.2) IRN に PFC を追加で有効化しても性能は改善せず、**むしろ悪化する**(各指標が約 1.5〜2 倍悪化)。原因は PFC 固有の head-of-the-line blocking と輻輳伝播であり、あるリンクでの輻輳によるポーズがキューの蓄積と上流エンティティでのポーズを引き起こすカスケード効果を生む。PFC なしの IRN はパケットドロップ率が高い(8.5%)がその悪影響は輻輳を経験したフロー自身に限定され、PFC のように他フローへ伝播しない。本論文は、この結果が「よく設計されたロス回復機構が無損失ネットワークに勝る」ことを初めて示したものだと主張する。 **Figure 2: IRN への PFC 有効化の影響** ![[_attachments/Revisiting-network-support-for-RDMA/fig02-pfc-with-irn.png]] (Figure 2. IRN with PFC(オレンジ)と IRN without PFC(青)を比較。3 指標いずれも PFC を有効化すると悪化する。) ### RoCE requires PFC(§4.2.3) 対照的に、現行 RoCE では PFC の無効化が性能を 1.5〜3 倍悪化させる。原因は go-back-N ロス回復が (i) 冗長再送による輻輳増加、(ii) 冗長パケット送信による時間・帯域の浪費を招くため。 **Figure 3: RoCE への PFC 無効化の影響** ![[_attachments/Revisiting-network-support-for-RDMA/fig03-pfc-with-roce.png]] (Figure 3. RoCE(with PFC、オレンジ)と RoCE(without PFC、青)を比較。PFC を無効化すると全指標が大幅に悪化する。) ### 明示的輻輳制御(Timely・DCQCN)の効果(§4.2.4) Timely/DCQCN 併用時も IRN は RoCE を 1.5〜2.2 倍上回り(Figure 4)、IRN への PFC 追加の効果はほぼ無視できる程度(最大改善 1% 未満、最大悪化 3.4%、Figure 5)。一方 RoCE は明示的輻輳制御を使っても依然として PFC を必要とし、PFC 有効化により性能が 1.35〜3.5 倍改善する(Figure 6)。 **Figure 4: 明示的輻輳制御下での IRN と RoCE の比較** ![[_attachments/Revisiting-network-support-for-RDMA/fig04-irn-vs-roce-cc.png]] (Figure 4. Timely・DCQCN 併用下で RoCE と IRN を比較。IRN が一貫して優位。) **Figure 5: 明示的輻輳制御下で IRN に PFC を追加した効果** ![[_attachments/Revisiting-network-support-for-RDMA/fig05-pfc-with-irn-cc.png]] (Figure 5. IRN with PFC と IRN without PFC を Timely・DCQCN 併用下で比較。差はごくわずか。) **Figure 6: 明示的輻輳制御下で RoCE から PFC を無効化した効果** ![[_attachments/Revisiting-network-support-for-RDMA/fig06-pfc-with-roce-cc.png]] (Figure 6. RoCE(with PFC)と RoCE(without PFC)を Timely・DCQCN 併用下で比較。PFC 無効化で大幅に悪化する。なお RoCE+DCQCN without PFC は Resilient RoCE[34] と等価である。) ### Key Takeaways(§4.2 まとめ) (1) IRN(PFC なし)は RoCE(PFC あり)を上回る、(2) IRN は PFC を必要としない、(3) RoCE は PFC を必要とする。 ### IRN の要因分析(§4.3) Figure 7 は IRN の 2 つの変更(効率的ロス回復・BDP-FC)それぞれの寄与を分析する。go-back-N 版 IRN は SACK ベースの標準 IRN より大幅に性能が劣る(冗長再送による帯域浪費のため)。BDP-FC を無効化した場合も性能は悪化するが、go-back-N の悪化幅の方が大きく、2 つの変更のうち**効率的ロス回復の方が BDP-FC より寄与が大きい**と結論づける。 **Figure 7: go-back-N ロス回復と BDP-FC 無効化の影響(要因分析)** ![[_attachments/Revisiting-network-support-for-RDMA/fig07-gobackn-bdpfc-factor.png]] (Figure 7. 平均 FCT を IRN・IRN with Go-Back-N・IRN without BDP-FC の 3 バーで比較(NoCC/Timely/DCQCN の 3 グループ)。IRN with Go-Back-N の NoCC 条件では 7.1ms に達するため、可視化のため y 軸を 3ms でキャップしている。) 代替設計の検討として、(1) go-back-N を単純に改善する試み(明示的バックオフは Timely で改善したが DCQCN では改善せず、SACK ベースの方が平均 FCT で 20〜50% 優れる)、(2) SACK なしの選択的再送(go-back-N より優れるが複数ロスがウィンドウ内にあると劣化、平均 FCT の劣化幅は <1%〜75%)、(3) 動的タイムアウト計算(設計を複雑化するだけで効果なし)を検証したが、いずれも現行 IRN 設計を上回らなかった(§4.3)。 ### 基本結果のロバスト性(§4.4) リンク利用率(30〜90%)・リンク帯域(10〜100Gbps)・トポロジ規模(128・250 サーバ)・ワークロード分布・バッファサイズ(60〜480KB)・IRN パラメータ(RTO・N 値)を変えた広範な実験(詳細は extended report[31] の Appendix A)を通じて、以下の傾向が一貫して確認された(§4.4.1): - IRN(PFC なし)は常に RoCE(PFC あり)を上回り、性能改善幅は 6〜83% に及ぶ。 - 明示的輻輳制御なしの場合、IRN に PFC を追加すると常に性能が悪化し、最大悪化幅は 2.4 倍に達する。 - Timely・DCQCN 併用時も IRN への PFC 追加は多くの場合性能を悪化させる(最大悪化幅 Timely 39%・DCQCN 20%)。改善する場合でも Timely で 1.6%、DCQCN で 5% 以内に留まる。 IRN に PFC を追加した際の悪影響は (a) リンク利用率の増加とともに増大、(b) 帯域幅の増加とともに減少、(c) バッファサイズの減少とともに増大する傾向を持つ。$RTO_{high}$ や N の値を増やしても基本結果への影響は小さく、IRN はパラメータ値に対して鈍感である。 **テール遅延(§4.4.2)**: 単一パケットメッセージのテール遅延(90%ile〜99.9%ile)でも§4.2 の傾向が一貫して成立する。IRN(PFC なし)は低い $RTO_{low}$ タイムアウト値により単一パケットメッセージのロスから迅速に回復できるため。 **Figure 8: 単一パケットメッセージのテール遅延 CDF** ![[_attachments/Revisiting-network-support-for-RDMA/fig08-tail-latency-cdf.png]] (Figure 8. 90%ile〜99.9%ile のテール遅延 CDF を輻輳制御なし・Timely・DCQCN の 3 条件で RoCE(with PFC)・IRN with PFC・IRN(without PFC)について比較。全条件で IRN(without PFC)が最も低遅延。) **インキャスト(§4.4.3)**: cross-traffic なしのインキャスト(150MB を M=10〜50 台のセンダーから 1 宛先へストライプ送信)では、IRN と RoCE の性能はほぼ同等(RCT の差は 2.5% 以内)。cross-traffic ありのインキャスト(M=30、default workload と併走)では IRN(without PFC)が RoCE(with PFC)を 4〜30% 上回り、バックグラウンドワークロードでは 32〜87% 上回る。IRN への PFC 追加は多くの場合 1〜75% 性能を悪化させ、改善するのは DCQCN 併用インキャストの 1 ケース(1.13% 改善)のみ。 **Figure 9: インキャストの RCT 比(IRN/RoCE)** ![[_attachments/Revisiting-network-support-for-RDMA/fig09-incast-rct-ratio.png]] (Figure 9. インキャストのリクエスト完了時間(RCT)比(IRN/RoCE)を、送信者数 M=10〜50 の関数として NoCC・DCQCN・Timely の 3 条件でプロット。比が 1.0 未満であれば IRN が優位。) **ウィンドウベース輻輳制御(§4.4.4)**: TCP AIMD・DCTCP のようなウィンドウベース輻輳制御を IRN に実装した場合も§4.2 と同様の傾向を確認。TCP AIMD 併用時は PFC 無効化の効果がさらに強まる(パケットドロップを輻輳シグナルとして活用するため、PFC 有効時はこのシグナルが失われる)。 ### Resilient RoCE との比較(§4.5) Resilient RoCE[34](RoCE + DCQCN、PFC なしでパケットロス回避を狙う)との直接比較(Figure 10)では、IRN は明示的輻輳制御なしでも Resilient RoCE を大きく上回る(優れたロス回復と BDP-FC による)。 **Figure 10: Resilient RoCE との比較** ![[_attachments/Revisiting-network-support-for-RDMA/fig10-vs-resilient-roce.png]] (Figure 10. Resilient RoCE(RoCE+DCQCN、PFC なし)と IRN を比較。IRN が優位。) ### iWARP との比較(§4.6) IRN(明示的輻輳制御なし)と INET 内蔵 TCP スタック(iWARP 相当)を比較(Figure 11)。slow start の不在(BDP-FC で代替)により IRN のスローダウンは 21% 小さく、平均・テール FCT は同程度。TCP の AIMD ロジックを IRN に組み込むとさらに改善し、平均スローダウンは 44%、平均 FCT は 11% iWARP より小さくなる。IRN の単純な設計は、現行 RoCE NIC と同程度のメッセージレートを小さいオーバーヘッドで達成できる一方、iWARP NIC は RoCE NIC の最大 4 分の 1 のメッセージレートしか出せない(§2)。 **Figure 11: iWARP(TCP スタック)との比較** ![[_attachments/Revisiting-network-support-for-RDMA/fig11-vs-iwarp.png]] (Figure 11. iWARP(INET 内蔵 TCP スタック)と IRN を比較。IRN が優位。) ### iWARP と RoCE の実測比較(§2.3・予備実験) 本論文は §2.3 で、iWARP と RoCE の実 NIC を用いた予備実験も報告する。Chelsio T-580-CR(iWARP、40Gbps)と Mellanox MCX416A-BCAT(RoCE、リンク速度 40Gbps 設定)で 64B の RDMA Write をシングルキューペアで測定した結果、iWARP はスループット 3.24 Mpps・レイテンシ 2.89µs に対し、RoCE はスループット 14.7 Mpps・レイテンシ 0.94µs であった(iWARP は RoCE の 3 倍のレイテンシ、4 分の 1 のスループット)。購入時価格は iWARP NIC が $760、RoCE NIC が $420。著者らはこれらの差が転送設計の複雑さ以外の要因(利益率・機能差・エンジニアリング労力)にも起因しうるとして、あくまで参考証拠と位置づけている。 **Table 1: iWARP NIC と RoCE NIC の生の性能(64B RDMA Write、単一キューペア)** | NIC | Throughput | Latency | |---|---|---| | Chelsio T-580-CR (iWARP) | 3.24 Mpps | 2.89 µs | | Mellanox MCX416A-BCAT (RoCE) | 14.7 Mpps | 0.94 µs | (Table 1. 64 バイトのバッチ化された RDMA Write における単一キューペアでの iWARP NIC と RoCE NIC の raw 性能比較。) ## 実装オーバーヘッドの評価(§6) ### NIC 状態オーバーヘッド(§6.1) IRN が追加する状態は、数千の QP・数万の WQE を扱う場合でも現行 NIC キャッシュのわずか 3〜10% に収まる(100Gbps リンクを考慮した場合でも同様)。 - **per-QP 追加状態**: IRN のトランスポートロジックに 52 ビットの追加状態(再送すべきパケットシーケンスと回復シーケンスの追跡に各 24 ビット、各種フラグに 4 ビット)。要求側・応答側それぞれで 52 ビットのため per-QP オーバーヘッドは 104 ビット。応答側では Read タイムアウト用タイマーと Read WQE バッファ内の進行中 Read 要求追跡変数に 56 ビットが追加され、合計 160 ビットの per-QP 追加状態となる。RoCE NIC は現在 QP あたり数千ビットの状態変数を保持している。 - **ビットマップ**: 応答側の 2-bitmap(受信パケット追跡)×2、要求側の Read 応答追跡×1、要求側・応答側それぞれの選択的確認応答追跡×各 1 の計 5 個の BDP サイズビットマップが必要。各ビットマップを 128 ビット(40Gbps・往復伝搬遅延 24µs という典型的なデータセンタートポロジの BDP キャップに合わせたサイズ)とすると、QP あたり合計 640 ビット。これは Mellanox ConnectX-5 NIC の OOO サポート用ビットマップの総サイズよりかなり小さい。 - **per-WQE 追加コンテキスト**: 現在 64 バイトの per-WQE コンテキストに 3 バイトを追加。 - **追加共有状態**: BDP キャップ値・$RTO_{low}$ 値・N を合わせて計 10 バイトのみ。 ### パケット処理オーバーヘッド(§6.2) Xilinx Vivado Design Suite 2017.2 を用いて Kintex Ultrascale XCKU060 FPGA(Mellanox Innova Flex 4 10/40Gbps NIC に bump-on-the-wire として実装される FPGA)への高位合成(HLS)により 4 つの主要パケット処理モジュール(receiveData・txFree・receiveAck・timeout)を評価。合成の正当性は§4 のシミュレーションから生成したイベントトレースを RTL 検証用テストベンチに入力し、シミュレータの出力トレースと照合することで確認した。 **Table 2: 各パケット処理モジュールの Xilinx Kintex Ultrascale KU060 FPGA 上での性能・リソース使用量** | Module | FF | LUT | Max Latency | Min Throughput | |---|---|---|---|---| | receiveData | 0.62% | 1.93% | 16.5 ns | 45.45 Mpps | | txFree | 0.32% | 0.95% | 15.9 ns | 47.17 Mpps | | receiveAck | 0.4% | 1.05% | 15.96 ns | 46.99 Mpps | | timeout | 0.01% | 0.08% | < 6.3 ns | 318.47 Mpps | | **Total** | **1.35%** | **4.01%** | — | Min Bottleneck 45.45 Mpps | (Table 2. 4 モジュール合計で FF 1.35%・LUT 4.01% のみを消費(BRAM・DSP48E は不使用)。100Gbps リンク対応にビットマップサイズを拡大した場合でも FF 2.66%・LUT 9.5% に収まる。最も低いスループットの receiveData モジュールでも 45.45 Mpps(MTU サイズパケットで 372Gbps 相当)であり、Mellanox MCX416A-BCAT RoCE NIC で観測された最大メッセージレート 39.5 Mpps を上回る。) なお、ここでの結果は ASIC 実装の最適結果からは程遠い(HLS は直接 Verilog を書くより最大 2 倍非効率、FPGA は一般に ASIC より非効率)ため、実際の ASIC 実装ではさらに小さいオーバーヘッドが期待できる。 ### エンドツーエンド性能への影響(§6.3) 実装上の 2 つのオーバーヘッド要因——(1) 再送パケット取得の遅延(worst-case で 2µs のフェッチ遅延を仮定)、(2) 追加ヘッダ(Write パケットへの 16 バイト RETH ヘッダを最悪ケースとして全パケットに付与)——をモデル化した結果、性能低下はわずか 4〜7%(IRN オーバーヘッドなし比)に留まり、RoCE(PFC あり)ベースラインに対しては依然として 35〜63% 優れた性能を維持する。 **Figure 12: 実装オーバーヘッドを考慮した IRN の性能** ![[_attachments/Revisiting-network-support-for-RDMA/fig12-overhead-impact.png]] (Figure 12. RoCE(with PFC)・IRN(no overheads)・IRN(worst-case overheads)の 3 者比較。オーバーヘッドを考慮しても IRN は RoCE を大きく上回る。) ### まとめ(§6.4) IRN はチップ面積・NIC メモリ要件・帯域オーバーヘッドいずれも実現可能な範囲に収まる。著者らは Mellanox を含む 2 社の商用 NIC ベンダーとの詳細な議論を通じて分析を検証し、両ベンダーとも IRN 設計が自社ハードウェア NIC 上で容易に実装可能であることを確認したと報告している。本論文の結果に触発され、Mellanox は次リリースで IRN の一版を実装することを検討しているという(§6.4)。 ## 考察(§7 Discussion and Related Work) - **後方互換性**: NIC ベンダーが RoCE/IRN デュアルモード対応 NIC を製造し、両エンドポイント間で IRN 利用を RDMA connection manager 経由でネゴシエートする(未対応の場合は RoCE モードにフォールバック、RoCEv1→RoCEv2 移行時と同様の手法)段階的デプロイ経路を提案。全エンドポイントが IRN に移行するまで PFC を継続運用し、移行完了後に PFC を恒久的に無効化できる。 - **ロードバランシングによる再順序化**: 現行データセンターは ECMP(フロー内順序を維持)を用いるが、IRN の OOO パケット配送サポートは、フロー内再順序化を引き起こす他のロードバランシング方式([20, 22])も許容する。一定数の NACK 閾値を超えてからロス回復をトリガーすることで、再順序化への頑健性をさらに高められる。 - **他のハードウェアベースロス回復——MELO[28]**: IRN と並行して開発された、オフチップメモリに OOO パケットをバッファするハードウェアベース選択的再送の代替設計。MELO は PFC 有効環境のみを対象とし、障害由来のランダムロスへの頑健性向上を狙う点で IRN(PFC 不要化そのものが主眼)とは目的が異なるが、NIC でのより良いロス回復の実現可能性を裏付ける。 - **HPC ワークロード**: HPC コミュニティは長年無損失性を支持してきたが、これは HPC クラスタが小規模でトラフィックパターンが制御されており、無損失性の負の効果(輻輳伝播・デッドロック)が稀であるため。PFC の問題は大規模クラスタでより深刻化する。 - **クレジットベースフロー制御**: 本論文の実験は PFC(Ethernet 上の RDMA 展開)を対象としたが、Infiniband が用いるクレジットベースフロー制御(ダウンリンクが十分なバッファ容量を持つ時アップリンクへクレジットを送る方式)も head-of-the-line blocking・輻輳伝播・デッドロックの可能性という同種の性能問題を抱えるため、本論文の観察はクレジットベースフロー制御にも適用可能と考えられると論じる。 ## 強み / 弱点・課題 **Strengths** - 「PFC の問題を個別に修正する」のではなく「PFC は本当に必要か」という前提を問い直す視点の転換。 - シミュレーション評価が極めて広範(トポロジ規模・リンク帯域・ワークロード・輻輳制御アルゴリズム・バッファサイズ・パラメータ感度)であり、結果のロバスト性を丁寧に検証している(§4.4)。 - FPGA 高位合成による定量的なハードウェアオーバーヘッド評価(§6.2)と、商用 NIC ベンダー(Mellanox 含む)との議論による裏付け(§6.4)を伴い、単なる理論提案に留まらず実装可能性を示す。 - iWARP との比較を通じて、「PFC 不要という設計思想自体は iWARP が先に正しく掴んでいたが、実装の複雑さが市場での敗北を招いた」という業界の暗黙の前提(lossless fabric が RoCE の高性能に必須という思い込み)を覆す歴史的な位置づけを与えている。 **Weaknesses/Limitations** - 評価は商用ベンダー提供のシミュレータに依存し、実機での大規模本番展開での検証は本論文では行われていない(2018 年時点)。 - OOO パケット配送のサポート(§5.3)は、アプリケーションがデータ上書き(データが古いメッセージの再送パケットで上書きされる可能性)を扱う責任を負うことを前提としており(iWARP・ConnectX-5 と同様の戦略)、NIC/ドライバ側での完全な保護を提供しない。 - Go-back-N を廃止し選択的確認応答へ移行する場合の集合通信パターン(ring-allreduce 等)への影響は、本論文では直接評価されていない([[RDMA]] concept の未解決の問いを参照)。 - デプロイには RoCE/IRN デュアルモード対応の新規 NIC ハードウェアが必要であり、既存 RoCE NIC への遡及適用はソフトウェアのみでは実現できない。 > [!note] 後続研究 > [[@2025__SIGCOMM__Revisiting RDMA Reliability for Lossy Fabrics]](DCP、SIGCOMM '25)は、本論文が評価対象とした IRN(RNIC-SR 系)の弱点として「パケットレベル負荷分散との構造的非互換」(単一経路前提のビットマップベース選択的再送が OOO 到着をロスと誤認し大量の偽の再送を誘発)を実証的に指摘し、スイッチと RNIC の共設計で解消した。 ## 関連 - 概念: [[RDMA]] / [[データセンター輻輳制御]] / [[RoCE設計課題]] - エンティティ: [[Radhika Mittal]] / [[Alexander Shpiner]] / [[Aurojit Panda]] / [[Eitan Zahavi]] / [[Arvind Krishnamurthy]] / [[Sylvia Ratnasamy]] / [[Scott Shenker]] / [[Mellanox]] / [[UC Berkeley]] / [[University of Washington]] - 後続研究: [[@2025__SIGCOMM__Revisiting RDMA Reliability for Lossy Fabrics]]