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.
NSDI’16 Reading
Network Architectures and Protocols
Hiroya Kaneko
2016/05/29
Some figures are cited from original papers o...
Contents
An Industrial-Scale Software Defined Internet Exchange Point
Jihyung Arpit Gupta (Princeton University), et al.
X...
An Industrial-Scale Software Defined Internet
Exchange Point
• 実現したいこと
• スケーラブルなSDN-IX
• FlowTable数、Route Updateの場合の計算量、D-...
Be Fast, Cheap and in Control with SwitchKV
• 実現したいこと
• 動的なワークロードに対して高速かつ、低レイテンシ、SPOFの無いロー
ドバランサ
• 論文のポイント
– OpenFlowを用いてリ...
XFabric: A Reconfigurable In-Rack Network for
Rack-Scale Computers
• 実現したいこと
• 低コストかつ高性能なIn-Rack Networkを実現
• 論文のポイント
– 市販...
Exploring Cross-Application Cellular Traffic
Optimization with Baidu TrafficGuard
• 実現したいこと
• モバイルトラフィックの削減
• 論文のポイント
– 中国...
Bitcoin-NG: A Scalable Blockchain Protocol
• 実現したいこと
• スケーラブルなBlockchain protocolの実現
• 既存技術の課題
– 既存のBitCoinで用いられているブロックチェー...
An Industrial-Scale Software Defined Internet
Exchange Point
• 実現したいこと
• スケーラブルなSDN-IX
• FlowTable数、Route Updateの場合の計算量、D-...
IXP(Internet Exchange Point)
• 異なる事業者が経路情報とトラフィックを交換するための
場所
• BGPを使って、自身を経由して到達可能なネットワークア
ドレスを広報し合う
L2スイッチ(IXP所有)
AS C
10...
IXP(Internet Exchange Point)
• Route Serverがいる場合(フルメッシュ回避)
L2スイッチ(IXP所有)
AS A
AS B
AS C
Route Server(IXP所有)
BGPを用いた経路交換の課題
• トラフィック制御の粒度がDestination Prefixのみ
– 10/8宛かつ80番ポートはAS Dへ -> できない
– 20/8から来たパケットはAS Cへ ->できない
L2スイッチ(IXP所有)
...
SDN-IX
• IXPにOpenFlowを導入し、より柔軟な経路制御を実現
– ControllerがBGP経路とSDN Policyをcomposition
OpenFlow SW FIB
AS C
10/8 , 40/8
AS D
10/...
課題1
ルール数の爆発
• Prefix数 * Policy数のエントリが必要になってしまう
– OpenFlow SWのルール数は有限かつ、書き換えに時間が掛かる
– ルールの計算時間も課題
OpenFlow SW
AS C
10/8 , 4...
課題1
ルール数の爆発
• 最終的に同じ挙動をするエントリをFECとしてまとめて、
1エントリで表現
OpenFlow SW
AS C
10/8 , 40/8
AS D
10/8 , 40/8 , 80/8
Destination NextHo...
課題1
ルール数の爆発
• ルール数が直積にならないようにテーブルを分割
• 各ASごとにControllerを設置し、自身のポリシの
compositionを各ASで実施
課題2
Route Updateのたびに多くのエントリ書き換えが必要
• 10/8がAS Cからwithdrawされた場合、下線のエントリの
書き換え(削除)が必要
OpenFlow SW
AS C
10/8 , 40/8
AS D
10/8 ...
Packetへのnexthopとreachability情報の埋め込み(1)
• 各ASのSDN Controllerが、各経路のnexthop向けのARPに対して以
下の通りencodeされたdMACを返す
– 一種のソースルーティング
Op...
Packetへのnexthopとreachability情報の埋め込み(2)
• 具体的なdstIPの値ではなく、Reachability bitを用いて
Ruleを記述する
OpenFlow SW
AS C
10/8 , 40/8
AS D
...
Packetへのnexthopとreachability情報の埋め込み(3)
• 経路に変更があった場合、送出パケットのdMACを変更す
るのみ(スイッチ上のルールの変更は不要)
• 例:AS Cが10/8をwithdrawした場合
– AS ...
Packetへのnexthopとreachability情報の埋め込み(4)
評価
• Forwarding Table数を65Kに削減(既存手法:750K)
• Commodity OpenFlow SwitchのFIB Table数(約100K)に収まる
評価
Be Fast, Cheap and in Control with SwitchKV
• 実現したいこと
• 動的なワークロードに対して高速かつ、低レイテンシ、SPOFの無いロー
ドバランサ
• 論文のポイント
– OpenFlowを用いてリ...
既存のLBの課題
• キャッシュミス時の大きなオーバヘッド
• LBのSPOF化
SwitchKV - Overview
SwitchKV – Contents-aware routing
• 要求パケットのdMACにコンテンツIDとリクエストメソッドをembed
– コンテンツIDはキャッシュMiss時にバックエンドからクライアントへ通知される
• OpenFl...
SwitchKV – キャッシュの管理
• ワークロードの変動に対応するため3つのキャッシュアップデート手
法を持つ
Cacheはcache-miss
したコンテンツを知ら
ないため必要
Hit率の低いコンテンツ
の無効化のために利用 急激なワ...
SwitchKV – 評価
SwitchKV – 評価
SwitchKV – 評価
SwitchKV – 評価
XFabric: A Reconfigurable In-Rack Network for
Rack-Scale Computers
• 実現したいこと
• 低コストかつ高性能なIn-Rack Networkを実現
• 論文のポイント
– 市販...
XFabric: A Reconfigurable In-Rack Network for
Rack-Scale Computers
• 著者スライド参考
XFabric: A Reconfigurable In-Rack Network for
Rack-Scale Computers
• Uplink crosspointはl本のラック外へのlinkを持つ
• SoCの一部とuplink cr...
XFabric: Reconfigure Fabric
• トポロジの再構成の手順
1. L1のTopologyをperiodicにTraffic Matrixから更新
2. 1が終わり次第、L1上のL2テーブルを構築し各SoCに配布
• In...
XFabric: L1トポロジの計算
1. SoCのTraffic Matrixから、ラックを超えるIngress/Egressトラ
フィック合計が大きい順に並べ、大きい値を持つものから順次uplink
crosspointとの接続性を確保
2...
XFabric: L1トポロジの計算
3. 先ほど決定したPartial クラスタ内のSoC間のホップ数が最小になる
ようにクラスタ内のトポロジを決定
XFabric: FabricのReconfigure(L1/L2)
1. 各CrossPoint ASICに新しい回路情報を送信(確定はまだ)
2. 各SoCに新しいForwarding Tableを送信
1. dMACにforwarding...
Exploring Cross-Application Cellular Traffic
Optimization with Baidu TrafficGuard
• 実現したいこと
• モバイルトラフィックの削減
• 論文のポイント
– 中国...
Bitcoin-NG: A Scalable Blockchain Protocol
• 実現したいこと
• スケーラブルなBlockchain protocolの実現
• 既存技術の課題
– 既存のBitCoinで用いられているブロックチェー...
Upcoming SlideShare
Loading in …5
×

