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– ５秒間

• じっくりロスパターンを見ないと、 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


16


17


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– ５秒間

• じっくりロスパターンを見ないと、 FEC の調整が難しい

柔軟に FEC の有効性を判断・推測する必要性がある !!

Problems of aggressive rate control

19

FEC recovery rate in various network congestions (Good Case)

20


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


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)




FECRAC(1)FECRAC(2)

30Mbps (10flows)15Mbps (1flow)

00


27

experiment(self-control method: 13 flows compete)




FECRAC(1)FECRAC(2)

30Mbps (3flows)15Mbps (10flows)

00


28

experiment (FECRAC: 13 flows compete)




FECRAC(1)FECRAC(2)

30Mbps (3flows)15Mbps (10flows)

00


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 ( １≦ Plos 3)≦

31

Documents

Adaptive High-performance Real-time applications