To Do FECRACを評価するためのNS環境づくり。 SenderがFECwindowを下げた時のタイマーsetting

Maui (2010/11/01) 適応型 高品位リアルタイムストリーミング Kazuhisa D4

研究概要 高品位リアルタイムストリーミングの品質維持をサポートする手法の提案 品質適応型配信機構の構築 高品位リアルタイムストリーミング 高データ転送レート(数十～百Mbps) 高インタラクティブ性 (例：ビデオ会議, 遠隔医療) ストリーミング品質 1) データロス率 2) 実データ転送レート 品質適応型配信機構の構築 ネットワーク状態変動に対応し、ストリーミング品質を最大化

関連研究：適応型リアルタイムストリーミング TCP-Friendly Rate Control パケットロス率，RTT (Round trip time)を基に利用可能な帯域幅を決定 TCPと同じネットワーク帯域を消費する 決定された帯域幅を超えないように転送レートコントロールを行う パケットロスが発生しない場合は、転送レートを増加させて、パケットロス率を探る

問題意識 従来のLoss/Delay-based適応手法 1)パケットロスをネットワーク指標(輻輳発生)として用いる パケットロス発生による再生品質劣化が前提 2)パケットロス発生/Delayの変化に対し、容易に実データ転送レートを減少させる(パケットロスを出来るだけ発生させない仕組み) ネットワーク帯域利用効率が低くなる  実データ転送レートを最大化しない 要求されるデータレート データロス 　　 or 遅延の変化 ギャップ 転送レートコントロール

TFRC throughput vs. Delay and Ploss LAN US-EU US-ASIA US 1000 800 600 400 200 Throughput (Mb/s) 1000 800 600 400 200 0.01% 0.05% 0.1% 0.5% Throughput (Mb/s) Packet Loss 1 10 100 200 400

提案手法 AL-FECを利用した品質適応: Dynamic FEC AL-FEC (Application Layer Forward Error Correction) パケットレベルでの冗長化を行う FECレート:データに付加する冗長データの割合 Dynamic FEC 1) FECレートを調整し再生品質維持を試みながら，ネットワーク状態推測を行う 2) その推測に基づき、 “必要に応じて”実データ転送レートを調整(転送レートコントロール) Dynamic FEC 要求されるデータレート ギャップ

Dynamic FECに基づく品質適応

Design Goal FEC-based Rate Control (FECRAC) Real-time Video Application Issues High utilization of the link bandwidth  高データ転送レートを維持 Effective FEC rate control  データロスを最小化 High stability No severe fluctuations of both data and FEC rate. Cooperative control of consumption bandwidth Preserve fairness among multiple connections RTT-fairnessとは？？ The convergence rate depends on the network bandwidth and the round trip delay. Video Streaming BW Delay TCP flows ・・・ ・・・

Design Goal FEC-based Rate Control (FECRAC) パケットロスを最小化し、要求されるデータ転送レートを維持する 協調的な制御: 各FECRACフロー, TCPフロー ネットワーク状態に応じて、効率的なデータ転送レートコントロールを行える TCPフローの大きなパフォーマンス低下を引き起こさない RTT-fairnessとは？？ The convergence rate depends on the network bandwidth and the round trip delay. Video Streaming BW Delay TCP flows ・・・ ・・・

Design Goal FEC-based Congestion Control Concept: FECRACよりも，fairnessを更に意識している RTT fairness Responsivenessが遅いフロー(i.e. long RTT)の対応手法が問題になる Video Streaming BW Delay TCP flows ・・・ ・・・

提案手法の要件 どのように、またどのようなネットワーク状態(輻輳)指標を抽出・利用し、FECレート又は実データ転送レート変更していく必要があるのか 1) ネットワーク状態・指標の定義 転送制御に必要な決定要素 2) FEC/実データ転送レートコントロールの定義 増加/減少アルゴリズム 3) レート変更決定粒度の定義 フィードバックアルゴリズム 品質適応 (Dynamic FEC) 転送制御 ネットワーク状態推測 FECレートコントロール 転送レートコントロール

Requirement ああ Packet Sending strategy TCP詳細を参考に(Control Strategy) System requirement TCP詳細を参考に(Control Strategy)

ネットワーク指標 何をもって制御していくか？

転送制御 FEC/実データレート変更手法とアルゴリズム

