idnits 2.17.1 draft-ietf-avt-rtp-format-guidelines-01.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-26) 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 (November 13, 1998) is 9296 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 281 looks like a reference -- Missing reference section? '2' on line 282 looks like a reference -- Missing reference section? '4' on line 286 looks like a reference -- Missing reference section? '5' on line 289 looks like a reference -- Missing reference section? '6' on line 292 looks like a reference -- Missing reference section? '7' on line 296 looks like a reference -- Missing reference section? '3' on line 284 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 9 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-01.txt ISI 5 November 13, 1998 6 Expires: May 1999 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 philosophy. 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 Note that this also implies smart, network aware, end-points. An 80 application using RTP should be aware of the limitations of the 81 underlying network, and should adapt its transmission to match those 82 limitations. Our experience is that a smart end-point implementation 83 can achieve significantly better performance on real IP-based net- 84 works than a naive implementation. 86 3 Channel Characteristics 88 We identify the following channel characteristics that influence the 89 best-effort transport of RTP over UDP/IP in the Internet: 91 o Packets may be lost 93 o Packets may be duplicated 95 o Packets may be reordered in transit 96 o Packets will be fragmented if they exceed the MTU of the 97 underlying network 99 The loss characteristics of a link may vary widely over short time 100 intervals. 102 Although fragmentation is not a disastrous phenomena if it is a rare 103 occurance, relying on IP fragmentation is a bad design strategy as it 104 significantly increases the effective loss rate of a network and 105 decreases goodput. This is because if one fragment is lost, the 106 remaining fragments (which have used up bottleneck bandwidth) will 107 then need to be discarded by the receiver. It also puts additional 108 load on the routers performing fragmentation and on the end-systems 109 re-assembling the fragments. 111 In addition, it is noted that the transit time between two hosts on 112 the Internet will not be constant. This is due to two effects - 113 jitter caused by being queued behind cross-traffic, and routing 114 changes. The former is possible to characterise and compensate for by 115 using a playout buffer, but the latter is impossible to predict and 116 difficult to accommodate gracefully. 118 4 Guidelines 120 We identify the following requirements of RTP payload format specifi- 121 cations: 123 o A payload format should be devised so that in the presence of 124 loss, the payload can still be decoded. 126 o Ideally all the contents of every packet should be possible to 127 be decoded and played out irrespective of whether preceding 128 packets have been lost or arrive late. 130 The first of these requirements is based on the nature of the inter- 131 net. Although it may be possible to engineer parts of the internet to 132 produce low loss rates through careful provisioning or the use of 133 non-best-effort services, as a rule payload formats should not be 134 designed for these special purpose environments. Payload formats 135 should be designed to be used in the public internet with best effort 136 service, and thus should expect to see moderate loss rates. For exam- 137 ple, a 5% loss rate is not uncommon. We note that TCP steady state 138 models[4][5][6] indicate that a 5% loss rate with a 1KByte packet 139 size and 200ms round-trip time will result in TCP achieving a 140 throughput of around 180Mb/s. Higher loss rates, smaller packet 141 sizes, or a larger RTT are required to constrain TCP to lower data 142 rates. For the most part, it is such TCP traffic that is producing 143 the background loss that many RTP flows must co-exist with. Without 144 explicit congestion notification (ECN)[7], loss must be considered an 145 intrinsic property of best-effort parts of the Internet. 147 Where payload formats do not assume packet loss will occur, they 148 should state this explicitly up front, and they will be considered 149 special purpose payload formats, unsuitable for use on the public 150 internet without special support from the network infrastructure. 152 The second of these requirements is more explicit about how RTP 153 should cope with loss. If an RTP payload format is properly designed, 154 every packet that is actually received should be useful. Typically 155 this implies the following guidelines are adhered to: 157 o Packet boundaries should coincide with codec frame boundaries. 158 Thus a packet should normally consist of one or more complete 159 codec frames. 161 o A codec's minimum unit of data should never be packetised so 162 that it crossed a packet boundary unless it is larger than the 163 MTU. 165 o If a codecs frame size is larger than the MTU, the payload 166 format must not rely on IP fragmentation. Instead it must 167 define its own fragmentation mechanism. Such mechanisms may 168 involve codec-specific information that allows decoding of 169 fragments. Alternatively they might allow codec-independent 170 packet-level forward error correction[3] to be applied that 171 cannot be used with IP-level fragmentation. 173 In the abstract, a codec frame (i.e., the ADU or the minimum size 174 unit that has semantic meaning when handed to the codec) can be of 175 arbitrary size. For PCM audio, it is one byte. For GSM audio, a frame 176 corresponds to 20ms of audio. For H.261 video, it is a Group of 177 Blocks (GOB), or one twelfth of a CIF video frame. 179 For PCM, it does not matter how audio is packetised, as the ADU size 180 is one byte. For GSM audio, arbitrary packetisation would split a 181 20ms frame over two packets, which would mean that if one packet were 182 lost, partial frames in packets before and after the loss are mean- 183 ingless. This means that not only were the bits in the missing packet 184 lost, effectively additional bits in packets that used bottleneck 185 bandwidth were also lost because the receiver must throw them away. 186 Instead, we would packetise GSM by including several complete GSM 187 frames in a packet; typically four GSM frames are included in current 188 implementations. Thus every packet received can be decoded because 189 even in the presence of loss, no incomplete frames are received. 191 The H.261 specification allows GOBs to be up to 3KBytes long, 192 although most of the time they are smaller than this. It might be 193 thought that we should insert a group of blocks into a packet when it 194 fits, and arbitrarily split the GOB over two or more packets when a 195 GOB is large. In the first version of the H.261 payload format, this 196 is what was done. However, this still means that there are cir- 197 cumstances where H.261 packets arrive at the receiver and must be 198 discarded because other packets were lost - a loss multiplier effect 199 that we wish to avoid. In fact there are smaller units than GOBs in 200 the H.261 bit-stream called macroblocks, but they are not identifi- 201 able without parsing from the start of the GOB. However, if we pro- 202 vide a little additional information at the start of each packet, we 203 can re-instate information that would normally be found by parsing 204 from the start of the GOB, and we can packetise H.261 by splitting 205 the data stream on macroblock boundaries. This is a less obvious 206 packetisation for H.261 than the GOB packetisation, but it does mean 207 that a slightly smarter depacketiser at the receiver can reconstruct 208 a valid H.261 bitstream from a stream of RTP packets that has experi- 209 enced loss, and not have to discard any of the data that arrived. 211 An additional guideline concerns codecs that require the decoder 212 state machine to keep step with the encoder state machine. Many audio 213 codecs such as LPC or GSM are of this form. Typically they are loss 214 tolerant, in that after a loss, the predictor coefficients decay, so 215 that after a certain amount of time, the predictor error induced by 216 the loss will disappear. Most codecs designed for telephony services 217 are of this form because they were designed to cope with bit errors 218 without the decoder remaining in permanent error. Just packetising 219 these formats so that packets consist of integer multiples of codec 220 frames may not be optimal, as although the packet received immedi- 221 ately after a packet loss can be decoded, the start of the audio 222 stream produced will be incorrect (and hence distort the signal) 223 because the decoder predictor is now out of step with the encoder. In 224 principle, all of the decoder's internal state could be added using a 225 header attached to the start of every packet, but for lower bit-rate 226 encodings, this state is so substantial that the bit rate is no 227 longer low bit rate. However, a compromise can usually be found, 228 where a greatly reduced form of decoder state is sent in every 229 packet, which does not recreate the encoders predictor precisely, but 230 does reduce the magnitude and duration of the distortion produced 231 when the previous packet is lost. Such compressed state is by defini- 232 tion, very dependent on the codec in question. Thus we recommend: 234 o Payload formats for encodings where the decoder contains 235 internal data-driven state that attempts to track encoder state 236 should normally consider including a small additional header 237 that conveys the most critical elements of this state to reduce 238 distortion after packet loss. 240 5 Summary 242 Designing packet formats for RTP is not a trivial task. Typically a 243 detailed knowledge of the codec involved is required to be able to 244 design a format that is resilient to loss, does not introduce loss 245 magnification effects due to inappropriate packetisation, and does 246 not introduce unnecessary distortion after a packet loss. We believe 247 that considerable effort should be put into designing packet formats 248 that are well tailored to the codec in question. Typically this 249 requires a very small amount of processing at the sender and 250 receiver, but the result can be greatly improved quality when operat- 251 ing in typical internet environments. 253 Designers of new codecs for use with RTP should consider making the 254 output of the codec "naturally packetizable". This implies that the 255 codec should be designed to produce a packet stream, rather than a 256 bit-stream; and that that packet stream contains the minimal amount 257 of redundancy necessary to ensure that each packet is independently 258 decodable with minimal loss of decoder predictor tracking. It is 259 recognised that sacrificing some small amount of bandwidth to ensure 260 greater robustness to packet loss is often a worthwhile tradeoff. 262 It is hoped that, in the long run, new codecs should be produced 263 which can be directly packetised, without the trouble of designing a 264 codec-specific payload format. 266 It is possible to design generic packetisation formats that do not 267 pay attention to the issues described in this document, but such for- 268 mats are only suitable for special purpose networks where packet loss 269 can be avoided by careful engineering at the network layer, and are 270 not suited to current best-effort networks. 272 Acknowledgments 274 This document is based on experience gained over several years by 275 many people, including Van Jacobson, Steve McCanne, Steve Casner, 276 Henning Schulzrinne, Thierry Turletti, and Christian Huitema amongst 277 others. Colin Perkins contributed to the text. 279 6 Bibliography 281 [1] H.Schulzrinne, S.Casner, R.Frederick, V. Jacobson, "Real-Time 282 Transport Protocol", RFC1899. [2] D. Clark, D. Tennenhouse, "Archi- 283 tectural Considerations for a New Generation of Network Protocols" 284 Proc ACM Sigcomm 90. [3] J. Nonnenmacher, E. Biersack, Don Towsley, 285 "Parity-Based Loss Recovery for Reliable Multicast Transmission", 286 Proc ACM Sigcomm '97, Cannes, France, 1997. [4] J. Mahdavi and S. 288 Floyd. "TCP-friendly unicast rate-based flow control". Note sent to 289 end2end-interest mailing list, Jan 1997. [5] M. Mathis, J. Semske, 290 J. Mahdavi, and T. Ott. "The macro-scopic behavior of the TCP conges- 291 tion avoidance algorithm". Computer Communication Review, 27(3), July 292 1997. [6] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, "Modeling TCP 293 Throughput: A Simple Model and its Empirical Validation", Proc. ACM 294 Sigcomm 1998. 296 [7] K. K. Ramakrishnan, Sally Floyd, "A Proposal to add Explicit 297 Congestion Notification (ECN) to IP" INTERNET DRAFT, Work in Pro- 298 gress.