idnits 2.17.00 (12 Aug 2021) /tmp/idnits32525/draft-lennox-avt-recoverable-packets-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 601. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 19, 2006) is 5808 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) == Outdated reference: draft-ietf-avt-rtcp-feedback has been published as RFC 4585 == Outdated reference: draft-ietf-avt-rtp-hdrext has been published as RFC 5285 == Outdated reference: A later version (-04) exists of draft-ietf-avt-rtp-no-op-00 == Outdated reference: draft-ietf-avt-rtp-retransmission has been published as RFC 4588 == Outdated reference: draft-ietf-avt-ulp has been published as RFC 5109 -- Obsolete informational reference (is this intentional?): RFC 2833 (Obsoleted by RFC 4733, RFC 4734) -- Obsolete informational reference (is this intentional?): RFC 3984 (Obsoleted by RFC 6184) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport J. Lennox 3 Internet-Draft Layered Media 4 Expires: December 21, 2006 June 19, 2006 6 Marking and Selectively Retransmitting High-Priority Packets in the 7 Real-Time Transport Protocol (RTP) 8 draft-lennox-avt-recoverable-packets-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 21, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 In some circumstances, it is useful and desirable for the sender of 42 an RTP stream to be able to deliver a subset of its RTP packets 43 reliably. One example of this is a video codec which can encode a 44 video stream such that decoder state can be maintained using just a 45 subset of the packets encoded. However, existing RTP reliability 46 mechanisms only define mechanisms which retransmit all the packets of 47 an RTP stream. 49 This document describes a mechanism by which the sender of an RTP 50 stream can mark a subset of the packets of an RTP stream as high- 51 priority recoverable packets, and by which the receiver of the stream 52 can request retransmission of the high-priority packets. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Use of R Packets With Video Streams . . . . . . . . . . . . . 4 60 5. RTP Header Extension to Indicate R Packets . . . . . . . . . . 5 61 6. RTCP Feedback Messages . . . . . . . . . . . . . . . . . . . . 8 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 67 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 11 68 Appendix B. Analysis of Alternate Approaches . . . . . . . . . . 12 69 B.1. Generic NACK . . . . . . . . . . . . . . . . . . . . . . . 12 70 B.2. Generic NACK with Codec knowledge . . . . . . . . . . . . 12 71 B.3. Codec-Specific NACK . . . . . . . . . . . . . . . . . . . 13 72 B.4. Multiple streams . . . . . . . . . . . . . . . . . . . . . 13 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 Intellectual Property and Copyright Statements . . . . . . . . . . 15 76 1. Introduction 78 In many circumstances, it is useful to allow a subset of the packets 79 in a Real-Time Transport Protocol (RTP) [RFC3550] media stream to be 80 transmitted reliably (i.e. that they be retransmitted if they are 81 lost). However, current mechanisms require either that any lost 82 packet be retransmitted, or that none are. There is no way for the 83 sender of an RTP stream to select some packets of a stream to be 84 retransmittable. 86 For example, modern flexible video codecs such as H.264 87 [ITU.H264.2005] allow video streams to be encoded flexibly. Unlike 88 in earlier video codecs, inter-picture image prediction may be based 89 not just on an immediately preceding picture, but optionally instead 90 on earlier pictures transmitted in the video stream. As a result, it 91 is possible for a video encoder to encode its stream such that in 92 high packet loss situations, stream state can be maintained or re- 93 established using only a fraction of the RTP packets transmitted in 94 the stream. If a media stream experiences transient packet loss, a 95 decoder can avoid reporting all lost packets, and an encoder does not 96 need to retransmit all the missed packets, in order for the decoder 97 to fully re-establish state. 99 To achieve this desirable property, however, a decoder must be able 100 to determine, based only on the packets it has received, whether a 101 packet it has missed was one that it needed to receive reliably to 102 reestablish stream state. This document describes a payload-format 103 independent mechanism by which a receiver (or intermediate media- 104 aware network entity) can quickly determine whether essential packets 105 have been lost and can request their retransmission. 107 The mechanism described by this document is also applicable to other 108 application scenarios -- for example, DTMF [RFC2833] tones in an 109 audio stream -- in which it is useful for some, but not all, of the 110 packets in an RTP stream to be transmitted reliably. 112 Appendix A lists the requirements for this protocol, and Appendix B 113 evaluates some alternate approaches to the problem described. 115 2. Terminology 117 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 118 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 119 and "OPTIONAL" are to be interpreted as described in RFC 2119 120 [RFC2119] and indicate requirement levels for compliant 121 implementations. 123 3. Overview 125 When sending a stream of RTP packets, a media sender may choose to 126 mark a subset of the stream's packets as high-reliability packets. 127 This subset of the RTP packets is named "R packets," for 128 "recoverable" packets. Other packets are called "Non-R packets". 130 An RTP stream can contain several independent series of R packets. 131 (A given R packet can belong to only one series of R packets). Every 132 R packet is identified with an R packet sequence number (RSeq), 133 unique (modulo 2^16) within its series. R packets within a series 134 are numbered in order, and a receiver detects missing R packets by 135 noting gaps in the R packet sequence numbers. R packets sequence 136 numbers are identified using an RTP header extension element, defined 137 in Section 5. 139 This header extension element is also used in non-R packets, to 140 identify the RTP stream's most recently transmitted R packet in each 141 series. Thus, receivers can detect missing R packets based on non-R 142 packets as well as R packets. Since R packets can be sent at a 143 fairly low rate relative to the overall packet sending rate of the 144 RTP stream, this allows receivers to detect missing R packets much 145 more quickly. If multiple series of R packets are being sent, R 146 packet from one series can also identify the most recently sent R 147 packets from the other active series. 149 When a receiver detects that it has missed an R packet, it sends an R 150 packet NACK message (RNACK), described in Section 6, using the RTCP 151 feedback (AVPF) [I-D.ietf-avt-rtcp-feedback] mechanism. On receiving 152 an RNACK message, the sender can then retransmit the missing packet. 154 If a sender determines that some R packets, sent in the past, are no 155 longer needed by the receiver, it can send a new R packet indicating 156 that the earlier ones are no longer needed. This R packet is called 157 a superseding R packet, as receipt of a superseding R packet 158 indicates that earlier R packets need not be requested by a receiver. 159 The first R packet of an RTP stream is always encoded such that it 160 supersedes all the previous (non-existent) R packets in the stream. 162 4. Use of R Packets With Video Streams 164 For several video formats, it is possible for a video encoder to 165 encode and packetize its media so that a subset of the packets of an 166 RTP [RFC3550] stream are sufficient for a stream decoder to fully 167 reestablish the correct decoding state. 169 In order to take advantage of R packets, an encoder periodically 170 encodes a frame (or other unit of the media data) in a way that 171 either depends on no previous data (an intra-encoded R frame) or that 172 depends only on previously transmitted R packets (a P-encoded R 173 frame). Frames transmitted in non-R packets can then reference the 174 frames encoded in R packets. If transient packet loss occurs, a 175 decoder need only request retransmission of the R packets it has 176 missed in order to re-establish decoder state; missed non-R packets 177 can be safely ignored. Missed R packets are useful (and necessary) 178 for maintaining the continuity of the media stream. In some cases 179 even if retransmissions of R packets arrive at the decoder too late 180 to be played out, the decoder can "fast-forward" through a subset of 181 the stream in order to catch up to the stream's current playout 182 point. 184 It is not necessary to receive every R packet ever transmitted on a 185 media stream in order to reestablish the stream state. As mentioned, 186 while some R packets (P frames) depend on previous data transmitted 187 in a stream, others (intra frames) depend on no previous data and 188 imply full stream state. Thus, the R packets carrying intra frames 189 are encoded such that they supersede all the R packets prior to the 190 first packet of the intra frame. 192 Furthermore, when an encoder receives a report about a lost R packet, 193 it is possible for it to decide to encode a fresh R frame (based only 194 on R frames it believes have been received correctly) rather than 195 retransmitting the lost packet. This frame's R packets are then 196 marked as superseding the R packets of the frames which are no longer 197 used for dependency tracking. 199 In layered encodings, there can be more than one series of required 200 packets, e.g. a base-layer I-frame eliminates the need for previous 201 base-layer long-term reference frames, but not for enhancement-layer 202 long-term reference frames. In this case, each layer's R frames are 203 identified by a different R packet series. 205 5. RTP Header Extension to Indicate R Packets 207 This section describes the RTP header extension element used to 208 indicate R packets. 210 In an RTP stream containing R packets, packets are marked with an RTP 211 header extension element using the Named RTP Header Extension 212 mechanism [I-D.ietf-avt-rtp-hdrext]. 214 The R packet header extension element identifies both R packets 215 themselves and previously-sent R packets. This header extension 216 element has the name "org.ietf.avt.r-packet/200606". Every R packet 217 includes, and every non-R packet SHOULD include, at least one header 218 extension element of this form. It MAY occur multiple times in a 219 header extension if multiple R packet series are in use, but MUST 220 occur only once for any given series. 222 0 1 2 3 223 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | ID | len |R| MBZ | SER | RSEQ | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | SUPERSEDE_START [opt] | SUPERSEDE_END [opt] | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 1: R packet header extension element 232 The structure of this header extension element is illustrated in 233 Figure 1. Its fields are defined as follows: 235 ID: 4 bits The local identifier negotiated for this header extension 236 element, as defined in [I-D.ietf-avt-rtp-hdrext]. 237 Length (len): 4 bits The length minus one of the data bytes of this 238 header extension element, not counting the header byte (ID and 239 len), as defined in [I-D.ietf-avt-rtp-hdrext]. This will have the 240 value 6 if the second word (the superseded range) is present, and 241 2 if it is not. Its value MUST either be 2 or 6. 242 R: 1 bit A bit indicating that the packet containing this header 243 extension element is an R packet. If this bit is set (1), this 244 header extension element identifies the current packet as an R 245 packet in series SER with R sequence number RSEQ. If it is not 246 set (0), this header extension element instead indicates that the 247 media stream's most recent R packet in series SER had R sequence 248 number RSEQ. (This latter case is known as a "mark element".) An 249 R packet is a packet where exactly one header extension element 250 has the R bit set, whereas a non-R packet is a packet where no 251 header header extension element has the R bit set. If this bit is 252 not set, the superseded range SHOULD NOT be present for that 253 header extension element (i.e. the len field SHOULD be 2) and MUST 254 be ignored if present. 255 Reserved, Must Be Zero (MBZ): 3 bits Reserved bits. These MUST be 256 set to zero on transmit and ignored on receive. 257 Series ID (SER): 4 bits An identifier of which series of R packets is 258 being described by this header extension element. If a media 259 encoder is describing only a single series of R packets, this 260 SHOULD have the value 0. 262 R Packet Sequence Number (RSEQ): 16 bits An unsigned sequence number 263 indicating the number of this R packet within the series SER. 264 This value is incremented by 1 (modulo 2^16) for every R packet 265 sent in a given series. RSEQ values for separate series are 266 independent. 267 Start of Superseded Range (SUPERSEDE_START): 16 bits The R sequence 268 number of the earliest R packet, inclusive, superseded by this R 269 packet, calculated modulo 2^16. (Since this value uses modulo 270 arithmetic, the value RSEQ + 1 MAY be used for SUPERSEDE_START to 271 indicate that all R packets prior to the end of the superseded 272 range have been superseded.) This field is optional, and is only 273 present when len=6. 274 End of Superseded Range (SUPERSEDE_END): 16 bits The R sequence 275 number of the final R packet, inclusive, superseded by this R 276 packet, calculated modulo 2^16. This value MUST lie in the closed 277 range [SUPERSEDE_START .. RSEQ] modulo 2^16. This field is 278 optional, and is only present when len=6. 280 An RTP packet MAY contain multiple R packet mark elements, so long as 281 each of these elements has a different value for SER. However, an 282 RTP MUST NOT contain more than one of these header extension elements 283 with the R bit set, i.e. an R packet may not belong to more than one 284 series. 286 All RTP packets in a media stream using R packets SHOULD include a 287 mark element for all active series. 289 When the second word of this header extension element is present, it 290 indicates that this R packet supersedes some previously-received R 291 packets, meaning that these packets are no longer necessary in order 292 to reconstruct stream state. This second word MUST only appear in a 293 header extension element which has its R bit set. 295 An R packet can only supersede R packets in the series identified by 296 the element's SER field. R packets cannot supersede packets in other 297 series. 299 It is valid for a supersede element to have SUPERSEDE_END=RSEQ. This 300 indicates that the R packet supersedes itself, i.e. that this R 301 packet immediately becomes irrelevant to the stream state. The most 302 common reason to do this would be to end a series; this can be done 303 by sending an empty packet (e.g. an RTP No-op 304 [I-D.ietf-avt-rtp-no-op] packet) with the superseded range 305 (SUPERSEDE_START, SUPERSEDE_END) = (RSEQ+1, RSEQ), so that the series 306 no longer contains any non-superseded packets. 308 The first R packet sent in a series SHOULD be sent with a superseded 309 range such that SUPERSEDE_START = RSEQ+1, to make it clear that no 310 previous R packets are present in the range. 312 R packets MAY redundantly include already-superseded packets in their 313 range of packets to be superseded. If a group of superseding R 314 packets are sent together (e.g., if a number of packets together 315 encode an intra frame), they SHOULD all be marked as superseding the 316 same range of R packets. 318 6. RTCP Feedback Messages 320 This section describes the RTCP feedback message used to indicate 321 that R packets have been lost. 323 The R Packet Negative Acknowledgement (RNACK) Message is an RTCP 324 Feedback (AVPF) [I-D.ietf-avt-rtcp-feedback] message identified by 325 PT=RTPFB and FMT=4 (value tentatively chosen). The FCI field MUST 326 contain at least one and MAY contain more than one RNACK. 328 The RNACK packet is used to indicate the loss of one or more R 329 packets. The lost packet(s) are identified by means of a packet 330 sequence number, the series identifier, and a bit mask. 332 The structure and semantics of the RNACK message are similar to that 333 of the AVPF Generic NACK message. 335 The RNACK Feedback Control Information (FCI) field has the following 336 syntax Figure 2: 338 0 1 2 3 339 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | RSEQ | SER | BLR | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Figure 2: Feedback Control Information for R Packet Negative 345 Acknowledgment (RNACK) 347 R Packet Sequence Number (RSEQ): 16 bits The RSEQ field indicates a 348 RSEQ value that the receiver has not received. 349 Series ID (SER): 4 bits An identifier of which series of R packets is 350 being described as being lost by this header extension element. 351 Bitmask of following Lost R Packets (BLR): 12 bits The BLR allows for 352 reporting losses of any of the 12 R Packets packets immediately 353 following the RTP packet indicated by RSEQ. Denoting the BLP's 354 least significant bit as bit 1, and its most significant bit as 355 bit 12, then bit i of the bit mask is set to 1 if the receiver has 356 not received R packet number (RSEQ+i) in the series SER (modulo 357 2^16) and indicates this packet is lost; bit i is set to 0 358 otherwise. Note that the sender MUST NOT assume that a receiver 359 has received an R packet because its bit mask was set to 0. For 360 example, the least significant bit of the BLR would be set to 1 if 361 the packet corresponding to RSEQ and the following R packet in the 362 series had been lost. However, the sender cannot infer that 363 packets RSEQ+2 through RSEQ+16 have been received simply because 364 bits 2 through 15 of the BLR are 0; all the sender knows is that 365 the receiver has not reported them as lost at this time. 367 When a receiver detects that it has not received a non-superseded R 368 packet, it sends an RNACK message as soon as possible, subject to the 369 rules of RTCP feedback [I-D.ietf-avt-rtcp-feedback]. (In multipoint 370 scenarios, this includes listening for RNACK packets from other 371 receivers and not sending an RNACK for a lost R packet that has 372 already been reported.) 374 When a sender receives an RNACK packet, it checks whether the packet 375 has been superseded. If it has not, it retransmits the packet for 376 which an RNACK was sent (using, e.g., the RTP retransmission payload 377 [I-D.ietf-avt-rtp-retransmission]). If the packet has been 378 superseded, it retransmits the most recent packet whose R packet 379 element indicated a superseded packet range including the packet 380 requested. 382 A sender MAY choose to generate and send a new R packet superseding 383 the one requested in an RNACK, rather than retransmitting a packet 384 that has been sent previously. 386 If, after some period of time, a receiver has not received either a 387 retransmission of the R packet for which an RNACK was sent, or an R 388 packet superseding that packet, it SHOULD retransmit the RNACK 389 message. A receiver MUST NOT send RNACK messages more often than 390 permitted by AVPF. It SHOULD perform estimation of the round-trip 391 time to the sender, if possible, and SHOULD NOT send RNACK messages 392 more often than once per round-trip time. (If the receiver is also 393 acting as an RTP sender, and the sender is sending RTCP reception 394 reports for the receiver's stream, round-trip times can be inferred 395 from the sender report's LSR and DLSR fields.) If the round-trip 396 time is not available, receivers SHOULD NOT send RNACK messages more 397 often than once per 100 milliseconds. [TODO: this value is a 398 complete guess.] 400 7. Security Considerations 402 All security considerations of RTP [RFC3550] apply here as well. 404 A receiver MUST NOT assume that an R packet bitstream it receives 405 actually provides complete decoder state; the bitstream MUST still be 406 validated. 408 8. IANA Considerations 410 This document defines an org.ietf RTP header extension element: 411 'org.ietf.r-packet/200606'. Its format is defined in Section 5 . 412 This header extension element should be registered by IANA as 413 described in [I-D.ietf-avt-rtp-hdrext]. 415 This document defines an RTCP transport-layer feedback message: 416 'RNACK'. Its format is defined in Section 6. It should be defined 417 in the RTPFB FMT as follows: 418 Name: RNACK 419 Long name: R Packet Negative Acknowledgment 420 Value: 4 (tentatively chosen) 421 Reference: RFC XXXX. 423 9. References 425 9.1. Normative References 427 [I-D.ietf-avt-rtcp-feedback] 428 Ott, J. and S. Wenger, "Extended RTP Profile for RTCP- 429 based Feedback(RTP/AVPF)", draft-ietf-avt-rtcp-feedback-11 430 (work in progress), August 2004. 432 [I-D.ietf-avt-rtp-hdrext] 433 Singer, D., "A general mechanism for RTP Header 434 Extensions", draft-ietf-avt-rtp-hdrext-03 (work in 435 progress), June 2006. 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, March 1997. 440 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 441 Jacobson, "RTP: A Transport Protocol for Real-Time 442 Applications", STD 64, RFC 3550, July 2003. 444 9.2. Informative References 446 [I-D.ietf-avt-rtp-no-op] 447 Andreasen, F., "A No-Op Payload Format for RTP", 448 draft-ietf-avt-rtp-no-op-00 (work in progress), May 2005. 450 [I-D.ietf-avt-rtp-retransmission] 451 Rey, J., "RTP Retransmission Payload Format", 452 draft-ietf-avt-rtp-retransmission-12 (work in progress), 453 September 2005. 455 [I-D.ietf-avt-ulp] 456 Li, A., "RTP Payload Format for Generic Forward Error 457 Correction", draft-ietf-avt-ulp-17 (work in progress), 458 March 2006. 460 [ITU.H264.2005] 461 International Telecommunications Union, "Advanced video 462 coding for generic audiovisual services", ITU- 463 T Recommendation H.264 (2005), ISO Standard 14496-10:2005, 464 March 2005. 466 [RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF 467 Digits, Telephony Tones and Telephony Signals", RFC 2833, 468 May 2000. 470 [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, 471 M., and D. Singer, "RTP Payload Format for H.264 Video", 472 RFC 3984, February 2005. 474 Appendix A. Requirements 476 This appendix describes the requirements motivating the design of the 477 protocol described in the rest of this document. (This appendix is 478 not normative; it thus does not use the formal upper-case versions of 479 the RFC 2119 [RFC2119] terms for its requirements.) 481 An encoder must be able to indicate a subset of the packets in a 482 generated RTP stream as being high-priority (R) packets. 484 A decoder must be able to determine when it has lost R packets, 485 whenever any packet of the stream is received, and regardless of the 486 dependency structure of the encoded stream. 488 Similarly, a decoder must be able to determine that it has not lost 489 any R packets as of the latest packet that has been received, 490 regardless of how many other non-R packets have been lost. 492 An encoder must be able to split a frame into any number of R 493 packets, either in a codec-aware manner (e.g. H.264 [ITU.H264.2005] 494 slices) or a codec-unaware manner (e.g. RFC 3984 [RFC3984] 495 fragmentation units). 497 An encoder must be able to state that an R packet supersedes previous 498 R packets, i.e. that some previous R packets are no longer necessary 499 in order to establish the stream state. This includes both being 500 able to state that all R packets before a given one have been 501 superseded, and that a range of R packets are superseded. 503 It must be possible for an encoder to apply forward error correction 504 [I-D.ietf-avt-ulp] to its media stream, either to all packets or 505 selectively only to R packets, in a way that allows R packet state to 506 be recovered from the FEC stream. 508 An encoder must be able to describe multiple separate series of R 509 packets, such that an R packet may supersede all previous R packets 510 of one series without altering the need for other series. It must 511 also be able to describe the most recent R packet of multiple series. 513 Appendix B. Analysis of Alternate Approaches 515 This appendix describes some alternate approaches that could be 516 considered to provide a reliable substream of a media stream. It 517 describes how they fail to satisfy the requirements listed in 518 Appendix A. 520 B.1. Generic NACK 522 This approach uses the Generic NACK mechanism [I-D.ietf-avt-rtcp- 523 feedback]. A receiver of a stream sends a Generic NACK for every RTP 524 packet it misses. The stream sender then re-sends only those packets 525 it knows are needed for the reliable subset of the stream. 527 In addition to causing many more NACK messages to be sent than are 528 necessary for the stream, this approach's primary difficulty is that 529 there is no way for a receiver to know when it should stop sending 530 NACK messages for those packets which it will not receive. 532 B.2. Generic NACK with Codec knowledge 534 This approach is like the previous one, except that decoders track 535 codec-specific dependency state to infer whether a missed packet was 536 an R packet or not, and they only send Generic NACK messages for the 537 packets that they conclude were R packets. 539 This conclusion is not in general possible, if a receiver misses both 540 an R packet and a subsequent non-R packet directly dependent on it. 541 Additionally, if an R frame is fragmented or sliced, a decoder can't 542 determine which packets were part of the sliced or fragmented R 543 frame. 545 B.3. Codec-Specific NACK 547 This approach is also like the previous one, except that decoders 548 send codec-specific NACK messages (in RPSI messages) listing specific 549 parts of frames that have been missed. 551 It is not in general possible to tell whether a missed frame was an R 552 packet, and the layering mechanisms don't support media-independent 553 fragmentation (for example RFC 3984 [RFC3984] fragmentation units). 555 B.4. Multiple streams 557 In this approach, R packets are sent on a separate RTP session than 558 the the non-R packets. RTP NACK messages are sent for packets on the 559 R packet session only. 561 This approach has the drawback that receipt of a non-R packet does 562 not trigger a NACK request for a missed R packet; only the next R 563 packet does that, unless the receiver has knowledge of the sender's 564 timing of R packets and thus can pro-actively send a NACK for a 565 packet it does not actually know it has missed. Since R packets tend 566 to be spaced far apart, this can greatly delay stream recovery. 568 Author's Address 570 Jonathan Lennox 571 Layered Media, Inc. 572 350 W. Passaic St 573 Fourth Floor 574 Rochelle Park, NJ 07662 575 US 577 Email: jonathan at layeredmedia.com 579 Intellectual Property Statement 581 The IETF takes no position regarding the validity or scope of any 582 Intellectual Property Rights or other rights that might be claimed to 583 pertain to the implementation or use of the technology described in 584 this document or the extent to which any license under such rights 585 might or might not be available; nor does it represent that it has 586 made any independent effort to identify any such rights. Information 587 on the procedures with respect to rights in RFC documents can be 588 found in BCP 78 and BCP 79. 590 Copies of IPR disclosures made to the IETF Secretariat and any 591 assurances of licenses to be made available, or the result of an 592 attempt made to obtain a general license or permission for the use of 593 such proprietary rights by implementers or users of this 594 specification can be obtained from the IETF on-line IPR repository at 595 http://www.ietf.org/ipr. 597 The IETF invites any interested party to bring to its attention any 598 copyrights, patents or patent applications, or other proprietary 599 rights that may cover technology that may be required to implement 600 this standard. Please address the information to the IETF at 601 ietf-ipr@ietf.org. 603 Disclaimer of Validity 605 This document and the information contained herein are provided on an 606 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 607 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 608 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 609 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 610 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 611 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 613 Copyright Statement 615 Copyright (C) The Internet Society (2006). This document is subject 616 to the rights, licenses and restrictions contained in BCP 78, and 617 except as set forth therein, the authors retain all their rights. 619 Acknowledgment 621 Funding for the RFC Editor function is currently provided by the 622 Internet Society.