> [!abstract] 概要(Abstract の日本語訳) > 無損失(lossless)RDMA ネットワークは運用の複雑性が高く展開規模も限られるため、コミュニティは有損失(lossy)ファブリック上での効率的な RDMA 通信を模索してきた。最先端(SOTA)の有損失 RDMA ソリューションは、ロス回復効率を高めるため RDMA NIC(RNIC)に簡略化された選択的再送(selective repeat)機構を実装する。しかし、これらのソリューションは依然として、避けられない ECMP ハッシュ衝突や過剰な再送タイムアウト(RTO)といった性能上の課題に直面している。本論文では、PFC から独立していること、パケットレベル負荷分散(load balancing、LB)と互換であること、RTO から解放されていること、ハードウェアオフローディングに適していること、という目標のもとで RDMA 信頼性を再考する。この目的のため、我々は DCP を提案する。DCP はスイッチと RNIC を共設計するトランスポートアーキテクチャであり、上記の設計目標を完全に満たす。DCP の中核である DCP-Switch は、単純ながら効果的な無損失制御プレーンを導入し、これを DCP-RNIC が活用することで、高速な有損失ファブリック向けの信頼性サポートを強化する。この強化は主にヘッダオンリー(header-only、HO)ベースの再送とビットマップフリーなパケット追跡から成る。我々は P4 スイッチを用いて DCP-Switch を、FPGA を用いて DCP-RNIC をプロトタイプ実装した。大規模な実験により、DCP は SOTA の無損失および有損失 RDMA ソリューションと比較してそれぞれ 1.6 倍・2.1 倍の性能改善を達成することを実証した。 ## 論文情報 - タイトル: Revisiting RDMA Reliability for Lossy Fabrics - 著者: Wenxue Li・Xiangzhou Liu・Yunxuan Zhang・Zihao Wang・Wei Gu・Tao Qian・Gaoxiong Zeng・Shoushou Ren・Xinyang Huang・Zhenghang Ren・Bowen Liu・Junxue Zhang・[[Kai Chen (HKUST)|Kai Chen]]・Bingyang Liu - 所属: 香港科技大学([[Hong Kong University of Science and Technology|HKUST]])、[[Huawei Technologies|Huawei]](Nanjing・Beijing・Shenzhen)。筆頭著者 Wenxue Li は Huawei でのインターン期間中に本研究を実施。対応著者は Bingyang Liu(Huawei)と Kai Chen(HKUST)。 - 媒体・発表年: ACM SIGCOMM '25(2025年9月8〜11日、Coimbra, Portugal)、14 ページ - DOI: 10.1145/3718958.3750480 ## 概要 DCP は、PFC(Priority Flow Control)に依存せずパケットレベル負荷分散(LB)と互換な RDMA トランスポートを実現する、スイッチと RNIC の共設計アーキテクチャである。既存の有損失 RDMA ソリューション(IRN 系の RNIC-SR)がパケットレベル LB との組み合わせで偽の再送を大量発生させる問題と、タイムアウト依存によるテールレイテンシ悪化の問題を、「制御プレーン(ヘッダ転送)のみを無損失に保ち、データプレーン(ペイロード転送)は有損失のまま許容する」という非対称設計で解決する。P4 スイッチと FPGA によるフル機能プロトタイプを実装し、testbed 実験と NS3 大規模シミュレーションの両方で SOTA 比の性能改善を実証した。 ## 問題設定 - **入力**: RDMA ワークロード(汎用データセンタートラフィック、AI 集合通信ワークロード)。ネットワークはロス(パケットドロップ)が発生しうる Ethernet ファブリック(PFC なし)。 - **前提**: RDMA は本来ロスレスな InfiniBand 向けに設計され、伝統的な RNIC(RNIC-GBN)は Go-Back-N 再送に依存するため PFC による無損失化を要求する(§2.1)。しかし PFC は HoL ブロッキング・輻輳伝播(congestion spreading)・デッドロック・展開距離制約という課題を持つ(Table 1 で商用 ASIC の無損失通信可能距離を試算し、8 キュー構成では 512 m 前後に制限されることを示す)。 - **要求仕様(R1〜R4、§3)**: - R1 PFC からの独立(その弊害を完全回避) - R2 パケットレベル LB との互換(実パケットロスと LB 起因の OOO(out-of-order)到着を正確に区別) - R3 RTO に頼らない高速な再送(明示的なロス通知機構) - R4 ハードウェア指向設計(最小限のメモリ・計算オーバーヘッド) ## 提案手法 ### アーキテクチャ DCP は **DCP-Switch**(スイッチ側)と **DCP-RNIC**(送受信 RNIC 側)から成る(Figure 3)。DCP は概念的にペイロード転送のデータプレーン(DP)と、ヘッダ転送の制御プレーン(CP)を分離する。従来の無損失 RDMA が PFC で DP・CP 双方を無損失化するのに対し、DCP-Switch は **CP のみ**を無損失に保ち、DP は有損失のまま動作させる。 **Figure 3: DCP workflow.** ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig03-dcp-workflow.png]] (Figure 3. スイッチがデータキュー輻輳時にパケットをトリミングし HO(header-only)パケットを制御キューへ送る(①)。受信側 RNIC は HO パケットの送信元・宛先を入れ替えて送信元へ送り返す(②)。送信側 RNIC は HO パケットに含まれる PSN に基づき精密に再送する(③④)。受信側は in-order/out-of-order を問わずアプリケーションメモリへ直接書き込み(④)、必要に応じて ACK を返す(⑤)。Source: Adapted from Figure 3.) **表2: DCP と近縁研究の比較(R1〜R4 充足状況)** ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/table02-comparison-related-work.png]] (Table 2. RNIC-GBN は R4 のみ、RNIC-SR(IRN 系)は R1・R4、MPTCP・NDP・CP はソフトウェア実装のため R4 を欠き、MP-RDMA は GBN 依存のため R1・R3 を欠く。DCP のみ R1〜R4 全てを満たす。Source: Table 2.) ### DCP-Switch: 無損失制御プレーン(§4.2) IP ヘッダの ToS フィールド中の 2 ビットを DCP タグとして予約し、非 DCP パケット(00・輻輳時にドロップ)、DCP データパケット(10・通常/再送データ)、HO パケット(11・トリミング後のヘッダのみ)、DCP ACK パケット(01)の 4 種を区別する。 **パケットトリミングモジュール**: エグレスのデータキュー長が閾値を超えると、スイッチはペイロードを切り離し、残ったヘッダ(57 バイト = MAC 14B + IP 20B + UDP 8B + BTH 12B + MSN 3B)の DCP タグを 11 に書き換えて制御キューへ投入する。閾値未満ならそのままデータキューへ送る。 **WRR スケジューリング**: データキューと制御キューを重み付きラウンドロビン(WRR)で捌き、制御キューを優先することで CP の無損失性を保証しつつ DP の飢餓(starvation)を防ぐ。スイッチ段数 $N$(radix)と HO/データパケットサイズ比 $1:r$ から、最悪ケース($N-1$ 対 $1$ incast で全データパケットがトリミングされる場合)でも制御キューを無損失に保つ理論重み $w = \frac{N-1}{r-N+1}$(ただし $r > N-1$ が必要)を導出する。$r < N-1$ の場合は理論保証がないが、§6.3 の実験で小さい $w$ でも極端な incast をおおむね処理できることを示す。HO パケット自体が偶発的に失われた場合は、後述のコースグレインタイムアウトにフォールバックする。 ### DCP-RNIC: HO ベース再送(§4.3) **Table 1: PFC 有効時の商用スイッチ ASIC の最大無損失通信距離** ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/table01-lossless-distance.png]] (Table 1. Tomahawk 3/5、Tofino 1/2、Spectrum、Spectrum-4 の総バッファ量から式 $L = \frac{\text{buffer}}{\text{bandwidth} \times \text{one-hop-delay} \times 2}$ で最大距離を試算。8 キュー構成ではいずれも 320〜634 m に制限される。Source: Table 1.) DCP-RNIC の Tx パスは、fetch-and-drop 戦略(未使用 WQE をキャッシュせず破棄し次回再取得)で QP スケジューリングを行う(§4.3、$n=8$ WQE、round_quota=16KB の設定は PCIe BDP に合わせて調整)。HO パケットは独立・ステートレスであるため、素朴な逐次処理(HO ごとに WQE を fetch → データ fetch)は HO 1 個あたり 2 回の PCIe トランザクションを要し著しく低スループットになる(課題 #1)。また CC モジュールと非連携だと、再送レートが HO パケットの受信レートにそのまま結びつき輻輳を悪化させうる(課題 #2)。 **Figure 4: DCP のヘッダ拡張** ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig04-dcp-header-extension.png]] (Figure 4. DCP データパケットヘッダに MSN(Message Sequence Number、全操作共通)・sRetryNo(two-sided 操作のみ)・SSN(Send Sequence Number、two-sided 操作のみ)・RETH(one-sided 操作のみ、全パケットに付与)を追加。ACK パケットには eMSN(期待 MSN)を含む。赤太字が DCP による追加フィールド。Source: Figure 4.) **解決策(HO ベース再送、Figure 5)**: Rx パスと Tx パスを分離し、QP ごとにホストメモリ上の再送キュー(RetransQ)を設けてバッチフェッチ戦略を採る。HO 受信時に (MSN, PSN) を抽出し RetransQ へ書き込む(ソフトウェア関与なし)。QP がスケジュールされると、RNIC は CC モジュールから $awin$(利用可能ウィンドウ)を取得し、$\min(16, len, awin/\text{MTU})$ 件の再送エントリを一括フェッチしてから WQE を fetch・MTT(Memory Translation Table)でアドレス変換・ペイロード fetch・送信する。再送と CC は分離して動作するため、任意の CC 方式とマイクロアーキテクチャ的に互換である。 **Figure 5: HO ベース再送の動作ステップ** ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig05-ho-retransmission-steps.png]] (Figure 5. Rx パス(赤: HO パケット)は RetransQ への書き込みのみで CPU オーバーヘッドなし。Tx パス(青: 再送データパケット)は QPC・RetransQ・SQ から情報を集約し MTT でアドレス変換してペイロードを送信する。灰色モジュールが DCP による変更箇所。Source: Figure 5.) ### 順序非依存パケット受信(Order-tolerant Packet Reception、§4.4) パケットロスと LB のいずれも OOO(out-of-order)到着を招きうる。標準 RDMA ヘッダは in-order 到着専用設計のため、従来手法は RNIC/ホストに大きな reorder buffer を確保して対処する。DCP は標準 RDMA ヘッダを拡張し、OOO パケットでもアプリケーションメモリの正しい位置へ直接書き込めるようにすることで reorder buffer を不要にする。 - **Write**: RETH(remote memory location を含むヘッダ)を標準では先頭パケットのみに含めるが、DCP は Write メッセージの全パケット(先頭・中間・末尾)に RETH を含める。 - **Send / Write-with-Immediate**(two-sided 操作): 標準では受信側の Receive WQE との対応が到着順に暗黙的に決まるため OOO で破綻する。DCP は SSN(投稿順序を示す)を Send パケット全てと Write-with-Immediate の末尾パケットに含め、適切な Receive WQE を明示的に特定する。 ### ビットマップフリーなパケット追跡(§4.5) **Figure 6: 3 通りのパケット追跡方式** ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig06-packet-tracking-approaches.png]] (Figure 6. (a) BDP サイズ固定ビットマップは定数時間アクセスだがメモリオーバーヘッド大(10k QP・Intra-DC で 3MB)。(b) リンクドチャンクは低 OOO 度で省メモリだが $O(n)$ アクセス遅延でパケットレートを劣化させる。(c) DCP のビットマップフリー方式は、head ポインタ(eMSN を指す)から多ビットのパケットカウンタ・1 ビットのメッセージ完了フラグ(mcf)・1 ビットの CQE フラグ(cf)を持つのみ。Source: Figure 6.) DCP の無損失 CP と HO ベース再送は「exactly once」特性(任意のパケットがちょうど 1 回だけ受信側に到達すること)を保証する。これによりパケット単位ではなく**メッセージ単位**の追跡で足りる。受信側はメッセージごとに多ビットカウンタを持ち、パケット到着ごとに +1、カウンタがメッセージサイズに達したら完了と判定する(QP ごとに eMSN(expected MSN)状態を保持し、順不同で完了したメッセージは eMSN 順に CQE を生成)。AI アプリケーション(NCCL、outstanding message per QP = 8、メッセージサイズ数 MB)では 1 メッセージあたり 2 バイト(14 ビットカウンタ)で追跡できる。 **Figure 7: 理論パケットレート** ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig07-theoretical-packet-rate.png]] (Figure 7. クロック周波数 300MHz 時、BDP サイズ固定・DCP は OOO 度に依存せず一定(約 60 Mpps)を維持するが、リンクドチャンクは OOO 度の増加に伴い急落する(OOO度448で10 Mpps未満)。Source: Figure 7.) **表3: パケット追跡のメモリオーバーヘッド** ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/table03-memory-overhead.png]] (Table 3. Per-QP・Intra-DC で DCP は 32B(BDP サイズ固定 320B の 1/10)。10k QP では DCP 0.3MB に対し BDP サイズ固定 3MB。Source: Table 3.) **コースグレインタイムアウトのフォールバック**: 無損失 CP の前提が(リンク/スイッチ障害等で)破られた場合、HO ベース再送は機能しない。送信側は QP ごとに最小未確認 MSN(unaMSN)とタイマーを保持し、タイムアウト時に unaMSN 番目のメッセージ全体を再送する。この際「exactly once」保証が崩れるため、送信側 sRetryNo・受信側 rRetryNo という再送世代カウンタを導入し、両者を突き合わせてパケットカウンタの誤加算を防ぐ。 ## 新規性 - 既存の有損失 RDMA(RNIC-SR/IRN)はパケットレベル LB と本質的に非互換(単一経路前提のビットマップベース SR 方式が OOO をロスと誤認)であり、GBN(RNIC-GBN)は PFC 依存を残す。DCP は「無損失 CP・有損失 DP」という非対称設計により、両者が同時に満たせなかった R1〜R4 を初めて同時に満たす(Table 2)。 - SR ベース再送とホーベース再送は根本的に異なる。SR は送信側ビットマップというステートを保持し任意時点で選択的に再送できるが、HO ベースはステートレスで個々の HO パケットが再送を直接トリガする(§7「Distinction of SR- and HO-based retransmission」)。 - NDP・CP(Catch the whole lot in an action、NSDI'14)もパケットトリミングを用いるが、NDP は受信側駆動 CC が主眼でソフトウェア実装(DPDK)中心、CP は TCP 向けで送受信双方のビットマップに依存する。DCP-RNIC 固有の HO ベース再送・拡張ヘッダ・ビットマップフリー追跡はいずれの先行研究にも存在しない(§7「Differences with NDP and CP」)。 - SRNIC は単一経路伝送を前提に OOO はロス起因と仮定するためビットマップをホストメモリに置けるが、DCP はパケットレベル LB によりロスなしでも OOO が生じうるためビットマップアクセス頻度が高く、この前提を採用できない(§7「Onloading bitmaps to host memory?」)。 ## 実験設定 - **Testbed**(§6.1、Figure 9): P4 プログラマブルスイッチ 2 台(Switch1・Switch2)、各 8 FPGA(PCIe Gen3 x16、100Gbps Ethernet、クロック 300MHz)、スイッチ間 8 並列リンク(計 100Gbps)。比較対象は Mellanox CX5(RNIC-GBN)。 - **大規模シミュレーション**(§6.2): NS3 上の 2 層 CLOS(spine 16・leaf 16・サーバ 256、1 ラック 16 台)、全リンク 100Gbps。Intra-DC 伝搬遅延 1µs、Cross-DC 実験ではサーバ-leaf 間 1µs・leaf-spine 間 500µs(100km 相当)/5ms(1000km 相当)。比較対象: PFC(RNIC-GBN + PFC)、IRN(RNIC-SR)、MP-RDMA。WebSearch ワークロード(load 0.3/0.5)と AllReduce/AllToAll AI ワークロードを使用。CC は代表として DCQCN を統合。 - **評価指標**: goodput(Gbps)、FCT(Flow Completion Time)スローダウン、JCT(Job Completion Time)、タイムアウト回数、HO パケットロス率。 ## 実験結果 **Figure 1・2: IRN の問題点の実証実験** ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig01-irn-spurious-retrans.png]] (Figure 1. NS3・WebSearch load 0.3 でパケットロスがない条件でも、IRN はフローサイズを問わず偽の再送を発生させる(小 50%・中 80%・大 90% のフローが経験)。DCP は全フローで回避。Source: Figure 1.) ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig02-irn-excessive-rtos.png]] (Figure 2. 128-to-1 incast(load 0.1)併存下、IRN-AR は IRN-ECMP よりさらに多いタイムアウトを経験する(偽の再送がさらなる輻輳を誘発するため)。DCP は背景・incast いずれのフローもタイムアウト 0。Source: Figure 2.) **Figure 8〜12: Testbed ベンチマーク** ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig08-dcp-rnic-basic-validation.png]] (Figure 8. DCP-RNIC 直結でのスループット・レイテンシは RNIC-GBN と同等で、いずれも TCP を大きく上回る。ハードウェアオフロード能力が維持されていることの基礎検証。Source: Figure 8.) ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig10-loss-recovery-efficiency.png]] (Figure 10. ロス率 0.01%〜5% で DCP は CX5(RNIC-GBN)比 1.6〜72 倍のロス回復効率(goodput)を達成。CX5 はロス率上昇に伴い goodput が急落する一方、DCP は 5% でも約 50Gbps を維持。Source: Figure 10.) ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig11-adapt-unequal-paths-ar.png]] (Figure 11. 2 経路の帯域比を 1:1・1:4・1:10 と変化させても DCP は安定した goodput を維持するが、CX5 は非等帯域下で goodput が大幅に低下する(パケットレベル LB 非互換の帰結)。Source: Figure 11.) ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig09-testbed-topology.png]] (Figure 9. Switch1・Switch2 それぞれに 8 FPGA を接続、100Gbps x 8 のクロススイッチリンクで構成。Source: Figure 9.) ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig12-ai-workload-vs-cx5.png]] (Figure 12. verbs API + OpenMPI による AllReduce/AllToAll ベンチマーク(16 RNIC を 4 グループ)で、DCP は CX5 比 JCT を最大 33%(AllReduce)・42%(AllToAll)削減。Source: Figure 12.) 長距離通信検証では、クロススイッチリンクの 1 本を 10km 光リンク(片道遅延 50µs)に置換し、DCP は約 85Gbps で安定動作することを確認した(初歩的な長距離通信対応の検証)。 **Figure 13〜15: 大規模シミュレーション** ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig13-webseach-workload-comparison.png]] (Figure 13. WebSearch ワークロード(load 0.3/0.5)の P50・P95 FCT スローダウン。DCP(AR)は IRN(AR)比 5〜16%、MP-RDMA 比 10〜12% 低いテール FCT を達成。ファイングレイン LB(MP-RDMA・AR)は総じて ECMP(PFC)を上回る。Source: Figure 13.) ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig14-allreduce-alltoall-comparison.png]] (Figure 14. AllReduce/AllToAll(16 グループ、各 300MB)で、DCP は MP-RDMA・IRN・PFC 比それぞれ平均 38%・44%・61% 低い JCT(AllReduce)、5%・45%・46% 低い JCT(AllToAll)を達成。AI ワークロードは同期的なため 1 フローの遅延が集団全体の性能を左右し、DCP のテール FCT の低さが JCT 優位に直結する。Source: Figure 14.) ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig15-crossdc-comparison.png]] (Figure 15. 100km(500µs)・1000km(5ms)のクロス DC シナリオ(WebSearch load 0.5)で、DCP は PFC・MP-RDMA・IRN 比それぞれ約 89%・81%・46%(100km)、84%・95%・51%(1000km)低いテール FCT を達成。PFC・MP-RDMA はバッファを 600MB/6GB に拡大しているにもかかわらず、フロー間で性能が振動する現象が観測された(大バッファが一部の大フローだけを PAUSE 未発動のまま通す非対称性に起因)。Source: Figure 15、Appendix A.1。) **Figure 16・17・表4・5: Deep Dive** ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig16-incast-fct-slowdown.png]] (Figure 16. WebSearch(load 0.5)+128-to-1 incast(load 0.05)の高輻輳条件下、CC(DCQCN)なしでは DCP の P50 FCT は最良だが P99 FCT は最悪になる。severe incast で大量の HO パケットが生成され、それがさらなる再送トラフィックを誘発するため。CC 統合後(DCP+CC)は P99 FCT で MP-RDMA・IRN 比それぞれ約 31%・29% 改善し最良となる。Source: Figure 16。) **表4: FPGA プロトタイプのリソース使用量** ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/table04-fpga-resource-usage.png]] (Table 4. DCP-RNIC は RNIC-GBN 比 LUT 5.5%(+1.7pt)・レジスタ 3.6%(+0.4pt)・BRAM 20%(+1.1pt程度)・URAM 3.8%(-0.1pt)で、追加オーバーヘッドはごくわずか。Source: Table 4.) **表5: 極端な incast 下での HO パケットロス率** ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/table05-ho-packet-loss-rate.png]] (Table 5. N=22(スイッチ radix)であれば 128-to-1・255-to-1 いずれの incast でも CC なしで HO パケットロス 0。N=16(radix を絞った場合)では 255-to-1 で 0.16% のロスが生じるが、CC 有効時はいずれの設定でもロス 0。DCP の無損失制御プレーンが severe incast 下でも堅牢であることを示す。Source: Table 5、§6.3「Robustness of the lossless control plane」。) ![[_attachments/revisiting-rdma-reliability-lossy-fabrics/fig17-loss-recovery-vs-racktlp.png]] (Figure 17. ロス率 0.01%〜5% で DCP は RACK-TLP・IRN・Timeout ベース方式に対しそれぞれ最大 22%・98%・99% 高い goodput を達成。RACK-TLP は再送を 1 RTT 遅延させる代償でタイムアウトを回避するが、パケット単位のタイムスタンプ維持というハードウェアオフロードに不向きなオーバーヘッドを伴う。Source: Figure 17、§6.3「Comparison with Timeout and RACK-TLP」。) ## 考察 - **DCP+CC は高負荷下で最良の性能を出す一方、DCP 単体(CC なし)は severe incast の P99 テールで最悪になりうる**(§6.3)。これは HO ベース再送がステートレスであるがゆえに、大量の HO パケット到着がそのまま大量の再送トラフィックへ転化し輻輳を悪化させる構造的トレードオフである。論文は再送と CC の分離設計をこの問題への解として位置づけ、DCQCN 統合により緩和されることを実験的に示す。 - **DCP の性能優位はクロス DC シナリオでより顕著になる**(§6.2)。BDP が大きくなるほど輻輳が深刻化しやすく、DCP のロス耐性の効果が相対的に拡大するため。 - **DCP はロス回復のみを扱い、LB と CC には非干渉(orthogonal)** という設計思想を一貫させている(§3「DCP vs. closely related works」、§7「Congestion Control for DCP」)。現行実装は DCQCN と統合しているが、パケットレベル LB と組み合わせた際に最適な CC 戦略が何かという問いは今後の課題として明示的に残されている。 ## 強み / 弱点・課題 **強み** - PFC 非依存・パケットレベル LB 互換・RTO フリー・ハードウェアオフロード対応という 4 要件を同時に満たす初の設計であることを、P4 スイッチ + FPGA によるフル機能プロトタイプで実証した(シミュレーションのみに留まらない)。 - ビットマップフリーなパケット追跡(メッセージ単位カウンタ)は「exactly once」の CP 保証という前提のもとで導出されており、他手法(BDP サイズ固定・リンクドチャンク)が抱えるメモリ/レイテンシのトレードオフを本質的に回避する新しいアーキテクチャ的アイデアである。 - FPGA 実装コストの定量化(LUT +1.7pt・レジスタ +0.4pt・BRAM +1.1pt 程度)により、ハードウェア指向設計(R4)の主張を具体的な数値で裏付けている。 **弱点・課題**(論文が明示的に述べるもの) - WRR の重み設定式($w = \frac{N-1}{r-N+1}$)は $r > N-1$ の場合にのみ理論的にロスレス CP を保証でき、$r < N-1$ の場合(HO/データサイズ比が小さい・スイッチ radix が大きい)は理論保証がない。実験的な補強に留まる(§4.2、§6.3)。 - ビットマップフリー設計は「exactly once」という無損失 CP の前提が破られた場合(リンク/スイッチ障害)に機能せず、コースグレインタイムアウトへのフォールバックが必要になる。この設計は実運用での障害耐性に本質的な課題を抱えることを論文自身が認めている(§4.5「Orthogonality」: "we acknowledge that it faces tremendous challenges in real-world deployment")。 - HO パケットを送信元へ送り返す際、必ず一度受信側を経由する必要がある(スイッチが送信元 QPN を知らないため)。理論上はスイッチが送受信 QPN のマッピングテーブルを持てば直接返送できるが、状態オーバーヘッドと計算複雑性の観点で見送られている(§7「Back-to-sender for HO packets」)。 - HO ベース再送のキューは(HO パケット数が多くなりうるため)ハードウェアではなくソフトウェアで実装せざるを得ないと述べられている(§7「Distinction of SR- and HO-based retransmission」)。SR ベース(ビットマップ方式)との対比で、この点は SR に対する DCP の相対的な弱みとして位置づけられる。