idnits 2.17.1 draft-leon-rtp-retransmission-02.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 1 longer page, the longest (page 1) being 695 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 2002) is 8071 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 87 looks like a reference -- Missing reference section? '2' on line 106 looks like a reference -- Missing reference section? '3' on line 127 looks like a reference -- Missing reference section? '4' on line 431 looks like a reference -- Missing reference section? '5' on line 522 looks like a reference -- Missing reference section? '6' on line 451 looks like a reference -- Missing reference section? '7' on line 437 looks like a reference -- Missing reference section? '8' on line 503 looks like a reference -- Missing reference section? '9' on line 510 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 David Leon 3 Internet Draft Viktor Varsa 4 Document: draft-leon-rtp-retransmission-02.txt Nokia 5 Expires: September 2002 March 2002 7 RTP retransmission framework 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 RTP retransmission is an effective packet loss recovery scheme for 32 real-time applications with relaxed delay bounds. 34 This document describes an RTP retransmission framework. It defines 35 a payload format for retransmitted packets and recommends rules for 36 sending these packets. Retransmitted RTP packets are sent in a 37 separate stream from the original RTP stream. It is assumed that 38 feedback from receivers to senders indicating the occurred packet 39 losses is available by some means not defined here. 41 Main changes since draft-leon-rtp-retransmission-01.txt 43 The draft was updated according to the comments given at IETF#52: 45 *The draft describes the use of the redundancy payload format (RFC 46 2198) in order to send retransmission data and original data in the 47 same stream. 49 Leon, Varsa IETF draft - Expires September 2002 1 50 RTP retransmission framework March 2002 52 *The draft gives some motivations in defining this retransmission 53 framework document instead of using the FEC payload format (RFC 54 2733) 56 *Congestion section rewritten so as to state clearly the risks of 57 RTP retransmission. Congestion control rules when using RTP 58 retransmission have been clarified. 60 Editorial modifications were made throughout the text. 62 Table of Contents 64 Abstract...........................................................1 65 Main changes since draft-leon-rtp-retransmission-01.txt............1 66 1. Introduction....................................................2 67 2. Terminology.....................................................3 68 3. Retransmission framework basic principles.......................3 69 4. Retransmission payload format...................................5 70 5. Use with the Extended RTP profile for RTCP-based feedback.......5 71 6. Congestion control and scheme efficiency........................7 72 7. Example scenario................................................8 73 8. Retransmission piggybacked on original packets..................9 74 9. SDP usage.......................................................9 75 10. FEC for retransmission........................................10 76 11. Security consideration........................................11 77 12. References....................................................11 78 Author's Addresses................................................12 80 1. Introduction 82 Packet losses between an RTP sender and receiver may significantly 83 degrade the quality of the received signal. Several techniques, such 84 as forward error correction (FEC), retransmissions or adaptation of 85 application layer (e.g. video) error resilience techniques based on 86 back-channel messages may be considered to increase the robustness 87 to packet loss. RFC-2354 [1] discusses the different options. 89 When choosing a technique for a particular system, the tolerable 90 latency of the application has to be taken into account. In the case 91 of multimedia conferencing, the end-to-end delay has to be at most a 92 few hundred milliseconds in order to guarantee interactivity, which 93 usually excludes the use of retransmission. On the other hand, in 94 the case of multimedia streaming, the user can tolerate an initial 95 latency as part of the session setup and thus an end-to-end delay of 96 several seconds is possible. Retransmission may thus be considered 97 for such applications. 99 Leon, Varsa - Expires September 2002 2 100 RTP retransmission framework March 2002 102 This document proposes a retransmission framework. It defines a 103 payload format for retransmitted RTP packets and retransmission 104 rules. This RTP retransmission scheme requires frequent packet loss 105 indication feedback to the RTP entity performing retransmission. The 106 AV profile [2] does not provide this feature and could therefore not 107 be used. However, the retransmission scheme could be run under the 108 extended RTP profile for RTCP-based feedback[3] which defines a NACK 109 message that can be sent as part of a compound RTCP packet. 111 2. Terminology 113 The following terms are used in this document: 115 Original packet: refers to an RTP packet sent by an RTP sender as 116 part of an RTP stream. 118 Original stream: refers to the stream of original packets. 120 Retransmission packet: refers to an RTP packet whose payload 121 includes the payload of an already sent original packet. Such a 122 retransmission packet is said to be associated with the original RTP 123 packet whose payload is included in the retransmission packet. 125 Retransmission request: a means by which an RTP receiver is able to 126 request that the RTP sender send a retransmission packet associated 127 with a given original packet. In [3], a retransmission request is 128 sent as a packet loss indication in a NACK message. 130 Retransmission stream: the stream of retransmission packets 131 associated to with an original stream. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 135 this document are to be interpreted as described in RFC-2119 [4]. 137 3. Retransmission framework basic principles 139 Retransmission packets MUST NOT share the RTP Sequence Number (SN) 140 space with the original stream. The retransmission stream SHOULD use 141 a different RTP session (as defined in RTP [5]) from that of the 142 original stream. When a separate session is used, the original and 143 retransmission streams are sent to different multicast group/unicast 144 addresses and/or port numbers. The retransmission stream has then 145 its own SN space. The retransmission stream MAY also be sent as 146 redundant data piggybacked to the original packets as shown in 147 Section 9. In the latter case, the retransmission stream does not 148 have any SN space. 150 There are several reasons why the SN space must not be shared: 152 Leon, Varsa - Expires September 2002 3 153 RTP retransmission framework March 2002 155 Since retransmission packets do not share the SN space with the 156 original packets, the receiver is able to distinguish between the 157 loss of original packets and retransmission packets. Otherwise, 158 reliable data loss detection would not be possible. Reliable data 159 loss detection is mandated for example in RTP conversational text 160 [6]. 162 RTP Timestamp (TS) estimation of missing original packets is 163 necessary at the receiver in order to decide whether a 164 retransmission is useful or not. A retransmission is useful if the 165 retransmission packet as a response to the retransmission request is 166 estimated to arrive at the receiver before the time it is used for 167 playback (playout time). The missing original packet TS can be 168 estimated from TS of packets preceding and following the SN gap 169 caused by the missing packet in the original stream. 170 The fact that RTP streams for original and retransmission packets do 171 not share the same SN space guarantees that the RTP timestamp 172 estimation method is reliable. Reliability would be sacrificed if 173 original and retransmission packets were sent in the same RTP 174 stream. The TS estimate for a lost retransmission packet ,when 175 calculated as above, would then be incorrect. This is because the 176 retransmission packet usually has a smaller "out-of-order" TS than 177 the TS of the consecutive original packets. 179 There are some additional advantages when the RTP stream is sent to 180 a separate session vs. piggybacked data: 182 There are no modifications to the payload format of the original 183 packets. Retransmission can thus work with any existing payload 184 format. 186 When the retransmission stream is sent to a multicast RTP session, 187 receivers may choose to subscribe or not to subscribe to the RTP 188 session carrying the retransmission stream. Thus, a multicast 189 streaming application can use retransmission and still be backwards 190 compatible as receivers which do not implement the retransmission 191 payload format only join the RTP session carrying the original 192 stream. A scenario where the original session is multicast and 193 separate unicast sessions carry the retransmission stream to each 194 participant, is also possible. In this scenario a receiver can 195 receive retransmission packets only for original packets that it has 196 itself requested, and not the retransmission packets that are sent 197 as responses to retransmission requests from other receivers. 199 5. Mixers, translators and packet caches may be able to separate 200 retransmission packets from original packets at an RTP session level 201 and process them differently if necessary. 203 6. As a consequence of having separate RTP sessions for original and 204 retransmission streams, there are also separate RTCP streams and 205 statistics for these two sessions. There is thus no corruption of 206 the original stream RTCP statistics. The RTP sender is able to know 207 the packet loss and jitter of the original stream. It can thus 209 Leon, Varsa - Expires September 2002 4 210 RTP retransmission framework March 2002 212 estimate what the quality of the received signal would be without 213 the use of retransmission. 215 4. Retransmission payload format 217 The payload format of a retransmission packet is shown below. 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | RTP Header | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 |E| OPT | OSN | | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 224 | Original RTP Packet Payload | 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 RTP header usage: 229 The same SSRC value SHOULD be used for the original stream and the 230 retransmission stream. In the RTP header, SN has the standard 231 definition, i.e. it MUST be one higher than the SN of the preceding 232 retransmission packet. The payload type is dynamic and indicates the 233 use of the retransmission payload format. All other fields of the 234 RTP header have the same value as in the original RTP packet. 236 The retransmission packet payload carries an E bit, an OPT field (7 237 bits) and an OSN field (2 bytes) followed by the original RTP packet 238 payload. The E bit is an extension bit for future-proofing. It MUST 239 be set to zero. The OPT field is the payload type of the original 240 packet payload that is being retransmitted. The OSN field is the SN 241 of the original packet that originally carried the same payload. 243 5. Use with the Extended RTP profile for RTCP-based feedback 245 When the Extended RTP profile for RTCP-based feedback [4] is used, 246 it is RECOMMENDED that receivers send retransmission requests 247 according to the rules in this section. The rules described 248 hereafter aim at limiting the maximum delay before a retransmission 249 request can be sent and are compliant to the more general rules 250 described in the profile itself. 252 5.1 Sending rules for RTCP-based feedback 254 The minimum RTCP report interval is computed according to the 255 allowed RTCP bandwidth of a given session (obtained explicitly or 256 calculated as a percentage of the RTP session bandwidth). The NACK 257 message format defined in the profile is used. Early RTCP packets 258 SHOULD NOT be used, and the NACK message SHOULD always be appended 259 to a regularly scheduled compound RTCP packet that is sent at every 260 RTCP report interval T_rr. 262 Leon, Varsa - Expires September 2002 5 263 RTP retransmission framework March 2002 265 Any other rules to send feedback MAY be used as long as they are 266 compliant with the profile in use. In particular, a receiver MAY 267 send NACK messages in early RTCP packets. However, in that case the 268 time when the next RTCP packet following this early RTCP packet can 269 be sent could be too late to report a loss occurring right after the 270 early RTCP packet was sent. Sending RTCP packets at regular 271 intervals guarantees that the delay between detecting an original 272 packet loss and being able to send a NACK message for that packet is 273 no longer than the regular RTCP interval. 275 A receiver should compute an estimate of the delay D to receive a 276 retransmission packet after a NACK message has been sent. This 277 estimate may be obtained from past observations, RTCP report round- 278 trip time if available or any other means. 280 The minimum receiver buffering delay B (i.e. the time between a 281 packet is received and its payload is used at the receiver) is the 282 RTCP reporting interval added to the delay estimate, which 283 guarantees that a retransmission packet as a response to a sent 284 retransmission request can be received before its payload is used. 285 i.e. 286 B>T_rr+D 288 It can be seen that the needed receiver buffering delay is dependent 289 on the amount of RTCP traffic allowed in the session. It is 290 illustrated in Section 7 that moderate RTCP feedback traffic is 291 enough to perform retransmission with reasonable receiver buffering 292 delay. 294 5.2 Receiver algorithm for generating retransmission requests 296 A receiver needs to maintain a list of missing original packet 297 sequence numbers (SN) since its last sent RTCP packet. A receiver 298 needs also to store for each missing original packet an estimated 299 RTP timestamp (TS) as described in Section 3. 301 At the next scheduled RTCP packet time, the receiver estimates based 302 on the estimated TS of the missing original packet if a 303 retransmission packet as a response to a NACK message that would be 304 sent in the current RTCP packet could arrive at the receiver before 305 its playout time or not. If not, it removes the packet SN from its 306 list of missing packets. The receiver then sends retransmission 307 requests for the missing original packets by adding the SNs of the 308 missing original packets to a NACK message in the scheduled RTCP 309 compound packet (see usage of the PID and BLP fields of the NACK 310 message format in [4]). If needed for signalling of multiple missing 311 SN, multiple NACK messages can be added to the RTCP compound 312 packet.. 314 If the retransmission stream is sent to a multicast session, the 315 receiver SHOULD listen to NACK messages from other receivers. If a 317 Leon, Varsa - Expires September 2002 6 318 RTP retransmission framework March 2002 320 NACK message for the SN of a missing packet at the receiver has been 321 sent by another receiver, the receiver SHOULD ignore that SN in its 322 list of missing packets and refrain from sending a retransmission 323 request for that SN. 325 The same retransmission request may be resent by the receiver if no 326 retransmission packet with OSN equal to the missing original packet 327 SN was received after an estimated retransmission reception time. 328 This increases robustness to the loss of a NACK message or of a 329 retransmission packet. The repeated retransmission request may be 330 sent at the earliest at the next RTCP report scheduled time. 331 Repeated retransmission requests MUST be sent in the original RTP 332 session and not in the retransmission RTP session. The number of 333 repeated retransmission requests that may be sent for a given 334 missing original packet SN depends on the ratio of the receiver 335 buffering delay and RTCP session bandwidth. 337 The receiver should upon reception of a retransmission packet remove 338 the SN corresponding to the original packet (OSN in the 339 retransmission payload format) from the list of missing SNs. 341 5.3 RTCP sending rules in the retransmission RTP session 343 When the original stream and the retransmission stream are carried 344 in separate RTP sessions, the retransmission stream has its own RTCP 345 stream as well. The amount of RTCP sent for the retransmission 346 stream is computed as a fraction of the retransmission RTP session 347 bandwidth. Since, the retransmission traffic is limited, the 348 overhead caused by the additional RTCP packets in the retransmission 349 RTP session is moderate. For example, assuming a 64 kbps original 350 RTP session and on average 3% packet loss and all lost original 351 packets retransmitted once, the bandwidth of the retransmission RTP 352 session would be about 2 kbps. In this case the recommended RTCP 353 traffic for the retransmission RTP session would be 0.1 kbps. 355 Early RTCP packets and RTCP feedback messages SHOULD NOT be used in 356 the retransmission RTP session. 358 6. Congestion control 360 RTP retransmission poses a risk of increased network congestion. In 361 a best-effort environment, packet loss is caused by congestion. 362 Reacting to loss by retransmitting older packets in addition to the 363 current data would thus further increase congestion. Implementations 364 SHOULD follow the recommendations below in order to use 365 retransmission. 367 The RTP profile under which the retransmission scheme is used 368 defines an appropriate congestion control mechanism in different 370 Leon, Varsa - Expires September 2002 7 371 RTP retransmission framework March 2002 373 environments. Following the rules under this profile, an RTP 374 application can determine its acceptable bitrate and packet rate in 375 order to be fair to other applications such as TCP flows and other 376 RTP flows. 378 If an RTP application uses retransmission, the acceptable packet 379 rate and bitrate SHOULD include both the original and retransmitted 380 data. This will guarantee that an application using retransmission 381 should be fair to any other RTP or TCP flows. Such a rule would 382 translate in practice into the following actions: 384 If enhanced service is used it should made sure that the total 385 bitrate and packet rate do not exceed that of the requested service. 386 It should be further monitored that the requested services are 387 actually delivered. In a best-effort environment, the sender SHOULD 388 NOT send retransmission packets without reducing the packet rate and 389 bitrate of the original stream (for example by encoding the data at 390 a lower rate). 392 In addition, the sender MAY retransmit only the packets that it 393 deems important and ignore NACK messages for other packets in order 394 to limit the bitrate 396 These congestion control mechanisms should keep the congestion level 397 under an acceptable limit. This would in turn guarantee that the 398 packet loss should be moderate. Too high a packet loss would mean 399 that congestion is not kept under control and retransmission should 400 then not be used. 402 7. Example scenario of unicast streaming 404 Let us assume that the RTP session bandwidth is 64 kbps and the 405 receiver buffering delay is 3 seconds. The network round trip time 406 is 500 ms and Receiver RTCP packets are sent at 2-second intervals 407 from the receiver including NACK messages for missing original 408 packet SNs. With these time limitations, when the receiver algorithm 409 for generating retransmission requests described in Section 5.2 is 410 followed, only one NACK message but no repeated NACK messages can be 411 sent for the same original packet loss. Let us assume an original 412 packet rate of 50 packets per second (1 packet every 20 ms). At this 413 packet rate in a packet loss distribution worst case scenario where 414 every 17th original packet is lost (i.e. 5.88% uniform packet loss), 415 a maximum of 6 NACK messages need to be appended to the RTCP 416 compound packet that is sent every 2 seconds. The 6 NACK messages 417 can report any packet losses in an SN range of 6*17=102, thus the 418 number of required NACK messages would not increase with higher 419 packet loss rates. The overhead required per RTCP compound packet 420 for the 6 NACK messages is 36 bytes which carries 6 PID and 6 BLP 421 fields in addition to the feedback message headers. 423 The total compound RTCP packets size is thus: IPv4 (20) + UDP (8)+ 424 RR(header 8 + report 24)+ CNAME(12)+ NACK (36) = 108 bytes. The 425 needed receiver RTCP bandwidth would then be 0.432 kbps. This RTCP 427 Leon, Varsa - Expires September 2002 8 428 RTP retransmission framework March 2002 430 bandwidth is well below the maximum allowed RTCP bandwidth that 431 would be allowed when using [4]. From the receiver to the sender the 432 RTCP bandwidth limit in an RTP session with 64 kbps is about 0.25*64 433 = 1.6 kbps. 435 8. Retransmission piggybacked onto original packets 437 The RTP payload format for redundant audio data [7] may be used to 438 send retransmitted data within the same RTP stream. It may either be 439 used instead of the retransmission payload format or complementarily 440 to the retransmission payload format. 442 Original packet payloads for which a retransmission request was 443 received from the receiver may be sent piggybacked to other original 444 packets as if they were redundant data. Although this may be 445 suitable for some applications, such a scheme is not generally 446 applicable, as the RTP payload format for redundant audio data can 447 not carry all the RTP header fields of the retransmitted data which 448 are necessary to implement a complete retransmission scheme. In 449 particular, the receiver would not know the original SN of the 450 retransmitted data. This fact is very limiting as some applications 451 like conversational text [6] could not use the retransmitted data 452 without the SN. 454 On the other hand, the payload format for redundant audio and the 455 retransmission payload format may be used complementarily by sending 456 the retransmission payload format as a redundant encoding of the 457 original data. Note that although the original SN and TS which are 458 necessary for the retransmission scheme are preserved, the original 459 marker bit and CSRC list are lost. 461 Upon a receiver retransmission request, the sender SHOULD retransmit 462 only the original data of the packet if the requested packet 463 contains both original and redundant (retransmitted) data. Multiple 464 retransmission should be performed by requesting multiple times the 465 original packet SN. 467 9. SDP usage 469 The binding to the payload type number is indicated by an rtpmap 470 attribute. The name used in the binding is "RTX". Two example SDP 471 descriptions are shown below. 473 Retransmission stream as a separate stream: 475 c=IN IP4 113.3.12.11 476 m=video 49170 RTP/AVPF 96 477 a=rtpmap:96 H263-1998/90000 478 a=fmtp:96 rtcp-fb nack 479 m=video 49172 RTP/AVPF 97 480 a=rtpmap:97 RTX/90000 482 Leon, Varsa - Expires September 2002 9 483 RTP retransmission framework March 2002 485 Use with the redundancy payload format: 487 c=IN IP4 113.3.12.11 488 m=video 49170 RTP/AVPF 121 96 97 489 a=rtpmap:121 red/90000 490 a=rtpmap:96 H263-1998/90000 491 a=fmtp:96 rtcp-fb nack 492 a=rtpmap:97 RTX/90000 493 a=fmtp:121 96/97 495 In this case, although the retransmission payload format is 496 specified as a possible encoding for this stream, retransmission 497 packets MUST NOT be sent by themselves but piggybacked as redundant 498 data. 500 10. FEC for retransmission 502 It is possible to retransmit the payload of an original packet by 503 sending a FEC packet as defined in [8] instead of using the 504 retransmission payload format. The base SN of the FEC header is the 505 sequence number of the original packet that carried the same payload 506 and the mask is set to zero. There are some advantages in using the 507 FEC payload format in particular in multicast sessions as a single 508 FEC packet may repair the loss of different packets at different 509 receivers. In a multicast session, FEC may be combined with 510 retransmission requests as described in [9] in order to achieve 511 scalable reliable multicast transmission. 513 There are however some motivations to define the retransmission 514 payload format in order to perform retransmission instead of using 515 the FEC payload format: 517 *The retransmission payload format has reduced overhead (3 bytes 518 instead of 12 bytes). 520 *In the retransmission payload format, the RTP header TS is the 521 actual TS of the (retransmitted) media carried in the packets. This 522 is in line with RTP [5] specifications. This is useful in particular 523 for RTP mixers/translators which process the TS. On the other hand, 524 the FEC payload format uses the RTP transmission time (as the FEC 525 packet should be computed over data with different TS). 527 *Assuming that no retransmission payload format were defined, the 528 FEC payload format would then be used in different ways: sending 529 computed FEC packets proactively for correction of lost packets at 530 the receiver without requiring NACK messages (referred hereafter as 531 proactive FEC) or sending retransmitted data upon receipt of a NACK 532 message from the receiver. 533 Although they could use the same payload format, these two repair 534 mechanisms are different. For a given amount of overhead, they offer 535 a different residual packet loss vs. latency trade-off. 537 Leon, Varsa - Expires September 2002 10 538 RTP retransmission framework March 2002 540 Retransmission provides higher packet loss recovery at the expense 541 of higher delay. If a sender uses proactive FEC and none of the 542 packets protected by a given FEC packet is lost, there is then no 543 use of the FEC packet at the receiver. On the other hand, data which 544 are retransmitted are known to have been lost. 545 Therefore, a receiver may wish to use only retransmission and not 546 receive any proactive FEC from the sender in order to trade-off 547 itself the buffering delay, the data-loss rate and the overhead. 548 There is thus a motivation to let the receiver decide at session 549 setup whether the sender may send proactive FEC or retransmission 550 only. 551 If the same payload format were used for these different purposes, 552 the receiver would not know at session establishment which repair 553 mechanism is used by the sender (without defining out-of-band 554 signalling). The sender would decide by itself whether FEC or 555 retransmission (or both) is used and the receiver would not know 556 until receiving the FEC packets whether proactive FEC or 557 retransmission is used. 558 On the other hand, having different payload formats or at least 559 different out of band signalling for these two repair mechanisms 560 (e.g. through defining the binding name 'RTX' SDP rtpmap attribute) 561 would allow the receiver to choose which mechanism to use (among 562 those supported by the sender). The receiver would then have an 563 explicit way to tell the sender not to send proactive FEC. 564 Furthermore, if the receiver did not know at session establishment 565 whether it will receive FEC packets or retransmission, it would have 566 to be prepared to receive FEC and thus be able to perform FEC packet 567 recovery operations. Implementers could thus not choose to implement 568 only a FEC or retransmission scheme. 570 11. Security consideration 572 The security considerations of the profile under which the 573 retransmission scheme is used should be applied. 575 12. References 577 1 Perkins, C., Hodson, O., "Options for Repair of Streaming Media", 578 RFC 2354, June 1998. 580 2 Schulzrinne, H and Casner, S. " RTP Profile for Audio and 581 VideoConferences with Minimal Control," Internet Draft draft- 582 ietf-avt-profile-new-12.txt, November 2001. 584 3 J Ott, S Wenger, S Fukunaga, N Sato, K Yano, M Akihiro, H Koichi, 585 R Hakenberg, C. Burmeister "Extended RTP profile for RTCP-based 586 feedback", November 2001 588 Leon, Varsa - Expires September 2002 11 589 RTP retransmission framework March 2002 591 4 RFC 2119 S Bradner ., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, March 1997 594 5 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: 595 A Transport Protocol for Real-Time Applications", Internet Draft 596 draft-ietf-avt-rtp-new-11.txt, November 2001. 598 6 Hellstrom, J, "RTP for conversational text", RFC 2793, May 2000 600 7 Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., 601 Bolot, J.C, Vega-Garcia, A, Fosse-Parisis, S., "RTP payload for 602 redundant audio data", RFC 2198, September 1997. 604 8 Rosenberg, J. and Schulzrinne, H., " An RTP Payload Format for 605 Generic Forward Error Correction", RFC 2733, December 1999. 607 9 Nonnenmacher, Biersack, E, Towsley, D,. "Parity-based loss 608 recovery for reliable multicast transmission", ACM SIGCOMM'97, 609 Cannes, France, September 1997 611 Author's Addresses 613 David Leon 614 Nokia Research Center 615 6000 Connection Drive Phone: 1-972-374-1860 616 Irving, TX. USA Email: david.leon@nokia.com 618 Viktor Varsa 619 Nokia Research Center 620 6000 Connection Drive Phone: 1-972-374-1861 621 Irving, TX. USA Email: viktor.varsa@nokia.com 623 Leon, Varsa - Expires September 2002 12