| 0.50 | 0.243 | 0.264 | 0.284 |
| 0.75 | 0.285 | 0.286 | 0.325 |
| 1.00 | 0.329 | 0.305 | 0.350 |
| 1.25 | 0.351 | 0.329 | 0.370 |
| 1.50 | 0.361 | 0.363 | 0.388 |
| 1.75 | 0.360 | 0.387 | 0.392 |
| 2.00 | 0.367 | 0.412 | 0.400 |
| 3.00 | 0.368 | 0.507 | 0.398 |
| 4.00 | 0.368 | 0.568 | 0.398 |
Table 8: The mean loss report delay, measured at the sender.
As can be seen from Table 8, the delay increases, in general, as l
increases. Also, a similar effect as for the feedback suppression
performance is present: beyond a certain threshold, the additional
increase in delay is not significant anymore. The threshold is
environment dependent and seems to be related to the threshold, where
the feedback suppression gain would not increase anymore.
6.3. Summary of "l" Investigations
We have shown experimentally that the performance of the feedback
suppression mechanisms increases as l increases. The same applies
for the report delay, which also increases as l increases. This
leads to a threshold where both the performance and the delay do not
increase any further. The threshold is dependent upon the
environment.
So finding an optimum value of l is not possible because it is always
a trade-off between delay and feedback suppression performance. With
l=0.5, we think that a trade-off was found that is acceptable for
typical applications and environments.
7. Applications Using AVPF
NEWPRED is one of the error resilience tools, which is defined in
both ISO/IEC MPEG-4 visual part and ITU-T H.263. NEWPRED achieves
fast error recovery using feedback messages. We simulated the
behavior of NEWPRED in the network simulator environment as described
above and measured the waiting time statistics, in order to verify
that the extended RTP profile for RTCP-based feedback (AVPF) [1] is
appropriate for the NEWPRED feedback messages. Simulation results,
which are presented in the following sections, show that the waiting
time is small enough to get the expected performance of NEWPRED.
7.1. NEWPRED Implementation in NS2
The agent that performs the NEWPRED functionality, called NEWPRED
agent, is different from the RTP agent we described above. Some of
the added features and functionalities are described in the following
points:
Application Feedback
The "Application Layer Feedback Messages" format is used to
transmit the NEWPRED feedback messages. Thereby the NEWPRED
functionality is added to the RTP agent. The NEWPRED agent
creates one NACK message for each lost segment of a video frame,
and then assembles multiple NACK messages corresponding to the
segments in the same video frame into one Application Layer
Feedback Message. Although there are two modes, namely, NACK mode
and ACK mode, in NEWPRED [6][7], only NACK mode is used in these
simulations. In this simulation, the RTP layer doesn’t generate
feedback messages. Instead, the decoder (NEWPRED) generates a
NACK message when the segment cannot be decoded because the data
hasn’t arrived or loss of reference picture has occurred. Those
conditions are detected in the decoder with frame number, segment
number, and existence of reference pictures in the decoder.
The parameters of NEWPRED agent are as follows:
f: Frame Rate(frames/sec)
seg: Number of segments in one video frame
bw: RTP session bandwidth(kbps)
Generation of NEWPRED’s NACK Messages
The NEWPRED agent generates NACK messages when segments are lost.
a. The NEWPRED agent generates multiple NACK messages per one
video frame when multiple segments are lost. These are
assembled into one Feedback Control Information (FCI) message
per video frame. If there is no lost segment, no message is
generated and sent.
b. The length of one NACK message is 4 bytes. Let num be the
number of NACK messages in one video frame (1 <= num <= seg).
Thus, 12+4*num bytes is the size of the low-delay RTCP feedback
message in a compound RTCP packet.
Measurements
We defined two values to be measured:
- Recovery time
The recovery time is measured as the time between the detection
of a lost segment and reception of a recovered segment. We
measured this "recovery time" for each lost segment.
- Waiting time
The waiting time is the additional delay due to the feedback
limitation of RTP.
Figure 2 depicts the behavior of a NEWPRED agent when a loss occurs.
The recovery time is approximated as follows:
(Recovery time) = (Waiting time) +
(Transmission time for feedback message) +
(Transmission time for media data)
Therefore, the waiting time is derived as follows:
(Waiting time) = (Recovery time) - (Round-trip delay), where
(Round-trip delay ) = (Transmission time for feedback message) +
(Transmission time for media data)
Picture Reference |: Picture Segment
____________________ %: Lost Segment
/_ _ _ _ \
v/ \ / \ / \ / \ \
v \v \v \v \ \
Sender ---|----|----|----|----|----|---|------------->
\ \ ^ \
\ \ / \
\ \ / \
\ v / \
\ x / \
\ Lost / \
\ x / \
_____
v x / NACK v
Receiver ---------------|----%===-%----%----%----|----->
|-a-| |
|------- b -------|
a: Waiting time
b: Recover time (%: Video segments are lost)
Figure 2: Relation between the measured values at the NEWPRED agent
7.2. Simulation
We conducted two simulations (Simulation A and Simulation B). In
Simulation A, the packets are dropped with a fixed packet loss rate
on a link between two NEWPRED agents. In Simulation B, packet loss
occurs due to congestion from other traffic sources, i.e., ftp
sessions.
7.2.1. Simulation A - Constant Packet Loss Rate
The network topology used for this simulation is shown in Figure 3.
Link 1 Link 2 Link 3
+--------+ +------+ +------+ +--------+
| Sender |------|Router|-------|Router|------|Receiver|
+--------+ +------+ +------+ +--------+
10(msec) x(msec) 10(msec)
Figure 3: Network topology that is used for Simulation A
Link1 and link3 are error free, and each link delay is 10 msec.
Packets may get dropped on link2. The packet loss rates (Plr) and
link delay (D) are as follows:
D [ms] = {10, 50, 100, 200, 500}
Plr = {0.005, 0.01, 0.02, 0.03, 0.05, 0.1, 0.2}
Session bandwidth, frame rate, and the number of segments are shown
in Table 9.
+------------+----------+-------------+-----+
|Parameter ID| bw(kbps) |f (frame/sec)| seg |
+------------+----------+-------------+-----+
| 32k-4-3 | 32 | 4 | 3 |
| 32k-5-3 | 32 | 5 | 3 |
| 64k-5-3 | 64 | 5 | 3 |
| 64k-10-3 | 64 | 10 | 3 |
| 128k-10-6 | 128 | 10 | 6 |
| 128k-15-6 | 128 | 15 | 6 |
| 384k-15-6 | 384 | 15 | 6 |
| 384k-30-6 | 384 | 30 | 6 |
| 512k-30-6 | 512 | 30 | 6 |
| 1000k-30-9 | 1000 | 30 | 9 |
| 2000k-30-9 | 2000 | 30 | 9 |
+------------+----------+-------------+-----+
Table 9: Parameter sets of the NEWPRED agents
Figure 4 shows the key values of the result (packet loss rate vs.
mean of waiting time).
When the packet loss rate is 5% and the session bandwidth is 32 kbps,
the waiting time is around 400 msec, which is just allowable for
reasonable NEWPRED performance.
When the packet loss rate is less than 1%, the waiting time is less
than 200 msec. In such a case, the NEWPRED allows as much as
200-msec additional link delay.
When the packet loss rate is less than 5% and the session bandwidth
is 64 kbps, the waiting time is also less than 200 msec.
In 128-kbps cases, the result shows that when the packet loss rate is
20%, the waiting time is around 200 msec. In cases with more than
512-kbps session bandwidth, there is no significant delay. This
means that the waiting time due to the feedback limitation of RTCP is
negligible for the NEWPRED performance.
+------------------------------------------------------------+
| | Packet Loss Rate = |
| Bandwidth | 0.005| 0.01 | 0.02 | 0.03 | 0.05 |0.10 |0.20 |
|-----------+------+------+------+------+------+------+------|
| 32k |130- |200- |230- |280- |350- |470- |560- |
| | 180| 250| 320| 390| 430| 610| 780|
| 64k | 80- |100- |120- |150- |180- |210- |290- |
| | 130| 150| 180| 190| 210| 300| 400|
| 128k | 60- | 70- | 90- |110- |130- |170- |190- |
| | 70| 80| 100| 120| 140| 190| 240|
| 384k | 30- | 30- | 30- | 40- | 50- | 50- | 50- |
| | 50| 50| 50| 50| 60| 70| 90|
| 512k | < 50 | < 50 | < 50 | < 50 | < 50 | < 50 | < 60 |
| | | | | | | | |
| 1000k | < 50 | < 50 | < 50 | < 50 | < 50 | < 50 | < 55 |
| | | | | | | | |
| 2000k | < 30 | < 30 | < 30 | < 30 | < 30 | < 35 | < 35 |
+------------------+------+------+------+------+------+------+
Figure 4: The result of simulation A
7.2.2. Simulation B - Packet Loss Due to Congestion
The configurations of link1, link2, and link3 are the same as in
Simulation A except that link2 is also error-free, regarding bit
errors. However, in addition, some FTP agents are deployed to
overload link2. See Figure 5 for the simulation topology.
Link1 Link2 Link3
+--------+ +------+ +------+ +--------+
| Sender |------|Router|-------|Router|------|Receiver|
+--------+ /|+------+ +------+|\ +--------+
+---+/ | | \+---+
+-|FTP|+---+ +---+|FTP|-+
| +---+|FTP| ... |FTP|+---+ | ...
+---+ +---+ +---+ +---+
FTP Agents FTP Agents
Figure 5: Network Topology of Simulation B
The parameters are defined as for Simulation A with the following
values assigned:
D[ms] ={10, 50, 100, 200, 500} 32 FTP agents are deployed at each
edge, for a total of 64 FTP agents active.
The sets of session bandwidth, frame rate, and the number of segments
are the same as in Simulation A (Table 9).
We provide the results for the cases with 64 FTP agents, because
these are the cases where packet losses could be detected to be
stable. The results are similar to those for Simulation A except for
a constant additional offset of 50..100 ms. This is due to the delay
incurred by the routers’ buffers.
7.3. Summary of Application Simulations
We have shown that the limitations of RTP AVPF profile do not
generate such high delay in the feedback messages that the
performance of NEWPRED is degraded for sessions from 32 kbps to 2
Mbps. We could see that the waiting time increases with a decreasing
session bandwidth and/or an increasing packet loss rate. The cause
of the packet loss is not significant; congestion and constant packet
loss rates behave similarly. Still we see that for reasonable
conditions and parameters the AVPF is well suited to support the
feedback needed for NEWPRED. For more information about NEWPRED, see
[8] and [9].
8. Summary
The new RTP profile AVPF was investigated regarding performance and
potential risks to the network stability. Simulations were conducted
using the network simulator ns2, simulating unicast and several
differently sized multicast topologies. The results were shown in
this document.
Regarding the network stability, it was important to show that the
new profile does not lead to any feedback implosion or use more
bandwidth than it is allowed. We measured the bandwidth that was
used for RTCP in relation to the RTP session bandwidth. We have
shown that, more or less exactly, 5% of the session bandwidth is used
for RTCP, in all considered scenarios. Other RTCP bandwidth values
could be set using the RTCP bandwidth modifiers [10]. The scenarios
included unicast with and without errors, differently sized multicast
groups, with and without errors or congestion on the links. Thus, we
can say that the new profile behaves in a network-friendly manner in
the sense that it uses only the allowed RTCP bandwidth, as defined by
RTP.
Secondly, we have shown that receivers using the new profile
experience a performance gain. This was measured by capturing the
delay that the sender sees for the received feedback. Using the new
profile, this delay can be decreased by orders of magnitude.
In the third place, we investigated the effect of the parameter "l"
on the new algorithms. We have shown that there does not exist an
optimum value for it but only a trade-off can be achieved. The
influence of this parameter is highly environment-specific and a
trade-off between performance of the feedback suppression algorithm
and the experienced delay has to be met. The recommended value of
l=0.5 given in this document seems to be reasonable for most
applications and environments.
9. Security Considerations
This document describes the simulation work carried out to verify the
correct working of the RTCP timing rules specified in the AVPF
profile [1]. Consequently, security considerations concerning these
timing rules are described in that document.
10. Normative References
[1] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control Protocol
(RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
11. Informative References
[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[4] Network Simulator Version 2 - ns-2, available from
http://www.isi.edu/nsnam/ns.
[5] C. Burmeister, T. Klinner, "Low Delay Feedback RTCP - Timing
Rules Simulation Results". Technical Report of the Panasonic
European Laboratories, September 2001, available from:
http://www.informatik.uni-bremen.de/~jo/misc/
SimulationResults-A.pdf.
[6] ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology -
Coding of audio-visual objects - Part2: Visual", July 2000.
[7] ITU-T Recommendation, H.263. Video encoding for low bitrate
communication. 1998.
[8] S. Fukunaga, T. Nakai, and H. Inoue, "Error Resilient Video
Coding by Dynamic Replacing of Reference Pictures", IEEE Global
Telecommunications Conference (GLOBECOM), pp.1503-1508, 1996.
[9] H. Kimata, Y. Tomita, H. Yamaguchi, S. Ichinose, T. Ichikawa,
"Receiver-Oriented Real-Time Error Resilient Video Communication
System: Adaptive Recovery from Error Propagation in Accordance
with Memory Size at Receiver", Electronics and Communications in
Japan, Part 1, vol. 84, no. 2, pp.8-17, 2001.
[10] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003.
Authors’ Addresses
Carsten Burmeister
Panasonic R&D Center Germany GmbH
Monzastr. 4c
D-63225 Langen, Germany
EMail: carsten.burmeister@eu.panasonic.com
Rolf Hakenberg
Panasonic R&D Center Germany GmbH
Monzastr. 4c
D-63225 Langen, Germany
EMail: rolf.hakenberg@eu.panasonic.com
Akihiro Miyazaki
Matsushita Electric Industrial Co., Ltd
1006, Kadoma, Kadoma City, Osaka, Japan
EMail: miyazaki.akihiro@jp.panasonic.com
Joerg Ott
Helsinki University of Technology, Networking Laboratory
PO Box 3000, 02015 TKK, Finland
EMail: jo@acm.org
Noriyuki Sato
Oki Electric Industry Co., Ltd.
1-16-8 Chuo, Warabi, Saitama 335-8510 Japan
EMail: sato652@oki.com
Shigeru Fukunaga
Oki Electric Industry Co., Ltd.
2-5-7 Hommachi, Chuo-ku, Osaka 541-0053 Japan
EMail: fukunaga444@oki.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).