Advertisement
Check these out next
システム系論文輪講会20140806
Aug. 19, 2014•0 likes•18,848 views
4 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download to read offline
Report
Engineering
Reading Dynamic Scheduling of Network update , Xin Jin et al , at SIGCOMM'14.
紘也 金子Follow
Preferred Networks, Inc. - Engineer at Preferred Networks, Inc.Advertisement
システム系論文輪講会20140806
- システム系論文輪講会� Reading: “Dynamic Scheduling of Network update” @SIGCOMM’14 , Xin Jin et al. 注釈のない図表は原論文より引用 h#p://research.microso0.com/apps/pubs/default.aspx?id=218283
- 背景 分散制御の世界 自律ルーティングプロト コルベースで協調 自分の転送ルールは自 分で決める 2 集中制御の世界(SDN) 親が全てのパス設計を行う 全ての転送ルールは親 が設定 今回はこっちの話 h#p://blog.ine.com/tag/ospf/より引用 h#p://tech-‐sketch.jp/2012/04/openflow-‐1.htmlより引用
- Network State = スイッチ群の転送Rule,link帯域など スイッチの動作(FIB Rule) = Flow Matching + Forwarding Flow(End-to-End) = FIB Ruleのchain Network Update B C D A f1: 3 7/7 3/7 0/7 0/7 4/7 3 Match:Flow f1 AcRon:Output Port A f1: 4
- Network Update 4 4 • Network Update – ２つのNetwork State間の遷移 – Flow群を追加/削除/移動
- Network Update • 集中制御の世界(OpenFlowなど) – スイッチのルールは自分で全部管理 – Network全体をAtomicにupdateはできない – 安全かつ高速なルール書き換えが必要 • State全体のconsistency – Blackhole-‐freedom -‐> パケットが途中で消えない – Loop-‐freedom -‐> ループが発生しない – Packet coherence -‐> 同時にルールが混在しない – CongesRon-‐freedom -‐> リンクの容量を守る 5
- Variability in Update time 6 • ルール書き換え時間はばらつく – Add/Modify rule • Priorityが一定の場合 -‐> 線形 • Priorityが異なる場合-‐>非線形(TCAMの再構築) • ModifyはAddより時間がかかる(削除-‐>追加) – C-‐Planeの処理によっても大きく影響を受ける • C-‐Plane負荷が高いスイッチは非常に低速なupdate
- Network Update 7 7 どっちが早い? PlanA : [F3->F2][F4->F1] PlanB : [F4][F3->F2->F1]
- 既存研究 • “Achieving high uRlizaRon with so0ware-‐ driven WAN,” C.-‐Y. Hong et al. , ACM SIGCOMM 2013. – Updateの段階をいくつかのstageに分割し、stag e内の処理が全て終了すると次stageに移行 – Stage数をminimizeするような最適化を行う • PlanA : [F3->F2][F4->F1](2stage,fast) • PlanB : [F4][F3->F2->F1](3stage) • しかし実際は更新速度は一定ではない – Stage内で低速ノードがいると全体が律速 8
- 本論文の概要 • 目的 – 更新速度の異なるノードが存在していた場合 にも高速なnetwork updateを実現したい • 方針 – Network全体が必要とする制約を満たしたまま dynamicなnetwork updatingをスケジューリング 9
- Dionysus Overview 10 1. Current/Target Stateか らDependency Graphを生 成 2. Dependency Graphから ルール設定をスケジュー リング 3. ルール設定が完了次第依 存グラフをアップデート， 2に戻る 最終的なルール投入順は，スイッチの設定完了の ばらつきの影響から制約の範囲内で前後する
- Network State Model ネットワークフロー的な一般的なモデル • Network State Model – Network G consists of • Switches , directed Links – Flow f consists of • Ingress to egress switches , traffic volume • Forwarding Model – Tunnel Based – WCMP(Weighted Cost MulR Path) 11
- パス移動の考え方@Tunnelベース 1. 移動先パスの設定 – 移動先スイッチのルール設定数の制約 2. IngressでのFlowの切り替え – 切り替え先パスのcongesRonの問題 3. 古いパスの削除 12
- Dependency Graph 13 操作とリソースの 依存関係を記述
- Tunnel Basedな場合 PktCoherence/Loop -‐ 定義より問題なし CongesRon -‐ by resource Node Blackhole -‐ Tunnel生成後 に切り替えを行う Dependency Graph Generation 14 Straight forwardに構築可能(と書いてある)
- Network Update Scheduling • ILPでも解けるけどfeasibleではない • Theorem1. In the presence of both link capacity and switch memory constraints , finding a feasible update schedule is NP-‐ Complete. • Theorem2. In the presence of link capacity constraints , but no switch memory constraints , finding the fastest update schedule is NP-‐Complete （証明は別論文） 15
- Dionysus Scheduling • Lemma 1.If the dependency graph is DAG , finding a feasible update schedule is in P. • 簡単なDependency GraphはDAG • DAG上のクリティカルパス長で優先度付け – CPLを値を各OpNodeで計算 16
- • Dependency GraphにはCycleも存在する • Cycleの検出 – Tarjan’s AlgorithでSCC(強連結成分)を抽出 • O(|V|+|E|) • SCC全体を1つのVritualNodeとして扱う – クリティカルパス長には内包するNode数を加える Handling Cycles 17 １ 2 3 3 4 5 5 １ １ 5
- Handling Cycles • SCC内部ノードのorderingについて – Virtual Node内のopNodeが１つの場合 • 単純にSCCのCPLによる – Virtual Node内に複数のopNodeがある場合 • Out-‐degreeベースのcentralize metricsで順序を決定 18 5
- Handling Cycles • Avoid Deadlock HeurisRcs – SCC内opNodeとSCC外opNodeが同一のリソー スを参照している場合DeadLockの可能性がある – このパターンに関してはヒューリスティック的な 手法で対処 19
- Dionysus Scheduling 20
- DeadLocks • それでもなおDeadlockは発生しうる • そもそもfeasibleな解が存在しない場合がある • Reduce flow rate – Flow rateを徐々に減らしていくことで解にたど り着く 21
- 評価 • 主にSWAN(stage based scheduling)と比較 • 評価パターン – WAN-‐TE case • Traffic Matrixが変化した場合 – WAN-‐Failure Recovery case • LinkDownが発生した場合 – Large-‐Scale-‐SimulaRon • WAN • DC • AlternaRve 22
- WAN-TE case • Flow[S6-‐>S5-‐>S7] をFlow[S6-‐>S8-‐>S7]へ移動 • S4とS7に500msのレイテンシを挿入(WAN EmulaRon) • どうやらその他Flowも流れている？ 23 １ 2 3 3 4 5 5 １ １ 5 Inject 500ms latency
- WAN-TE case • 先行ノードが存在しないopNodeについて、 CLP降順に実行開始 • S8,S7,S1,S2が実行開始 24 １ 2 3 3 4 5 5 １ １ 5 4 Inject 500ms latency
- WAN-TE case • S7が実行終了,新規実行可能op無し • running[S8,S2,S1] 25 １ 2 3 3 4 5 5 １ １ 5 4 Inject 500ms latency
- WAN-TE case • S1が実行終了,新規実行可能op無し • running[S8,S2] 26 １ 2 3 3 4 5 5 １ １ 5 4 Inject 500ms latency
- WAN-TE case • S8が実行終了,S8とS6実行開始 • running[S8,S6,S2] 27 １ 2 3 3 4 5 5 １ １ 5 4 Inject 500ms latency
- WAN-TE case • S8,S6が実行終了,S3,S5,S7が実行開始 • running[S2,S3,S5,S7] 28 １ 2 3 3 4 5 5 １ １ 5 4 Inject 500ms latency
- WAN-TE case • S5が実行終了,新規実行可能op無し • running[S2,S3,S7] 29 １ 2 3 3 4 5 5 １ １ 5 4 Inject 500ms latency
- WAN-TE case • S7が実行終了,新規実行可能op無し • running[S2,S3] 30 １ 2 3 3 4 5 5 １ １ 5 4 Inject 500ms latency
- WAN-TE case • S3が実行終了,S4実行開始 • running[S2,S4] 31 １ 2 3 3 4 5 5 １ １ 5 4 Inject 500ms latency
- WAN-TE case • S2が実行終了,新規実行可能op無し • running[S4] 32 １ 2 3 3 4 5 5 １ １ 5 4 Inject 500ms latency
- WAN-TE case • S4が実行終了,S5実行開始 • running[S5] 33 １ 2 3 3 4 5 5 １ １ 5 4 Inject 500ms latency
- WAN-TE case • S5が実行終了 • running[] 34 １ 2 3 3 4 5 5 １ １ 5 4 Inject 500ms latency
- Dionysus vs SWAN • SWANと比較して500ms程度高速 – Stageごとに進行するSWANは高遅延環境で無 駄が多い
- まとめ • スイッチのstate updateにかかる時間にはばらつきがある – C/M-‐Planeの負荷、C-‐Planeの回線遅延@WAN – Stageベースの既存手法では最遅スイッチで性能が律 速 • Consistency/constraintsを破壊しない範囲で最 大限並列にupdate可能なように命令をdynamic scheduling • 結果，ばらつきの大きい場面においてはstage basedよりも高速な結果が得られた 36
Advertisement