Transcript D-camp 2009s Adaptive High-performance Real

Adaptive High-performance
Real-time applications
慶応義塾大学 政策メディア・研究科
kazuhisa
Motivation
• リアルタイムストリーミングの一般化普及
– e-learning, international symposium, telemedicine.
– “Mission-critical flow”: (1)インタラクティブ性、(2)パ
フォーマンス(映像・音声の品質)が求められる
• Best quality VS. Traffic Congestion
– パケットロスによる品質劣化が発生
• “安定”かつ”最良品質”のストリーミングをEnd-to-Endモ
デルで実現
– 各フローがネットワーク状態に応じて最良品質を維持しながら
packet lossを最小化
2
Challenges
• (1)Rate Control : 自身のパフォーマンスのみを考慮
– (Best quality) VS. (packet loss, and rate oscillation)
• Best data transmission rate を維持する
– 最良品質
• packet loss, rate oscillationを防ぐ
– “Aggressive Rate Control”が上記を満たす上で必要
• (2)Congestion control: ストリーミングフロー全体のパフォーマンス
を考慮
– (Aggressive Rate Control) VS. (Nervous Rate Control)
• Scalability: 全体のパフォーマンスを可能な限り向上させる
• Fairness
– Mission-critical なストリーミングフローに着目
• “(1) and (2)”を実現するにはどうするか？
– Error control (FEC)の使い方が肝
3
Related Work
(Adaptive end-to-end Streaming)
• (2) Congestion Control
– RAP (INFOCOMM `99)
– TCP Friendly Rate Control (SIGCOMM`2000, INFOCOM`2001)
– DCCP(SIGCOMM`06): アプリケーションが輻輳制御メカニズムを選択可能
(i.e. TCP-like and TFRC)
– DVRC (IEEE ICC`07) UDP + Congestion Control
• (2) Congestion Control + (2) Error Control
–
Adaptive FEC (INFOCOM’ 99): TFRC、audio application
– QAFEC (NOSSDAV’05): TFRC、MPEG
– TCP-AFEC (PV’ 07): TCP-like、VoD
• TCP-friendlyなアプローチがほとんど
– パケットロスが起きるとすぐに品質を下げる(defferential)
– Mission-critical streamingに向かない
Network Estimation
• TCPに帯域を合わせてしまう
Network Controller
End-Node controller
Quality Adaptation
4
Aggressive Rate Control
• (1)Rate Control mechanism
– (Best quality) VS. (packet loss, and rate oscillation)
• アプローチ: Dynamic FECを品質維持とネットワーク
状態把握に利用
Application policy
Media source
Rate Control
Dynamic FEC Congestion
control
network
client
・Packet loss rate
・The number of consecutive loss packets
・FEC recovery rate
5
Aggressive Rate Control:
Rate Control with DynamicFEC
1. Decision Function
– ロスパターン (Packet loss rate, consecutive lost packets)
– FEC recovery rate (ネットワーク状態指標としては使っていない)
2. Increase/decrease algorithm
– 固定アルゴリズム(省略)
– データ転送レートとFECレートを調整
– 1. FECでリカバーできるか？
• できなさそうならdata transmission rateを下げる
– 2. data transmission rateを上げられるか？
• FEC rate を増加させて、ロスパターンを見る
3. Decision Frequency
–
５秒間
• じっくりロスパターンを見ないと、FECの調整が難しい
6
Aggressive Rate Controlの問題点
• FECによる冗長化が結果的に各パフォーマン
スを低下させる
– パケットロスをFECでリカバーできない
– データ転送レートの振動が起きる
• (3) Congestion Controlが必要
– 柔軟にFECの有効性を判断する必要性がある
7
FECRAC
(FEC-based Rate Control Scheme)
• (2)Congestion control
– Aggressive Rate Control VS. Nervous Rate Control
• アプローチ：FEC recovery rateを利用し、FECの有効性を予測
– FEC recovery rate: FECがどれくらい効いているかを示す
– “FEC効率”: FECレートを上げた時のFEC recover y rate の増加率
• 最終的にはCongestion controlの指標にしたい
Application policy
Media source
Rate Control
Dynamic FEC Congestion
control
network
client
・FEC recovery rate
8
FECRAC
1. Decision Function
– FEC効率予測値
•
FECレートX%時(FEC効率閾値)におけるFEC recovery rateの
予測値
2. Increase/decrease algorithm (sender based)
1. FECレート:5%単位で変更
2. 映像データ転送レート(“Scale value”): 1単位で変更
柔軟にFECの有効性を判断・推測
する必要性がある!!
3. Decision Frequency
–
Data loss (loss rate閾値)が起きた時
•
Receiverがfeedbackする
9
FEC recovery rate in various network
congestions (Good Case)
10
FEC recovery rate in various network
congestions (Bad Case)
11
•
FEC recovery rate
結果：
– FEC recovery rateはおおよそ線形的に増加する (増加率は輻輳状態に
よって様々)
– 増加率によってthreshold FEC rate (X%)におけるFEC recovery rate
(100%)を推測
– 以下を判断
• 1) FEC rateを上げる
• 2) data rate を下げる
• 仮説：
– Threshold Xは以下に依存
• Application
– Data transmission rate
(low or high)
• Network
– RTT,Bottleneck link bandwidth
– Threshold Xをadaptiveに変えると, 目指すべきcongestion control ができ
るのではないか？(そうなって欲しい)
• Xが大きい (aggressive)
• Xが小さい (nervous)
12
Future work
• FECRACの改良
• 現状：以下のパラメータは固定
• Application (data transmission rate)
• Network (RTT, bottleneck link
bandwidth)
• Simulation
• 様々な環境で検証
• 分析
• threshold Xについての検証
• Consecutive lost packets (N)とFEC
recovery rateの関係を利用できるか？
• 実装・実ネットワークでの評価
Video format
Bandwidth
HDTV
compression
20Mbps
DV, HDV
30Mbps
TV, PCM coding
140Mbps
HDTV lossless
compression
500Mbps
Raw HD
1Gbps
QHD
5Gbps
14
Problems of aggressive rate control:
30 flows compete on 1G network (1/2)
15
Problems of aggressive rate control:
30 flows compete on 1G network (2/2)
16
Problems of aggressive rate control:
35 flows compete on 1G network (1/2)
17
Problems of aggressive rate control:
35 flows compete on 1G network (2/2)
18
Problems of aggressive rate control
•
FECによる冗長化が結果的に各パフォーマンスを低下させる
–
–
Packet lossをより引き起こす (FECでリカバーできない)
Rate oscillationによる品質の低下
2. Increase/decrease algorithm
– 固定アルゴリズム(省略)
– Data rateとFECrateを調整
– 1. FECでリカバーできるか？
• できなさそうならdata transmission rateを下げる
– 2. data rateを上げられるか？
• FECをバリバリ増加させて、ロスパターンを見る
3. Decision Frequency
–
５秒間
柔軟にFECの有効性を判断・推測
する必要性がある!!
• じっくりロスパターンを見ないと、FECの調整が難しい
19
FEC recovery rate in various network
congestions (Good Case)
20
FEC recovery rate in various network
congestions (Bad Case)
21
•
FEC recovery rate
結果：
– FEC recovery rateはおおよそ線形的に増加する (増加率は輻輳状態に
よって様々)
– 増加率によってthreshold FEC rate (X%)におけるFEC recovery rate
(100%)を推測
– 以下を判断
• 1) FEC rateを上げる
• 2) data rate を下げる
• 仮説：
– Threshold Xは以下に依存
• Application
– Data transmission rate
(low or high)
• Network
– RTT,Bottleneck link bandwidth
– Threshold Xをadaptiveに変えると, 目指すべきcongestion control ができ
るのではないか？(そうなって欲しい)
• Xが大きい (aggressive)
• Xが小さい (nervous)
22
FEC recovery rate in various network
congestions (Bad Case)
Estimated Frec
threshold
23
Sender state
Initial
P_loss>0
Estimation
P_loss=0
Steady
Est_frec > 100
P_loss=0
(n = n – 5;)
Succeed 3 times
If (real_data_loss > thresh)
frec_stack[0] = frec
No real data loss 3 times
Previous p_loss – ploss >3
N_inital = n;
Active_probe
real_data_loss > thresh
Succeed
or
real_data_loss > thresh
Scale down
Polling_stable
Count <3 && no dataloss
fail
BackOff
Set initial F_rate
No real data loss 5 times
Probe_scaleup
If ( p_loss < 1 &&
scale_next <= scale_now + F_rate)
Increase scale value by 1
24
FECRAC experiments
on real-network
• FECRAC VS. Aggressive Rate Control
FEC parameters
• topology
MAX FEC rate
100
Threshold FEC rate
100
The number of
source symbols
90
Symbol size (bytes)
1420
Data transmission
parameters
300Mbps
1ms
sender
Receiver
Scale Value
2
Scale 1
15Mbps
Scale 2
30Mbps
Packet Size (bytes)
1420
25
experiment
(self-control method: 11 flows compete)
Flow
Convergence
(the number)
oscillation
Data loss rate
Self-control
None (11flows)
5 times
3.8%
FECRAC(1)
FECRAC(2)
30Mbps (10flows)
15Mbps (1flow)
0
0
0.1% (after converged)
1.1% (after converged)
26
experiment
(FECRAC: 11 flows compete)
Flow
Convergence
(the number)
oscillation
Data loss rate
Self-control
None (11flows)
5 times
3.8%
FECRAC(1)
FECRAC(2)
30Mbps (10flows)
15Mbps (1flow)
0
0
0.1% (after converged)
1.1% (after converged)
27
experiment
(self-control method: 13 flows compete)
Flow
Convergence
(the number)
oscillation
Data loss rate
Self-control
None (13flows)
11 times
5.0%
FECRAC(1)
FECRAC(2)
30Mbps (3flows)
15Mbps (10flows)
0
0
0.1% (after converged)
0.5% (after converged)
28
experiment
(FECRAC: 13 flows compete)
Flow
Convergence
(the number)
oscillation
Data loss rate
Self-control
None (13flows)
11 times
5.0%
FECRAC(1)
FECRAC(2)
30Mbps (3flows)
15Mbps (10flows)
0
0
0.1% (after converged)
0.5% (after converged)
29
Simulation
• A sender transmits T Mbps UDP packets
– Receiver receives the packets and measures within 5 seconds;
• The packet loss rate: Ploss
• The number of consecutively lost packets: N
• The number of non-recovered UDP packets: L
• In the same network condition in which L was given:
– The sender transmits T Mbps UDP packets with Fenc% (FEC encoding
rate)
– The receiver measures L’ within 5 seconds
Streaming UDP node
T Mbps
TCP nodes
UDP nodes
100Mbps
10ms < RTT < 200ms
30
Simulation results (１≦Plos≦3)
Frec(%) =
L － L’
L
(L > L’, L≠0)
0
(L≦L’, L≠0)
Frec: FEC recovery rate
Fenc: FEC encoding rate
L: (the number of non-recoverd
UDP packets within 5 seconds)31