Adaptive High-performance Real-time applications
description
Transcript of Adaptive High-performance Real-time applications
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 に向かない
• TCP に帯域を合わせてしまう Network Estimation
Quality Adaptation
Network Controller End-Node controller
4
Aggressive Rate Control• (1)Rate Control mechanism
– (Best quality) VS. (packet loss, and rate oscillation)
• アプローチ : Dynamic FEC を品質維持とネットワーク状態把握に利用
Application policy
Media source
Congestioncontrol
Rate Control
network
client
・ Packet loss rate・ The number of consecutive loss packets・ FEC recovery rate
Dynamic FEC
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– 5秒間
• じっくりロスパターンを見ないと、 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
Congestioncontrol
Rate Control
network
client
・ FEC recovery rateDynamic FEC
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 単位で変
更
3. Decision Frequency– Data loss (loss rate 閾値 ) が起きた時
• Receiver が feedback する
柔軟に FEC の有効性を判断・推測する必要性がある !!
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
• 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– 5秒間
• じっくりロスパターンを見ないと、 FEC の調整が難しい
柔軟に FEC の有効性を判断・推測する必要性がある !!
Problems of aggressive rate control
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)
23threshold
Estimated Frec
Sender state Initial
Estimation
Steady
BackOff
P_loss=0
P_loss>0
If (real_data_loss > thresh) frec_stack[0] = frec
Active_probeActive_probe
Probe_scaleupProbe_scaleup
Polling_stablePolling_stable
P_loss=0(n = n – 5;)
Succeed or Scale down
Est_frec > 100
Succeed 3 times
real_data_loss > thresh
No real data loss 3 timesPrevious p_loss – ploss >3N_inital = n;
fail
Set initial F_rate
real_data_loss > thresh
No real data loss 5 times
If ( p_loss < 1 && scale_next <= scale_now + F_rate)Increase scale value by 1
Count <3 && no dataloss
24
FECRAC experiments on real-network
• FECRAC VS. Aggressive Rate Control
• topologyFEC parameters
MAX FEC rate 100
Threshold FEC rate 100
The number of source symbols
90
Symbol size (bytes) 1420
300Mbps1ms
sender Receiver
25
Data transmission parameters
Scale Value 2
Scale 1 15Mbps
Scale 2 30Mbps
Packet Size (bytes) 1420
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)
00
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)
00
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)
00
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)
00
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
100Mbps10ms < RTT < 200ms
Streaming UDP node
TCP nodes
UDP nodes
T Mbps
30
Frec(%) = LL - L’ (L > L’, L≠0)
(L L’, L≠0)≦0
Frec: FEC recovery rateFenc: FEC encoding rateL: (the number of non-recoverd UDP packets within 5 seconds)
Simulation results ( 1≦ Plos 3)≦
31