Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

システム系論文輪講会20140806

18,476 views

Published on

Reading Dynamic Scheduling of Network update , Xin Jin et al , at SIGCOMM'14.

Published in: Engineering
  • Dating direct: ❤❤❤ http://bit.ly/36cXjBY ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Dating for everyone is here: ❶❶❶ http://bit.ly/36cXjBY ❶❶❶
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

システム系論文輪講会20140806

  1. 1.   システム系論文輪講会� Reading: “Dynamic Scheduling of Network update” @SIGCOMM’14 , Xin Jin et al. 注釈のない図表は原論文より引用 h#p://research.microso0.com/apps/pubs/default.aspx?id=218283
  2. 2. 背景 分散制御の世界   自律ルーティングプロト コルベースで協調   自分の転送ルールは自 分で決める 2 集中制御の世界(SDN)   親が全てのパス設計を行う   全ての転送ルールは親 が設定 今回はこっちの話 h#p://blog.ine.com/tag/ospf/より引用   h#p://tech-­‐sketch.jp/2012/04/openflow-­‐1.htmlより引用  
  3. 3. 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
  4. 4. Network Update 4 4 •  Network Update – 2つのNetwork State間の遷移 – Flow群を追加/削除/移動
  5. 5. Network Update •  集中制御の世界(OpenFlowなど)   – スイッチのルールは自分で全部管理   – Network全体をAtomicにupdateはできない   – 安全かつ高速なルール書き換えが必要   •  State全体のconsistency   – Blackhole-­‐freedom  -­‐>  パケットが途中で消えない   – Loop-­‐freedom  -­‐>  ループが発生しない   – Packet  coherence  -­‐>  同時にルールが混在しない   – CongesRon-­‐freedom -­‐>  リンクの容量を守る   5
  6. 6. Variability in Update time 6 •  ルール書き換え時間はばらつく   – Add/Modify  rule   •  Priorityが一定の場合  -­‐>  線形   •  Priorityが異なる場合-­‐>非線形(TCAMの再構築)   •  ModifyはAddより時間がかかる(削除-­‐>追加)   – C-­‐Planeの処理によっても大きく影響を受ける   •  C-­‐Plane負荷が高いスイッチは非常に低速なupdate  
  7. 7. Network Update 7 7 どっちが早い? PlanA : [F3->F2][F4->F1] PlanB : [F4][F3->F2->F1]
  8. 8. 既存研究 •  “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
  9. 9. 本論文の概要 •  目的 – 更新速度の異なるノードが存在していた場合 にも高速なnetwork updateを実現したい •  方針 – Network全体が必要とする制約を満たしたまま dynamicなnetwork updatingをスケジューリング 9
  10. 10. Dionysus Overview 10 1.  Current/Target Stateか らDependency Graphを生 成 2.  Dependency Graphから ルール設定をスケジュー リング 3.  ルール設定が完了次第依 存グラフをアップデート, 2に戻る 最終的なルール投入順は,スイッチの設定完了の ばらつきの影響から制約の範囲内で前後する
  11. 11. 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
  12. 12. パス移動の考え方@Tunnelベース 1.  移動先パスの設定   –  移動先スイッチのルール設定数の制約   2.  IngressでのFlowの切り替え   –  切り替え先パスのcongesRonの問題   3.  古いパスの削除 12
  13. 13. Dependency Graph 13 操作とリソースの 依存関係を記述
  14. 14. Tunnel  Basedな場合   PktCoherence/Loop    -­‐  定義より問題なし   CongesRon    -­‐  by  resource  Node   Blackhole    -­‐  Tunnel生成後 に切り替えを行う   Dependency Graph Generation 14 Straight  forwardに構築可能(と書いてある)
  15. 15. 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
  16. 16. 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
  17. 17. •  Dependency  GraphにはCycleも存在する   •  Cycleの検出   – Tarjan’s  AlgorithでSCC(強連結成分)を抽出   •  O(|V|+|E|)   •  SCC全体を1つのVritualNodeとして扱う   – クリティカルパス長には内包するNode数を加える Handling Cycles 17 1 2 3 3 4 5 5 1 1                                                        5  
  18. 18. Handling Cycles •  SCC内部ノードのorderingについて   – Virtual  Node内のopNodeが1つの場合   •  単純にSCCのCPLによる   – Virtual  Node内に複数のopNodeがある場合   •  Out-­‐degreeベースのcentralize  metricsで順序を決定   18                                                                                                                                    5  
  19. 19. Handling Cycles •  Avoid  Deadlock  HeurisRcs   – SCC内opNodeとSCC外opNodeが同一のリソー スを参照している場合DeadLockの可能性がある   – このパターンに関してはヒューリスティック的な 手法で対処   19
  20. 20. Dionysus Scheduling 20
  21. 21. DeadLocks •  それでもなおDeadlockは発生しうる   •  そもそもfeasibleな解が存在しない場合がある   •  Reduce  flow  rate   – Flow  rateを徐々に減らしていくことで解にたど り着く   21
  22. 22. 評価 •  主にSWAN(stage  based  scheduling)と比較   •  評価パターン   – WAN-­‐TE  case   •  Traffic  Matrixが変化した場合   – WAN-­‐Failure  Recovery  case   •  LinkDownが発生した場合   – Large-­‐Scale-­‐SimulaRon   •  WAN   •  DC   •  AlternaRve   22
  23. 23. WAN-TE case •  Flow[S6-­‐>S5-­‐>S7]  をFlow[S6-­‐>S8-­‐>S7]へ移動   •  S4とS7に500msのレイテンシを挿入(WAN  EmulaRon)   •  どうやらその他Flowも流れている? 23 1 2 3 3 4 5 5 1 1                                                        5   Inject  500ms   latency
  24. 24. WAN-TE case •  先行ノードが存在しないopNodeについて、 CLP降順に実行開始   •  S8,S7,S1,S2が実行開始 24 1 2 3 3 4 5 5 1 1 5 4 Inject  500ms   latency
  25. 25. WAN-TE case •  S7が実行終了,新規実行可能op無し   •  running[S8,S2,S1] 25 1 2 3 3 4 5 5 1 1 5 4 Inject  500ms   latency
  26. 26. WAN-TE case •  S1が実行終了,新規実行可能op無し   •  running[S8,S2] 26 1 2 3 3 4 5 5 1 1 5 4 Inject  500ms   latency
  27. 27. WAN-TE case •  S8が実行終了,S8とS6実行開始   •   running[S8,S6,S2] 27 1 2 3 3 4 5 5 1 1 5 4 Inject  500ms   latency
  28. 28. WAN-TE case •  S8,S6が実行終了,S3,S5,S7が実行開始   •   running[S2,S3,S5,S7] 28 1 2 3 3 4 5 5 1 1 5 4 Inject  500ms   latency
  29. 29. WAN-TE case •  S5が実行終了,新規実行可能op無し   •   running[S2,S3,S7] 29 1 2 3 3 4 5 5 1 1 5 4 Inject  500ms   latency
  30. 30. WAN-TE case •  S7が実行終了,新規実行可能op無し   •   running[S2,S3] 30 1 2 3 3 4 5 5 1 1 5 4 Inject  500ms   latency
  31. 31. WAN-TE case •  S3が実行終了,S4実行開始   •   running[S2,S4] 31 1 2 3 3 4 5 5 1 1 5 4 Inject  500ms   latency
  32. 32. WAN-TE case •  S2が実行終了,新規実行可能op無し   •   running[S4] 32 1 2 3 3 4 5 5 1 1 5 4 Inject  500ms   latency
  33. 33. WAN-TE case •  S4が実行終了,S5実行開始   •   running[S5] 33 1 2 3 3 4 5 5 1 1 5 4 Inject  500ms   latency
  34. 34. WAN-TE case •  S5が実行終了   •   running[] 34 1 2 3 3 4 5 5 1 1 5 4 Inject  500ms   latency
  35. 35. Dionysus vs SWAN •  SWANと比較して500ms程度高速   – Stageごとに進行するSWANは高遅延環境で無 駄が多い  
  36. 36. まとめ •  スイッチのstate  updateにかかる時間にはばらつきがある   –  C/M-­‐Planeの負荷、C-­‐Planeの回線遅延@WAN   –  Stageベースの既存手法では最遅スイッチで性能が律 速   •  Consistency/constraintsを破壊しない範囲で最 大限並列にupdate可能なように命令をdynamic   scheduling   •  結果,ばらつきの大きい場面においてはstage   basedよりも高速な結果が得られた   36

×