310 likes | 480 Views
Adaptive High-performance Real-time applications. 慶応義塾大学 政策メディア・研究科 kazuhisa. Motivation. リアルタイムストリーミングの一般化普及 e-learning, international symposium, telemedicine. “Mission-critical flow”: (1) インタラクティブ性、 (2) パフォーマンス ( 映像・音声の品質 ) が求められる Best quality VS. Traffic Congestion パケットロスによる品質劣化が発生
E N D
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を最小化
Challenges • (1)Rate Control : 自身のパフォーマンスのみを考慮 • (Best quality) VS. (packet loss, and rate oscillation) • Best data transmission rate を維持する • 最良品質 • packet loss, rate oscillationを防ぐ • “AggressiveRate Control”が上記を満たす上で必要 • (2)Congestion control: ストリーミングフロー全体のパフォーマンスを考慮 • (Aggressive Rate Control) VS. (Nervous Rate Control) • Scalability: 全体のパフォーマンスを可能な限り向上させる • Fairness • Mission-critical なストリーミングフローに着目 • “(1) and (2)”を実現するにはどうするか? • Error control (FEC)の使い方が肝
Network Estimation Network Controller End-Node controller Quality Adaptation 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に帯域を合わせてしまう
Aggressive Rate Control • (1)Rate Control mechanism • (Best quality) VS. (packet loss, and rate oscillation) • アプローチ: Dynamic FECを品質維持とネットワーク状態把握に利用 Application policy network client Rate Control Media source ・Packet loss rate ・The number of consecutive loss packets ・FEC recovery rate Congestion control Dynamic FEC
Aggressive Rate Control:Rate Control with DynamicFEC • Decision Function • ロスパターン (Packet loss rate, consecutive lost packets) • FEC recovery rate (ネットワーク状態指標としては使っていない) • Increase/decrease algorithm • 固定アルゴリズム(省略) • データ転送レートとFECレートを調整 • 1. FECでリカバーできるか? • できなさそうならdata transmission rateを下げる • 2. data transmission rateを上げられるか? • FEC rate を増加させて、ロスパターンを見る • Decision Frequency • 5秒間 • じっくりロスパターンを見ないと、FECの調整が難しい
Aggressive Rate Controlの問題点 • FECによる冗長化が結果的に各パフォーマンスを低下させる • パケットロスをFECでリカバーできない • データ転送レートの振動が起きる • (3) Congestion Controlが必要 • 柔軟にFECの有効性を判断する必要性がある
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 network client Rate Control Media source Congestion control Dynamic FEC ・FEC recovery rate
FECRAC • Decision Function • FEC効率予測値 • FECレートX%時(FEC効率閾値)におけるFEC recovery rateの予測値 • Increase/decrease algorithm(sender based) • FECレート:5%単位で変更 • 映像データ転送レート(“Scale value”): 1単位で変更 • Decision Frequency • Data loss (loss rate閾値)が起きた時 • Receiverがfeedbackする 柔軟にFECの有効性を判断・推測 する必要性がある!!
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)
Future work • FECRACの改良 • 現状:以下のパラメータは固定 • Application(data transmission rate) • Network (RTT, bottleneck link bandwidth) • Simulation • 様々な環境で検証 • 分析 • threshold Xについての検証 • Consecutive lost packets (N)とFEC recovery rateの関係を利用できるか? • 実装・実ネットワークでの評価
Problems of aggressive rate control:30 flows compete on 1G network (1/2)
Problems of aggressive rate control:30 flows compete on 1G network (2/2)
Problems of aggressive rate control:35 flows compete on 1G network (1/2)
Problems of aggressive rate control:35 flows compete on 1G network (2/2)
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 • 5秒間 • じっくりロスパターンを見ないと、FECの調整が難しい 柔軟にFECの有効性を判断・推測 する必要性がある!!
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)
FEC recovery rate in various network congestions (Bad Case) Estimated Frec threshold
Sender state P_loss>0 Initial Estimation Est_frec > 100 P_loss=0 P_loss=0 (n = n – 5;) Active_probe real_data_loss > thresh BackOff Succeed or Scale down real_data_loss > thresh Set initial F_rate Succeed 3 times Steady Polling_stable No real data loss 5 times fail If (real_data_loss > thresh) frec_stack[0] = frec Count <3 && no dataloss No real data loss 3 times Previous p_loss – ploss >3 N_inital = n; Probe_scaleup If ( p_loss < 1 && scale_next <= scale_now + F_rate) Increase scale value by 1
FECRACexperiments on real-network • FECRAC VS. Aggressive Rate Control • topology 300Mbps 1ms sender Receiver
Simulation • A sender transmits TMbps 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 TMbps UDP packets with Fenc%(FEC encoding rate) • The receiver measures L’within 5 seconds Streaming UDP node T Mbps TCP nodes 100Mbps 10ms < RTT < 200ms UDP nodes
Simulation results (1≦Plos≦3) Frec: FEC recovery rate Fenc: FEC encoding rate L: (the number of non-recoverd UDP packets within 5 seconds) L - L’ (L > L’, L≠0) L Frec(%) = (L≦L’, L≠0) 0