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

1. LOLCASTLayered Overlay Multicast Protocol階層構造を持つデータの配信に適したオーバーレイ・マルチキャストプロトコル 慶応義塾大学環境情報学部　小椋康平 <koh39@sfc.wide.ad.jp> 親　今泉英明 <hiddy@sfc.wide.ad.jp> サブ親　石原知洋 <sho@sfc.wide.ad.jp>

2. 本研究の概要 • インターネットを利用した個人による情報発信が盛んになった • 映像中継等の情報発信は困難 • 既存の配信技術は乏しい資源を持つ一般の利用者を対象不可能 • 新たなオーバーレイマルチキャスト技術(LOLCAST)を提案 • 階層構造を持つデータを用い受信者資源環境の抽象化 • 多くの受信者を対象可能 • 発信者・受信者は共に限られた資源内で多くの受信者に対しその環境に応じた配信が可能となり、問題を解決

3. 問題意識 • インターネット上で行われる創作活動 • 成果物の発信 • 共通の興味・目的を持った人々がグループを形成 • 様々な表現メディア • 文字・音声・映像 • 人々の表現の場としてのインターネット • リアルタイム性の高いコンテンツ配信を行う事が困難 • 実時間性ではなく中継等の用途

4. 既存配信技術の問題点 (1) • サーバクライアントモデル • 受信者数の帯域的な負荷が発信者に発生 • 多くの受信者を対象不可能 • IP Multicast • 様々な理由によりdeployされていない • IANAへのマルチキャストアドレス申請, ISP間のポリシの違い, 全ルータのマルチキャスト対応, etc.

5. 既存配信技術の問題点 (2) • Overlay Multicast (OLM) • IP Multicastの代替技術 • Deploy可能 • マルチキャストに関わる機能をアプリケーションレイヤへ • エンドホストのUnicast • OLMプロトコル • Narada, Overcast, Hostcast • 単一的なデータの配信 • 映像・音声等は品質を制御可能 • 複数品質でのサービス • 品質毎のマルチキャストツリー • 管理のオーバーヘッド • 帯域的な負荷の増加 • 提供できるサービスの品質が限定

6. 達成目標 • 発信者 • 一般利用者にとって現実的な資源で配信網を構築・管理可能 • 受信者の環境に合わせた複数品質での配信 • 受信者 • 資源環境による参加の制限を受けない • 環境に合わせた品質を選択可能

7. 本研究のアプローチ • 階層的な構造を持つデータの配信を行う新たなOLMプロトコル(LOLCAST)で解決 • 階層的な構造を持つデータ • 単一のデータを複数のレイヤに分割 • レイヤ数により品質制御可能 • ex.階層符号化, マルチチャンネル, 既存表現のコンポジット • マルチキャストツリーの構成 • 発信者が最高品質のデータを提供 • 各ノードは親と子の関係 • 親が子にデータを提供 • 発信者は単一の配信網の管理により受信者の資源環境に適応した複数品質での配信が可能

8. 要件 • 想定規模 • 数千人 • 個人レベルで運営される最大のコミュニティの大きさを想定 • 発信者、受信者の資源環境 • 多種多様であり一般利用者にとって現実的 • Ex. FTTH (100Mbps), ADSL (40Mbps), Dialup (56kbps) • 発信者は配信網を構築でき、運用コストも許容できる範囲 • 受信者は資源環境に左右されず参加可能 • 各ノードの保持品質の異なりへの対処 • 一つのメトリックに沿ったマルチキャストツリーの構築が不可能 • レイヤ数を考慮した上で参加や繋ぎ変えが必要

9. プロトコル設計概要 • マルチキャストツリーの構成 • 発信ノード(Source Node) • 全ノード情報・現在のツリー構造を管理 • 受信ノード(Recipient Node) • 最低限の情報を管理 • 親ノード・子ノードのノード情報 • Source Nodeからの要求に沿った処理を実行 • 処理の終了後に必ずSource Nodeにツリーの更新を伝達 • 参加の際にSource Nodeに参加先のノードリストを要求 • ノード間の情報のやり取り • メッセージパッシング

10. Source Node 1. 自身のノード情報 2. 現在のマルチキャストツリー構造 3. 全ノード情報を含む Recipient Node 1. 自身のノード情報 2. SourceNodeのノード情報 3. 親ノード情報 4. 子ノード情報のリスト ノード情報 1. ノード識別子 (Nodeid) 2. 所持／要求レイヤ数 3. 木の深さ 4. 対応するネットワーク層プロトコル 5. アドレスのリスト 各ノードの保持する情報 A Source Node 10 B 6 8 C Recipient Node 1 6 F G

11. PPL Extraction • PPL (Potential Parent List) の抽出 • 新規ノードが参加をする条件を満たす親ノードのリスト • マルチキャストツリーを規定 • ツリーの品質に大きく関わる処理 • 要求レイヤ数が処理に渡され条件を元にPPLを抽出 • 所持レイヤ数が要求レイヤ数を満たす • 管理子ノード数に空き • 現在処理中のノードではない (離脱処理中 etc.)

