idnits 2.17.1 draft-ietf-avt-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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance 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 (June 2002) is 7986 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 103 looks like a reference -- Missing reference section? '3' on line 124 looks like a reference -- Missing reference section? '4' on line 321 looks like a reference -- Missing reference section? '5' on line 629 looks like a reference -- Missing reference section? '6' on line 192 looks like a reference -- Missing reference section? '7' on line 610 looks like a reference -- Missing reference section? '8' on line 617 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 10 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: Nokia 5 draft-ietf-avt-rtp-retransmission-02.txt 6 Expires: December 2002 June 2002 8 RTP retransmission framework 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 RTP retransmission is an effective packet loss recovery scheme for 33 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 43 *since draft-ietf-avt-rtp-retransmission-01.txt 44 IANA considerations section added 45 New appendix on RTP retransmission and multiplexing. It results from 46 a discussion on mailing list. 48 *since draft-ietf-avt-rtp-retransmission-00.txt: 49 An applicability statement was added. 50 The security considerations section was expanded. 52 *since draft-leon-rtp-retransmission-02.txt: 54 The previous version of the draft described the use of the 55 redundancy payload format (RFC 2198) in order to send retransmission 56 data and original data in the same stream. At IETF #53, it was 57 concluded that RFC 2198 was not intended to such a use. Piggybacking 58 retransmitted packets was thus removed from the draft. 60 Table of Contents 62 Abstract...........................................................1 63 Main changes.......................................................1 64 1. Introduction....................................................2 65 2. Terminology.....................................................3 66 3. Applicability statement.........................................3 67 4. Retransmission framework basic principles.......................4 68 5. Retransmission payload format...................................5 69 6. Use with the Extended RTP profile for RTCP-based feedback.......6 70 7. Congestion control..............................................8 71 8. Example scenario of unicast streaming...........................9 72 9. SDP usage.......................................................9 73 10. IANA considerations............................................9 74 11. Security consideration........................................11 75 Appendix A: Retransmission and SSRC multiplexing..................12 76 Appendix B: FEC for retransmission................................13 77 References........................................................14 78 Author's Addresses................................................15 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 application 85 layer (e.g. video) error resilience adaptation based on back-channel 86 messages may be considered to increase the robustness to packet 87 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 This document proposes a retransmission framework. It defines a 100 payload format for retransmitted RTP packets and retransmission 101 rules. This RTP retransmission scheme requires frequent packet loss 102 indication feedback to the RTP entity performing retransmission. The 103 AV profile [2] does not provide this feature and could therefore not 104 be used. However, the retransmission scheme could be run under the 105 extended RTP profile for RTCP-based feedback[3] which defines a NACK 106 message that can be sent as part of a compound RTCP packet. 108 2. Terminology 110 The following terms are used in this document: 112 Original packet: refers to an RTP packet which carries user data 113 sent for the first time by an RTP sender. 115 Original stream: refers to the stream of original packets. 117 Retransmission packet: refers to an RTP packet whose payload 118 includes the payload of an already sent original packet. Such a 119 retransmission packet is said to be associated with the original RTP 120 packet whose payload is included in the retransmission packet. 122 Retransmission request: a means by which an RTP receiver is able to 123 request that the RTP sender send a retransmission packet associated 124 with a given original packet. In [3], a retransmission request is 125 sent as a packet loss indication in a NACK message. 127 Retransmission stream: the stream of retransmission packets 128 associated to with an original stream. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC-2119 [4]. 134 3. Applicability statement 136 There are two proposals for RTP retransmissions (this proposal 137 draft-ietf-avt-rtp-retransmission-01.txt and draft-ietf-avt-rtp- 138 selret-05.txt). Both proposals may be optimum under a different set 139 of constraints. 141 This draft enables the receiver to perform reliable loss detection 142 of user data, i.e. the receiver can differentiate between lost 143 packets sent for first time and lost retransmissions. 144 Reliable user data loss detection is required for example in RTP 145 conversational text (RFC 2793) in order to indicate missing text to 146 the user. For some applications, reliable loss detection of user 147 data may not be strictly required but may enhance a receiver 148 performance. 150 This retransmission algorithm allows receivers to trade-off the 151 playout delay versus the number of retransmissions for a given 152 packet. This delay does not need to be signalled to the sender and 153 can be changed dynamically during the session in order to adapt to 154 varying network conditions. Receivers should choose whether to 155 request a missing packet based on an estimation of its timestamp 156 which is usually obtained from the observed correlation between the 157 RTP sequence number and timestamp. Implementers should carefully 158 design their decision retransmission request algorithm in order to 159 limit the risk of unnecessary retransmission. 161 This retransmission scheme requires a separate RTP session to send 162 retransmitted packets. As a consequence, two additional ports are 163 needed: one port for the RTP retransmission stream and one port for 164 the associated RTCP. While this is generally not a problem, the 165 implementers should assess the implications in the targeted 166 environment. 168 This scheme may be used in a multicast RTP session in order to 169 perform unicast retransmission to each participant. 171 If a separate session is used, mixers, translators and packet caches 172 may be able to separate retransmission packets from original packets 173 at an RTP session level based only on the port being used and 174 process them differently if necessary. 176 4. Retransmission framework basic principles 178 Retransmission packets MUST NOT share the RTP Sequence Number (SN) 179 space with the original stream. The retransmission stream SHOULD use 180 a different RTP session (as defined in RTP [5]) from that of the 181 original stream. Since a separate session is used, the original and 182 retransmission streams are sent to different multicast group/unicast 183 addresses and/or port numbers. 185 There are several reasons why the SN space must not be shared: 187 Since retransmission packets do not share the SN space with the 188 original packets, the receiver is able to distinguish between the 189 loss of original packets and retransmission packets. Otherwise, 190 reliable loss detection of user data would not be possible. Reliable 191 data loss detection of user data is mandated for example in RTP 192 conversational text [6]. 194 RTP Timestamp (TS) estimation of missing original packets is 195 necessary at the receiver in order to decide whether a 196 retransmission is useful or not. A retransmission is useful if the 197 retransmission packet sent as a response to the retransmission 198 request may still be used when it arrives at the receiver. The 199 missing original packet timestamp can be estimated from timestamp of 200 packets preceding and/or following the sequence number gap caused by 201 the missing packet in the original stream. 203 The fact that RTP streams for original and retransmission packets do 204 not share the same SN space guarantees that the RTP timestamp 205 estimation method is reliable. Reliability would be sacrificed if 206 original and retransmission packets were sent in the same RTP stream 207 as the timestamp estimate for a lost retransmission packet would 208 then be incorrect. This is because the retransmission packet usually 209 has a smaller "out-of-order" timestamp than the timestamp of the 210 consecutive original packets. 212 When the retransmission stream is sent to a multicast RTP session, 213 receivers may choose whether to subscribe or not to the RTP session 214 carrying the retransmission stream. Therefore, a multicast streaming 215 application can use retransmission and still be backwards compatible 216 as receivers which do not implement the retransmission payload 217 format only join the RTP session carrying the original stream. A 218 scenario where the original session is multicast and separate 219 unicast sessions carry the retransmission stream to each 220 participant, is also possible. In this scenario, a receiver receives 221 only the retransmission packets it has itself requested and not the 222 retransmission packets that are requested by other receivers. 224 Mixers, translators and packet caches may be able to separate 225 retransmission packets from original packets at an RTP session level 226 and process them differently if necessary. 228 As a consequence of having separate RTP sessions for original and 229 retransmission streams, there are also separate RTCP streams and 230 statistics for these two sessions. There is thus no corruption of 231 the original stream RTCP statistics. The RTP sender is able to know 232 the packet loss and jitter of the original stream. It can thus 233 estimate what the quality of the received signal would be without 234 the use of retransmission. 236 5. Retransmission payload format 238 The payload format of a retransmission packet is shown below. 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | RTP Header | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 |E| OPT | OSN | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 245 | Original RTP Packet Payload | 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 RTP header usage: 249 The same SSRC value SHOULD be used for the original stream and the 250 retransmission stream. In the RTP header, SN has the standard 251 definition, i.e. it MUST be one higher than the sequence number of 252 the preceding retransmission packet. The payload type is dynamic and 253 indicates the use of the retransmission payload format. All other 254 fields of the RTP header have the same value as in the original RTP 255 packet. 257 The retransmission packet payload carries an E bit, an OPT field (7 258 bits) and an OSN field (2 bytes) followed by the original RTP packet 259 payload. The E bit is an extension bit for future-proofing. It MUST 260 be set to zero. The OPT field is the payload type of the original 261 packet payload that is being retransmitted. The OSN field is the 262 sequence number of the original packet that originally carried the 263 same payload. 265 6. Use with the Extended RTP profile for RTCP-based feedback 267 6.1 Sending rules for RTCP-based feedback 269 When the Extended RTP profile for RTCP-based feedback [4] is used, 270 it is RECOMMENDED that receivers send retransmission requests 271 according to the rules in this section. The rules described 272 hereafter aim at limiting the maximum delay before a retransmission 273 request can be sent and are compliant to the more general rules 274 described in the profile itself. 276 The NACK message format defined in the profile should be used. Early 277 RTCP packets should not be used and the NACK message should always 278 be appended to a regularly scheduled compound RTCP packet that is 279 sent at every RTCP report interval. 281 Any other rules to send feedback may be used as long as they are 282 compliant with the profile. In particular, a receiver may send NACK 283 messages in early RTCP packets. However, in that case the time when 284 the next RTCP packet following this early RTCP packet can be sent 285 could be too late to report a loss occurring right after the early 286 RTCP packet was sent. Sending RTCP packets at regular intervals 287 guarantees that the delay between detecting an original packet loss 288 and being able to send a NACK message for that packet is no longer 289 than the RTCP interval. 291 6.2 Receiver algorithm for generating retransmission requests 293 This section gives some general guidelines on how a receiver should 294 decide whether or not to request a packet retransmission. An actual 295 receiver implementation should take into account such factors as the 296 network environment and the media type. 298 A receiver should compute an estimate of the retransmission delay to 299 receive a retransmission packet after a NACK message has been sent. 300 This estimate may be obtained from past observations, RTCP report 301 round-trip time if available or any other means. 303 The minimum receiver buffering delay (i.e. the time between a packet 304 is received and its payload is used at the receiver) is the RTCP 305 reporting interval added to the retransmission delay estimate. This 306 delay guarantees that a retransmission packet sent as a response to 307 a retransmission request can be received before its payload is used. 309 It can be seen that the needed receiver buffering delay is dependent 310 on the amount of RTCP traffic allowed in the session. It is 311 illustrated in Section 8 that moderate RTCP feedback traffic is 312 enough to perform retransmission with reasonable receiver buffering 313 delay. 315 A receiver should maintain a list of missing original packet 316 sequence numbers. A receiver needs also to store for each missing 317 original packet an estimated RTP timestamp as described in Section 318 4. At the next scheduled RTCP packet sending time, the receiver 319 estimates which of the missing packets should be requested in the 320 NACK message (see usage of the PID and BLP fields of the NACK 321 message format in [4]) of the RTCP compound packet. A missing packet 322 should be requested if it is estimated the associated retransmission 323 packet could still be used at the time it arrives at the receiver. 324 The receiver should remove from its list of missing packets, the 325 packets which were deemed too old to be requested. 327 If the retransmission stream is sent to a multicast session, the 328 receiver should listen to NACK messages from other receivers. If a 329 NACK message for the sequence number of a missing packet has been 330 sent by another receiver, the receiver should ignore that sequence 331 number in its list of missing packets and refrain from sending a 332 retransmission request for that sequence number. 334 The same retransmission request may be resent in the original RTP 335 session if the requested packet was not received after an estimated 336 retransmission reception time. This increases the robustness to the 337 loss of a NACK message or of a retransmission packet. The number of 338 retransmission requests that may be sent for a given missing 339 original packet sequence number depends on the receiver buffering 340 delay. 342 The receiver should upon reception of a retransmission packet remove 343 the corresponding original packet sequence number(OSN in the 344 retransmission payload format) from the list of missing sequence 345 numbers. 347 6.3 RTCP sending rules in the retransmission RTP session 348 Since the original stream and the retransmission stream are carried 349 in separate RTP sessions, the retransmission stream has its own RTCP 350 stream as well. The amount of RTCP sent for the retransmission 351 stream is computed as a fraction of the retransmission RTP session 352 bandwidth. Since the retransmission traffic is limited, the overhead 353 caused by the additional RTCP packets in the retransmission RTP 354 session is moderate. For example, assuming a 64 kbps original RTP 355 session and on average 3% packet loss and all lost original packets 356 retransmitted once, the bandwidth of the retransmission RTP session 357 would be about 2 kbps. In this case the recommended RTCP traffic for 358 the retransmission RTP session would be 0.1 kbps. 360 Early RTCP packets and RTCP feedback messages SHOULD NOT be used in 361 the retransmission RTP session. 363 7. Congestion control 365 RTP retransmission poses a risk of increased network congestion. In 366 a best-effort environment, packet loss is caused by congestion. 367 Reacting to loss by retransmission of older packets in addition to 368 the current data would thus further increase congestion. 369 Implementations SHOULD follow the recommendations below in order to 370 use retransmission. 372 The RTP profile under which the retransmission scheme is used 373 defines an appropriate congestion control mechanism in different 374 environments. Following the rules under the profile, an RTP 375 application can determine its acceptable bitrate and packet rate in 376 order to be fair to other applications such as TCP flows and other 377 RTP flows. 379 If an RTP application uses retransmission, the acceptable packet 380 rate and bitrate SHOULD include both the original and retransmitted 381 data. This guarantees that an application using retransmission 382 should be fair to any other RTP or TCP flows. Such a rule would 383 translate in practice into the following actions: 385 If enhanced service is used, it should be made sure that the total 386 bitrate and packet rate do not exceed that of the requested service. 387 It should be further monitored that the requested services are 388 actually delivered. In a best-effort environment, the sender SHOULD 389 NOT send retransmission packets without reducing the packet rate and 390 bitrate of the original stream (for example by encoding the data at 391 a lower rate). 393 In addition, the sender MAY retransmit only the packets that it 394 deems important and ignore NACK messages for other packets in order 395 to limit the bitrate 397 These congestion control mechanisms should keep the congestion level 398 under an acceptable limit. This would in turn guarantee that the 399 packet loss should be moderate. Too high a packet loss would mean 400 that congestion is not kept under control and retransmission should 401 then not be used. 403 8. Example scenario of unicast streaming 405 Let us assume that the RTP session bandwidth is 64 kbps and the 406 receiver buffering delay is 3 seconds. The network round trip time 407 is 500 ms and Receiver RTCP packets (including NACK messages ) are 408 sent at 2-second intervals. With these time limitations, when the 409 receiver algorithm for generating retransmission requests described 410 in Section 6.2 is followed, only one request per packet loss can be 411 sent. Let us assume an original packet rate of 50 packets per second 412 (1 packet every 20 ms). At this packet rate, with the packet loss 413 distribution worst case scenario where every 17th original packet is 414 lost (i.e. 5.88% uniform packet loss), a maximum of 6 NACK messages 415 need to be appended to the RTCP compound packet that is sent every 2 416 seconds. The 6 NACK messages can report any packet losses in an SN 417 range of 6*17=102, thus the number of required NACK messages would 418 not increase with higher packet loss rates. The overhead required 419 per RTCP compound packet for the 6 NACK messages is 36 bytes which 420 carries 6 PID and 6 BLP fields in addition to the feedback message 421 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 426 bandwidth is well below the recommended RTCP bandwidth. The receiver 427 RTCP recommended bandwidth in an RTP session with 64 kbps is about 428 0.25*64 = 1.6 kbps. 430 9. SDP usage 432 The binding to the payload type number is indicated by an rtpmap 433 attribute. The name used in the binding is "rtx". 435 An SDP example is shown below: 437 c=IN IP4 113.3.12.11 438 m=video 49170 RTP/AVPF 96 439 a=rtpmap:96 H263-1998/90000 440 a=fmtp:96 rtcp-fb nack 441 m=video 49172 RTP/AVPF 97 442 a=rtpmap:97 rtx/90000 444 10. IANA considerations 446 10.1 Registration of audio/rtx 448 MIME type: audio 449 MIME subtype: rtx 451 Required parameters: rate 452 The RTP timestamp clockrate is equal to the RTP timestamp clockrate 453 of the media that is retransmitted. 454 Optional parameters: none 456 Encoding considerations: this type is only defined for transfer via 457 RTP. 459 Security considerations: see Section 11 461 Interoperability considerations: none 463 Published specification: RFC xxx 465 Applications which use this media type: multimedia streaming 466 applications 468 Additional information: none 470 Person & email address to contact for further information: 471 david.leon@nokia.com 473 Intended usage: COMMON 475 Author/Change controller: David Leon 477 10.2 Registration of video/rtx 479 MIME type: video 481 MIME subtype: rtx 483 Required parameters: rate 484 The RTP timestamp clockrate is equal to the RTP timestamp clockrate 485 of the media that is retransmitted. 486 Optional parameters: none 488 Encoding considerations: this type is only defined for transfer via 489 RTP. 491 Security considerations: see Section 11 493 Interoperability considerations: none 495 Published specification: RFC xxx 497 Applications which use this media type: multimedia streaming 498 applications 500 Additional information: none 501 Person & email address to contact for further information: 502 David.leon@nokia.com 504 Intended usage: COMMON 506 Author/Change controller: David Leon 508 10.3 Registration of text/rtx 510 MIME type: text 512 MIME subtype: rtx 514 Required parameters: rate 515 The RTP timestamp clockrate is equal to the RTP timestamp clockrate 516 of the media that is retransmitted. 517 Optional parameters: none 519 Encoding considerations: this type is only defined for transfer via 520 RTP. 522 Security considerations: see Section 11 524 Interoperability considerations: none 526 Published specification: RFC xxx 528 Applications which use this media type: multimedia streaming 529 applications 531 Additional information: none 533 Person & email address to contact for further information: 534 David.leon@nokia.com 536 Intended usage: COMMON 538 Author/Change controller: David Leon 540 11. Security consideration 542 Retransmission and FEC [7] have similar security conditions as far 543 as encryption and congestion control are concerned. 544 Applications utilizing encryption SHOULD encrypt both the original 545 and the retransmission stream. Old keys will likely need to be 546 cached so that when the keys change for the original stream, the old 547 key is used until it is determined that the key has changed on the 548 retransmission packets as well. 549 Congestion control considerations with the use of retransmission are 550 dealt with in Section 7 of this document. 552 Any other security considerations of the profile under which the 553 retransmission scheme is used should be applied. 555 Appendix A: Retransmission and SSRC multiplexing 557 In this document, it is required that two separate RTP streams with 558 their own sequence number space be used for the original stream and 559 the retransmission stream. This should be achieved by sending the 560 RTP stream and its associated retransmission stream to different 561 ports. 563 Another way the original and the retransmission stream could be 564 multiplexed is through the use of different SSRCs if these streams 565 are sent to the same port. 566 In general, SSRC multiplexing is not feasible as in a multicast 567 group it would not be possible to associate an original stream and 568 its retransmission stream since the SSRC is a random number chosen 569 by the RTP sender. 570 However, in unicast this should not be an issue if exactly one RTP 571 stream and its retransmission stream are multiplexed based on their 572 SSRC. Since the receiver knows the payload types used by the 573 original stream and the retransmission stream, it would be able to 574 derive which SSRC maps to the original data and which SSRC maps to 575 retransmissions. 577 SSRC multiplexing should generally be avoided as discussed in 578 Section 5.2 of RTP [5]. One of the advantage of multiplexing at the 579 transport layer (i.e. based on the IP address or port number) is the 580 use of different network paths or resources for different streams. 581 However, in the case of unicast retransmission, it is the same media 582 sent in both the original and the retransmission. 584 It also has to be noted that the SSRC-multiplexing approach is 585 allowed in FEC [7]. Section 3 of FEC states "This document does not 586 prescribe the definition of "separate streams", but leaves this to 587 applications and higher level protocols to define. For multicast, 588 the separate stream may be implemented by separate multicast groups, 589 different ports in the same group, or by a different SSRC within the 590 same group/port. For unicast, different ports or different SSRC may 591 be used. Each of these approaches has drawbacks and benefits which 592 depend on the application". 594 This retransmission draft recommends the following rules: 595 Separate addresses and/or ports must be used in the multicast case 596 and should be used in the unicast case to multiplex the original 597 stream and the retransmission stream. In the unicast case, exactly 598 one RTP stream and its associated retransmission stream may be sent 599 to the same port and multiplexed based on their SSRCs 601 The motivation not to prevent SSRC multiplexing is to minimise the 602 number of ports usage when it may be a performance issue for high- 603 scale RTP servers and/or middle-ware proxies while allowing the 604 original and the retransmitted data to be sent into separate RTP 605 streams with their own sequence number spaces. 607 Appendix B: FEC for retransmission 609 It is possible to retransmit the payload of an original packet by 610 sending a FEC packet as defined in [7] instead of using the 611 retransmission payload format. The base sequence number of the FEC 612 header is the sequence number of the original packet that carried 613 the same payload and the mask is set to zero. There are some 614 advantages in using the FEC payload format in particular in 615 multicast sessions as a single FEC packet may repair the loss of 616 different packets at different receivers. In a multicast session, 617 FEC may be combined with retransmission requests as described in [8] 618 in order to achieve scalable reliable multicast transmission. 620 There are however the following motivations to define the 621 retransmission payload format in order to perform retransmission 622 instead of using the FEC payload format: 624 *The retransmission payload format has reduced overhead (3 bytes 625 instead of 12 bytes). 627 *In the retransmission payload format, the RTP header TS field is 628 the actual timestamp of the (retransmitted) media carried in the 629 packets. This is in line with RTP [5] specifications. This is useful 630 in particular for RTP mixers/translators which process the TS field. 631 On the other hand, the FEC payload format uses the RTP transmission 632 time (as the FEC packet should be computed over data with different 633 timestamp). 635 *Assuming that no retransmission payload format were defined, the 636 FEC payload format would then be used in different ways: sending 637 computed FEC packets proactively for correction of lost packets at 638 the receiver without requiring NACK messages (referred hereafter as 639 proactive FEC) or sending retransmitted data upon receipt of a NACK 640 message from the receiver. 641 Although they could use the same payload format, these two repair 642 mechanisms are different. For a given amount of overhead, they offer 643 a different residual packet loss vs. latency trade-off. 644 Retransmission provides higher packet loss recovery at the expense 645 of higher delay. If a sender uses proactive FEC and none of the 646 packets protected by a given FEC packet is lost, there is then no 647 use of the FEC packet at the receiver. On the other hand, data which 648 are retransmitted are known to have been lost. 649 Therefore, a receiver may wish to use only retransmission and not 650 receive any proactive FEC from the sender in order to trade-off 651 itself the buffering delay, the data-loss rate and the overhead. 652 There is thus a motivation to let the receiver decide at session 653 setup whether the sender may send proactive FEC or retransmission 654 only. 656 If the same payload format were used for these different purposes, 657 the receiver would not know at session establishment which repair 658 mechanism is used by the sender (without defining out-of-band 659 signalling). The sender would decide by itself whether FEC or 660 retransmission (or both) is used and the receiver would not know 661 until receiving the FEC packets whether proactive FEC or 662 retransmission is used. 663 On the other hand, having different payload formats or at least 664 different out of band signalling for these two repair mechanisms 665 (e.g. through defining the binding name 'RTX' SDP rtpmap attribute) 666 would allow the receiver to choose which mechanism to use (among 667 those supported by the sender). The receiver would then have an 668 explicit way to tell the sender not to send proactive FEC. 669 Furthermore, if the receiver did not know at session establishment 670 whether it will receive FEC packets or retransmission, it would have 671 to be prepared to receive FEC and thus be able to perform FEC packet 672 recovery operations. Implementers would thus not be able choose to 673 implement only a FEC or retransmission scheme. 675 References 677 1 Perkins, C., Hodson, O., "Options for Repair of Streaming Media", 678 RFC 2354, June 1998. 680 2 Schulzrinne, H and Casner, S. " RTP Profile for Audio and 681 VideoConferences with Minimal Control," Internet Draft draft- 682 ietf-avt-profile-new-12.txt, November 2001. 684 3 J Ott, S Wenger, S Fukunaga, N Sato, K Yano, M Akihiro, H Koichi, 685 R Hakenberg, C. Burmeister "Extended RTP profile for RTCP-based 686 feedback", November 2001 688 4 RFC 2119 S Bradner ., "Key words for use in RFCs to Indicate 689 Requirement Levels", BCP 14, RFC 2119, March 1997 691 5 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: 692 A Transport Protocol for Real-Time Applications", Internet Draft 693 draft-ietf-avt-rtp-new-11.txt, November 2001. 695 6 Hellstrom, J, "RTP for conversational text", RFC 2793, May 2000 697 7 Rosenberg, J. and Schulzrinne, H., " An RTP Payload Format for 698 Generic Forward Error Correction", RFC 2733, December 1999. 700 8 Nonnenmacher, Biersack, E, Towsley, D,. "Parity-based loss 701 recovery for reliable multicast transmission", ACM SIGCOMM'97, 702 Cannes, France, September 1997 703 Author's Addresses 705 David Leon 706 Nokia Research Center 707 6000 Connection Drive Phone: 1-972-374-1860 708 Irving, TX. USA Email: david.leon@nokia.com 710 Viktor Varsa 711 Nokia Research Center 712 6000 Connection Drive Phone: 1-972-374-1861 713 Irving, TX. USA Email: viktor.varsa@nokia.com