NSDI16_reading

NSDI’16 Reading
Network Architectures and Protocols
Hiroya Kaneko
2016/05/29
Some figures are cited from original papers or slides
http://system-reading.connpass.com/event/31207/

Contents
An Industrial-Scale Software Defined Internet Exchange Point
Jihyung Arpit Gupta (Princeton University), et al.
XFabric: A Reconfigurable In-Rack Network for Rack-Scale Computers
Sergey Legtchenko (Microsoft Research), et al.
Be Fast, Cheap and in Control with SwitchKV
Xiaozhou Li (Intel Labs) , et al.
Bitcoin-NG: A Scalable Blockchain Protocol
Ittay Eyal (Cornell University), et al.
Exploring Cross-Application Cellular Traffic Optimization with Baidu TrafficGuard
Zhenhua Li (Tsinghua University and Baidu Mobile Security), et al.

An Industrial-Scale Software Defined Internet
Exchange Point
• 実現したいこと
• スケーラブルなSDN-IX
• FlowTable数、Route Updateの場合の計算量、D-PlaneへのFlowMod/sec
• 論文のポイント
– BGPによる経路アップデートとSDN的な制御を適切に分離することで、数多くの
ASが接続する環境におけるスケーラビリティを改善するアーキテクチャを提案し、
実データセット上における有効性を示した
• 手法（既存手法からの改善点）
• エントリ数の爆発を防ぐためのテーブル構造
• Control-Planeの計算を各ASごとに分散するアーキテクチャ
• パケットヘッダ(dMAC)にnexthopとreachability情報を埋め込むことで、Route
Updateごとに必要だったd-planeの再設定を不要にした
• 検証結果(511 participants,30万経路のデータセットを用いて検証)
– Forwarding Table数を65Kに削減(既存手法：750K)
• Commodity OpenFlow SwitchのFIB Table数(約100K)に収まる
– Route Updateの場合に必要なD-Planeへのflow-modを0
– 必要なNextHop向けのエントリ数を360へ削減(既存手法25K)

Be Fast, Cheap and in Control with SwitchKV
• 動的なワークロードに対して高速かつ、低レイテンシ、SPOFの無いロー
ドバランサ
– OpenFlowを用いてリクエストごとにダイレクトにキャッシュへルーティングする
ことで、低レイテンシかつスケールするKVSを実現
• 手法
• パケットヘッダ(dMAC)にKeyを埋め込み、OpenFlowを用いてコンテン
ツレベルでクライアント-キャッシュ間のルーティングを制御するアーキ
テクチャ
• ワークロードの変化に高速に追従するためのキャッシュ制御アルゴリズム
• Top-Kコンテンツの効率的検出とスイッチのルール書き換え
• 検証結果
– キャッシュミスを起こすユースケースにおいて、レイテンシを改善
– バックエンドノードの増加に対して、リニアにスケールすることを確認
– ワークロードの変化に対して1秒程度で追従(スループットを回復)

XFabric: A Reconfigurable In-Rack Network for
Rack-Scale Computers
• 低コストかつ高性能なIn-Rack Networkを実現
– 市販のCross-Connect ASICで低コストにTraffic AwareなReconfigurable In-
Rack Networkを実現
• 手法
• 市販のCross-Connect ASICを複数利用し、ノード間をPartialに相互接続
することでコストを削減するアーキテクチャ
• トラフィックデマンドに応じて、ノード間を相互接続するCircuit
topologyを変更することで性能を維持
• 検証結果
– Clos Circuit Switchを用いた場合と比較してコストを1/5に低減
– Path lengthを3D-Torus比で37%削減
– ワークロード完了までの実行時間を3D-Torus比で30%削減

Exploring Cross-Application Cellular Traffic
Optimization with Baidu TrafficGuard
• モバイルトラフィックの削減
– 中国のBaiduユーザ20万人の実データを元にモバイルトラフィックを詳細に分析し、
その結果から効果的なトラフィック削減手法を提案している
• 手法
• ユーザ端末(Android)の全ての送受信パケットをTUN I/Fでinterceptし、
通信圧縮Proxy(Traffic Guard)へ転送
• Traffic Guardは通信データ圧縮のために以下を行う
• トラフィックの多く(71%)を占める画像データの再圧縮
• ブラックリストベースのMalicious,Advertisementのブロック(端末/クラウド双方)
• バックグラウンドトラフィックのスロットリング
• 夜間のトラフィックのスロットリング
• URLベースコンテンツキャッシュ(Squidを利用)
• 検証結果(Dec. 21–27, 2014, 350M HTTP requests issued from 0.6M users)
– 36%のトラフィック削減を実現

