asymmetric caching: improved network deduplication for mobile devices
TRANSCRIPT
M1GP 2013
Asymmetric Caching:Improved Network Deduplication
for Mobile Devices
Shruti SanadhyaRaghupathy SivakumarKyu-Han KimPaul CongdonSriram LakshmananJatinder P Singh
浅見・川原研究室 M1 高木 雅
1
[Mobicom 2012]
M1GP 2013
もくじ背景トラヒックの冗長性Network Deduplication
Asymmetric CachingCacheFeedback
評価実験
結論
2
M1GP 2013
背景トラヒックの冗長性約20%[1]（スマートフォン・HTTP通信）ロゴ
アイコン
JavascriptファイルjQuery／Prototype.js
CSSファイル
3
M1GP 2013
背景Network Deduplication [Dedup]通信経路上にSourceとDest.を配置CacheとHashテーブルを事前に共有冗長部分をHashコードに置換→ トラヒックの削減
4
[1] Qian et al,, “Web Caching on Smartphones: Ideal vs. Reality “ , MobiSys 2012
Sender ReceiverDedupSource
DedupDest.
Hash
H1 C1H2 C2H3 C3： ：
H1 C1H2 C2H3 C3： ：
DataData
M1GP 2013
ボトルネックの解消
5
Sender ReceiverDedupSource
DedupDest.
3G
Wi-Fi
3G基地局
Wi-Fiルータ
スマートフォン
PC
M1GP 2013
Network Dedupの問題点(1)
6
H1 C1H2 C2H3 C3： ：
H1 C1H2 C2H3 C3： ：
H1 C1H2 C2H3 C3： ：
H1 C1H2 C2H3 C3： ：
3G基地局 Wi-Fiルータ
WiMAX基地局
H1 C1H2 C2H3 C3： ：
H1 C1H2 C2H3 C3： ：
NICの数だけHashテーブルが必要端末のストレージを逼迫
M1GP 2013
H1 C1H2 C2H3 C3： ：
H1 C1H2 C2H3 C3： ：
Network Dedupの問題点(2)基地局間でのHashテーブルの共有が必要HO処理が複雑に
7
H1 C1H2 C2H3 C3： ：
？
3G基地局 3G基地局HO
M1GP 2013
Network Dedupの問題点(3)基地局に膨大な数のHashテーブルが必要過去の通信記録を活用できない
8
H1 C1H2 C2H3 C3： ：
H1 C1H2 C2H3 C3： ：
H1 C1H2 C2H3 C3： ：
H1 C1H2 C2H3 C3： ：
3G基地局
H1 C1H2 C2H3 C3： ：
H1 C1H2 C2H3 C3： ：
M1GP 2013
もくじ背景トラヒックの冗長性Network Deduplication
Asymmetric CachingCacheFeedback
評価実験
結論
9
M1GP 2013
H1 C1H2 C2H3 C3H4 C4H5 C5： ：
Asymmetric CachingSource Cache ⊆ Dest. CacheSource Cache：Regular Cache + FB Cache
トラヒックの傾向を随時Feedback過去の通信記録を活用
10
Sender ReceiverDedupSource
DedupDest.
HashH1 C1H2 C2： ：
DataData
Feedback
H1 C1H2 C2： ：
FB CacheRegular Cache
M1GP 2013
CacheSource CacheRegular Cache頻出パターン と Hash値 の組
FB CacheDest.からFBされた頻出パターン と Hash値 の組
Dest. Cache頻出パターン と Hash値 の組過去のトラヒックデータFlowlet 単位で保管• ※ 次ページ
11
M1GP 2013
Flowlet前後のPacketの類似性が低い所で区切った一塊
ファイルの境目などで切れるアプリケーションに依存しない数B～数百KB程度？
(ex) WebブラウザのトラヒックHTMLファイルCSSファイル画像ファイル ：
12
M1GP 2013
Feedback選択基準現在のトラヒックに最も似たFlowletを探すそのFlowletの中で、通信中の部分に相当する部分を推定し、(offset)だけ後ろのパケットをFBするoffsetは、Source - Dest. 間の遅延時間などで決める直近のFBとの重複チェックは行う
送信タイミングデータ受信時に随時（Reactive）
13
H1 H2 H3 H4 H5 H6 H7 H8 H9 H10 H11 H12
現在のトラヒック
最も似たFlowlet
H1 H21 H22 H3 H6 H7
Offset
FB
M1GP 2013
もくじ背景トラヒックの冗長性Network Deduplication
Asymmetric CachingCacheFeedback
評価実験
結論
14
M1GP 2013
評価実験(1)実験データ30ユーザスマホ：5人• 3G+Wi-Fi• Android 2.1 + T-mobile + tcpdumpラップトップ：25人• Wi-Fiのみ• Windows7/Linux + Wireshark
3ヶ月間26GB+のトラヒック
15
M1GP 2013
評価実験(2)各ユーザごとに評価実験データの半分：Dest. Cacheの学習残り半分：トラヒックと想定30コネクションをランダム抽出5KB以上のコネクションのみ
Cache容量Source Cache1MB+1MB（Regular + FB）
Dest. Cache250MB
16
M1GP 2013
評価(1)冗長部分の検出率平均89.7%（従来手法では39.3%）
17
M1GP 2013
評価(2)FB量とトラヒック削減量の比率平均6.74倍（1パケットのFBで、6.74パケットのトラヒックを削減）最大30倍
18
（冗長部分の割合）
M1GP 2013
評価(3)Cache容量と検出率Source Cache：2MB→0.4MB でも劣化せずDest. Cache ：250MB→150MB でも劣化せず
19
Source（Regular + FB）Cache Dest. Cache
M1GP 2013
評価(4)
20
CPU使用率 メモリ使用量
CPU使用率とメモリ使用量Nexus S（1GHz CPU・512MB RAM）Ubuntu OS（2GHz CPU・2GB RAM）
M1GP 2013
もくじ背景トラヒックの冗長性Network Deduplication
Asymmetric CachingCacheFeedback
評価実験
結論
21
M1GP 2013
結論Asymmetric Cachingで冗長部分の89.7%を検出従来手法では39.3%
FB量の6.74倍のトラヒックを削減最大で30倍
性能劣化しない最小のCache容量Source：0.2MB + 0.2MB（Regular + FB）Dest.：150MB→ 基地局側・スマホ側とも実装可能な水準
22