Upload
patrick-lloyd
View
214
Download
0
Tags:
Embed Size (px)
Citation preview
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