NSDI17 Reading, Networking for data center session. https://system-reading.connpass.com/event/58217/

1. NSDIʼ17 Reading
Networking for Datacenter
Hiroya Kaneko
2017/06/25
Some figures are cited from original papers or slides
https://system-reading.connpass.com/event/58217/

2. Contents
RAIL:A Case for Redundant Arrays of Inexpensive Links in Data Center Networks
Jihyung Arpit Gupta (Princeton University), et al.
->安価な光トランシーバ(SR)を使ってデータセンタのコストを削減する
Passive Realtime Datacenter Fault Detection and Localization
Arjun Roy, University of California, San Diego
->Closネットワークにおいて効率的にネットワーク障害の検出と局所化を行う
Enabling Wide-Spread Communications on Optical Fabric with MegaSwitch
Li Chen (The Hong Kong University of Science and Technology), et al.
->WSSを用いたデータセンタネットワーク

3. RAIL: A Case for Redundant Arrays of
Inexpensive Links in Data Center Networks
• 背景/実現したいこと
• データセンタネットワークにおいて光トランシーバの価格はその多くを占める
• 市販されているトランシーバは、規格で定義しているよりも数桁低いBERを実現し
ている
• 基本的なアイデア
– 規格で定義されている最⼤⻑を超えた場合にも10G-SRなどの安価なトランシーバ
を利⽤することで、ネットワークのコストを削減
• 論⽂のポイント
– 市販のトランシーバのBER測定し、データセンタにおいて規格が定義している距離
よりもStretchして利⽤することが可能なことを確認した
– Error-rateにsensitiveなApplicationに影響が出ないように、エンドツーエンドの
異なる信頼性を持つ複数の仮想トポロジを構築し、アプリケーションから選択可能
にした
– Stretchして利⽤した場合に問題となるエラーレートの増加に対して、エンドホス
トで動作するエラー訂正アルゴリズムで対処
• 検証結果
– 10G Networkで10%, 40G Networkで44%のコスト削減効果

4. データセンタネットワークのコスト構造
• 光トランシーバのコストはデータセンタネットワークのコ
ストのうち⼤きな部分を占める
• 基本的に⻑距離⾶ぶものは⾼い
– 利⽤可能な波⻑が異なる

5. 光トランシーバの品質
• 300K linkの運⽤中DCで実際に測定
• 規格で定義しているBERからマージンが取られている
– ベンダ問わず⼤きくマージンが取られている
– 規格ではその他componentに関してworst-case designされてい
るため

6. 本論⽂の基本的なアイデア
• アプリケーションに影響の出ない範囲で、トランシーバを実際の規格
よりもStretchして利⽤することで、ネットワークのコストを削減
– 下の図の例で、200mならSRを使っても良さそう！というのがアイデアのすべて

7. Challenges
Q:どの程度Stretchしてトランシーバを利⽤すべきなのかわからない
全てのLinkをStretchした場合、アプリケーションに影響を与えるレベルでエンドツー
エンドのエラーレートが増⼤する可能性がある
A:NRB(Network Reliability Bound)という指標を導⼊し、Stretch可能
なトランシーバを決定
Q:低品質なトランシーバを⽤いると、Applicationの性能に与える可能性
がある
Latency-sensitiveなApplication(ex.RDMA)などに問題は出ないのか？
A1:異なるNRBを保証する仮想トポロジをアプリケーションに対して提
供
A2:NRBが低いパスにおける性能を担保するために、エンドホスト上で
動作するエラー訂正機能を実装
本論⽂の⼿法では基本的に3-stage Clos Networkを想定

8. NRBとBER
• BER = 単⼀Linkにおけるエラーレート
• NRB = エンドツーエンドのパスにおける信頼性
– NRBをどこに設定するかは設計上のdecision,論⽂中では99%と95%で評価
– 3-stage clos Networkにおいては、エンドツーエンドのホップ数は必ず4なので、
BERは単純に（１­NRBの４乗根）で与えられる
– 例えばNRB=95%を実現したい場合、各リンクはBER=99.7%を達成する必要があ
る
• 各リンクがStretch可能かどうか判断するためには、各リンクを
Stretchした場合にBERが99.7を下回らないかどうかで判断可能
– BERは距離に対する関数となることを本論⽂では実験より確認

