idnits 2.17.1 draft-ietf-avt-rtp-format-guidelines-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. 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 (December 16, 1997) is 9622 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 213 looks like a reference -- Missing reference section? '2' on line 214 looks like a reference -- Missing reference section? '3' on line 216 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force AVT Working Group 3 Internet Draft Mark Handley 4 draft-ietf-avt-rtp-format-guidelines-00.txt ISI 5 December 16, 1997 6 Expires: June 1998 8 Guidelines for writers of RTP payload format specifications 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute work- 15 ing documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress''. 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 ABSTRACT 32 This document provides general guidelines aimed at 33 assisting the authors of RTP Payload Format specifica- 34 tions in deciding on good formats. These guidelines 35 attempt to capture some of the experience gained with RTP 36 as it evolved during its development. 38 1 Introduction 40 This document provides general guidelines aimed at assisting the 41 authors of RTP [1] Payload Format specifications in deciding on good 42 formats. These guidelines attempt to capture some of the experience 43 gained with RTP as it evolved during its development. 45 2 Background 47 RTP was designed around the concept of Application Level Framing 48 (ALF), first described by Clark and Tennenhouse[2]. The key argument 49 underlying ALF is that there are many different ways an application 50 might be able to cope with misordered or lost packets. These range 51 from ignoring the loss, to resending the missing data (either from a 52 buffer or by regenerating it), and to sending new data which super- 53 sedes the missing data. The application only has this choice if tran- 54 sport protocol is dealing with data in "Application Data Units" 55 (ADUs). An ADU contains data that can be processed out-of-order with 56 respect to other ADUs. Thus the ADU is the minimum unit of error 57 recovery. 59 The key property of a transport protocol for ADUs is that each ADU 60 contains sufficient information to be processed by the receiver 61 immediately. An example is a video stream, wherein the compressed 62 video data in an ADU must be capable of being decompressed regardless 63 of whether previous ADUs have been received. Additionally the ADU 64 must contain "header" information detailing its position in the video 65 image and the frame from which it came. 67 Although an ADU need not be a packet, there are many applications for 68 which a packet is a natural ADU. Such ALF applications have the great 69 advantage that all packets that are received can be processed by the 70 application immediately. 72 RTP was designed around an ALF philosphy. In the context of a stream 73 of RTP data, an RTP packet header provides sufficient information to 74 be able to identify and decode the packet irrespective of whether it 75 was received in order, or whether preceding packets have been lost. 76 However, these arguments only hold good if the RTP payload formats 77 are also designed using an ALF philosophy. 79 3 Guidelines 81 We identify the following requirements of RTP payload format specifi- 82 cations: 84 o A payload format should be devised so that in the presence of 85 loss, the payload can still be decoded. 87 o Ideally all the contents of every packet should be possible to 88 be decoded and played out irrespective of whether preceding 89 packets have been lost or arrive late. 91 The first of these requirements is based on the nature of the inter- 92 net. Although it may be possible to engineer parts of the internet to 93 produce low loss rates through careful provisioning or the use of 94 non-best-effort services, as a rule payload formats should not be 95 designed for these special purpose environments. Payload formats 96 should be designed to be used in the public internet with best effort 97 service, and thus should expect to see moderate loss rates (for exam- 98 ple, a 5% loss rate is not uncommon). Where payload formats do not 99 make these assumptions, they should state this explicitly up front, 100 and they will be considered special purpose payload formats, unsuit- 101 able for use on the public internet without special support from the 102 network infrastructure. 104 The second of these requirements is more explicit about how RTP 105 should cope with loss. If an RTP payload format is properly designed, 106 every packet that is actually received should be useful. Typically 107 this implies the following guidelines are adhered to: 109 o Packet boundaries should coincide with codec frame boundaries. 110 Thus a packet should normally consist of one or more complete 111 codec frames. 113 o A codec's minimum unit of data should never be packetised so 114 that it crossed a packet boundary unless it is larger than the 115 MTU. 117 o If a codecs frame size is larger than the MTU, the payload 118 format must not rely on IP fragmentation. Instead it must 119 define its own fragmentation mechanism. Such mechanisms may 120 involve codec-specific information that allows decoding of 121 fragments. Alternatively they might allow codec-independent 122 packet-level forward error correction[3] to be applied that 123 cannot be used with IP-level fragmentation. 125 In the abstract, a codec frame (i.e., the ADU or the minimum size 126 unit that has semantic meaning when handed to the codec) can be of 127 arbitrary size. For PCM audio, it is one byte. For GSM audio, a frame 128 corresponds to 20ms of audio. For H.261 video, it is a Group of 129 Blocks (GOB), or one twelfth of a CIF video frame. 131 For PCM, it does not matter how audio is packetised, as the ADU size 132 is one byte. For GSM audio, arbitrary packetisation would split a 133 20ms frame over two packets, which would mean that is one packet were 134 lost, partial frames in packets before and after the loss are mean- 135 ingless. This means that not only were the bits in the missing packet 136 lost, effectively additional bits in packets that used bottleneck 137 bandwidth were also lost because the receiver must throw them away. 138 Instead, we would packetise GSM by including several complete GSM 139 frames in a packet; typically four GSM frames are included in current 140 implementations. Thus every packet received can be decoded because 141 even in the presence of loss, no incomplete frames are received. 143 The H.261 specification allows GOBs to be up to 3KBytes long, 144 although most of the time they are smaller than this. It might be 145 thought that we should insert a group of blocks into a packet when it 146 fits, and arbitrarily split the GOB over two or more packets when a 147 GOB is large. In the first version of the H.261 payload format, this 148 is what was done. However, this still means that there are cir- 149 cumstances where H.261 packets arrive at the receiver and must be 150 discarded because other packets were lost - a loss multiplier effect 151 that we wish to avoid. In fact there are smaller units than GOBs in 152 the H.261 bit-stream called macroblocks, but they are not identifi- 153 able without parsing from the start of the GOB. However, if we pro- 154 vide a little additional information at the start of each packet, we 155 can re-instate information that would normally be found by parsing 156 from the start of the GOB, and we can packetise H.261 by splitting 157 the data stream on macroblock boundaries. This is a less obvious 158 packetisation for H.261 than the GOB packetisation, but it does mean 159 that a slightly smarter depacketiser at the receiver can reconstruct 160 a valid H.261 bitstream from a stream of RTP packets that has experi- 161 enced loss, and not have to discard any of the data that arrived. 163 An additional guideline concerns codecs that require the decoder 164 state machine to keep step with the encoder state machine. Many audio 165 codecs such as LPC or GSM are of this form. Typically they are loss 166 tolerant, in that after a loss, the predictor coefficients decay, so 167 that after a certain amount of time, the predictor error induced by 168 the loss will disappear. Most codecs designed for telephony services 169 are of this form because they were designed to cope with bit errors 170 without the decoder remaining in permanent error. Just packetising 171 these formats so that packets consist of integer multiples of codec 172 frames may not be optimal, as although the packet received immedi- 173 ately after a packet loss can be decoded, the start of the audio 174 stream produced will be incorrect (and hence distort the signal) 175 because the decoder predictor is now out of step with the encoder. In 176 principle, all of the decoder's internal state could be added using a 177 header attached to the start of every packet, but for lower bit-rate 178 encodings, this state is so substantial that the bit rate is no 179 longer low bit rate. However, a compromise can usually be found, 180 where a greatly reduced form of decoder state is sent in every 181 packet, which does not recreate the encoders predictor precisely, but 182 does reduce the magnitude and duration of the distortion produced 183 when the previous packet is lost. Such compressed state is by defini- 184 tion, very dependent on the codec in question. Thus we recommend: 186 o Payload formats for encodings where the decoder contains 187 internal data-driven state that attempts to track encoder state 188 should normally consider including a small additional header 189 that conveys the most critical elements of this state to reduce 190 distortion after packet loss. 192 4 Summary 194 Designing packet formats for RTP is not a trivial task. Typically a 195 detailed knowledge of the codec involved is required to be able to 196 design a format that is resilient to loss, does not introduce loss 197 magnification effects due to inappropriate packetisation, and does 198 not introduce unnecessary distortion after a packet loss. We believe 199 that considerable effort should be put into designing packet formats 200 that are well tailored to the codec in question. Typically this 201 requires a very small amount of processing at the sender and 202 receiver, but the result can be greatly improved quality when operat- 203 ing in typical internet environments. 205 It is possible to design generic packetisation formats that do not 206 pay attention to the issues described in this document, but such for- 207 mats are only suitable for special purpose networks where packet loss 208 can be avoided by careful engineering at the network layer, and are 209 not suited to current best-effort networks. 211 5 Bibliography 213 [1] H.Schulzrinne, S.Casner, R.Frederick, V. Jacobson, "Real-Time 214 Transport Protocol", RFC1899. [2] D. Clark, D. Tennenhouse, "Archi- 215 tectural Considerations for a New Generation of Network Protocols" 216 Proc ACM Sigcomm 90. [3] J. Nonnenmacher, E. Biersack, Don Towsley, 217 "Parity-Based Loss Recovery for Reliable Multicast Transmission", 218 Proc ACM Sigcomm '97, Canne, France, 1997.