この論文では,固有のビットレートを持つ複数のビデオストリームを,それぞれの視聴者グループに向けて個別に配信する問題について取り扱っています.
基本アイデアは,一連の論文と同様,与えられたビデオストリームを複数のサブストリーム(ストライプ)に分けて配信することなのですが,この論文では特に,動画品質の(質的な)違いをストライプ数の(量的な)違いに転嫁することでストリーム間の負荷分散も図っています(将来的にはこれを何らかのインセンティブメカニズムと結び付けたい).各ストライプは高さの制限された「コアツリー」と呼ばれる均一なオーバーレイを使って配信されます.コアツリーのルート(root)にはメディアサーバから直接ストライプが送られ,ルートに送られたストライプは,高々ツリーの高さ分の転送を繰り返して葉ノードに到達します(ホップ数を制限することでレイテンシの増加を抑えています).ツリーの次数は,各ピアのアップロード容量から決まる値です(論文では説明をわかりやすくするため容量を均一と仮定しています).各視聴者は自分が視聴するビデオストリームから生成されたストライプを配信するコアツリーに(視聴者・転送者として)参加すると同時に,もし容量に余力があれば,他のストリームに関するコアツリーにもヘルパーとして参加することができます.
この論文の一つの売りは,ピアの参加や離脱に伴うオーバーレイの更新処理が綺麗な形で与えられているという点です.新規ピアが参加するコアツリー群の選択は,リクエストを最初に受け取るメディアサーバによって集中的にコントロールされる必要がありますが,そのあとのオーバーレイの更新手続きは,各コアツリーに最近参加したピアのみによって分散的に実行することができます(理論的な深さはないけれども,それなりに実用的だと思う.その具体的な手続きを思いついたときに「これを論文にしよう」と思いました).
ただしこの方法には弱点もあって,ピアの参加・離脱が頻繁に起こる状況では更新のオーバーヘッドのため性能が大きく低下する恐れがあります.しかしそのような(動向の確定していない)不安定なピアにはメディアサーバから直接配信してもらうことにし,一定時間以上滞在したものから順にコアツリーに移していくようにすれば,なんとかなるような気がしています(極端な状況では,J19bのようなフラッシュクラウドの話との組み合わせになると思う).