転送制御パラメータ 輻輳指標 閾値FECレート: 前回輻輳が起きたポイント FECレート増加率: α(cfr, thfr, berr) ブロックエラー率P%以上発生 閾値FECレート: 前回輻輳が起きたポイント FECレート増加率: α(cfr, thfr, berr) FECレート減少率: β(cfr, berr) cfr: 現在のFECレート、thfr: 閾値FECレート, berrブロックエラー率に依存 (備考: next stepとして、RTTにも依存する) これによって、どんなメリットがあるか？ * 避けたいこと。 　極端に言うと、FECが効きにくいやつは、がんばるな！！邪魔になるだけ。協調しましょう。 High-data flow vs. Low data flow 　High-data flowは、block error rateが高くなりやすいので、慎重に無駄FECを減らす。 FECのbandwidthを考えると、同じコードレートでも、FECのbandowidthは、High-data-flowが高い。 　あまり、上げてほしくない。ブロックエラーレートが高くなる確率が高いので、High-data flowは上げにくくなる 2) Encoding Length 長い方が、block error率が低くなる。FECが効きやすい。これは、上げてもOK 逆に短いと、recoveryできない確率が高い無駄FEC

FEC window control FEC-WINDOW (FWND) MAX-FWNDまで変更可能 処理遅延と関係する FEC Encoding Block-baseのACKに応じて対応 Data packet Encoding Block Length (N) Repair packet ・・・・ FWND size (0<=FWND<=N) Block Error Rate congestion Non congestion ・・・・ ・・・・

Parameter Settings Scenario/Network FECRAC P: 1)0.01, 2)0.05, 3)0.1 AIAD (additive Increase and Adaptive Decrease)

FEC-based Rate Control Application policy network client Rate Control Media source ・Packet loss rate ・Block Error Rate Dynamic FEC Congestion control

検証シナリオ Network load Video_num : TCP_num = X:Y Low, middle, high Video_num : TCP_num = X:Y Video_num = 1 or 15 or 30 Video: TFRC, Static FEC, Dynamic FEC シミュレーションのシナリオ どうなって欲しいのか？何を期待してやるのか？何を見たいのか? 全体：FECの効果(リカバリ), stability, TCPとの帯域的な関係 FECRACのパラメータが上記とどのように関係してくるか？ Threshold_P, decrease/increase algorithm To identify the impact of FEC consumption bandwidth (RAP) To identify FEC effectiveness of recovering packet loss To identify FECRAC stability

Simulation Parameters パラメータ 値 最大データ転送レート(Mbps) 30(High), 10(Middle), 1(Low) パケットサイズ (bytes) 1460 キュー長:K 10 リンク帯域幅:u (Mbps) 1000 RTT (sec) 0.1 シミュレーション時間 60sec ブロック長 127 ・・・ Video Streaming TCP flows BW Delay

FECRAC: overall average data rate and loss rate (TRACE) Data rate/loss rate P=0.01 P=0.05 P=0.1 Time

FECRAC vs flow-number いるかなー？ Data rate/loss rate P=0.01 P=0.05 P=0.1

FECRAC: Fairness index with TCP aaa Fairness index TFRC P=0.01 P=0.05 P=0.1 TCP number

Chapter Introduction Rate Control Mechanism FEC-based Rate Control Related Work Problem Definition FEC-based Rate Control Definition FEC Codes/Rate Control Design Goals (CBR-TFRCの真似) FECRAC components to be considered Consideration FEC impact Analysis The Model FECRAC parameters Setting FECRAC parameters (giving justification) Evaluation To evaluate our method Conclusion and Future Work 何を残して、何でICNPを勝負するか？ RAPを参考にしてみるとよいのかな？ この部分をMAUIで相談

アルゴリズム・パラメータの記述 正当性・妥当性を強調したいが、 Ad hoc的な要素がある 許容ブロックエラー率，Decrease/increase ratio モデルで述べることが可能なのは、提案するアルゴリズムが一番妥当であるということ simulationでもOKでしたという流れ

今年度のスケジュール

以上です

分析モデル 有限キュー長をもつシングルボトルネック (M/M/1/K) (1) TFRC及びFECの特性検証 ネットワーク負荷 = λ_tot / u (1) TFRC及びFECの特性検証 FECレート/データ転送レートコントロール方式の検討 (2) 過渡特性解析 どのように安定させるか？(Feedback遅延の影響) (3): 総合的な解析・デザイン・評価 コンポーネントは４つ

ロスモデル FECが有効であるか否かは，ロスプロセスが根本的な要素(TFRCにとっても同様) 一般的なブロックエラー率の算出 再帰計算を利用 ブロックエラー率: Sequenceが連続しているN個のパケットがどれくらいおちるのか？ バースティ(連続的な)ロスが起きるのか、否か？ 一般的なブロックエラー率の算出 最大キュー長になる状態確率を利用 ロスプロセスは独立と見なしている 再帰計算を利用 [Cidon+ 1993] 一つ前のキュー長を考慮 TFRCも インターリーバは、ロス耐性をあげるだけ。アルゴリズム的には変わらない。