12. 6:JoinAccept +Nodeinfo of C 1:RendezvousRequest +Address capability E 4:PPLData +PPL C-B-D 3:PPLRequest +Layer of E 5:JoinRequest +Nodeinfo of E 2:RendezvousAccept +Nodeinfo of A + Nodeid of E 5 5 E E 8:Data 9:NotifyJoinComplete +Nodeinfo of E +Nodeinfo of C 7:DataStartRequest Join Procedure SourceNodeinfo: A ParentNodeinfo: - ChildNodeinfo: - Child Slot: 0/3 PPL: - SourceNodeinfo: - ParentNodeinfo: - ChildNodeinfo: - Child Slot: 0/3 PPL: - SourceNodeinfo: A ParentNodeinfo: - ChildNodeinfo: - Child Slot: 0/3 PPL: C-B-D SourceNodeinfo: A ParentNodeinfo: C ChildNodeinfo: - Child Slot: 0/3 PPL: B-D A 10 PPL Extraction Update tree B 8 6 C SourceNodeinfo - A ParentNodeinfo - A ChildNodeinfo D Child Slot 1/3 SourceNodeinfo - A ParentNodeinfo - A ChildNodeinfo D, E Child Slot 1/3 6 D

13. 4:DataStopRequest +Nodeinfo of D 5:LeaveCompleted +Nodeinfo of D 7:PruneRequest +Nodeinfo of C 1:NotifyLeaveProgress +Nodeinfo of C 9:NotifyLeaveComplete +Nodeinfo of C 6 8:PruneComplete D 6:NotifyParentChanged +Nodeinfo of D C 6 2:LeaveRequest +Nodeinfo of C 3:Data (Join Completed) 6 D Leave Procedure 子が他の親からデータを受け取ったことを確認してから離脱 -データの配信の停止を防ぐ A 10 B 8

14. 実装 • モジュールに分割されたシステム • LOLCASTのプロトコルによる評価、アプリケーションによる評価 • 単一のプロトコル処理部で行う • ４つのモジュールから構成 • プロトコル処理モジュール • アプリケーションモジュール • ネットワークモジュール • シミュレータモジュール Application LOLCAST API Protocol Administration Module Joint Network Simulator

15. 評価の目的 • 目標を達成できたか • 発信者 • 一般利用者にとって現実的な資源で配信網を構築・管理可能 • 受信者の環境に合わせた複数品質での配信 • 受信者 • 資源環境による参加の制限を受けない • 環境に合わせた品質を選択可能 • ノードの増加に伴うSource Nodeで発生する処理時間の増加

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

17. 定量評価 • ノードの増加に伴うSource Nodeにおける処理時間の増加 • シミュレータを用い計測 • シミュレータモジュールとアプリケーションモジュールを利用 • 計測対象 • Join Procedure • Source Nodeに対するインタラクションの総処理時間 • PPL Extraction • Join Procedureに含まれる • PPL生成の処理時間 • 計測環境 • 参加ノードの要求レイヤ数 • 固定レイヤ数 (Fixed layer) • 最悪なケースを想定 • PPL Extractionにおいて全ノードの含まれるテーブルを線形にサーチ • テーブルの上位から順に管理子ノードのスロットがうまり、最悪の場合となる • ランダムレイヤ数 (Random layer) • 10,000ノードを追加 • 1ノード追加毎に処理時間を計測

18. 1000ノード毎の平均処理時間 固定レイヤ数 (Fixed) Worst Case ランダムレイヤ数 (Random)

19. Average/10000Nodes/Fixed layer size

20. Average/10000Nodes/Random layer size

21. 評価結果 • 既存OLMとの比較 • 単一の配信網により複数の受信者環境に適応した配信 • 発信者の帯域的資源に対する負荷が減少 • 品質毎のデータが必要ない • 数千にを対象とした配信 • ランダムなレイヤ数 • 5000ノード 0.6msec • 10000ノード 1.4msec • 最悪なケース • 5000ノード 0.7msec • 10000ノード 1.7msec • 大幅な処理時間の増加は発生しない

22. まとめ • 階層的な構造を持つデータの配信を行うLOLCASTを提案 • 発信者 • 単一の配信網の構築・管理 • 受信者の資源環境に適応した配信可能 • 受信者 • 資源環境による配信網への参加が制限されない • 環境に合わせた品質を選択可能 • 既存OLMとの比較評価 • 発信者にかかる配信のためのコストを削減 • より多くの受信者を対象可能

23. 今後の課題 • PPL Extractionの性能改善 • Join Procedureにおける処理時間の大半を占める • 全ノードのテーブルより、レイヤ数を満たすノードを線形に検索・抽出した後に木の深さが最小となるノードを抽出 • O(n)の計算量 • 解決手法 • レイヤ数によるソート • キー(レイヤ数)に対し複数の値を持つテーブル • LOLCASTを利用したアプリケーションの提供

24. Join Procedure message passing

25. Leave Procedure message passing

26. メッセージフォーマット

27. 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 メッセージ群