9. 仮想トポロジの構築
• アプリケーションごとに異なるNRBへのRequirementを保証するために、単⼀の物理
ネットワーク上で複数の仮想トポロジを構築
– Clos network(w/ECMP)なので、PBRが低いリンクをトポロジから除去していくことで複数グレードのPBRを
持つ仮想ネットワークを構築可能
– Clos networkの対称性を利⽤すると、O(nlogn)で計算可能
• 仮想トポロジごとにアドレスレンジが分割されており、アプリケーションはそれぞれの
仮想トポロジにbindされた仮想NICを選択することで利⽤するネットワークを選択可能
– スイッチにも特別な対応は必要なし(BGPでそれぞれの仮想ネットワークのprefixを交換すればOK）

10. エンドホストにおけるエラー訂正
• RAILでは、Stretch linkを利⽤したことによるパスのエラーレート(PPER)に
よるアプリケーションの性能劣化を防ぐために、エンドホスト上で動作する
エラー訂正機構を持つ
• エラー訂正機構では、XOR encodingによるパリティパケットを⽤いて、エン
ドホスト上においてdropされたパケットの復元を⾏う
• パリティパケットの送信間隔は、PPER(利⽤するネットワークのパケットロ
ス率)から動的に決定される
– PPERが⾼いパスにおいては、送信頻度を短くするような動作
• PPERは以下の⽅法で、各エラー訂正モジュールがFlowの開始時に取得
– Tracerouteを送って利⽤しているパスの情報を取得(ID?)
– 仮想トポロジを管理するコントローラに対して、PPER情報の問い合わせを実施

11. コスト削減効果
• NRB=99%(Low),95%(High)
の環境それぞれにおいて、
ネットワークコストの削減効
果を試算
• 10G Networkで10%
• 40G Networkで44%
のコスト削減効果を確認

12. 評価
• 著者スライド参照

13. まとめ
• 論⽂のポイント
– 市販のトランシーバのBER測定し、データセンタにおいて規格が定義している距離
よりもStretchして利⽤することが可能なことを確認した
– Error-rateにsensitiveなApplicationに影響が出ないように、エンドツーエンドの
異なる信頼性を持つ複数の仮想トポロジを構築し、アプリケーションから選択可能
にした
– Stretchして利⽤した場合に問題となるエラーレートの増加に対して、エンドホス
トで動作するエラー訂正アルゴリズムで対処
• 検証結果
– 10G Networkで10%, 40G Networkで44%のコスト削減効果
• 所感
– データセンタ設計時に綱渡りでやっていたようなことにきちんと技術的な
裏付けをつけた点で重要

14. Passive Real-time Datacenter Fault Detection
and Localization
• 背景/実現したいこと
• データセンタネットワークのPartial faultはアプリケーションの性能に⼤きな影響
を与える
• 基本的なアイデア
– Clos network(w/ECMP)の対称性を利⽤して、トラフィックの経路情報を既存ネッ
トワークインフラ上で収集
– エンドホストの性能情報と紐付けることで、ネットワークの故障箇所の検出と局所
化を⾏う
• 論⽂のポイント
– パス情報を収集するために、Clos-networkの構造をうまく利⽤することで、既存
ネットワーク上で障害箇所のLocalizationを実現
– エンドホストのシステムコールの情報から、ネットワークの障害を検出できること
を⽰した
• 検証結果
– Facebookのclos-network上における実障害の検出に成功

15. 背景/モチベーション
• ネットワークの部分的なfaultは、アプリケーションのパフォーマンス
に⼤きな影響を与える
– ネットワークの⼀部のリンクが1%dropするだけで、99th-percentaileの
アプリケーションレイテンシが4.5倍以上になるという研究がある
• ネットワークの障害検出に関しては既存研究が多くあるが、オペレー
タの視点では、その障害が実際のトラフィックにどのように影響をあ
たえるのかが重要
• 本研究では、特にロードバランスされたネットワークに関して、障害
がトラフィックに与える影響という観点にフォーカスした障害箇所の
検出⼿法を提案

16. 背景 - 最近のデータセンタネットワーク
• 増加の著しいWest-Eastトラフィックをさばくため、over-
subscriptionを⾏わないClos-networkが主流に
– Pod-Agg-Coreの3-stage Clos Network(各stage間はECMP)

17. 背景 - 最近のデータセンタネットワーク
• 増加の著しいWest-Eastトラフィックをさばくため、over-
subscriptionを⾏わないClos-networkが主流に
– Pod-Agg-Coreの3-stage Clos Network(各stage間はECMP)

18. 本研究が⽬指すシステムの要件
• Clos-network(w/ECMP)におけるアプリケーションの性
能に影響を与える障害の検出
• Requirements
– Full-Path Information
– Passive monitoring, not active probing
– Reduced switch dependencies
– No per-application modelling
– Rapid online analysis

19. システムの概要
1. ネットワーク中で、経由パ
ス情報をパケットに埋め込
み
2. エンドホストがアプリケー
ションの性能劣化情報から、
リンクの性能劣化を検出
3. 集中管理のコントローラが
真の障害かどうかを判断

20. ネットワーク中のパス情報の収集
• Aggregation switchにおいて経由コアスイッチのIDをパ
ケットに埋め込む
– 経由コアスイッチがわかると、ネットワークの中の経由リンクが
⼀意に決まる
• IDの埋め込みにはIPv6 DSCP fieldを利⽤

21. アプリケーションの性能情報と
パス情報の対応付けた障害検出(1)
• ネットワーク的に同じ挙動を⽰すべきリンク群をES(equivalence set)と定義
し、ESごとにTCPレイヤやSystem Callに関する統計量を収集
• ES中の中で有意に異なる値(studentのt検定を利⽤)を持つパスが存在した場
合、当該パスを異常と識別し、コントローラに送信
• コントローラは、各ホストノードから送信されたリンクの異常情報をの中か
ら、有意に異常と検出された回数が⼀定期間内に多いものを異常と判定する

22. アプリケーションの性能情報と
パス情報の対応付けた障害検出(2)
• 取得する統計量
– Cwnd:congenstion window
– Sstresh:slow-start threshold
– Srtt:smoothed round-trip time
– Select:wait time for select()

23. 評価
• Private Test-bedにおける評価
– 評価環境
• Fat-tree, Pod=3(each Pod contains 9 hosts), Core=9
– 評価⼿法
• Iptablesを⽤いて特定のcore-aggを通過したパケットについてinbound⽅向の
packet drop/latencyを発⽣させた
• Packet drop率や挿⼊するlatency値を変動させ、障害検出までの速度や精度な
どについて評価
• FacebookのClosネットワークの⼀部を利⽤した評価
– 評価⼿法
• 現⾏のnetwork monitoringシステムよりも、実障害を早く検出できるかにつ
いて評価

24. Private-testbedにおける評価
- 検出速度及びsensitivity
• コントローラが障害を検出するのに⽤いる窓の区間
(interval)が⻑いほど、⾼いsensitivityで障害を検出する
• ⼀⽅、false positiveも多くなる
• 論⽂中では、intervalは⻑くても3分程度にすべき
(errorrate=0.1%程度を検出可能)とある

25. FacebookのClosネットワークの⼀部を
利⽤した評価
• 評価環境
– 評価環境:Facebookのclos-network上の30hostsを利⽤して評価
– 評価期間:2weeks
• 結果
– ラインカードの故障を検出できた

26. Passive Real-time Datacenter Fault Detection
and Localization
• 基本的なアイデア
– Clos network(w/ECMP)の対称性を利⽤して、トラフィックの経路情報を既存ネッ
トワークインフラ上で収集
– エンドホストの性能情報と紐付けることで、ネットワークの故障箇所の検出と局所
化を⾏う
• 論⽂のポイント
– パス情報を収集するために、Clos-networkの構造をうまく利⽤することで、既存
ネットワーク上で障害箇所のLocalizationを実現
– エンドホストのシステムコールの情報から、ネットワークの障害を検出できること
を⽰した
• 検証結果
– Facebookのclos-network上における実障害の検出に成功
• 所感
– Clos-networkの特性をうまく使っているなという印象
– 実際にどの程度Localization(≠Detection)できるかについては、様々な障
害/トラフィックパターンで評価が必要

27. Enabling Wide-Spread Communications on
Optical Fabric with MegaSwitch
• 背景/実現したいこと
• WSSを⽤いたデータセンタinterconnectには、データセンタにおいて必要とされ
る送受信ノード対が多い通信への対応が難しいという課題があった
• 本研究では多くのエンドホスト数をサポートする、WSSを⽤いたinterconnectを
提案する
• 基本的なアイデア
– 各WSSごとに専⽤の送信⽤ファイバをリング状に配置
– 送信(mux)時に各WSSが同じ波⻑を⽤い、受信(demux)時に複数の送信元WSS専
⽤のファイバから、単⼀の出⼒ポートに対して波⻑変換を⾏う
• 論⽂のポイント
– WSS同⼠を接続するファイバを各送信元WSS専⽤にしたことで増幅器が基本的に
はソースノード以外に必要ない(波⻑のDropはするがAddはしないため）
– 現⾏のWSSを⽤いることで、実際に製作可能
• 検証結果
– 現在のスケールでも、ある程度のCDNまでなら対応可能（机上計算）

28. Enabling Wide-Spread Communications on
Optical Fabric with MegaSwitch
• 著者スライド参照