idnits 2.17.1 draft-burmeister-avt-rtcp-feedback-sim-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 3) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2003) is 7712 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 839 looks like a reference -- Missing reference section? '6' on line 860 looks like a reference -- Missing reference section? '7' on line 860 looks like a reference -- Missing reference section? '4' on line 194 looks like a reference -- Missing reference section? '2' on line 202 looks like a reference -- Missing reference section? '10' on line 1083 looks like a reference -- Missing reference section? '5' on line 397 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 C. Burmeister 3 Internet Draft R. Hakenberg 4 draft-burmeister-avt-rtcp-feedback-sim-01.txt A. Miyazaki 5 Expires: September 2003 Matsushita 7 J. Ott 8 University of Bremen TZI 10 N. Sato 11 S. Fukunaga 12 Oki 14 March 2003 16 Extended RTP Profile for RTCP-based Feedback 17 - Results of the Timing Rule Simulations - 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance 22 with all provisions of Section 10 of RFC 2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 This document describes the results we achieved when simulating the 46 timing rules of the Extended RTP Profile for RTCP-based Feedback, 47 denoted AVPF. Unicast and multicast topologies are considered as 48 well as several protocol and environment configurations. The 50 Burmeister et al. Expires September 2003 1 51 results show that the timing rules result in better performance 52 regarding feedback delay and still preserve the well accepted RTP 53 rules regarding allowed bit rates for control traffic. 55 Table of Contents 57 1 Introduction 58 2 Conventions used in this document 59 3 Timing rules of the extended RTP profile for RTCP-based feedback 60 4 Simulation Environment 61 5 RTCP Bit Rate Measurements 62 5.1 Unicast 63 6 Feedback Measurements 64 6.1 Unicast 65 7 Investigations on "l" 66 8 Applications Using AVPF 67 9 Summary 68 References 69 IPR Notices 70 Authors' Address 71 Full Copyright Statement 73 1 Introduction 75 The Real-time Transport Protocol (RTP) is widely used for the 76 transmission of real-time or near real-time media data over the 77 Internet. While it was originally designed to work well for 78 multicast groups in very large scales, its scope is not limited to 79 that More and more applications use RTP for small multicast groups 80 (e.g. video conferences) or even unicast (e.g. IP telephony and 81 media streaming applications). 83 RTP comes together with its companion protocol Real-time Transport 84 Control Protocol (RTCP), which is used to monitor the transmission 85 of the media data and provide feedback of the reception quality. 86 Furthermore, it can be used for loose session control. Having the 87 scope of large multicast groups in mind, the rules when to send 88 feedback were much restricted to avoid feedback explosion or 89 feedback related congestion in the network. RTP and RTCP have 90 proven to work well in the Internet, especially in large multicast 91 groups, which is shown by its widespread usage today. 93 However the applications that transmit the media data only to small 94 multicast groups or unicast, may benefit from more frequent 95 feedback. The source of the packets may be able to react to changes 96 in the reception quality, which may be due to varying network 97 utilization (e.g. congestion) or other changes. Possible reactions 98 include transmission rate adaptation according to a congestion 100 Burmeister et al. Expires September 2003 2 101 control algorithm or the invocation of error resilience features for 102 the media stream (e.g. retransmissions, reference picture selection, 103 NEWPRED, etc.). 105 As mentioned before, more frequent feedback may be desirable to 106 increase the reception quality, but RTP restricts the use of RTCP 107 feedback. Hence it was decided to create a new extended RTP 108 profile, which redefines some of the RTCP timing rules, but keeps 109 most of the algorithms for RTP and RTCP, which have proven to work 110 well. The new rules should scale from unicast to multicast, where 111 unicast or small multicast applications have the most gain from it. 112 A detailed description of the new profile and its timing rules can 113 be found in [1]. 115 This document investigates the new algorithms by the means of 116 simulations. We show that the new timing rules scale well and 117 behave in a network-friendly manner. Firstly, the key features of 118 the new RTP profile that are important for our simulations are 119 roughly described in Section 3. After that, we describe the 120 environment that is used to conduct the simulations in Section 4. 121 Section 5 describes simulation results that show the backwards 122 compatibility to RTP and that the new profile is network-friendly in 123 terms of used bandwidth for RTCP traffic. In Section 6, we show the 124 benefit that applications could get from implementing the new 125 profile. In Section 7 we investigated the effect of the parameter 126 "l" (used to calculate the T_dither_max value) upon the algorithm 127 performance and finally in Section 8 we show the performance gain we 128 could get for a special application, namely NEWPRED in [6] and [7]. 130 2 Conventions used in this document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 134 this document are to be interpreted as described in RFC 2119. 136 3 Timing rules of the extended RTP profile for RTCP-based feedback 138 As said above, RTP restricts the usage of RTCP feedback. The main 139 restrictions on RTCP are as follows: 141 - RTCP messages are sent in compound packets, i.e. every RTCP packet 142 contains at least one sender report (SR) or receiver report (RR) 143 message and a source description (SDES) message. 144 - The RTCP compound packets are sent in time intervals (T_rr), which 145 are computed as a function of the average packet size, the number 146 of senders and receivers in the group and the session bandwidth 147 (5% of the session bandwidth is used for RTCP messages; this 148 bandwidth is shared between all session members, where the senders 149 may get a larger share than the receivers.) 151 Burmeister et al. Expires September 2003 3 152 - The minimum interval between two RTCP packets from the same source 153 is 5 seconds. 155 We see that these rules prevent feedback explosion and scale well to 156 large multicast groups. However, they not allow timely feedback at 157 all. While the second rule scales also to small groups or unicast 158 (in this cases the interval might be as small as a few 159 milliseconds), the third rule may prevent the receivers from sending 160 feedback timely. 162 The timing rules to send RTCP feedback from the new RTP profile [1] 163 consist of two key components. First the minimum interval of 5 164 seconds is abolished. Second, receivers get once during their (now 165 quite small) RTCP interval the chance to send an RTCP packet 166 "early", i.e. not according to the calculated interval, but 167 virtually immediately. It is important to note that the RTCP 168 interval calculation is still inherited from the original RTP 169 specification. 171 The specification and all the details of the extended timing rules 172 can be found in [1]. We shall describe the algorithms here, but 173 rather reference these from the original specification where needed. 174 Therefore we use also the same variable names and abbreviations as 175 in [1]. 177 4 Simulation Environment 179 This section describes the simulation testbed that was used for the 180 investigations and its key features. The extensions to the 181 simulator that were necessary are roughly described in the following 182 sections. 184 4.1 Network Simulator Version 2 186 The simulations were conducted using the network simulator version 2 187 (ns2). ns2 is an open source project, written in a combination of 188 Tool Command Language (TCL) and C++. The scenarios are set-up using 189 TCL. Using the scripts it is possible to specify the topologies 190 (nodes and links, bandwidths, queue sizes or error rates for links) 191 and the parameters of the "agents", i.e. protocol configurations. 192 The protocols itself are implemented in C++ in the agents, which are 193 connected to the nodes. The documentation for ns2 and a the newest 194 version can be found in [4]. 196 4.2 RTP Agent 198 We implemented a new agent, based on RTP/RTCP. RTP packets are sent 199 at a constant packet rate with the correct header sizes. RTCP 201 Burmeister et al. Expires September 2003 4 202 packets are sent according to the timing rules of [2] and also its 203 algorithms for group membership maintenance are implemented. Sender 204 and receiver reports are sent. 206 Further, we extended the agent to support the extended profile [1]. 207 The use of the new timing rules can be turned on and off via 208 parameter settings in TCL. 210 4.3 Scenarios 212 The scenarios that are simulated are defined in TCL scripts. We 213 set-up several different topologies, ranging from unicast with two 214 session members to multicast with up to 25 session members. 215 Depending on the sending rates used and the corresponding link 216 bandwidths, congestion losses may occur. In some scenarios, bit 217 errors are inserted on certain links. We simulated groups with 218 RTP/AVP agents, RTP/AVPF agents and mixed groups. 220 The feedback messages are generally NACK messages as defined in [1] 221 and are triggered by packet loss. 223 4.4 Topologies 225 Mainly four different topologies are simulated to show the key 226 features of the extended profile. However, for some specific 227 simulations we used different topologies. This is then indicated in 228 the description of the simulation results. The main four topologies 229 are named after the number of participating RTP agents, i.e. T-2, T- 230 4, T-8 and T-16, where T-2 is a unicast scenario, T-4 contains four 231 agents, etc. The figures below illustrate the main topologies. 233 Burmeister et al. Expires September 2003 5 234 A5 235 A5 | A6 236 / | / 237 / | /--A7 238 / |/ 239 A2 A2-----A6 A2--A8 240 / / / A9 241 / / / / 242 / / / /---A10 243 A1-----A2 A1-----A3 A1-----A3-----A7 A1------A3< 244 \ \ \ \---A11 245 \ \ \ \ 246 \ \ \ A12 247 A4 A4-----A8 A4--A13 248 |\ 249 | \--A14 250 | \ 251 | A15 252 A16 254 T-2 T-4 T-8 T-16 256 Figure 1: Simulated Topologies. 258 5 RTCP Bit Rate Measurements 260 The new timing rules allow more frequent RTCP feedback for small 261 multicast groups. In large groups the algorithm behaves similarly 262 to RTP. While it is generally good to have more frequent feedback 263 it cannot be allowed at all to increase the bit rate used for RTCP 264 above a fixed limit, i.e. 5% of the total RTP bandwidth according to 265 RTP. This section shows that the new timing rules keep RTCP 266 bandwidth usage under the 5% limit for all investigated scenarios, 267 topologies and group sizes. Furthermore, we show that mixed groups, 268 i.e. some members using AVP some AVPF, can be allowed and that each 269 session member behaves fair according to its corresponding 270 specification. Note that other value for the RTCP bandwidth limit 271 may be specified using the RTCP bandwidth modifiers as in [10]. 273 5.1 Unicast 275 First we measured the RTCP bandwidth share in the unicast topology 276 T-2. Even for a fixed topology and group size, there are several 277 protocol parameters which are varied to simulate a large range of 278 different scenarios. We varied the configurations of the agents in 279 the sense that the agents may use the AVP or AVPF. Thereby it is 280 possible that one agent uses AVP and the other AVPF in one RTP 281 session. This is done to test the backwards compatibility of the 282 AVPF profile. 284 Burmeister et al. Expires September 2003 6 285 First we consider scenarios where no losses occur. In this case 286 both RTP session members transmit the RTCP compound packets at 287 regular intervals, calculated as T_rr, if they use the AVPF, and use 288 the minimum interval of 5s if they implement the AVP. No early 289 packets are sent, because the need to send feedback is not given. 290 Still it is important to see that not more than 5% of the session 291 bandwidth is used for RTCP and that AVP and AVPF members can co- 292 exist without interference. The results can be found in table 1. 294 | | | | | | Used RTCP Bit Rate | 295 | Session | Send | Rec. | AVP | AVPF | (% of session bw) | 296 |Bandwidth|Agents|Agents|Agents|Agents| A1 | A2 | sum | 297 +---------+------+------+------+------+------+------+------+ 298 | 2 Mbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 | 299 | 2 Mbps | 1,2 | - | - | 1,2 | 2.49 | 2.49 | 4.98 | 300 | 2 Mbps | 1 | 2 | 1 | 2 | 0.01 | 2.49 | 2.50 | 301 | 2 Mbps | 1,2 | - | 1 | 2 | 0.01 | 2.48 | 2.49 | 302 | 2 Mbps | 1 | 2 | 1,2 | - | 0.01 | 0.01 | 0.02 | 303 | 2 Mbps | 1,2 | - | 1,2 | - | 0.01 | 0.01 | 0.02 | 304 |200 kbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 | 305 |200 kbps | 1,2 | - | - | 1,2 | 2.49 | 2.49 | 4.98 | 306 |200 kbps | 1 | 2 | 1 | 2 | 0.06 | 2.49 | 2.55 | 307 |200 kbps | 1,2 | - | 1 | 2 | 0.08 | 2.50 | 2.58 | 308 |200 kbps | 1 | 2 | 1,2 | - | 0.06 | 0.06 | 0.12 | 309 |200 kbps | 1,2 | - | 1,2 | - | 0.08 | 0.08 | 0.16 | 310 | 20 kbps | 1 | 2 | - | 1,2 | 2.44 | 2.54 | 4.98 | 311 | 20 kbps | 1,2 | - | - | 1,2 | 2.50 | 2.51 | 5.01 | 312 | 20 kbps | 1 | 2 | 1 | 2 | 0.58 | 2.48 | 3.06 | 313 | 20 kbps | 1,2 | - | 1 | 2 | 0.77 | 2.51 | 3.28 | 314 | 20 kbps | 1 | 2 | 1,2 | - | 0.58 | 0.61 | 1.19 | 315 | 20 kbps | 1,2 | - | 1,2 | - | 0.77 | 0.79 | 1.58 | 317 Table 1: Unicast simulations without packet loss. 319 We can see that in configurations, where both agents use the new 320 timing rules each of them uses, at most, about 2.5% of the session 321 bandwidth for RTP, which sums up to 5% of the session bandwidth for 322 both. This is achieved regardless of the agent being a sender or a 323 receiver. In the cases where agent A1 uses AVP and agent A2 AVPF, 324 the total RTCP session bandwidth is decreased. This is due to the 325 fact that agent A1 can send RTCP packets only with a minimum 326 interval of 5 seconds. Thus only a small fraction of the session 327 bandwidth is used for its RTCP packets. For a high bit rate session 328 (session bandwidth = 2 Mbps) the fraction of the RTCP packets from 329 agent A1 is as small as 0.01%. For smaller session bandwidths the 330 fraction increases, because the same amount of RTCP data is sent. 331 The bandwidth share that is used by RTCP packets from agent A2 is 332 not different from what was used, when both agents implemented the 333 AVPF. Thus the interaction of AVP and AVPF agents is not 334 problematic in these scenarios at all. 336 Burmeister et al. Expires September 2003 7 337 In our second unicast experiment, we show that the allowed RTCP 338 bandwidth share is not exceeded, even if packet loss occurs. We 339 simulated a constant byte error rate (BYER) on the link. The byte 340 errors are inserted randomly according to an uniform distribution. 341 Packets with byte errors are discarded on the link; hence the 342 receiving agents will not see the loss immediately. The agents 343 detect packet loss by a gap in the sequence number. 345 When the agents detect a packet loss, they feel the need to send 346 feedback. As described in AVPF [1], in unicast T_dither_max is 347 always zero, hence an early packet can be sent immediately if 348 allow_early is true. If the last packet was already an early one 349 (i.e. allow_early = false), the feedback might be appended to the 350 next regularly scheduled receiver report. The max_feedback_delay 351 parameter (which we set to 1 second in our simulations) determines 352 if that is allowed. 354 The results are shown in table 2, where we can see that there is no 355 difference in the RTCP bandwidth share, whether losses occur or not. 356 This is what we expected, because even though the RTCP packet size 357 grows and early packets are sent, the interval between the packets 358 increases and thus the RTCP bandwidth stays the same. Only the RTCP 359 bandwidth of the agents that use the AVP increases slightly. This 360 is because the interval between the packets is still 5 seconds, but 361 the packet size increased because of the feedback that is appended. 363 | | | | | | Used RTCP Bit Rate | 364 | Session | Send | Rec. | AVP | AVPF | (% of session bw) | 365 |Bandwidth|Agents|Agents|Agents|Agents| A1 | A2 | sum | 366 +---------+------+------+------+------+------+------+------+ 367 | 2 Mbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 | 368 | 2 Mbps | 1,2 | - | - | 1,2 | 2.49 | 2.49 | 4.98 | 369 | 2 Mbps | 1 | 2 | 1 | 2 | 0.01 | 2.49 | 2.50 | 370 | 2 Mbps | 1,2 | - | 1 | 2 | 0.01 | 2.48 | 2.49 | 371 | 2 Mbps | 1 | 2 | 1,2 | - | 0.01 | 0.02 | 0.03 | 372 | 2 Mbps | 1,2 | - | 1,2 | - | 0.01 | 0.01 | 0.02 | 373 |200 kbps | 1 | 2 | - | 1,2 | 2.42 | 2.56 | 4.98 | 374 |200 kbps | 1,2 | - | - | 1,2 | 2.50 | 2.49 | 4.99 | 375 |200 kbps | 1 | 2 | 1 | 2 | 0.06 | 2.50 | 2.56 | 376 |200 kbps | 1,2 | - | 1 | 2 | 0.08 | 2.49 | 2.57 | 377 |200 kbps | 1 | 2 | 1,2 | - | 0.06 | 0.07 | 0.13 | 378 |200 kbps | 1,2 | - | 1,2 | - | 0.09 | 0.08 | 0.17 | 379 | 20 kbps | 1 | 2 | - | 1,2 | 2.42 | 2.57 | 4.99 | 380 | 20 kbps | 1,2 | - | - | 1,2 | 2.52 | 2.51 | 5.03 | 381 | 20 kbps | 1 | 2 | 1 | 2 | 0.58 | 2.54 | 3.12 | 382 | 20 kbps | 1,2 | - | 1 | 2 | 0.83 | 2.43 | 3.26 | 383 | 20 kbps | 1 | 2 | 1,2 | - | 0.58 | 0.73 | 1.31 | 384 | 20 kbps | 1,2 | - | 1,2 | - | 0.86 | 0.84 | 1.70 | 386 Burmeister et al. Expires September 2003 8 387 Table 2: Unicast simulations with packet loss. 389 5.2 Multicast 391 Next, we investigated the RTCP bandwidth share in multicast 392 scenarios, i.e. we simulated the topologies T-4, T-8 and T-16 and 393 measured the fraction of the session bandwidth that was used for 394 RTCP packets. Again we considered different situations and protocol 395 configurations (e.g. with or without bit errors, groups with AVP 396 and/or AVPF agents, etc.). For reasons of readability, we present 397 only selected results. For a documentation of all results, see [5]. 399 The simulations of the different topologies in scenarios where no 400 losses occur (neither through bit errors nor through congestion) 401 show a similar behavior as in the unicast case. For all group sizes 402 the maximum used RTCP bit rate share is 5.06% of the session 403 bandwidth in a simulation of 16 session members in a low bit rate 404 scenario (session bandwidth = 20kbps) with several senders. In all 405 other scenarios without losses the used RTCP bit rate share is below 406 that. Thus the requirement, that not more than 5% of the session 407 bit rate should be used for RTCP is fulfilled with reasonable 408 accuracy. 410 Simulations, were bit errors are randomly inserted in RTP and RTCP 411 packets and the corrupted packets are discarded, give the same 412 results. The 5% rule is kept (at maximum 5.07% of the session 413 bandwidth is used for RTCP). 415 Finally we conducted simulations, where we reduced the link 416 bandwidth and thereby caused congestion related losses. These 417 simulations are different from the previous bit error simulations, 418 in that the losses occur more in bursts and are more correlated, 419 also between different agents. The correlation and burstiness of 420 the packet loss is due to the queuing discipline in the routers we 421 simulated; we used simple FIFO queues with a drop-tail strategy to 422 handle congestion. Random Early Detection (RED) queues may enhance 423 the performance, because the burstiness of the packet loss might be 424 reduced, however this is not subject of our investigations, but is 425 left for future research. The delay between the agents, which also 426 influences RTP and RTCP packets, is much more variable because of 427 the added queuing delay. Still the used RTCP bit rate share does 428 not increase beyond 5.09% of the session bandwidth. Thus also for 429 these special cases the requirement is fulfilled. 431 5.3 Summary of the RTCP bit rate measurements 433 We have shown that for unicast and reasonable multicast scenarios, 434 feedback implosion does not happen. The requirement that at maximum 436 Burmeister et al. Expires September 2003 9 437 5% of the session bandwidth is used for RTCP is fulfilled for all 438 investigated scenarios. 440 6 Feedback Measurements 442 In this chapter we describe the results of feedback delay 443 measurements, which we conducted in the simulations. Therefore we 444 use two metrics for measuring the performance of the algorithms, 445 these are the "mean waiting time" (MWT) and the number of feedback 446 packets that are sent, suppressed or not allowed. The waiting time 447 is the time, measured at a certain agent, between the detection of a 448 packet loss event and the time when the corresponding feedback is 449 sent. Assuming that the value of the feedback decreases with its 450 delay, we think that the mean waiting time is a good metric to 451 measure the performance gain we could get by using AVPF instead of 452 AVP. 454 The feedback an RTP/AVPF agent wants to send can be either sent or 455 not sent. If it was not sent, this could be due to the feedback 456 suppression, i.e. another receiver already sent the same feedback or 457 because the feedback was not allowed, i.e. the max_feedback_delay 458 was exceeded. We traced for every detected loss, if the agent sent 459 the corresponding feedback or not and if not, why. The more 460 feedback was not allowed, the worse the performance of the 461 algorithm. Together with the waiting times, this gives us a good 462 hint of the overall performance of the scheme. 464 6.1 Unicast 466 In the unicast case, the maximum dithering interval T_dither_max is 467 fixed and set to zero. This is due to the fact that it does not 468 make sense for a unicast receiver to wait for other receivers if 469 they have the same feedback to send. But still feedback can be 470 delayed or might not be permitted to be sent at all. The regularly 471 scheduled packets are spaced according to T_rr, which depends in the 472 unicast case mainly on the session bandwidth. 474 Table 3 shows the mean waiting times (MWT) measured in seconds for 475 some configurations of the unicast topology T-2. The number of 476 feedback packets that are sent or discarded is listed also (feedback 477 sent (sent) or feedback discarded (disc)). We do not list 478 suppressed packets, because for the unicast case feedback 479 suppression does not apply. In the simulations, agent A1 was a 480 sender and agent A2 a pure receiver. 482 | | | Feedback Statistics | 483 | Session | | AVP | AVPF | 484 |Bandwidth| PLR | sent |disc| MWT | sent |disc| MWT | 485 +---------+-------+------+----+-------+------+----+-------+ 487 Burmeister et al. Expires September 2003 10 488 | 2 Mbps | 0.001 | 781 | 0 | 2.604 | 756 | 0 | 0.015 | 489 | 2 Mbps | 0.01 | 7480 | 0 | 2.591 | 7548 | 2 | 0.006 | 490 | 2 Mbps | cong. | 25 | 0 | 2.557 | 1741 | 0 | 0.001 | 491 | 20 kbps | 0.001 | 79 | 0 | 2.472 | 74 | 2 | 0.034 | 492 | 20 kbps | 0.01 | 780 | 0 | 2.605 | 709 | 64 | 0.163 | 493 | 20 kbps | cong. | 780 | 0 | 2.590 | 687 | 70 | 0.162 | 495 Table 3: Feedback Statistics for the unicast simulations. 497 From the table above we see that the mean waiting time can be 498 decreased dramatically by using AVPF instead of AVP. While the 499 waiting times for agents using AVP is always around 2.5 seconds 500 (half the minimum interval) it can be decreased to a few ms for most 501 of the AVPF configurations. 503 In the cases of high session bandwidth normally all triggered 504 feedback is sent. This is because more RTCP bandwidth is available. 505 There are only very few exceptions, which are probably due to more 506 that one packet losses within one RTCP interval, where the first 507 loss was by chance sent quite early. In this case it might be 508 possible that the second feedback is triggered after the early 509 packet was sent, but possibly too early to append it to the next 510 regularly scheduled report, because of the limitation of the 511 max_feedback_delay. This is different for the cases with a small 512 session bandwidth, where the RTCP bandwidth share is quite low and 513 T_rr thus larger. After an early packet was sent the time to the 514 next regularly scheduled packet can be very high. We saw that in 515 some cases the time was larger than the max_feedback_delay and in 516 these cases the feedback is not allowed to be sent at all. 518 With a different setting of max_feedback_delay it is possible to 519 have either more feedback that is not allowed and a decreased mean 520 waiting time or more feedback that is sent but an increased waiting 521 time. Thus the parameter should be set with care according to the 522 application's needs. 524 6.2 Multicast 526 In this section we describe some measurements of feedback statistics 527 in the multicast simulations. We picked out certain characteristic 528 and representative results. We considered the topology T-16. 529 Different scenarios and applications are simulated for this 530 topology. The parameters of the different links are set as follows. 531 The agents A2, A3 and A4 are connected to the middle node of the 532 multicast tree, i.e. agent A1, via high bandwidth and low delay 533 links. The other agents are connected to the nodes 2, 3 and 4 via 534 different link characteristics. The agents connected to node 2 535 represent mobile users. They suffer in certain configurations from 536 a certain byte error rate on their access links and the delays are 538 Burmeister et al. Expires September 2003 11 539 high. The agents that are connected to node 3 have low bandwidth 540 access links, but do not suffer from bit errors. The last agents, 541 that are connected to node 4 have high bandwidth and low delay. 543 6.2.1 Shared Losses vs. Distributed Losses 545 In our first investigation, we wanted to see the effect of the loss 546 characteristic on the algorithm's performance. We investigate the 547 cases where packet loss occurs for several users simultaneously 548 (shared losses) or totally independently (distributed losses). We 549 first define agent A1 to be the sender. In the case of shared 550 losses, we inserted a constant byte error rate on one of the middle 551 links, i.e. the link between A1 and A2. In the case of distributed 552 losses, we inserted the same byte error rate on all links downstream 553 of A2. 555 These scenarios are especially interesting, because of the feedback 556 suppression algorithm. When all receivers share the same loss, it 557 is only necessary for one of them to send the loss report. Hence if 558 a member receives feedback with the same content that it has 559 scheduled to be sent, it suppresses the scheduled feedback. Of 560 course, this suppressed feedback does not contribute to the mean 561 waiting times. So we expect reduced waiting times for shared 562 losses, because the probability is high that one of the receivers 563 can send the feedback more or less immediately. The results are 564 shown in the following table. 566 | | Feedback Statistics | 567 | | Shared Losses | Distributed Losses | 568 |Agent|sent|fbsp|disc|sum | MWT |sent|fbsp|disc|sum | MWT | 569 +-----+----+----+----+----+-----+----+----+----+----+-----+ 570 | A2 | 274| 351| 25| 650|0.267| -| -| -| -| -| 571 | A5 | 231| 408| 11| 650|0.243| 619| 2| 32| 653|0.663| 572 | A6 | 234| 407| 9| 650|0.235| 587| 2| 32| 621|0.701| 573 | A7 | 223| 414| 13| 650|0.253| 594| 6| 41| 641|0.658| 574 | A8 | 188| 443| 19| 650|0.235| 596| 1| 32| 629|0.677| 576 Table 4: Feedback statistics for multicast simulations. 578 Table 4 shows the feedback statistics for the simulation of a large 579 group size. All 16 agents of topology T-16 joined the RTP session. 580 However only agent A1 acts as an RTP sender, the other agents are 581 pure receivers. Only 4 or 5 agents suffer from packet loss, i.e. 582 A2, A5, A6, A7 and A8 for the case of shared losses and A5, A6, A7 583 and A8 in the case of distributed losses. Since the number of 584 session members is the same for both cases, T_rr is also the same on 585 the average. Still the mean waiting times are reduced by more than 586 50% in the case of shared losses. This proves our assumption that 587 shared losses enhance the performance of the algorithm, regardless 588 of the loss characteristic. 590 Burmeister et al. Expires September 2003 12 591 The feedback suppression mechanism seems to be working quite fine. 592 Even though some feedback is sent from different receivers (i.e. 593 1150 loss reports are sent in total and only 650 packets were lost, 594 resulting in loss report being received on the average 1.8 times) 595 most of the redundant feedback was suppressed. I.e. 2023 loss 596 reports were suppressed from 3250 individual detected losses, which 597 means that more than 60% of the feedback was actually suppressed. 599 7 Investigations on "l" 601 In this section we want to investigate the effect of the parameter 602 "l" on the T_dither_max calculation in RTP/AVPF agents. We 603 investigate the feedback suppression performance as well as the 604 report delay for three sample scenarios. 606 For all receivers the T_dither_max value is calculated as 607 T_dither_max = l * T_rr, with l = 0.5. The rational for this is 608 that, in general, if the receiver has no RTT estimation, it does not 609 know how long it should wait for other receivers to send feedback. 610 The feedback suppression algorithm would certainly fail, if the time 611 is selected too short. However, the waiting time is increased 612 unnecessarily (and thus the value of the feedback is decreased) in 613 case the chosen value is too large. Ideally, the optimum time value 614 could be found for each case but this is not always feasible. On 615 the other hand, it is not dangerous if the optimum time is not used. 616 A decreased feedback value and a failure of the feedback suppression 617 mechanism do not hurt the network stability. We have shown for the 618 cases of distributed losses that the overall bandwidth constraints 619 are kept in any case and thus we could only loose some performance 620 by choosing the wrong time value. On the other hand, a good measure 621 for T_dither_max however is the RTCP interval T_rr. This value 622 increases with the number of session members. Also, we know that we 623 can send feedback at least every T_rr. Thus increasing T_dither max 624 beyond T_rr would certainly make no sense. So by choosing T_rr/2 we 625 guarantee that at least sometimes (i.e. when a loss is detected in 626 the first half of the interval between two regularly scheduled RTCP 627 packets) we are allowed to send early packets. Because of the 628 randomness of T_dither we still have a good chance to send the early 629 packet in time. 631 The AVPF profile specifies that the calculation of T_dither_max, as 632 given above, is common to session members having an RTT estimation 633 and to those not having it. If this were not so, participants using 634 different calculations for T_dither_max might also have very 635 different mean waiting times before sending feedback, which 636 translates into different reporting priorities. For example, in an 637 scenario where T_rr = 1s and the RTT = 100 ms, receivers using the 638 RTT estimation would, on average, send more feedback than those not 639 using it. This might partially cancel out the feedback suppression 640 mechanism and even cause feedback implosion. Also note that, in a 642 Burmeister et al. Expires September 2003 13 643 general case where the losses are shared, the feedback suppression 644 mechanism works if the feedback packets from each receiver have 645 enough time to reach each of the other ones before the calculated 646 T_dither_max seconds. Therefore, in scenarios of very high 647 bandwidth (small T_rr) the calculated T_dither_max could be much 648 smaller than the propagation delay between receivers, which would 649 translate into a failure of the feedback suppression mechanism. In 650 these cases, one solution could be to limit the bandwidth available 651 to receivers (see [10]) such that this does not happen. Another 652 solution could be to develop a mechanism for feedback suppression 653 based on the RTT estimation between senders. This will not be 654 discussed here and may be object of another document. Note, 655 however, that a really high bandwidth media stream is not that 656 likely to rely on this kind of error repair in the first place. 658 In the following, we define three representative sample scenarios. 659 We use the topology from the previous section, T-16. Most of the 660 agents contribute only little to the simulations, because we 661 introduced an error rate only on the link between the sender A1 and 662 the agent A2. 664 The first scenario represents those cases, where losses are shared 665 between two agents. One agent is located upstream on the path 666 between the other agent and the sender. Therefore, agent A2 and 667 agent A5 see the same losses, that are introduce on the link between 668 the sender and agent A2. Agents A6, A7 and A8 do not join the RTP 669 session. From the other agents only agents A3 and A9 join. All 670 agents are pure receivers, except A1 which is the sender. 672 The second scenario represents also cases, where losses are shared 673 between two agents, but this time the agents are located on 674 different branches of the multicast tree. The delays to the sender 675 are roughly of the same magnitude. Agents A5 and A6 share the same 676 losses. Agents A3 and A9 join the RTP session, but are pure 677 receivers and do not see any losses. 679 Finally, in the third scenario, the losses are shared between two 680 agents, A5 and A6. The same agents as in the second scenario are 681 active. However the delays of the links are different. The delay 682 of the link between agent A2 and A5 is reduced to 20ms and between 683 A2 and A6 to 40ms. 685 All agents beside agent A1 are pure RTP receivers. Thus these 686 agents do not have an RTT estimation to the source. T_dither_max is 687 calculated with the above given formula, depending only on T_rr and 688 l, which means that all agents should calculate roughly the same 689 T_dither_max. 691 7.1 Feedback Suppression Performance 693 Burmeister et al. Expires September 2003 14 694 The feedback suppression rate for an agent is defined as the ratio 695 of the total number of feedback packets not sent out of the total 696 number of feedback packets the agent intended to send (i.e. the sum 697 of sent and not sent). The reasons for not sending a packet 698 include: the receiver already saw the same loss reported in a 699 receiver report coming from another session member or the 700 max_feedback_delay (application-specific) was surpassed. 702 The results for the feedback suppression rate of the agent Af that 703 is further away from the sender, are depicted in Table 10. In 704 general it can be seen that the feedback suppression rate increases 705 with an increasing l. However there is a threshold, depending on 706 the environment, from which the additional gain is not significant 707 anymore. 709 | | Feedback Suppression Rate | 710 | l | Scen. 1 | Scen. 2 | Scen. 3 | 711 +------+---------+---------+---------+ 712 | 0.10 | 0.671 | 0.051 | 0.089 | 713 | 0.25 | 0.582 | 0.060 | 0.210 | 714 | 0.50 | 0.524 | 0.114 | 0.361 | 715 | 0.75 | 0.523 | 0.180 | 0.370 | 716 | 1.00 | 0.523 | 0.204 | 0.369 | 717 | 1.25 | 0.506 | 0.187 | 0.372 | 718 | 1.50 | 0.536 | 0.213 | 0.414 | 719 | 1.75 | 0.526 | 0.215 | 0.424 | 720 | 2.00 | 0.535 | 0.216 | 0.400 | 721 | 3.00 | 0.522 | 0.220 | 0.405 | 722 | 4.00 | 0.522 | 0.220 | 0.405 | 724 Table 10: Fraction of feedback that was suppressed at agent Af of 725 the total number of feedback the agent wanted to send 727 Similar results can be seen for the agent that is nearer to the 728 sender in Table 11. 730 | | Feedback Suppression Rate | 731 | l | Scen. 1 | Scen. 2 | Scen. 3 | 732 +------+---------+---------+---------+ 733 | 0.10 | 0.056 | 0.056 | 0.090 | 734 | 0.25 | 0.063 | 0.055 | 0.166 | 735 | 0.50 | 0.116 | 0.099 | 0.255 | 736 | 0.75 | 0.141 | 0.141 | 0.312 | 737 | 1.00 | 0.179 | 0.175 | 0.352 | 738 | 1.25 | 0.206 | 0.176 | 0.361 | 739 | 1.50 | 0.193 | 0.193 | 0.337 | 740 | 1.75 | 0.197 | 0.204 | 0.341 | 741 | 2.00 | 0.207 | 0.207 | 0.368 | 742 | 3.00 | 0.196 | 0.203 | 0.359 | 743 | 4.00 | 0.196 | 0.203 | 0.359 | 745 Burmeister et al. Expires September 2003 15 746 Table 11: Fraction of feedback that was suppressed at agent An of 747 the total number of feedback the agent wanted to send 749 The rate of feedback suppression failure is depicted in Table 12. 750 The trend of additional performance increase is not significant from 751 a certain threshold, dependency on the scenario is here as well 752 noticeable. 754 | |Feedback Suppr. Failure Rate | 755 | l | Scen. 1 | Scen. 2 | Scen. 3 | 756 +------+---------+---------+---------+ 757 | 0.10 | 0.273 | 0.893 | 0.822 | 758 | 0.25 | 0.355 | 0.885 | 0.624 | 759 | 0.50 | 0.364 | 0.787 | 0.385 | 760 | 0.75 | 0.334 | 0.679 | 0.318 | 761 | 1.00 | 0.298 | 0.621 | 0.279 | 762 | 1.25 | 0.289 | 0.637 | 0.267 | 763 | 1.50 | 0.274 | 0.595 | 0.249 | 764 | 1.75 | 0.274 | 0.580 | 0.235 | 765 | 2.00 | 0.258 | 0.577 | 0.233 | 766 | 3.00 | 0.282 | 0.577 | 0.236 | 767 | 4.00 | 0.282 | 0.577 | 0.236 | 769 Table 12: The ratio of feedback suppression failures. 771 Summarizing the feedback suppression results, it can be said that in 772 general the feedback suppression performance increases with an 773 increasing l. However from a certain threshold, depending on 774 environment parameters such as propagation delays or session 775 bandwidth, the additional increase is not significant anymore. 776 This threshold is not uniform across all scenarios; a value of l=0.5 777 seems to produce reasonable results with acceptable (though not 778 optimal) overhead. 780 7.2 Loss Report Delay 782 In this section we show the results for the measured report delay 783 during the simulations of the three sample scenarios. This 784 measurement is a metric of the performance of the algorithms, 785 because the value of the feedback for the sender typically decreases 786 with the delay of its reception. The loss report delay is measured 787 as the time at the sender between sending a packet and receiving the 788 first corresponding loss report. 790 | | Mean Loss Report Delay | 791 | l | Scen. 1 | Scen. 2 | Scen. 3 | 792 +------+---------+---------+---------+ 793 | 0.10 | 0.124 | 0.282 | 0.210 | 794 | 0.25 | 0.168 | 0.266 | 0.234 | 795 | 0.50 | 0.243 | 0.264 | 0.284 | 797 Burmeister et al. Expires September 2003 16 798 | 0.75 | 0.285 | 0.286 | 0.325 | 799 | 1.00 | 0.329 | 0.305 | 0.350 | 800 | 1.25 | 0.351 | 0.329 | 0.370 | 801 | 1.50 | 0.361 | 0.363 | 0.388 | 802 | 1.75 | 0.360 | 0.387 | 0.392 | 803 | 2.00 | 0.367 | 0.412 | 0.400 | 804 | 3.00 | 0.368 | 0.507 | 0.398 | 805 | 4.00 | 0.368 | 0.568 | 0.398 | 807 Table 13: The mean loss report delay, measured at the sender. 809 As can be seen from Table 13 the delay increases in general with an 810 increasing value of l. Also, a similar effect as for the feedback 811 suppression performance is present: from a certain threshold, the 812 additional increase in delay is not significant anymore. The 813 threshold is environment dependent and seems to be related to the 814 threshold, where the feedback suppression gain would not increase 815 anymore. 817 7.3 Summary of "l" investigations 819 We have shown experimentally that the performance of the feedback 820 suppression mechanisms increases with an increasing value of l. The 821 same applies for the report delay, which increases also with an 822 increasing l. This leads to a threshold where both the performance 823 and the delay does not increase any further. The threshold is 824 environment dependent. 826 So finding an optimum value of l is not possible because it is 827 always a trade-off between delay and feedback suppression 828 performance. With l=0.5 we think that a tradeoff was found that is 829 acceptable for typical applications and environments. 831 8 Applications Using AVPF 833 NEWPRED is one of the error resilience tools, which is defined in 834 both ISO/IEC MPEG-4 visual part and ITU-T H.263. NEWPRED achieves 835 fast error recovery using feedback messages. We simulated the 836 behavior of NEWPRED in the network simulator environment as 837 described above and measured the waiting time statistics, in order 838 to verify that the extended RTP profile for RTCP-based feedback 839 (AVPF)[1] is appropriate for the NEWPRED feedback messages. 840 Simulation results, which present in the following sections, show 841 that the waiting time is small enough to get the expected 842 performance of NEWPRED. 844 8.1 NEWPRED Implementation in NS2 846 Burmeister et al. Expires September 2003 17 847 The agent that performs the NEWPRED functionality, called NEWPRED 848 agent, is different from the RTP agent we described above. Some of 849 the added features and functionalities are described in the 850 following points: 852 Application Feedback 853 The "Application Layer Feedback Messages" format is used to 854 transmit the NEWPRED feedback messages. Thereby the NEWPRED 855 functionality is added to the RTP agent. The NEWPRED agent 856 creates one NACK message for each lost segment of a video frame, 857 and then assembles a plural number of NACK messages corresponding 858 to the segments in the same video frame, into one Application 859 Layer Feedback Message. Although there are two modes, namely 860 NACK mode and ACK mode in NEWPRED [6][7], only NACK mode is used 861 in these simulations. 863 The parameters of NEWPRED agent are as follows: 864 f: Frame Rate(frames/sec) 865 seg: Number of segments in one video frame 866 bw: RTP session bandwidth(kbps) 868 Generation of NEWPRED's NACK Messages 869 The NEWPRED agent generates NACK messages when segments are lost. 870 a. The NEWPRED agent generates plural number of NACK messages per 871 one video frame when plural number of segments are lost. These 872 are assembled into one FCI message per video frame. If there 873 is no lost segment, no message is generated and sent. 874 b. The length of one NACK message is 4 bytes. Let num be the 875 number of NACK messages in one video frame(1 <= num <= seg). 876 Thus, 12+4*num bytes is the size of the low delay RTCP feedback 877 message. 879 Measurements 880 We defined two values to be measured: 881 - Recovery time 882 The recovery time is measured as the time between the detection 883 of a lost segment and reception of a recovered segment. We 884 measured this "recovery time" for each lost segment. 885 - Waiting time 886 The waiting time is the additional delay due to the feedback 887 limitation of RTP. 889 Fig.1 depicts the behavior of a NEWPRED agent when a loss occurs. 890 The recovery time is approximated as follows: 891 (Recovery time) = (Waiting time) + 892 (Transmission time for feedback message) + 893 (Transmission time for media data) 895 Therefore, the waiting time is derived as follows: 897 (Waiting time) = (Recovery time) - (Round-trip delay), where 899 Burmeister et al. Expires September 2003 18 900 (Round-trip delay ) = (Transmission time for feedback message) + 901 (Transmission time for media data) 903 Picture Reference |: Picture Segment 904 ____________________ %: Lost Segment 905 /_ _ _ _ \ 906 v/ \ / \ / \ / \ \ 907 v \v \v \v \ \ 908 Sender ---|----|----|----|----|----|---|-------------> 909 \ \ ^ \ 910 \ \ / \ 911 \ \ / \ 912 \ v / \ 913 \ x / \ 914 \ Lost / \ 915 \ x / \ _____ 916 v x / NACK v 917 Receiver ---------------|----%===-%----%----%----|-----> 918 |-a-| | 919 |------- b -------| 921 a: Waiting time 922 b: Recover time (%: Video segments are lost) 924 Fig.1: Relation between the measured values at the NEWPRED agent 926 8.2 Simulation 928 We conducted two simulations (Simulation A and Simulation B). In 929 Simulation A, the packets are dropped with a fixed packet loss rate 930 on a link between two NEWPRED agents. In Simulation B, packet loss 931 occurs due to congestion from other traffic sources, i.e. ftp 932 sessions. 934 8.2.1. Simulation A - Constant Packet Loss Rate 936 The network topology, used for this simulation is shown in Fig.2. 938 Link 1 Link 2 Link 3 939 +--------+ +------+ +------+ +--------+ 940 | Sender |------|Router|-------|Router|------|Receiver| 941 +--------+ +------+ +------+ +--------+ 943 Burmeister et al. Expires September 2003 19 944 10(msec) x(msec) 10(msec) 946 Fig2. Network topology that is used for Simulation A 948 Link1 and link3 are error free, and each link delay is 10 msec. 949 Packets may get dropped on link2. The packet loss rates (Plr) and 950 link delay (D) are as follows: 952 D [ms] = {10, 50, 100, 200, 500} 953 Plr = {0.005, 0.01, 0.02, 0.03, 0.05, 0.1, 0.2} 954 Session band width, frame rate and the number of segments are 955 shown in Table 14 957 +------------+----------+-------------+-----+ 958 |Parameter ID| bw(kbps) |f (frame/sec)| seg | 959 +------------+----------+-------------+-----+ 960 | 32k-4-3 | 32 | 4 | 3 | 961 | 32k-5-3 | 32 | 5 | 3 | 962 | 64k-5-3 | 64 | 5 | 3 | 963 | 64k-10-3 | 64 | 10 | 3 | 964 | 128k-10-6 | 128 | 10 | 6 | 965 | 128k-15-6 | 128 | 15 | 6 | 966 | 384k-15-6 | 384 | 15 | 6 | 967 | 384k-30-6 | 384 | 30 | 6 | 968 | 512k-30-6 | 512 | 30 | 6 | 969 | 1000k-30-9 | 1000 | 30 | 9 | 970 | 2000k-30-9 | 2000 | 30 | 9 | 971 +------------+----------+-------------+-----+ 973 Table 14: Parameter sets of the NEWPRED agents 975 Figure3 shows the packet loss rate vs. mean of waiting time. A 976 plotted line represents a parameter ID ( "[session bandwidth] - 977 [frame rate] - [the number of segments] - [link2 delay]" ). E.g. 978 384k-15-9-100 means the session of 384kbps session bandwidth, 15 979 frames per second, 9 segments per frame and 100msec link delay. 981 When the packet loss rate is 5% and the session bandwidth is 32kbps, 982 the waiting time is around 400msec, which is just allowable for 983 reasonable NEWPRED performance. 985 When the packet loss rate is less than 1%, the waiting time is less 986 than 200msec. In such a case, the NEWPRED allows as much as 200msec 987 additional link delay. 989 When the packet loss rate is less than 5% and the session bandwidth 990 is 64kbps, the waiting time is also less than 200msec. 992 In 128kbps cases, the result shows that when the packet loss rate is 993 20%, the waiting time is around 200msec. In cases with more than 995 Burmeister et al. Expires September 2003 20 996 512kbps session bandwidth, there is no significant delay. This 997 means that the waiting time due to the feedback limitation of RTCP 998 is neglectable for the NEWPRED performance. 1000 +------------------------------------------------------------+ 1001 | | Packet Loss Rate = | 1002 | Bandwidth | 0.005| 0.01 | 0.02 | 0.03 | 0.05 |0.10 |0.20 | 1003 |-----------+------+------+------+------+------+------+------| 1004 | 32k |130- |200- |230- |280- |350- |470- |560- | 1005 | | 180| 250| 320| 390| 430| 610| 780| 1006 | 64k | 80- |100- |120- |150- |180- |210- |290- | 1007 | | 130| 150| 180| 190| 210| 300| 400| 1008 | 128k | 60- | 70- | 90- |110- |130- |170- |190- | 1009 | | 70| 80| 100| 120| 140| 190| 240| 1010 | 384k | 30- | 30- | 30- | 40- | 50- | 50- | 50- | 1011 | | 50| 50| 50| 50| 60| 70| 90| 1012 | 512k | < 50 | < 50 | < 50 | < 50 | < 50 | < 50 | < 60 | 1013 | | | | | | | | | 1014 | 1000k | < 50 | < 50 | < 50 | < 50 | < 50 | < 50 | < 55 | 1015 | | | | | | | | | 1016 | 2000k | < 30 | < 30 | < 30 | < 30 | < 30 | < 35 | < 35 | 1017 +------------------+------+------+------+------+------+------+ 1019 Fig. 3 The result of simulation A 1021 8.2.2. Simulation B - Packet Loss due to Congestion 1023 The configuration of link1, link2, and link3 are the same as in 1024 simulation A except that link2 is also error-free, regarding bit 1025 errors. However in addition, some FTP agents are deployed to 1026 overload link2. See Figure 4 for the simulation topology. 1028 Link1 Link2 Link3 1029 +--------+ +------+ +------+ +--------+ 1030 | Sender |------|Router|-------|Router|------|Receiver| 1031 +--------+ /|+------+ +------+|\ +--------+ 1032 +---+/ | | \+---+ 1033 +-|FTP|+---+ +---+|FTP|-+ 1034 | +---+|FTP| ... |FTP|+---+ | ... 1035 +---+ +---+ +---+ +---+ 1037 FTP Agents FTP Agents 1039 Fig4. Network Topology of Simulation B 1041 Burmeister et al. Expires September 2003 21 1042 The parameters are defined as for Simulation A with the following 1043 values assigned: 1045 D[ms] ={10, 50, 100, 200, 500} 1046 32 FTP agents are deployed at each edge, and totally 64 FTP 1047 agents are active. 1048 The sets of session bandwidth, frame rate, the number of segments 1049 are the same as in Simulation A (Table 14) 1051 We provide the results for the cases of 64 FTP agents, because these 1052 are the cases where packet losses could be detected stable. The 1053 results are similar to the Simulation A except for a constant 1054 additional offset of 50..100ms. This is due to the delay incurred 1055 by the routers buffers. 1057 8.3 Summary of Application Simulations 1059 We have shown that the limitations of RTP AVPF profile do not 1060 generate such high delay to the feedback messages that the 1061 performance of NEWPRED is degraded in the sessions from 32kbps to 1062 2Mbps. We could see that the waiting time increases with a 1063 decreasing session bandwidth and/or an increasing packet loss rate. 1064 Thereby it is not significant what the packet loss caused. 1065 Congestion or constant packet loss rates behave similar. Still we 1066 see that for reasonable conditions and parameters the AVPF is well 1067 suited to support the feedback needed for NEWPRED. 1069 9 Summary 1071 The new RTP profile AVPF was investigated regarding performance and 1072 potential risks to the network stability. Simulations were 1073 conducted using the network simulator, simulating unicast and 1074 several differently sized multicast topologies. The results were 1075 shown in this document. 1077 Regarding the network stability, it was important to show that the 1078 new profile does not lead to any feedback implosion, or uses more 1079 bandwidth as it is allowed. Thus we measured the bandwidth that was 1080 used for RTCP in relation to the RTP session bandwidth. We have 1081 shown that, more or less exactly, 5% of the session bandwidth is 1082 used for RTCP, in all considered scenarios. Other RTCP bandwidth 1083 values could be set using the RTCP bandwidth modifiers [10]. The 1084 scenarios included unicast with and without bit errors, different 1085 sized multicast groups, with and without errors or congestion on the 1086 links. Thus we can say that the new profile behaves network- 1087 friendly in the sense that it uses only the allowed RTCP bandwidth, 1088 as defined by RTP. 1090 Burmeister et al. Expires September 2003 22 1091 Secondly, we have shown that receivers using the new profile 1092 experience a performance gain. This was measured by capturing the 1093 delay that the sender sees for the received feedback. Using the new 1094 profile this delay can be decreased by orders of magnitude. 1096 In the third place, we investigated the effect of the parameter "l" 1097 on the new algorithms. We have shown that there does not exist an 1098 optimum value for it but only a trade-off can be achieved. The 1099 influence of this parameter is highly environment-specific and a 1100 trade-off between performance of the feedback suppression algorithm 1101 and the experienced delay has to be met. The recommended value of 1102 l= 0.5 given in the draft seems to be reasonable for most 1103 applications and environments. 1105 References 1107 1 J. Ott, S. Wenger, N. Sato, C. Burmeister, and J. Rey, "Extended 1108 RTP Profile for RTCP-based Feedback", Internet Draft, draft-ietf- 1109 avt-rtcp-feedback-05.txt, Work in Progress, February 2003. 1111 2 H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, " RTP - 1112 A Transport Protocol for Real-time Applications, Internet Draft, 1113 draft-ietf-avt-rtp-new-11.txt, Work in Progress, May 2002. 1115 3 H. Schulzrinne, S. Casner, "RTP Profile for Audio and Video 1116 Conferences with Minimal Control", Internet Draft, draft-ietf-avt- 1117 profile-new-11.txt, Work in Progress, July 2001. 1119 4 Network Simulator Version 2 - ns-2, available from 1120 http://www.isi.edu/nsnam/ns. 1122 5 C. Burmeister, T. Klinner, "Low Delay Feedback RTCP - Timing Rules 1123 Simulation Results". Technical Report of the Panasonic European 1124 Laboratories, September 2001, available from: 1125 http://www.informatik.uni-bremen.de/~jo/misc/SimulationResults- 1126 A.pdf. 1128 6 ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology - 1129 Coding of audio-visual objects - Part2: Visual", July 2000. 1131 7 ITU-T Recommendation, H.263. Video encoding for low bitrate 1132 communication. 1998. 1134 8 S. Fukunaga, T. Nakai, and H. Inoue, "Error Resilient Video Coding 1135 by Dynamic Replacing of Reference Pictures," IEEE Global 1136 Telecommunications Conference (GLOBECOM), pp.1503-1508, 1996. 1138 9 H. Kimata, Y. Tomita, H. Yamaguchi, S. Ichinose, T. Ichikawa, 1139 "Receiver-Oriented Real-Time Error Resilient Video Communication 1141 Burmeister et al. Expires September 2003 23 1142 System: Adaptive Recovery from Error Propagation in Accordance 1143 with Memory Size at Receiver," Electronics and Communications in 1144 Japan, Part 1, vol.84, no.2, pp.8-17, 2001. 1146 10 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", draft- 1147 ietf-avt-rtcp-bw-05.txt, May 2002. 1149 IPR Notices 1151 The IETF takes no position regarding the validity or scope of any 1152 intellectual property or other rights that might be claimed to 1153 pertain to the implementation or use of the technology described in 1154 this document or the extent to which any license under such rights 1155 might or might not be available; neither does it represent that it 1156 has made any effort to identify any such rights. Information on the 1157 IETF's procedures with respect to rights in standards-track and 1158 standards-related documentation can be found in BCP 11 [13]. Copies 1159 of claims of rights made available for publication and any assurances 1160 of licenses to be made available, or the result of an attempt made to 1161 obtain a general license or permission for the use of such 1162 proprietary rights by implementers or users of this specification can 1163 be obtained from the IETF Secretariat. 1165 The IETF invites any interested party to bring to its attention any 1166 copyrights, patents or patent applications, or other proprietary 1167 rights which may cover technology that may be required to practice 1168 this standard. Please address the information to the IETF Executive 1169 Director. 1171 Authors' Address 1173 Carsten Burmeister 1174 Panasonic European Laboratories GmbH 1175 Monzastr. 4c, 63225 Langen, Germany 1176 mailto: burmeister@panasonic.de 1178 Rolf Hakenberg 1179 Panasonic European Laboratories GmbH 1180 Monzastr. 4c, 63225 Langen, Germany 1181 mailto: hakenberg@panasonic.de 1183 Akihiro Miyazaki 1184 Matsushita Electric Industrial Co., Ltd 1185 1006, Kadoma, Kadoma City, Osaka, Japan 1186 mailto: akihiro@isl.mei.co.jp 1188 Joerg Ott 1189 Universitdt Bremen TZI 1190 MZH 5180, Bibliothekstr. 1, 28359 Bremen, Germany 1192 Burmeister et al. Expires September 2003 24 1193 {sip,mailto}: jo@tzi.uni-bremen.de 1195 Noriyuki Sato 1196 Oki Electric Industry Co., Ltd. 1197 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan 1198 mailto: sato652@oki.co.jp 1200 Shigeru Fukunaga 1201 Oki Electric Industry Co., Ltd. 1202 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan 1203 mailto: fukunaga444@oki.co.jp 1205 Full Copyright Statement 1207 "Copyright (C) The Internet Society (2003). All Rights Reserved. 1209 This document and translations of it may be copied and furnished to 1210 others, and derivative works that comment on or otherwise explain it 1211 or assist in its implementation may be prepared, copied, published 1212 and distributed, in whole or in part, without restriction of any 1213 kind, provided that the above copyright notice and this paragraph are 1214 included on all such copies and derivative works. However, this 1215 document itself may not be modified in any way, such as by removing 1216 the copyright notice or references to the Internet Society or other 1217 Internet organizations, except as needed for the purpose of 1218 developing Internet standards in which case the procedures for 1219 copyrights defined in the Internet Standards process must be 1220 followed, or as required to translate it into languages other than 1221 English. 1223 The limited permissions granted above are perpetual and will 1224 not be revoked by the Internet Society or its successors or 1225 assigns. 1227 This document and the information contained herein is provided on an 1228 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1229 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1230 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1231 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1232 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1234 Burmeister et al. Expires September 2003 25