LOLCASTLayered Overlay Multicast Protocol

階層構造を持つデータの配信に適したオーバーレイ・マルチキャストプロトコル

慶応義塾大学環境情報学部　小椋康平<koh39@sfc.wide.ad.jp>

親　今泉英明 <hiddy@sfc.wide.ad.jp>サブ親　石原知洋 <sho@sfc.wide.ad.jp>

本研究の概要

• インターネットを利用した個人による情報発信が盛んになった

• 映像中継等の情報発信は困難– 既存の配信技術は乏しい資源を持つ一般の利用者を対象不可能

• 新たなオーバーレイマルチキャスト技術 (LOLCAST) を提案– 階層構造を持つデータを用い受信者資源環境の抽象化

• 多くの受信者を対象可能– 発信者・受信者は共に限られた資源内で多くの受信者に対しその環境

に応じた配信が可能となり、問題を解決

問題意識

• インターネット上で行われる創作活動– 成果物の発信– 共通の興味・目的を持った人々がグループを形成– 様々な表現メディア

• 文字・音声・映像– 人々の表現の場としてのインターネット

• リアルタイム性の高いコンテンツ配信を行う事が困難– 実時間性ではなく中継等の用途

既存配信技術の問題点 (1)

• サーバクライアントモデル– 受信者数の帯域的な負荷が発信者に発生– 多くの受信者を対象不可能

• IP Multicast– 様々な理由により deploy されていない– IANA へのマルチキャストアドレス申請 , ISP 間のポリシの違

い , 全ルータのマルチキャスト対応 , etc.

既存配信技術の問題点 (2)

• Overlay Multicast (OLM)– IP Multicast の代替技術

• Deploy 可能• マルチキャストに関わる機能をアプ

リケーションレイヤへ• エンドホストの Unicast• OLM プロトコル

– Narada, Overcast, Hostcast

– 単一的なデータの配信• 映像・音声等は品質を制御可能• 複数品質でのサービス

– 品質毎のマルチキャストツリー• 管理のオーバーヘッド• 帯域的な負荷の増加• 提供できるサービスの品質が限定

達成目標

• 発信者– 一般利用者にとって現実的な資源で配信網を構築・管理可能– 受信者の環境に合わせた複数品質での配信

• 受信者– 資源環境による参加の制限を受けない– 環境に合わせた品質を選択可能

本研究のアプローチ

• 階層的な構造を持つデータの配信を行う新たな OLM プロトコル (LOLCAST)で解決

• 階層的な構造を持つデータ– 単一のデータを複数のレイヤに分割– レイヤ数により品質制御可能

• ex. 階層符号化 , マルチチャンネル , 既存表現のコンポジット

• マルチキャストツリーの構成– 発信者が最高品質のデータを提供– 各ノードは親と子の関係– 親が子にデータを提供

• 発信者は単一の配信網の管理により受信者の資源環境に適応した複数品質での配信が可能

要件

• 想定規模– 数千人– 個人レベルで運営される最大のコミュニティの大きさを想定

• 発信者、受信者の資源環境• 多種多様であり一般利用者にとって現実的

– Ex. FTTH (100Mbps), ADSL (40Mbps), Dialup (56kbps)

• 発信者は配信網を構築でき、運用コストも許容できる範囲• 受信者は資源環境に左右されず参加可能

• 各ノードの保持品質の異なりへの対処– 一つのメトリックに沿ったマルチキャストツリーの構築が不可能– レイヤ数を考慮した上で参加や繋ぎ変えが必要

プロトコル設計概要

• マルチキャストツリーの構成– 発信ノード (Source Node)

• 全ノード情報・現在のツリー構造を管理– 受信ノード (Recipient Node)

• 最低限の情報を管理• 親ノード・子ノードのノード情報• Source Nodeからの要求に沿った処理を実行• 処理の終了後に必ず Source Node にツリーの更新を伝達• 参加の際に Source Node に参加先のノードリストを要求

• ノード間の情報のやり取り– メッセージパッシング

各ノードの保持する情報

10

86

A

B C

1

F

6

G

Sou

rce

Nod

eR

ecip

ien

t N

od

e

1. ノード識別子 (Nodeid)2. 所持／要求レイヤ数3. 木の深さ4. 対応するネットワーク層プロトコ

ル5. アドレスのリスト

ノード情報

1. 自身のノード情報2. 現在のマルチキャストツリー構造3. 全ノード情報を含む

Source Node

1. 自身のノード情報2. SourceNode のノード情報3. 親ノード情報4. 子ノード情報のリスト

Recipient Node

PPL Extraction

• PPL (Potential Parent List) の抽出– 新規ノードが参加をする条件を満たす親ノードのリスト

• マルチキャストツリーを規定– ツリーの品質に大きく関わる処理

• 要求レイヤ数が処理に渡され条件を元に PPL を抽出– 所持レイヤ数が要求レイヤ数を満たす– 管理子ノード数に空き– 現在処理中のノードではない (離脱処理中 etc.)

Join Procedure

10

68

A

B C

6

D

1:RendezvousRequest 　 +Address capability E

2:RendezvousAccept 　 +Nodeinfo of A + Nodeid of E

5

E

5

E

3:PPLRequest　 +Layer of E

4:PPLData　 +PPL C-B-D

5:JoinRequest　 +Nodeinfo of E

6:JoinAccept　 +Nodeinfo of C

9:NotifyJoinComplete　 +Nodeinfo of E +Nodeinfo of C

7:DataStartRequest

8:Data

PPL Extraction

SourceNodeinfo: -ParentNodeinfo: -ChildNodeinfo: -Child Slot: 0/3PPL: -

