idnits 2.17.1 draft-ietf-avt-info-repair-02.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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 8) being 60 lines 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 71 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 54 has weird spacing: '...ined to be a ...' == Line 55 has weird spacing: '... packet compr...' -- 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 (7 January 1998) is 9606 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. '1' -- 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. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Obsolete normative reference: RFC 1889 (ref. '15') (Obsoleted by RFC 3550) -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 7 January 1998 4 Colin Perkins 5 Orion Hodson 6 University College London 8 Options for Repair of Streaming Media 9 draft-ietf-avt-info-repair-02 11 Status of this memo 13 This document is an Internet-Draft. Internet-Drafts are working documents 14 of the Internet Engineering Task Force (IETF), its areas, and its working 15 groups. Note that other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months and 19 may be updated, replaced, or obsoleted by other documents at any time. It 20 is inappropriate to use Internet-Drafts as reference material or to cite 21 them other than as ``work in progress''. To learn the current status of 22 any Internet-Draft, please check the ``1id-abstracts.txt'' listing 23 contained in the Internet-Drafts Shadow Directories on ftp.is.co.za 24 (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), 25 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 Comments are solicited and should be addressed to the author(s) and/or the 30 IETF Audio/Video Transport working group's mailing list at rem-conf@es.net. 32 Abstract 34 This document summarizes a range of possible techniques 35 for the repair of continuous media streams subject to packet 36 loss. The techniques discussed include redundant transmission, 37 retransmission, interleaving and forward error correction. 38 The range of applicability of these techniques is noted, 39 together with the protocol requirements and dependencies. 41 1 Introduction 43 A number of applications have emerged which use RTP/UDP transport to 44 deliver continuous media streams. Due to the unreliable nature of UDP 45 packet delivery, the quality of the received stream will be adversely 46 affected by packet loss. A number of techniques exist by which the effects 47 of packet loss may be repaired. These techniques 48 have a wide range of applicability and require varying degrees of 49 protocol support. In this document, a number of such techniques 50 are discussed, and recommendations for their applicability made. 52 2 Terminology and Protocol Framework 54 A unit is defined to be a timed interval of media data, typically derived 55 from the workings of the media coder. A packet comprises one or more 56 units, encapsulated for transmission over the network. For example, many 57 audio coders operate on 20ms units, which are typically combined to produce 58 40ms or 80ms packets for transmission. 60 The framework of RTP [15] is assumed. This implies that packets have a 61 sequence number and timestamp. The sequence number denotes the order in 62 which packets are transmitted, and is used to detect losses. The timestamp 63 is used to determine the playout order of units. Most loss recovery 64 schemes rely on units being sent out of order, so an application must use 65 the RTP timestamp to schedule playout. 67 The use of RTP allows for several different media coders, with a payload 68 type field being used to distinguish between these at the receiver. Some 69 loss recovery schemes send some units multiple times, using different 70 encoding schemes. A receiver is assumed to have a `quality' ranking of the 71 differing encodings, and so is capable of choosing the `best' unit for 72 playout, given multiple options. 74 3 Network Loss Characteristics 76 If it is desired to repair a media stream subject to packet loss, it is 77 useful to have some knowledge of the loss characteristics which are likely 78 to be encountered. A number of studies have been conducted on the loss 79 characteristics of the Mbone [8,9] and although the results vary somewhat, 80 the broad conclusion is clear: in a large conference it is inevitable that 81 some receivers will experience packet loss. Packet traces taken by Handley 82 [5] show a session in which most receivers experience loss in the range 83 2-5%, with a somewhat smaller number seeing significantly higher loss 84 rates. Other studies have presented broadly similar results. 86 It has also been shown that the vast majority of losses are of single 87 packets. Burst losses of two or more packets are around an order of 88 magnitude less frequent than single packet loss, although they do occur 89 more often than would be expected from a purely random process. Longer 90 burst losses (of the order of tens of packets) occur infrequently. These 91 results are consistent with a network where small amounts of transient 92 congestion cause the majority of packet loss. In a few 93 cases, a network link is found to be severely overloaded, and large 94 amount of loss results. 96 The primary focus of a packet loss repair scheme must, therefore, be to 97 correct single packet loss, since this is by far the most frequent 98 occurrence. It is desirable that losses of a relatively small number of 99 consecutive packets may also be repaired, since such losses represent a 100 small but noticeable fraction of observed losses. The correction of large 101 bursts of loss is of considerably less importance. 103 4 Loss Mitigation Schemes 105 In the following sections, four loss mitigation schemes are discussed. 106 These schemes have been discussed in the literature a number of times, and 107 found to be of use in a number of scenarios. Each technique is briefly 108 described, and its advantages and disadvantages noted. 110 4.1 Forward Error Correction 112 Forward error correction (FEC) is the means by which repair data is added 113 to a media stream, such that packet loss can be repaired by the receiver of 114 that stream with no further reference to the sender. There are two classes 115 of repair data which may be added to a stream: those which are independent 116 of the contents of the stream, and those which use knowledge of the stream 117 to improve the repair process. 119 4.1.1 Media-Independent FEC 121 A number of media-independent FEC schemes have been proposed for use with 122 streamed media. These techniques add redundant data to a media stream 123 which is transmitted in separate packets. Traditionally, FEC techniques 124 are described as loss detecting and/or loss correcting. In the case of 125 streamed media loss detection is provided by the sequence numbers in RTP 126 packets. 128 The redundant FEC data is typically calculated using the mathematics of 129 finite fields [1]. The simplest of finite field is GF(2) where addition is 130 just the eXclusive-OR operation. 132 Basic FEC schemes transmit k data packets with n-k parity packets allowing 133 the reconstruction of the original data from any k of the n transmitted 134 packets. Budge et al [3] proposed applying the XOR operation across 135 different combinations of the media data with the redundant data 136 transmitted separately as parity packets. These vary the pattern of 137 packets over which the parity is calculated, and hence have different 138 bandwidth, latency and loss repair characteristics. 140 Luby et al [8] have discussed applying parity in layers. The first layer 141 in their scheme is the parity bits generated from the media. The second 142 layer is calculated as the parity bits of the first layer and so on. This 143 obviously improves the repair properties, but consumes additional 144 bandwidth. 146 Parity-based FEC based techniques have a significant advantage in that they 147 are media independent, and provide exact repair for lost packets. In 148 addition, the processing requirements are relatively light, especially when 149 compared with some redundancy schemes which use very low bandwidth, but 150 high complexity encodings. The disadvantage of parity-based FEC is that 151 the codings have higher latency in comparison with the media-specific 152 schemes discussed in following section. An RTP payload format for 153 parity-based FEC is defined in [14]. The format is generic, and can 154 specify many different parity encodings. 156 A number of FEC schemes exist which are based on higher-order finite 157 fields. An example of such are Reed-Solomon (RS) codes which are more 158 sophisticated and computationally demanding. These are usually structured 159 so that they have good burst loss protection. There has been much work 160 conducted in this area, and it is believed that a number of streaming 161 applications use RS codes. 163 4.1.2 Media-Specific FEC 165 The basis of media-specific FEC is to employ knowledge of a media 166 compression scheme to achieve more efficient repair of a stream than can 167 otherwise be achieved. To repair a stream subject to packet loss, it is 168 necessary to add redundancy to that stream: some information is added 169 which is not required in the absence of packet loss, but which can be used 170 to recover from that loss. 172 The nature of a media stream affects the means by which the redundancy is 173 added. If units of media data are packets, or if multiple units are 174 included in a packet, it is logical to use the unit as the level of 175 redundancy, and to send duplicate units. By recoding the redundant copy of 176 a unit, significant bandwidth savings may be made, at the expense of 177 additional computational complexity and approximate repair. This approach 178 has been advocated for use with streaming audio [5,6] and has been shown to 179 perform well. An RTP payload format for this form of redundancy has been 180 defined [12]. 182 If media units span multiple packets, for instance video, it is sensible to 183 include redundancy directly within the output of a codec. For example the 184 proposed RTP payload for H.263+ [2] includes multiple copies of key 185 portions of the stream, separated to avoid the problems of packet loss. 186 The advantages of this second approach is efficiency: the codec designer 187 knows exactly which portions of the stream are 188 most important to protect, and low complexity since each unit is coded once 189 only. 191 An alternative approach is to apply media-independent FEC techniques to the 192 most significant bits of a codecs output, rather than applying it over the 193 entire packet. Several codec descriptions include bit sensitivities that 194 make this feasible. This approach has low computational cost and can be 195 tailored to represent an arbitrary fraction of the transmitted data. 197 The use of media-specific FEC has the advantage of low-latency, with only a 198 single-packet delay being added. This makes it suitable for interactive 199 applications, where large end-to-end delays cannot be tolerated. In a 200 uni-directional non-interactive environment it is possible to delay sending 201 the redundant data, achieving improved performance in the presence of burst 202 losses [7], at the expense of additional latency. 204 4.2 Retransmission 206 Retransmission of lost packets is an obvious means by which loss may be 207 repaired. It is clearly of value in non-interactive applications, with 208 relaxed delay bounds, but the delay imposed means that it does not 209 typically perform well for interactive use. 211 In addition to the possibly high latency, there is a potentially large 212 bandwidth overhead to the use of retransmission. Not only are units of 213 data sent multiple times, but additional control traffic must flow to 214 request the retransmission. It has been shown that, in a large Mbone 215 session, most packets are lost by at least one receiver [5]. In this case 216 the overhead of requesting retransmission for most packets may be such that 217 the use of forward error correction is more acceptable. This leads to a 218 natural synergy between the two mechanisms, with a forward error correction 219 scheme being used to repair all single packet losses, and those receivers 220 experiencing burst losses, and willing to accept the additional latency, 221 using retransmission based repair as an additional recovery mechanism. 222 Similar mechanisms have been used in a number of reliable multicast 223 schemes, and have received some discussion in the literature [10, 6]. 225 In order to reduce the overhead of retransmission, the retransmitted units 226 may be piggy-backed onto the ongoing transmission. This also allows for 227 the retransmission to be recoded in a different format, to further reduce 228 the bandwidth overhead. 230 The choice of a retransmission request algorithm which is both timely 231 and network friendly is an area of current study. An obvious starting 232 point is the SRM protocol [4], and experiments have been conducted 233 using this, and with a low-delay variant, STORM [17]. This work 234 shows the trade-off between latency and quality for retransmission 235 based repair schemes, and illustrates that retransmission is an effective 236 approach to repair for applications which can tolerate the latency. 238 An RTP profile extension for SRM-style retransmission requests is 239 described in [11]. 241 4.3 Interleaving 243 When the unit size is smaller than the packet size, and end-to-end delay is 244 unimportant, interleaving [13] is a useful technique for reducing the 245 effects of loss. Units are resequenced before transmission, so that 246 originally adjacent units are separated by a guaranteed distance in the 247 transmitted stream, and returned to their original order at the receiver. 248 Interleaving disperses the effect of packet losses. If, for example, units 249 are 5ms in length and packets 20ms (ie: 4 units per packet), then the 250 first packet could contain units 1, 5, 9, 13; the second packet would 251 contain units 2, 6, 10, 14; and so on. It can be seen that the loss of a 252 single packet from an interleaved stream results in multiple small gaps in 253 the reconstructed stream, as opposed to the single large gap which would 254 occur in a non-interleaved stream. In many cases it is easier to 255 reconstruct a stream with such loss patterns, although this is clearly 256 media and codec dependent. The obvious disadvantage of interleaving is 257 that it increases latency. This limits the use of this technique for 258 interactive applications, although it performs well for non-interactive 259 use. The major advantage of interleaving is that it does not increase the 260 bandwidth requirements of a stream. 262 A potential RTP payload format for interleaved data is a simple extension 263 of the redundant audio payload [12]. That payload requires that the 264 redundant copy of a unit is sent after the primary. If this restriction is 265 removed, it is possible to transmit an arbitrary interleaving of units with 266 this payload format. 268 5 Recommendations 270 If the desired scenario is a non-interactive uni-directional transmission, 271 in the style of a radio or television broadcast for example, latency is of 272 considerably less importance than reception quality. In this case, the use 273 of interleaving and/or retransmission based repair is appropriate, with 274 interleaving being preferred due to its bandwidth efficiency (provided that 275 approximate repair is acceptable). 277 In an interactive session (typically defined as a session where the 278 end-to-end delay is less then 250ms, this includes media coding/decoding, 279 network transit and host buffering), the delay imposed by the use of 280 interleaving and retransmission is not acceptable, and a low-latency 281 FEC scheme is the only means of repair suitable. The choice between 282 media independent and media specific forward error correction is less 283 clear-cut: media-specific FEC can be made more efficient, but requires 284 modification to the output of the codec. When defining the packetisation 285 for a new codec, this is clearly an appropriate technique, and should 286 be encouraged. 288 If an existing codec is to be used, a media independent forward error 289 correction scheme is usually easier to implement, and can perform 290 well. A media stream protected in this way may be augmented with 291 retransmission based repair with minimal overhead, providing improved 292 quality for those receivers willing to tolerate additional delay. 293 Whilst the addition of error correction data to an media stream is 294 an effective means by which that stream may be protected against 295 packet loss, application designers should be aware that the addition 296 of large amounts of repair data will increase network congestion, 297 and hence packet loss, leading to a worsening of the problem which 298 the use of error correction coding was intended to solve. 300 At the time of writing, there is no standard solution to the problem 301 of congestion control for streamed media which can be used to solve 302 this problem. There have, however, been a number of contributions 303 which show the likely form the solution will take [9, 16]. This 304 work typically used some form of layered encoding of data over multiple 305 channels, with receivers joining and leaving layers in response to 306 packet-loss (which indicates congestion). The aim of such schemes 307 is to emulate the congestion control behaviour of a TCP stream, and 308 hence compete fairly with non-real-time traffic. This is necessary 309 for stable network behaviour in the presence of much streamed media. 311 6 Acknowledgements 313 The authors wish to thank Phil Karn for his helpful comments. 315 7 Author's Address 317 Colin Perkins/Orion Hodson 318 Department of Computer Science 319 University College London 320 Gower Street 321 London WC1E 6BT 322 United Kingdom 324 Email: @cs.ucl.ac.uk 325 References 327 [1] R.E. Blahut. Theory and Practice of Error Control Codes. 328 Addison Wesley, 1983. 330 [2] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, 331 D. Newell, J. Ott, S. Wenger, and C. Zhu. RTP payload 332 format for the 1998 version of ITU-T rec. H.263 video 333 (H.263+). IETF Audio/Video Transport Working Group, 334 November 1997. Work in progress. 336 [3] D. Budge, R. McKenzie, W. Mills, W. Diss, and P. Long. 337 Media-independent error correction using RTP, May 1997. 338 Work in progress. 340 [4] S. Floyd, V. Jacobson, S. McCanne, C.-G. Liu, and 341 L. Zhang. A reliable multicast framework for light-weight 342 sessions and applications level framing. IEEE/ACM 343 Transactions on Networking, 1995. 345 [5] M. Handley. An examination of Mbone performance. USC/ISI 346 Research Report: ISI/RR-97-450, April 1997. 348 [6] M. Handley and J. Crowcroft. Network text editor (NTE): A 349 scalable shared text editor for the Mbone. In Proceedings 350 ACM SIGCOMM'97, Cannes, France, September 1997. 352 [7] I. Kouvelas, O. Hodson, V. Hardman, and J. Crowcroft. 353 Redundancy control in real-time Internet audio 354 conferencing. In Proceedings of AVSPN'97, Aberdeen, 355 Scotland, September 1997. 357 [8] G.M. Luby, M. Mitzenmacher, M. Amin Shokrollahi, D.A. 358 Spielman, and V. Stemann. Practical loss-resilent codes. 359 In Twenty-Nineth Annual ACM Symposium on theTheory of 360 Computing, 1997. 362 [9] S. McCanne, V. Jacobson, and M. Vetterli. Receiver-driven 363 layered multicast. In Proceedings ACM SIGCOMM'96, Stanford, 364 CA., August 1996. 366 [10] J. Nonnenmacher, E. Biersack, and D. Towsley. Parity-based 367 loss recovery for reliable multicast transmission. In 368 Proceedings ACM SIGCOMM'97, Cannes, France, September 1997. 370 [11] P. Parnes. RTP extension for scalable reliable multicast, 371 November 1996. Work in progress. 373 [12] C. S. Perkins, I. Kouvelas, O. Hodson, V. Hardman, 374 M. Handley, J.-C. Bolot, A. Vega-Garcia, and 375 S. Fosse-Parisis. RTP Payload for redundant audio data. 376 IETF Audio/Video Transport Working Group, 1997. RFC2198. 378 [13] J.L. Ramsey. Realization of optimum interleavers. IEEE 379 Transactions on Information Theory, IT-16:338--345, May 380 1970. 382 [14] J. Rosenberg and H. Schulzrinne. An A/V profile extension 383 for generic forward error correction in RTP. IETF 384 Audio/Video Transport working group, July 1997. Work in 385 progress. 387 [15] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. 388 RTP: A transport protocol for real-time applications. IETF 389 Audio/Video Transport Working Group, January 1996. RFC1889. 391 [16] L. Vicisano, L. Rizzo, and Crowcroft J. TCP-like congestion 392 control for layered multicast data transfer. In Proceedings 393 IEEE INFOCOM'98, 1998. 395 [17] R. X. Xu, A. C. Myers, H. Zhang, and R. Yavatkar. 396 Resilient multicast support for continuous media 397 applications. In Proceedings of the 7th International 398 Workshop on Network and Operating SystemsSupport for 399 Digital Audio and Video (NOSSDAV'97), Washington University 400 in St. Louis, Missouri, May 1997.