Bitcoin-NG: A Scalable Blockchain Protocol
• スケーラブルなBlockchain protocolの実現
• 既存技術の課題
– 既存のBitCoinで用いられているブロックチェーンでは、コンセンサスを得るのに
時間がかかる(10分に1回程度、いつ得られるかも不定)
– BitCoinにおけるBlockChainを、Leader ElectionとTransaction Serializationの2
phaseに分割することで、BitCoinと同じTrust Modelを維持したまま、低レイテン
シでのコンセンサスを実現
• 手法
• Nakamono BlockをKeyBlockとMicroBlockに機能的に分割
– KeyBlockは、unix timestampとnonse,microblockへのreferenceを持つ
– MicroBlockはnonseを持たず、deterministicに決定された周期(10sec)で
生成される。直前のKeyBlockの所有者の秘密鍵で電子証明されることで
その正当性を証明する
• 検証結果
– コンセンサスdelayを90%削減

IXP(Internet Exchange Point)
• 異なる事業者が経路情報とトラフィックを交換するための
場所
• BGPを使って、自身を経由して到達可能なネットワークア
ドレスを広報し合う
L2スイッチ(IXP所有)
AS C
10/8 , 40/8
AS D
10/8 , 40/8 , 80/8
AS A
Destination NextHop
10/8 AS C
40/8 AS C
80/8 AS D
BGP

IXP(Internet Exchange Point)
• Route Serverがいる場合（フルメッシュ回避）
AS A
AS B
AS C
Route Server(IXP所有)

BGPを用いた経路交換の課題
• トラフィック制御の粒度がDestination Prefixのみ
– 10/8宛かつ80番ポートはAS Dへ -> できない
– 20/8から来たパケットはAS Cへ ->できない
AS C
10/8 , 40/8
AS D
10/8 , 40/8 , 80/8
AS A
Destination NextHop
10/8 AS C
40/8 AS C
80/8 AS D
BGP
AS A RIB

SDN-IX
• IXPにOpenFlowを導入し、より柔軟な経路制御を実現
– ControllerがBGP経路とSDN Policyをcomposition
OpenFlow SW FIB
AS C
10/8 , 40/8
AS D
10/8 , 40/8 , 80/8
Destination NextHop
10/8 AS C
40/8 AS C
80/8 AS D
OpenFlow
Controller
with RR
BGP
SDN Policy
dPort=443はAS C Match NextHop
10/8 & dPort=443 AS C
40/8 & dPort=443 AS C
80/8 & dPort=443 AS D
AS A RIB

課題１
ルール数の爆発
• Prefix数 * Policy数のエントリが必要になってしまう
– OpenFlow SWのルール数は有限かつ、書き換えに時間が掛かる
– ルールの計算時間も課題
OpenFlow SW
AS C
10/8 , 40/8
AS D
10/8 , 40/8 , 80/8
Destination NextHop
10/8 & dPort=443 AS C
40/8 & dPort=443 AS C
10/8 & dPort=22 AS C
10/8 & dPort=443 AS D
40/8 & dPort=443 AS D
80/8 & dPort=443 AS D
SDN Policy
dPort=443はAS C
dPort=22はAS C
SDN Policy
dPort=443はAS D
OpenFlow SW FIB

課題１
• 最終的に同じ挙動をするエントリをFECとしてまとめて、
1エントリで表現
OpenFlow SW
AS C
10/8 , 40/8
AS D
10/8 , 40/8 , 80/8
Destination NextHop
10/8 & dPort=443 AS C
40/8 & dPort=443 AS C
10/8 & dPort=443 AS D
40/8 & dPort=443 AS D
80/8 & dPort=443 AS D
Destination NextHop
VIP1 AS C
VIP2 AS D

課題１
• ルール数が直積にならないようにテーブルを分割
• 各ASごとにControllerを設置し、自身のポリシの
compositionを各ASで実施

課題２
Route Updateのたびに多くのエントリ書き換えが必要
• 10/8がAS Cからwithdrawされた場合、下線のエントリの
書き換え(削除)が必要
OpenFlow SW
AS C
10/8 , 40/8
AS D
10/8 , 40/8 , 80/8
Destination NextHop
10/8 & dPort=443 AS C
40/8 & dPort=443 AS C
10/8 & dPort=443 AS D
40/8 & dPort=443 AS D
80/8 & dPort=443 AS D