SourceNodeinfo: AParentNodeinfo: -ChildNodeinfo: -Child Slot: 0/3PPL: -

SourceNodeinfo: AParentNodeinfo: - ChildNodeinfo: - Child Slot: 0/3PPL: C-B-D

SourceNodeinfo: AParentNodeinfo: CChildNodeinfo: - Child Slot: 0/3PPL: B-D

SourceNodeinfo - AParentNodeinfo - AChildNodeinfo DChild Slot 1/3

Update tree

SourceNodeinfo - AParentNodeinfo - AChildNodeinfo D, EChild Slot 1/3

10

8

A

B 6C

6

D

子が他の親からデータを受け取ったことを確認してから離脱-データの配信の停止を防ぐ

1:NotifyLeaveProgress　 +Nodeinfo of C

2:LeaveRequest　 +Nodeinfo of C

6

D

3:Data(Join Completed)

5:LeaveCompleted +Nodeinfo of D

4:DataStopRequest +Nodeinfo of D

6:NotifyParentChanged +Nodeinfo of D

7:PruneRequest　 +Nodeinfo of C8:PruneComplete

9:NotifyLeaveComplete +Nodeinfo of C

Leave Procedure

実装

• モジュールに分割されたシステム– LOLCAST のプロトコルによる評価、

アプリケーションによる評価– 単一のプロトコル処理部で行う

• ４つのモジュールから構成– プロトコル処理モジュール– アプリケーションモジュール– ネットワークモジュール– シミュレータモジュール

Protocol Administration

Module Joint

SimulatorNetwork

LOLCAST API

Application

評価の目的

• 目標を達成できたか– 発信者

• 一般利用者にとって現実的な資源で配信網を構築・管理可能• 受信者の環境に合わせた複数品質での配信

– 受信者• 資源環境による参加の制限を受けない• 環境に合わせた品質を選択可能

• ノードの増加に伴う Source Node で発生する処理時間の増加

定性評価

• 単一なデータの配信により複数の品質を提供• 複数品質提供に伴うマルチキャストツリーの管理コストが減少• 予期しないノードの離脱への対処手法を提供

評価項目 /配信技術 LOLCAST 既存 OLM

提供可能な品質 複数の品質 単一な品質

複数品質提供による配信網の維持コスト

単一なマルチキャストツリー

品質毎のマルチキャストツリー

予期しない離脱への対処データパスの冗長化 ,

輻輳回避配信パスの冗長化 (Host Cast)再度 JoinProcedure(ALMI)

定量評価

• ノードの増加に伴う Source Node における処理時間の増加– シミュレータを用い計測

• シミュレータモジュールとアプリケーションモジュールを利用

• 計測対象– Join Procedure

• Source Node に対するインタラクションの総処理時間– PPL Extraction

• Join Procedure に含まれる• PPL 生成の処理時間

• 計測環境– 参加ノードの要求レイヤ数

• 固定レイヤ数 (Fixed layer)– 最悪なケースを想定– PPL Extraction において全ノードの含まれるテーブルを線形にサーチ– テーブルの上位から順に管理子ノードのスロットがうまり、最悪の場合となる

• ランダムレイヤ数 (Random layer)– 10,000ノードを追加

• 1ノード追加毎に処理時間を計測

1000ノード毎の平均処理時間

ノード数Join

Procedure (μsec)

PPLExtraction

(μsec.)

1000 75 39

2000 174 134

3000 355 311

4000 527 480

5000 692 643

6000 860 809

7000 1032 980

8000 1234 1180

9000 1468 1411

10000 1714 1654

ノード数Join

Procedure (μsec)

PPLExtraction

(μsec.)

1000 73 37

2000 146 108

3000 304 262

4000 475 430

5000 618 573

6000 770 722

7000 920 870

8000 1078 1026

9000 1254 1200

10000 1443 1386

固定レイヤ数 (Fixed)Worst Case

ランダムレイヤ数 (Random)

Average/10000Nodes/Fixed layer size

Average/10000Nodes/Random layer size

評価結果

• 既存 OLM との比較– 単一の配信網により複数の受信者環境に適応した配信– 発信者の帯域的資源に対する負荷が減少

• 品質毎のデータが必要ない

• 数千にを対象とした配信– ランダムなレイヤ数

• 5000 ノード 0.6msec• 10000 ノード 1.4msec

– 最悪なケース• 5000 ノード 0.7msec• 10000 ノード 1.7msec

– 大幅な処理時間の増加は発生しない

まとめ

• 階層的な構造を持つデータの配信を行う LOLCAST を提案– 発信者

• 単一の配信網の構築・管理– 受信者の資源環境に適応した配信可能

– 受信者• 資源環境による配信網への参加が制限されない• 環境に合わせた品質を選択可能

– 既存 OLM との比較評価• 発信者にかかる配信のためのコストを削減• より多くの受信者を対象可能

今後の課題

• PPL Extraction の性能改善– Join Procedure における処理時間の大半を占める

• 全ノードのテーブルより、レイヤ数を満たすノードを線形に検索・抽出した後に木の深さが最小となるノードを抽出

• O(n) の計算量• 解決手法

– レイヤ数によるソート– キー ( レイヤ数 ) に対し複数の値を持つテーブル

• LOLCAST を利用したアプリケーションの提供

Join Procedure message passing

Leave Procedure message passing

メッセージフォーマット

メッセージ群

• Rendezvous Message– Request– Accept– Reject

• PPL Message– Request– Data

• Join Message– Request– Accept– Reject

• Data Message– Start Request– Stop Request

• Leave Message– Request– Complete

• Prune Message– Request– Complete

• Notify Message– Join Complete– Parent Changed– Leave Progress– Leave Complete