1. June 11, 2001ICC20011 Department of Informatics and Mathematical Science, Graduate School of Engineering Science, Osaka University, Japan Masaki Miyabayashi E-mail: miyabays@ics.es.osaka-u.ac.jp MPEG-TFRCP: Video Transfer with TCP-friendly Rate Control Protocol

2. Introduction Unfairness: TCP vs.UDP –TCP: traditional data applications Congestion control –UDP: real-time multimedia applications No control mechanisms Unfairness: TCP vs.UDP –TCP: traditional data applications Congestion control –UDP: real-time multimedia applications No control mechanisms TCP ， UDP co-exist Use of multimedia apps. increases “Greedy” UDP degrades TCP performance 0 1 2 3 4 5 6 7 8 9 10 0 2030405060 Rate [Mbps] Time [sec] UDP TCP

3. June 11, 2001ICC20013 TCP-friendly rate control TFRCP (TCP-friendly Rate Control Protocol) –Equation-based control Estimate TCP throughput –AIMD control (Additive Increase/Multiplicative Decrease) TFRCP (TCP-friendly Rate Control Protocol) –Equation-based control Estimate TCP throughput –AIMD control (Additive Increase/Multiplicative Decrease) “A non-TCP connection should receive the same share of bandwidth as a TCP connection if they traverse the same path.”

4. MPEG-TFRCP mechanisms 1.Estimate network condition from feedback information 2.Derive TCP throughput 3.Regulate the sending rate 1.Estimate network condition from feedback information 2.Derive TCP throughput 3.Regulate the sending rate Ref [10] ： Naoki Wakamiya, Masayuki Murata, and Hideo Miyahara, “On TCP-friendly video transfer,” in Proceedings of SPIE International Symposium on Information Technologies 2000, November 2000. lost time 2  i r 1  i r i r 1  i r sending rate control interval 2  i I 1  i I i I 1  i I i I i r and determine sender receiver Estimation of RTT, Loss i.No loss, ii.Loss, adjusting MPEG-2 video rate Loss estimation  how to get feedback information?  applicability for real system?  perceived video quality? r i r i   2 1 )321() 8 3 3,1min( 3 2 2 0 p p p T p RTT MTU   1 r i 

5. June 11, 2001ICC20015 Research Targets Demonstrate applicability of MPEG-TFRCP to real system –Perceived video quality at receiver MOS (Mean Opinion Score) –Observation of traffic on the link Average throughput Rate variation Improve MPEG-TFRCP –Rate control algorithm –Control interval Demonstrate applicability of MPEG-TFRCP to real system –Perceived video quality at receiver MOS (Mean Opinion Score) –Observation of traffic on the link Average throughput Rate variation Improve MPEG-TFRCP –Rate control algorithm –Control interval

6. June 11, 2001ICC20016 System configuration TCP TFRCP/UDP SendersReceivers

7. June 11, 2001ICC20017 MPEG-TFRCP sender & receiver Hard Disk target rate Quantizer Scale Encoder Trans- mitter RTP RTCP RTP UDP Camera QoS Manager Estimator video data Sender Report Receiver Report Receiver Decoder Monitor Sender-sideReceiver-side

8. June 11, 2001ICC20018 Original MPEG-TFRCP Drastic rate variation –Increasing exponentially, decreasing extremely Average throughput ： TCP 4.4 [Mbps] ， TFRCP 2.0 [Mbps] –Not TCP-friendly Lower subjective video quality: MOS 1.25 0 2 4 6 8 10 050100150200 Rate [Mbps] GoP times MPEG-TFRCP TCP

9. June 11, 2001 Improving rate control algorithm Quantizer-scale-based Additive Increase algorithm (QAI) –When no loss occurs, Increase sending rate with regard to quantizer scale Decrease quantizer scale by two Initially set at 60 –When loss occurs, Original algorithm Quantizer-scale-based Additive Increase algorithm (QAI) –When no loss occurs, Increase sending rate with regard to quantizer scale Decrease quantizer scale by two Initially set at 60 –When loss occurs, Original algorithm 0 5 10 15 20 0102030405060 Average rate [Mbps] Quantizer scale Rate )321() 8 3 3,1min( 3 2 2 0 p p p T p RTT MTU   1 r i 

10. June 11, 2001ICC200110 Evaluation of QAI MPEG-TFRCP Rate variation becomes relatively smaller Not TCP-friendly –TCP : 4.3 [Mbps] –TFRCP : 2.3 [Mbps] Not attain high-quality video transfer (MOS) –UDP : 4.25 –Original : 1.25 –QAI : 2.50 0 2 4 6 8 10 050100150200 Rate [Mbps] GoP times TCP MPEG-TFRCP Rate variation (QAI)

11. June 11, 2001ICC200111 Variants in packet loss probability derivation Original –React so quickly against short-term congestion Extreme rate fluctuation Cumulative packet Loss probability (CL) Original –React so quickly against short-term congestion Extreme rate fluctuation Cumulative packet Loss probability (CL) Loss = Number of transmitted packets Number of Lost packets, within each control interval Loss = Total number of transmitted packets Total number of Lost packets, from beginning of the session

12. June 11, 2001ICC200112 Evaluation of QAI-CL Rate variation becomes relatively small Improve video quality –Original : 1.25 –QAI : 2.50 –QAI-CL : 3.00 accomplish reasonable TCP-friendly control –TCP : 3.7 [Mbps] –QAI-CL : 3.0 [Mbps] Rate and packet loss probability variations (QAI-CL)

13. June 11, 2001ICC200113 Election of the control interval When interval is too short, –Perceived video quality becomes unstable –Cannot estimate network condition precisely When interval is too long, –Cannot follow changes of network condition When interval is too short, –Perceived video quality becomes unstable –Cannot estimate network condition precisely When interval is too long, –Cannot follow changes of network condition GoPtime RTT Interval        32 32-RTT: proposal 8-RTT: 16-RTT: 64-RTT: 96-RTT: shorter longer

14. June 11, 2001ICC200114 Several settings of control interval 8-RTT 16-RTT 32-RTT 64-RTT 96-RTT TFRCPTCP Throughput [Mbps] Friendliness MOS value 3.10 2.87 2.97 2.51 2.33 3.53 3.71 3.70 4.06 4.29 0.878 0.774 0.802 0.618 0.543 2.25 3.25 3.00 3.33 2.50 16-RTT or 32-RTT control interval is appropriate

15. June 11, 2001ICC200115 Conclusion Conclusions –Evaluated applicability of proposed method to real system –Improving the TCP-friendliness and perceived video quality by our method (QAI-CL MPEG- TFRCP) Future work –Larger scale network –Consider RTT variation Conclusions –Evaluated applicability of proposed method to real system –Improving the TCP-friendliness and perceived video quality by our method (QAI-CL MPEG- TFRCP) Future work –Larger scale network –Consider RTT variation