document

Internet Indirection Infrastructure
Ion Stoica et. al. SIGCOMM 2002
Presented by sada
2005/4/18
アウトライン

背景とi3の基本アイディア

i3で出来ること

i3の細かい設計、および性能の問題

評価とまとめ
背景とi3の基本アイディア
背景

現在のインターネット




End-to-endの通信
固定されたIPアドレスの通信
Multicast, Anycast, Mobility, Service Composition
などを行う場合、個別に対応する必要がある
最近の動向


Peer-to-peer, Overlay networks , DHT等が登場
これらを利用して上記の問題を解決する機構が提案
されている
“One Ring to rule them all”
Multicast
Anycast
Mobility
Service
Composition
An indirection layer based on overlay network
decoupling sending and receiving
DHT
IP Layer
上記の4つを同時に実現する通信基盤があると便利
i3の基本アイディア

i3のインフラストラクチャ


エンドホストの参加方法


i3のサーバがDHTネットワークを形成
受信者はトリガー(id, IP address)を挿入する→送信者が利用
実際の通信


送信者はパケット(id, data) 送信
トリガーを参照、宛先ノードにdata渡す
send(R, data)
send(ID, data)
Sender
trigger
ID
R
DHT network
Receiver (R)
サービスモデル

API






sendPacket(p);
insertTrigger(t);
removeTrigger(t); // オプション
トリガーはソフトステート
IPのようなベストエフォート型
データ到達保証、輻輳制御、フローコントロール
はエンドノードで行う
i3で出来ること
モビリティ
Sender
id R2
R1
Receiver
(R1)
Receiver
(R2)
受信者のIPアドレスが変更になったらトリガーを更新するだけ
•送信者は今まで通りでよい
マルチキャスト

マルチキャスト

最もシンプルな方法: 全ての受信者が同じIDのトリ
ガーを挿入→送信者がそのID宛てに送信
大規模マルチキャスト

ツリー構造のマルチキャストを形成可能

トリガーのデータ部分に他のトリガーのIDを入れる
(g, data)
g
x
x
R3
R3
g g
R1 R2
R2
x
R4
R1
R4
拡張点

エニキャスト


IDのスタック


IDの初めk-bitsがマッチしたノードの1つにパケット送
信
サービスの合成
パブリックトリガー、プライベートトリガー

セキュリティ
エニキャスト

IDの初めk-bitsがマッチしたノードの1つにパケッ
ト送信


負荷分散、サーバの選択
なるべく近いサーバにアクセスできるようにする


サーバのIDには、ネットワーク上の位置のヒントをいれる
（郵便番号のような）
しかし具体的にどうやるかは書いていない。。。
IDのスタック

一種のソースルーティング



(id1, id2, id3)というIDのパケットを送った場合、id1,
id2, id3経由で届く
途中でエンドホストに届いてしまったら、アプリケー
ションに任せる
サービスの合成に利用可能
サービスの合成

例（MPEG→JPEG)


送信者主体の場合: (id_mpeg/jpeg, ID) というIDのパケット
を送る→受信者は気にしなくて良い
受信者主体の場合： (ID, (id_mpeg/jpeg,R) ) というトリガー
を挿入しておく→送信者は気にしなくて良い
S_MPEG/JPEG
send((ID_MPEG/JPEG,ID), data)
Sender
(MPEG)
send(R, data)
send(ID, data)
ID_MPEG/JPEG S_MPEG/JPEG
ID
R
Receiver R
(JPEG)
i3の細かい設計、および性能の問題
i3インフラに必要な事柄

耐故障性
規模性
効率性
普及
セキュリティ

DHTとしてChordを採用






著者がIon Stoicaなので。。。
CAN, Tapestry, Pastryでも可能
耐故障性

ルーティング


DHT任せ
トリガーの喪失対策


エンドホストが定期的にトリガーを更新する
バックアップトリガーを挿入する


(id_backup, R) + trigger stack(id, id_backup)
DHTで冗長化する
規模性

スケーラビリティ



優れている
トリガーが増えたらi3サーバを追加するだけでOK
負荷集中点の排除

あるトリガーにアクセスが集中したら、そのトリガーを
他のi3サーバにも持たせる
（ルーティングの）効率性

遅延（主にDHTネットワークで発生）


エンドホストが特定のIDに送信したら、そのトリガーを
持つサーバを覚えておく（キャッシュする）
三角問題の発生



送信者・受信者がSFCなのに、i3サーバはロンドン等
受信者は予め、自分宛のダミーパケットを送って近い
i3サーバを探しておく
そのi3サーバにトリガーが置かれるようなIDにする
普及

Incremental deployment


可能
プロキシの導入


既存のUDPを用いるソフトをi3インフラで動作可能
TCPも可能（他の論文で言及）
セキュリティ

盗聴



サーバのIDがid1の場合、攻撃者Aが(id1,A)というトリガーを挿入する
プライベートトリガー導入で解決
Dosアタックの可能性

エンドホストに対する攻撃


マルチキャストの宛先が、実は全て1ノード
インフラに対する攻撃

トリガーでループを作成→パケットが永遠に回り、インフラに影響


匿名性



特殊なパケットを投げて、ループを検知
IPアドレスはエンドホストには分からない
IPレベルでのフラッディング攻撃は起きない
フラッディング攻撃


ID空間が非常に広大なので、攻撃しにくい
万が一標的になったら、トリガーを一時的に削除
評価とまとめ
End-to-End の遅延


16384台のi3サーバのがある場合
i3サーバのトポロジ




Power law random graph
Transit-stub
X軸 1エンドホストあたりのID数
Y軸 IPによる直接通信の遅延が1とした場合、i3上での遅延
パフォーマンス

遅延は最初のパケットによるものが
大きい


キャッシュが効かないため
方法
 普通のChord
 Closest finger replica


Closest finger set


use r successors of each
finger for routing
choose closest log(N)/log(2)
fingers out of log(N)/log(b)
(b<2) fingers
マシンあたりの性能


2.4 x 10^6 のトリガーを扱える
1KBのパケット


25 micro-secsの遅延
200 Mbps のスループット
まとめ

I3の目的



I3の概要


オーバレイネットワークによる通信インフラ
Multicast, Anycast, Mobility, Service Composition
をこれ一つで解決
IDを指定した通信
感想



アイディアは面白いけど、普及しないのでは。。。
セキュリティの問題は、探せばもっとありそう
70点

Download Report