idnits 2.17.1 draft-ietf-avt-rtp-format-guidelines-03.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: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 183 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 13 has weird spacing: '...delines attem...' == Line 18 has weird spacing: '...ormance with ...' == Line 19 has weird spacing: '...visions of Se...' == Line 20 has weird spacing: '...as, and its...' == Line 25 has weird spacing: '...and may be ...' == (178 more instances...) -- 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 1999) is 9081 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 1899 (ref. '9') Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force AVT WG 2 INTERNET-DRAFT M. Handley, C. Perkins 3 draft-ietf-avt-rtp-format-guidelines-03.txt ACIRI, UCL 4 24th June 1999 5 Expires: Dec 1999 7 Guidelines for Writers of RTP Payload Format Specifications 9 Abstract 11 This document provides general guidelines aimed at assisting the authors 12 of RTP Payload Format specifications in deciding on good formats. These 13 guidelines attempt to capture some of the experience gained with RTP as 14 it evolved during its development. 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC2026. Internet-Drafts are working docu- 20 ments of the Internet Engineering Task Force (IETF), its areas, and its 21 working groups. Note that other groups may also distribute working doc- 22 uments as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference material 27 or to cite them other than as ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 1. Introduction 37 This document provides general guidelines aimed at assisting the authors 38 of RTP [9] Payload Format specifications in deciding on good formats. 39 These guidelines attempt to capture some of the experience gained with 40 RTP as it evolved during its development. 42 2. Background 44 RTP was designed around the concept of Application Level Framing (ALF), 45 first described by Clark and Tennenhouse[2]. The key argument underlying 46 ALF is that there are many different ways an application might be able 47 to cope with misordered or lost packets. These range from ignoring the 48 loss, to re-sending the missing data (either from a buffer or by regen- 49 erating it), and to sending new data which supersedes the missing data. 50 The application only has this choice if transport protocol is dealing 51 with data in ``Application Data Units'' (ADUs). An ADU contains data 52 that can be processed out-of-order with respect to other ADUs. Thus the 53 ADU is the minimum unit of error recovery. 55 The key property of a transport protocol for ADUs is that each ADU con- 56 tains sufficient information to be processed by the receiver immedi- 57 ately. An example is a video stream, wherein the compressed video data 58 in an ADU must be capable of being decompressed regardless of whether 59 previous ADUs have been received. Additionally the ADU must contain 60 ``header'' information detailing its position in the video image and the 61 frame from which it came. 63 Although an ADU need not be a packet, there are many applications for 64 which a packet is a natural ADU. Such ALF applications have the great 65 advantage that all packets that are received can be processed by the 66 application immediately. 68 RTP was designed around an ALF philosophy. In the context of a stream 69 of RTP data, an RTP packet header provides sufficient information to be 70 able to identify and decode the packet irrespective of whether it was 71 received in order, or whether preceding packets have been lost. How- 72 ever, these arguments only hold good if the RTP payload formats are also 73 designed using an ALF philosophy. 75 Note that this also implies smart, network aware, end-points. An appli- 76 cation using RTP should be aware of the limitations of the underlying 77 network, and should adapt its transmission to match those limitations. 78 Our experience is that a smart end-point implementation can achieve sig- 79 nificantly better performance on real IP-based networks than a naive 80 implementation. 82 3. Channel Characteristics 84 We identify the following channel characteristics that influence the 85 best-effort transport of RTP over UDP/IP in the Internet: 87 o Packets may be lost 89 o Packets may be duplicated 91 o Packets may be reordered in transit 92 o Packets will be fragmented if they exceed the MTU of the underlying 93 network 95 The loss characteristics of a link may vary widely over short time 96 intervals. 98 Although fragmentation is not a disastrous phenomena if it is a rare 99 occurrence, relying on IP fragmentation is a bad design strategy as it 100 significantly increases the effective loss rate of a network and 101 decreases goodput. This is because if one fragment is lost, the remain- 102 ing fragments (which have used up bottleneck bandwidth) will then need 103 to be discarded by the receiver. It also puts additional load on the 104 routers performing fragmentation and on the end-systems re-assembling 105 the fragments. 107 In addition, it is noted that the transit time between two hosts on the 108 Internet will not be constant. This is due to two effects - jitter 109 caused by being queued behind cross-traffic, and routing changes. The 110 former is possible to characterise and compensate for by using a playout 111 buffer, but the latter is impossible to predict and difficult to accom- 112 modate gracefully. 114 4. Guidelines 116 We identify the following requirements of RTP payload format specifica- 117 tions: 119 o A payload format should be devised so that the stream being trans- 120 ported is still useful even in the presence of a moderate amount of 121 packet loss. 123 o Ideally all the contents of every packet should be possible to be 124 decoded and played out irrespective of whether preceding packets 125 have been lost or arrive late. 127 The first of these requirements is based on the nature of the internet. 128 Although it may be possible to engineer parts of the internet to produce 129 low loss rates through careful provisioning or the use of non-best- 130 effort services, as a rule payload formats should not be designed for 131 these special purpose environments. Payload formats should be designed 132 to be used in the public internet with best effort service, and thus 133 should expect to see moderate loss rates. For example, a 5% loss rate 134 is not uncommon. We note that TCP steady state models[3][4][6] indicate 135 that a 5% loss rate with a 1KByte packet size and 200ms round-trip time 136 will result in TCP achieving a throughput of around 180Kb/s. Higher 137 loss rates, smaller packet sizes, or a larger RTT are required to con- 138 strain TCP to lower data rates. For the most part, it is such TCP 139 traffic that is producing the background loss that many RTP flows must 140 co-exist with. Without explicit congestion notification (ECN)[8], loss 141 must be considered an intrinsic property of best-effort parts of the 142 Internet. 144 Where payload formats do not assume packet loss will occur, they should 145 state this explicitly up front, and they will be considered special pur- 146 pose payload formats, unsuitable for use on the public internet without 147 special support from the network infrastructure. 149 The second of these requirements is more explicit about how RTP should 150 cope with loss. If an RTP payload format is properly designed, every 151 packet that is actually received should be useful. Typically this 152 implies the following guidelines are adhered to: 154 o Packet boundaries should coincide with codec frame boundaries. Thus 155 a packet should normally consist of one or more complete codec 156 frames. 158 o A codec's minimum unit of data should never be packetised so that it 159 crossed a packet boundary unless it is larger than the MTU. 161 o If a codec's frame size is larger than the MTU, the payload format 162 must not rely on IP fragmentation. Instead it must define its own 163 fragmentation mechanism. Such mechanisms may involve codec-specific 164 information that allows decoding of fragments. Alternatively they 165 might allow codec-independent packet-level forward error correc- 166 tion[5] to be applied that cannot be used with IP-level fragmenta- 167 tion. 169 In the abstract, a codec frame (i.e., the ADU or the minimum size unit 170 that has semantic meaning when handed to the codec) can be of arbitrary 171 size. For PCM audio, it is one byte. For GSM audio, a frame corre- 172 sponds to 20ms of audio. For H.261 video, it is a Group of Blocks 173 (GOB), or one twelfth of a CIF video frame. 175 For PCM, it does not matter how audio is packetised, as the ADU size is 176 one byte. For GSM audio, arbitrary packetisation would split a 20ms 177 frame over two packets, which would mean that if one packet were lost, 178 partial frames in packets before and after the loss are meaningless. 179 This means that not only were the bits in the missing packet lost, but 180 also that additional bits in neighboring packets that used bottleneck 181 bandwidth were effectively also lost because the receiver must throw 182 them away. Instead, we would packetise GSM by including several com- 183 plete GSM frames in a packet; typically four GSM frames are included in 184 current implementations. Thus every packet received can be decoded 185 because even in the presence of loss, no incomplete frames are received. 187 The H.261 specification allows GOBs to be up to 3KBytes long, although 188 most of the time they are smaller than this. It might be thought that 189 we should insert a group of blocks into a packet when it fits, and arbi- 190 trarily split the GOB over two or more packets when a GOB is large. In 191 the first version of the H.261 payload format, this is what was done. 192 However, this still means that there are circumstances where H.261 pack- 193 ets arrive at the receiver and must be discarded because other packets 194 were lost - a loss multiplier effect that we wish to avoid. In fact 195 there are smaller units than GOBs in the H.261 bit-stream called mac- 196 roblocks, but they are not identifiable without parsing from the start 197 of the GOB. However, if we provide a little additional information at 198 the start of each packet, we can re-instate information that would nor- 199 mally be found by parsing from the start of the GOB, and we can packe- 200 tise H.261 by splitting the data stream on macroblock boundaries. This 201 is a less obvious packetisation for H.261 than the GOB packetisation, 202 but it does mean that a slightly smarter depacketiser at the receiver 203 can reconstruct a valid H.261 bitstream from a stream of RTP packets 204 that has experienced loss, and not have to discard any of the data that 205 arrived. 207 An additional guideline concerns codecs that require the decoder state 208 machine to keep step with the encoder state machine. Many audio codecs 209 such as LPC or GSM are of this form. Typically they are loss tolerant, 210 in that after a loss, the predictor coefficients decay, so that after a 211 certain amount of time, the predictor error induced by the loss will 212 disappear. Most codecs designed for telephony services are of this form 213 because they were designed to cope with bit errors without the decoder 214 remaining in permanent error. Just packetising these formats so that 215 packets consist of integer multiples of codec frames may not be optimal, 216 as although the packet received immediately after a packet loss can be 217 decoded, the start of the audio stream produced will be incorrect (and 218 hence distort the signal) because the decoder predictor is now out of 219 step with the encoder. In principle, all of the decoder's internal 220 state could be added using a header attached to the start of every 221 packet, but for lower bit-rate encodings, this state is so substantial 222 that the bit rate is no longer low. However, a compromise can usually 223 be found, where a greatly reduced form of decoder state is sent in every 224 packet, which does not recreate the encoders predictor precisely, but 225 does reduce the magnitude and duration of the distortion produced when 226 the previous packet is lost. Such compressed state is by definition, 227 very dependent on the codec in question. Thus we recommend: 229 o Payload formats for encodings where the decoder contains internal 230 data-driven state that attempts to track encoder state should nor- 231 mally consider including a small additional header that conveys the 232 most critical elements of this state to reduce distortion after 233 packet loss. 235 A similar issue arises with codec parameters, and whether or not they 236 should be included in the payload format. An example is with a codec 237 that has a choice of huffman tables for compression. The codec may use 238 either huffman table 1 or table 2 for encoding and the receiver needs to 239 know this information for correct decoding. There are a number of ways 240 in which this kind of information can be conveyed: 242 o Out of band signalling, prior to media transmission. 244 o Out of band signalling, but the parameter can be changed mid-ses- 245 sion. This requires synchronization of the change in the media 246 stream. 248 o The change is signaled through a change in the RTP payload type 249 field. This requires mapping the parameter space into particular 250 payload type values and signalling this mapping out-of-band prior to 251 media transmission. 253 o Including the parameter in the payload format. This allows for 254 adapting the parameter in a robust manner, but makes the payload 255 format less efficient. 257 Which mechanism to use depends on the utility of changing the parameter 258 in mid-session to support application layer adaptation. However, using 259 out-of-band signalling to change a parameter in mid-session is generally 260 to be discouraged due to this problems of synchronizing the parameter 261 change with the media stream. 263 4.1. RTP Header Extensions 265 Many RTP payload formats require some additional header information to 266 be carried in addition to that included in the fixed RTP packet header. 267 The recommended way of conveying this information is in the payload sec- 268 tion of the packet. The RTP header extension should not be used to con- 269 vey payload specific information ([9],section 5.3) since this is ineffi- 270 cient in its use of bandwidth; requires the definition of a new RTP pro- 271 file or profile extension; and makes it difficult to employ FEC schemes 272 such as, for example, [7]. Use of an RTP header extension is only 273 appropriate for cases where the extension in question applies across a 274 wide range of payload types. 276 4.2. Header Compression 278 Designers of payload formats should also be aware of the needs of RTP 279 header compression [1]. In particular, the compression algorithm func- 280 tions best when the RTP timestamp increments by a constant value between 281 consecutive packets. Payload formats which rely on sending packets out 282 of order, such that the timestamp increment is not constant, are likely 283 to compress less well than those which send packets in order. This has 284 most often been an issue when designing payload formats for FEC informa- 285 tion, although some video codecs also rely on out-of-order transmission 286 of packets at the expense of reduced compression. Although in some 287 cases such out-of-order transmission may be the best solution, payload 288 format designers are encourage to look for alternative solutions where 289 possible. 291 5. Summary 293 Designing packet formats for RTP is not a trivial task. Typically a 294 detailed knowledge of the codec involved is required to be able to 295 design a format that is resilient to loss, does not introduce loss mag- 296 nification effects due to inappropriate packetisation, and does not 297 introduce unnecessary distortion after a packet loss. We believe that 298 considerable effort should be put into designing packet formats that are 299 well tailored to the codec in question. Typically this requires a very 300 small amount of processing at the sender and receiver, but the result 301 can be greatly improved quality when operating in typical internet envi- 302 ronments. 304 Designers of new codecs for use with RTP should consider making the out- 305 put of the codec ``naturally packetizable''. This implies that the codec 306 should be designed to produce a packet stream, rather than a bit-stream; 307 and that that packet stream contains the minimal amount of redundancy 308 necessary to ensure that each packet is independently decodable with 309 minimal loss of decoder predictor tracking. It is recognised that sacri- 310 ficing some small amount of bandwidth to ensure greater robustness to 311 packet loss is often a worthwhile tradeoff. 313 It is hoped that, in the long run, new codecs should be produced which 314 can be directly packetised, without the trouble of designing a codec- 315 specific payload format. 317 It is possible to design generic packetisation formats that do not pay 318 attention to the issues described in this document, but such formats are 319 only suitable for special purpose networks where packet loss can be 320 avoided by careful engineering at the network layer, and are not suited 321 to current best-effort networks. 323 6. Security Considerations 325 The guidelines in this document result in RTP payload formats that are 326 robust in the presence of real world network conditions. Designing pay- 327 load formats for special purpose networks that assume negligable loss 328 rates will normally result in slightly better compression, but produce 329 formats that are more fragile, thus rendering them easier targets for 330 denial-of-service attacks. 332 Designers of payload formats should pay close attention to possible 333 security issues that might arise from poor implementations of their for- 334 mats, and should be careful to specify the correct behaviour when anoma- 335 lous conditions arise. Examples include how to process illegal field 336 values, and conditions when there are mismatches between length fields 337 and actual data. Whilst the correct action will normally be to discard 338 the packet, possible such conditions should be brought to the attention 339 of the implementor to ensure that they are trapped properly. 341 The RTP specification covers encryption of the payload. This issue 342 SHOULD NOT normally be dealt with by payload formats themselves. How- 343 ever, certain payload formats spread information about a particular 344 application data unit over a number of packets, or rely on packets which 345 relate to a number of application data units. Care must be taken when 346 changing the encryption of such streams, since such payload formats may 347 constrain the places in a stream where it is possible to change the 348 encryption key without exposing sensitive data. 350 Designers of payload formats which include FEC should be aware that the 351 automatic addition of FEC in response to packet loss may increase net- 352 work congestion, leading to a worsening of the problem which the use of 353 FEC was intended to solve. Since this may, at its worst, constitute a 354 denial of service attack, designers of such payload formats should take 355 care that appropriate safeguards are in place to prevent abuse. 357 Authors Addresses 359 Mark Handley 360 AT&T Center for Internet Research at ICSI, 361 International Computer Science Institute, 362 1947 Center Street, Suite 600, 363 Berkeley, CA 94704, USA 364 mjh@aciri.org 366 Colin Perkins 367 Dept of Computer Science, 368 University College London, 369 Gower Street, 370 London WC1E 6BT, UK. 371 C.Perkins@cs.ucl.ac.uk 372 Acknowledgments 374 This document is based on experience gained over several years by many 375 people, including Van Jacobson, Steve McCanne, Steve Casner, Henning 376 Schulzrinne, Thierry Turletti, Jonathan Rosenberg and Christian Huitema 377 amongst others. 379 References 381 [1] S. Casner, V. Jacobson, ``Compressing IP/UDP/RTP Headers for Low- 382 Speed Serial Links'', RFC 2508. 384 [2] D. Clark, D. Tennenhouse, "Architectural Considerations for a New 385 Generation of Network Protocols" Proc ACM Sigcomm 90. 387 [3] J. Mahdavi and S. Floyd. ``TCP-friendly unicast rate-based flow 388 control''. Note sent to end2end-interest mailing list, Jan 1997. 390 [4] M. Mathis, J. Semske, J. Mahdavi, and T. Ott. ``The macro-scopic 391 behavior of the TCP congestion avoidance algorithm''. Computer Com- 392 munication Review, 27(3), July 1997. 394 [5] J. Nonnenmacher, E. Biersack, Don Towsley, ``Parity-Based Loss 395 Recovery for Reliable Multicast Transmission'', Proc ACM Sigcomm 396 '97, Cannes, France, 1997. 398 [6] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, ``Modeling TCP 399 Throughput: A Simple Model and its Empirical Validation'', Proc. 400 ACM Sigcomm 1998. 402 [7] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. 403 Bolot, A. Vega-Garcia, S. Fosse-Parisis, ``RTP Payload for Redun- 404 dant Audio Data'', RFC 2198. 406 [8] K. K. Ramakrishnan, Sally Floyd, ``A Proposal to add Explicit Con- 407 gestion Notification (ECN) to IP'' INTERNET DRAFT, Work in 408 Progress. 410 [9] H.Schulzrinne, S.Casner, R.Frederick, V. Jacobson, "Real-Time 411 Transport Protocol", RFC1899.