NSDI16_reading

210 views

Published on

NSDI'16 Reading
Network Architectures and Protocols Session.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

NSDI16_reading

  1. 1. 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/
  2. 2. 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.
  3. 3. 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)
  4. 4. Be Fast, Cheap and in Control with SwitchKV • 実現したいこと • 動的なワークロードに対して高速かつ、低レイテンシ、SPOFの無いロー ドバランサ • 論文のポイント – OpenFlowを用いてリクエストごとにダイレクトにキャッシュへルーティングする ことで、低レイテンシかつスケールするKVSを実現 • 手法 • パケットヘッダ(dMAC)にKeyを埋め込み、OpenFlowを用いてコンテン ツレベルでクライアント-キャッシュ間のルーティングを制御するアーキ テクチャ • ワークロードの変化に高速に追従するためのキャッシュ制御アルゴリズム • Top-Kコンテンツの効率的検出とスイッチのルール書き換え • 検証結果 – キャッシュミスを起こすユースケースにおいて、レイテンシを改善 – バックエンドノードの増加に対して、リニアにスケールすることを確認 – ワークロードの変化に対して1秒程度で追従(スループットを回復)
  5. 5. 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%削減
  6. 6. 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%のトラフィック削減を実現
  7. 7. 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%削減
  8. 8. 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)
  9. 9. 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
  10. 10. IXP(Internet Exchange Point) • Route Serverがいる場合(フルメッシュ回避) L2スイッチ(IXP所有) AS A AS B AS C Route Server(IXP所有)
  11. 11. BGPを用いた経路交換の課題 • トラフィック制御の粒度がDestination Prefixのみ – 10/8宛かつ80番ポートはAS Dへ -> できない – 20/8から来たパケットはAS Cへ ->できない 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 AS A RIB
  12. 12. 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
  13. 13. 課題1 ルール数の爆発 • 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 40/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
  14. 14. 課題1 ルール数の爆発 • 最終的に同じ挙動をするエントリを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=22 AS C 40/8 & dPort=22 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
  15. 15. 課題1 ルール数の爆発 • ルール数が直積にならないようにテーブルを分割 • 各ASごとにControllerを設置し、自身のポリシの compositionを各ASで実施
  16. 16. 課題2 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=22 AS C 40/8 & dPort=22 AS C 10/8 & dPort=443 AS D 40/8 & dPort=443 AS D 80/8 & dPort=443 AS D
  17. 17. 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
  18. 18. Packetへのnexthopとreachability情報の埋め込み(2) • 具体的な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=22 AS C 40/8 & dPort=22 AS C 10/8 & dPort=443 AS D 40/8 & dPort=443 AS D 80/8 & dPort=443 AS D
  19. 19. Packetへのnexthopとreachability情報の埋め込み(3) • 経路に変更があった場合、送出パケットの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
  20. 20. Packetへのnexthopとreachability情報の埋め込み(4)
  21. 21. 評価 • Forwarding Table数を65Kに削減(既存手法:750K) • Commodity OpenFlow SwitchのFIB Table数(約100K)に収まる
  22. 22. 評価
  23. 23. Be Fast, Cheap and in Control with SwitchKV • 実現したいこと • 動的なワークロードに対して高速かつ、低レイテンシ、SPOFの無いロー ドバランサ • 論文のポイント – OpenFlowを用いてリクエストごとにダイレクトにキャッシュへルーティングする ことで、低レイテンシかつスケールするKVSを実現 • 手法 • パケットヘッダ(dMAC)にKeyを埋め込み、OpenFlowを用いてコンテン ツレベルでクライアント-キャッシュ間のルーティングを制御するアーキ テクチャ • ワークロードの変化に高速に追従するためのキャッシュ制御アルゴリズム • Top-Kコンテンツの効率的検出とスイッチのルール書き換え • 検証結果 – キャッシュミスを起こすユースケースにおいて、レイテンシを改善 – バックエンドノードの増加に対して、リニアにスケールすることを確認 – ワークロードの変化に対して1秒程度で追従(スループットを回復)
  24. 24. 既存のLBの課題 • キャッシュミス時の大きなオーバヘッド • LBのSPOF化
  25. 25. SwitchKV - Overview
  26. 26. SwitchKV – Contents-aware routing • 要求パケットのdMACにコンテンツIDとリクエストメソッドをembed – コンテンツIDはキャッシュMiss時にバックエンドからクライアントへ通知される • OpenFlowスイッチはdMACフィールドを参照し、転送すべきノードを選択 (キャッシュ or バックエンド)
  27. 27. SwitchKV – キャッシュの管理 • ワークロードの変動に対応するため3つのキャッシュアップデート手 法を持つ Cacheはcache-miss したコンテンツを知ら ないため必要 Hit率の低いコンテンツ の無効化のために利用 急激なワークロード 変動対応のために利用
  28. 28. SwitchKV – 評価
  29. 29. SwitchKV – 評価
  30. 30. SwitchKV – 評価
  31. 31. SwitchKV – 評価
  32. 32. 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%削減
  33. 33. XFabric: A Reconfigurable In-Rack Network for Rack-Scale Computers • 著者スライド参考
  34. 34. XFabric: A Reconfigurable In-Rack Network for Rack-Scale Computers • Uplink crosspointはl本のラック外へのlinkを持つ • SoCの一部とuplink crosspointは直接接続される – Internal crosspointを介さない • 各SoCにおいてinbound/outboundのTraffic Matrixを管理
  35. 35. XFabric: Reconfigure Fabric • トポロジの再構成の手順 1. L1のTopologyをperiodicにTraffic Matrixから更新 2. 1が終わり次第、L1上のL2テーブルを構築し各SoCに配布 • In-flight packetは無視される
  36. 36. XFabric: L1トポロジの計算 1. SoCのTraffic Matrixから、ラックを超えるIngress/Egressトラ フィック合計が大きい順に並べ、大きい値を持つものから順次uplink crosspointとの接続性を確保 2. その後、partial クラスタのIngress/Egressトラフィック合計が平滑 化するようにSoCをd個(下図=6)のpartial クラスタに分割
  37. 37. XFabric: L1トポロジの計算 3. 先ほど決定したPartial クラスタ内のSoC間のホップ数が最小になる ようにクラスタ内のトポロジを決定
  38. 38. 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で送信
  39. 39. 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%のトラフィック削減を実現
  40. 40. 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%削減

×