再帰計算の概要 定常状態でのX_nの確率分布π K π=π・P X_n Nth packet 状態遷移行列 i packets K X_n+1 (N+1)th packet α(t) = λe-(λ・t) ブロックエラー率P(j,n)を確率分布π、状態遷移行列、及び初期条件を利用して、再帰的に求める 初期条件 1)キューイング？or 2)ドロップ？ i j 個のロス ・・・・ ・・・・・・・ n・・・・・・・・・・・・・・・・・・・・3 2 1

分析モデル Single Bottleneck link with finite queue length (M/M/1/K) (1) TFRC及びFECの特性検証 FECレート/データ転送レートコントロール方式の検討 (2) 過渡特性解析 どのように安定させるか？(Feedback 遅延の影響) (3): 総合的な検証・評価 1) 到着仮定、2)K、FIFOのリンク、3)サービス率u, 4)feedback every rtt

TFRC vs. AL-FEC u データ転送レートとネットワーク負荷に起因するロスプロセスがどのように影響するか？ ソースの最大データ転送レートは同一 全体のトラフィック(λ_tot)に対するストリーミングフローの合計トラフィック(最大転送レート時)の割合は一定 初期ネットワーク負荷(λ_tot/u)に応じたパフォーマンスを見る ストリーミングが使える帯域が一定であったとして、データレートに関する特徴を意味づけたかった。 高品位なストリーミングが増え来た場合の制御を考えたとき、 従来の制御では、問題となるから、新しい手法が必要。 最大転送レートX(Mbps)のビデオストリームN本 λ_tot ・・ Background Traffic u

TFRC vs. AL-FEC パフォーマンス指標 Video rate index (<= 1.0) 最高データ転送レートに対する現在のデータ転送レートの割合 Data loss rate (<= 1.0) ブロック長当たりのデータロス率 (After FEC decoding) FEC utility (<= 1.0) (利用可能なデータパケット + 復元されたパケット) / ブロック長 パラメータ 値 最大データ転送レート(Mbps) 30(High), 10(Middle), 1(Low) パケットサイズ (bytes) 1460 最大キュー長:K 10 リンク帯域幅:u (Mbps) 1000 RTT (sec) 0.1 ストリーミングの帯域率 0.2 ブロック長 127

TFRC High-data flow 比較的ネットワークロードが高くない状態でも、 Video Rate Indexが低下してしまう☹ ネットワークリソースを有効活用しない データロスを低く抑える☺ High-data-flowは、ロスのインパクトを大きく受け、比較的ネットワークロードが低い状態でも、 Video Rate Indexが下がってしまい、ネットワーク利用率が悪くなることを示している。 データロスに関しては、レートコントロールを行うので、ネットワーク負荷が高くなるにつれ、 データロスの影響を受けにくなる。

Adaptive FEC FECレートのみを変更 High-data flow 最も一般的な方式: Code Rate = 1.0 – (average Loss Rate) NO-FECにくらべ、FECが有効に効いているが、High-data flowは初期ネットワークロードが高くになるにつれ、 FEC-utiltiyの推移をみて分かるように、データロスレートが、low-data-flowに比べて高くなっていく. High-data-flowのFECは無駄になりやすいことをしめしている。 結果だけを言い、次で見解を示す。 High-data flow 初期ネットワーク負荷が増加するにつれ、データロスが発生しやすくなる☹ (low-data flowはFEC utilityが高い☺) 無駄な冗長パケットが発生しやすい

CDF of Block Error rate ネットワーク負荷0.8 ネットワーク負荷0.9 ネットワーク負荷1.0 (FECの効き方は、ロスのプロセスに依存する。) 1)ロスプロセスは、ネットワーク負荷、データレート(バースティネスともいえる)に依存し、フロー毎ごとに 効き方が変わる。CDFのグラフは、データレートとネットワーク負荷でのロスプロセスの差異を示している。 2)ブロックエラーレートは、ネットワーク負荷が同じでもデータレートによってことなり、負荷が高い場合は、顕著に FECの効き方に現れる。 3)様々なdata-flowが競合し、ネットワーク負荷がダイナミックに変わる状態を普通に考えた時、 FECの効き方はさらに複雑になり、賢くFECレートを変更していく必要がある