Packetへのnexthopとreachability情報の埋め込み(1)
• 各ASのSDN Controllerが、各経路のnexthop向けのARPに対して以
下の通りencodeされたdMACを返す
– 一種のソースルーティング
OpenFlow SW
Destination NextHop dMAC
(R2,N1の場合)
10/8 AS C 110
40/8 AS C 110
80/8 AS D 011
AS C
10/8 , 40/8
AS D
10/8 , 40/8 , 80/8
Nexthop(11bit)Reachability(37bit)
AS A RIB
i番目のASから到達可能であることを示す Best PathのASのTag
0(AS C)11
dMAC

• 具体的なdstIPの値ではなく、Reachability bitを用いて
Ruleを記述する
OpenFlow SW
AS C
10/8 , 40/8
AS D
10/8 , 40/8 , 80/8
Rule NextHop
1X & dPort=443 AS C
1X & dPort=443 AS C
1X & dPort=22 AS C
1X & dPort=22 AS C
X1 & dPort=443 AS D
X1 & dPort=443 AS D
X1 & dPort=443 AS D
0(AS C)11
dMAC
Destination NextHop
10/8 & dPort=443 AS C
40/8 & dPort=443 AS C
10/8 & dPort=443 AS D
40/8 & dPort=443 AS D
80/8 & dPort=443 AS D

• 経路に変更があった場合、送出パケットのdMACを変更す
るのみ（スイッチ上のルールの変更は不要）
• 例：AS Cが10/8をwithdrawした場合
– AS AのSDN ControllerがAS CのnexthopのdMACを変更(GARP)
OpenFlow SW
AS C
10/8 , 40/8
AS D
10/8 , 40/8 , 80/8
Rule NextHop
1X & dPort=443 AS C
1X & dPort=443 AS C
1X & dPort=22 AS C
1X & dPort=22 AS C
X1 & dPort=443 AS D
X1 & dPort=443 AS D
X1 & dPort=443 AS D
1(AS D)01
dMAC
Destination NextHop dMAC
(R2,N1の場合)
10/8 AS C 110 -> 011
40/8 AS C 110
80/8 AS D 011
AS A RIB

評価
• Forwarding Table数を65Kに削減(既存手法：750K)
• Commodity OpenFlow SwitchのFIB Table数(約100K)に収まる

既存のLBの課題
• キャッシュミス時の大きなオーバヘッド
• LBのSPOF化

SwitchKV – Contents-aware routing
• 要求パケットのdMACにコンテンツIDとリクエストメソッドをembed
– コンテンツIDはキャッシュMiss時にバックエンドからクライアントへ通知される
• OpenFlowスイッチはdMACフィールドを参照し、転送すべきノードを選択
(キャッシュ or バックエンド)

SwitchKV – キャッシュの管理
• ワークロードの変動に対応するため３つのキャッシュアップデート手
法を持つ
Cacheはcache-miss
したコンテンツを知ら
ないため必要
Hit率の低いコンテンツ
の無効化のために利用急激なワークロード
変動対応のために利用

• 著者スライド参考

• Uplink crosspointはl本のラック外へのlinkを持つ
• SoCの一部とuplink crosspointは直接接続される
– Internal crosspointを介さない
• 各SoCにおいてinbound/outboundのTraffic Matrixを管理

XFabric: Reconfigure Fabric
• トポロジの再構成の手順
1. L1のTopologyをperiodicにTraffic Matrixから更新
2. 1が終わり次第、L1上のL2テーブルを構築し各SoCに配布
• In-flight packetは無視される

XFabric: L1トポロジの計算
1. SoCのTraffic Matrixから、ラックを超えるIngress/Egressトラ
フィック合計が大きい順に並べ、大きい値を持つものから順次uplink
crosspointとの接続性を確保
2. その後、partial クラスタのIngress/Egressトラフィック合計が平滑
化するようにSoCをd個(下図=6)のpartial クラスタに分割

XFabric: L1トポロジの計算
3. 先ほど決定したPartial クラスタ内のSoC間のホップ数が最小になる
ようにクラスタ内のトポロジを決定

XFabric: FabricのReconfigure(L1/L2)
1. 各CrossPoint ASICに新しい回路情報を送信(確定はまだ）
2. 各SoCに新しいForwarding Tableを送信
1. dMACにforwarding tableのversionをencode
3. 各CrossPoint ASICの回路を更新
4. ASICの更新Ackを確認し次第、新しいForwarding Tableの使用開始
を指示するパケットをFloodingベースのProtocolで送信

NSDI16_reading

More Related Content

Similar to NSDI16_reading

More from 紘也 金子

NSDI16_reading

More from 紘也金子