June 11, 2001ICC20011 Department of Informatics and Mathematical Science, Graduate School of Engineering Science, Osaka University, Japan Masaki Miyabayashi.

June 11, 2001 ICC2001 1

Department of Informatics and Mathematical Science,Graduate School of Engineering Science, Osaka University, Japan

Masaki MiyabayashiE-mail: [email protected]

MPEG-TFRCP: Video Transfer with TCP-friendly Rate Control Protocol

MPEG-TFRCP: Video Transfer with TCP-friendly Rate Control Protocol

IntroductionIntroduction

• 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-existUse of multimedia apps.

increases

““Greedy” UDP degrades Greedy” UDP degrades TCP performanceTCP performance 0

123456789

10

0 10 20 30 40 50 60

Rat

e [M

bps]

Time [sec]

UDPTCP

June 11, 2001 ICC2001 3

TCP-friendly rate control 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 A non-TCP connection should receive the same share of bandwidth as a TCP connection same share of bandwidth as a TCP connection

if they traverse the same path.”if they traverse the same path.”

MPEG-TFRCP mechanisms 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.

lostlost

time

2ir 1ir ir 1irsending rate

control interval 2iI 1iI iI 1iIiIir anddetermine

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?

riri 21

)321()8

33,1min(3

2 20 pppTpRTT

MTU

1r i

June 11, 2001 ICC2001 5

Research TargetsResearch 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

June 11, 2001 ICC2001 6

TCP RenoPentiumIII

700Mhz

MPEG-TFRCP/UDPPentiumIII

700Mhz

MPEG-TFRCP/UDPPentiumIII

800Mhz

TCP RenoPentiumIII

800Mhz

HUB HUB

PC router

PentiumII233Mhz100Base-TX

100Base-TX 10Base-T

10Base-T

100Base-TX 10Base-T

System configurationSystem configuration

TCP

TFRCP/UDP

Senders Receivers

June 11, 2001 ICC2001 7

MPEG-TFRCP sender & receiver

MPEG-TFRCP sender & receiver

HardDisk

target rate

QuantizerScale

Encoder

Trans-mitter

RTP

RTCP RTCP

RTP

UDP UDP

Camera

QoSManager

Estimator

video data

SenderReport

ReceiverReport

ReceiverDecoder

Monitor

Sender-side Receiver-side

June 11, 2001 ICC2001 8

Original MPEG-TFRCPOriginal 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

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

0 50 100 150 200

Rat

e [M

bp

s]

GoP times

MPEG-TFRCPTCP

= 1.001 sec

0

5

10

15

20

25

0 50 100 150 2000.01

0.1

1

Rat

e [M

bp

s]

pac

ket

loss

pro

bab

ility

GoP times

losstarget ratevideo rate

June 11, 2001

Improving rate control algorithmImproving rate control algorithm• Quantizer-scale-based Additive Increase al

gorithm (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

0 10 20 30 40 50 60

Ave

rage

rat

e [M

bp

s]

Quantizer scale

Rate

)321()8

33,1min(3

2 20 pppTpRTT

MTU

1r i

June 11, 2001 ICC2001 10

Evaluation of QAI MPEG-TFRCPEvaluation 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

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

0 50 100 150 200

Rat

e [M

bp

s]

GoP times

TCPMPEG-TFRCP

Rate variation (QAI)

June 11, 2001 ICC2001 11

Variants in packet loss probability derivation

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

June 11, 2001 ICC2001 12

Evaluation of QAI-CLEvaluation of QAI-CL

0

2

4

6

8

10

0 50 100 150 200

0.001

0.01

0.1

Rat

e [M

bp

s]

pac

ket

loss

pro

bab

ility

GoP times

lossTCP

MPEG-TFRCP

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 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 probabilityvariations (QAI-CL)

June 11, 2001 ICC2001 13

Election of the control intervalElection 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

GoPtimeGoPtime

RTTInterval

32

32-RTT: proposal

8-RTT:

16-RTT: 64-RTT: 96-RTT:

shorter

longer

June 11, 2001 ICC2001 14

Several settings of control interval

Several settings of control interval

8-RTT

16-RTT

32-RTT

64-RTT

96-RTT

TFRCP TCP

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

June 11, 2001 ICC2001 15

ConclusionConclusion

• 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