idnits 2.17.00 (12 Aug 2021) /tmp/idnits13105/draft-shepherd-multicast-udp-guidelines-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 12, 2013) is 3258 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2629' is defined on line 282, but no explicit reference was found in the text == Outdated reference: draft-narten-iana-considerations-rfc2434bis has been published as RFC 5226 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF G. Shepherd, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Best Current Practice June 12, 2013 5 Expires: December 14, 2013 7 Multicast UDP Usage Guidelines for Application Designers 8 draft-shepherd-multicast-udp-guidelines-01 10 Abstract 12 The multi-recipient nature of Multicast prevents the use of any pont- 13 to-point connection-oriented transport, therefore restricts all 14 Multicast data to be sent over the User Datagram Protocol (UDP). UDP 15 provides a minimal message-passing transport that has no inherent 16 congestion control mechanisms. Because congestion control is 17 critical to the stable operation of the Internet, applications and 18 upper-layer protocols that choose to use Multicast UDP as an Internet 19 service must employ mechanisms to prevent congestion collapse and to 20 establish some degree of fairness with concurrent traffic. This 21 document provides guidelines on the use of UDP for the designers of 22 multicast applications and higher-level protocols. 24 Status of This Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 14, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 57 2. Multicast UDP Usage Guidelines . . . . . . . . . . . . . . . 3 58 2.1. Congestion Control Guidelines . . . . . . . . . . . . . . 3 59 2.1.1. Bulk Transfer Applications . . . . . . . . . . . . . 3 60 2.1.2. Low Data-Volume Applications . . . . . . . . . . . . 4 61 2.1.3. UDP Tunnels . . . . . . . . . . . . . . . . . . . . . 4 62 2.1.4. Message Size Guidelines . . . . . . . . . . . . . . . 4 63 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 6.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 The User Datagram Protocol (UDP) [RFC0768] provides a minimal, 75 unreliable, best-effort, message-passing transport to applications 76 and upper-layer protocols (both simply called "applications" in the 77 remainder of this document). [RFC5405] is scoped to provide 78 guidelines for unicast applications only, but all of the general 79 requirements, references, and use cases apply to multicast 80 [RFC1112][RFC4607] UDP application designers as well. This document 81 chooses to only make recommendations in requirements, use cases, and 82 references where they differ from [RFC5405]or are unique for 83 applications sending multicast UDP data (simply called "multicast" in 84 the remainder of this document). 86 1.1. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119] 92 2. Multicast UDP Usage Guidelines 94 2.1. Congestion Control Guidelines 96 [RFC2309] discusses the dangers of congestion-unresponsive flows and 97 states that "all UDP-based streaming applications should incorporate 98 effective congestion avoidance mechanisms". Many large-scale 99 multicast deployments are within a single administrative domain, and 100 are provisioned over a bandwidth-reserved path or paths where 101 congestion control is less relevant. But there are a growing number 102 of deployment cases where multicast is transiting multiple domains, 103 is tunneled across the unicast Internet, or transits the Internet 104 through a unicast overlay network. This document is only concerned 105 with the latter case of multicast data transiting the larger 106 Internet, either as native IP multicast or encapsulated in a unicast 107 tunnel and does not apply to administratively scoped deployments. 109 When the multicast traffic exits the administrative domain of a 110 single network or the bi-laterally agreed path between networks, or 111 is tunneled across the unicast Internet either to another multicast 112 network or to an end device, the application SHOULD provide a TCP- 113 compatible aggregate flow over the end-to-end path to each leaf. 115 There are currently two models of multicast delivery: the Any-Source 116 Multicast (ASM) model as defined in [RFC1112] and the Source-Specific 117 Multicast (SSM) model as defined in [RFC4607]. ASM group members 118 will receive all data sent to the group by any source, while SSM 119 constrains the distribution tree to only one single source. Many 120 congestion-controlled transport protocols are often not applicable to 121 multicast distribution services, or simply won't scale well to very 122 large multicast trees since they require bi-directional communication 123 and adapt the data-rate to accommodate the network conditions to a 124 single receiver. Multicast distribution trees can often fan out to 125 massive numbers of receivers limiting the scalability of an in-band 126 return channel to control the data-rate, and the one-to-many nature 127 of multicast distribution trees prevent adapting the data-rate to 128 individual receiver requirements. For this reason, TCP-compatible 129 aggregate flow for Internet multicast data, either native or 130 tunneled, is the responsibility of the application. 132 2.1.1. Bulk Transfer Applications 134 Applications that perform bulk transmission of data over a multicast 135 distribution tree, i.e., applications that exchange more than a small 136 number of UDP datagrams per maximum receiver RTT, SHOULD implement 137 Asynchronous Layered Coding (ALC) [RFC5775], TCP-Friendly Multicast 138 Congestion Control (TFMCC) [RFC4654], Wave and Equation Based Rate 139 Control (WEBRC) [RFC3738], NACK-Oriented Reliable Multicast (NORM) 140 transport protocol [RFC5740], File Delivery over Unidirectional 141 Transport (FLUTE) [RFC6726], Real Time Protocol/Control Protocol (RTP 142 /RTCP), [RFC3550] or another congestion control scheme following the 143 guidelines of [RFC2887]and utilizing the framework of [RFC3048]. 145 Bulk transfer applications that choose not to implement [RFC4654], 146 [RFC5775], [RFC3738], [RFC5740], [RFC6726], or [RFC3550] SHOULD 147 implement a congestion control scheme that results in bandwidth use 148 that competes fairly with TCP within an order of magnitude. 149 Section 2 of [RFC3551] suggests that applications SHOULD monitor the 150 packet loss rate to ensure that it is within acceptable parameters. 151 Packet loss is considered acceptable if a TCP flow across the same 152 network path under the same network conditions would achieve an 153 average throughput, measured on a reasonable timescale, that is not 154 less than that of the UDP flow. The comparison to TCP cannot be 155 specified exactly, but is intended as an "order-of-magnitude" 156 comparison in timescale and throughput. 158 Finally, some bulk transfer applications may choose not to implement 159 any congestion control mechanism and instead rely on transmitting 160 across reserved path capacity. This might be an acceptable choice 161 for a subset of restricted networking environments, but is by no 162 means a safe practice for operation in the Internet. When the 163 multicast traffic of such applications leaks out on unprovisioned 164 Internet paths, it can significantly degrade the performance of other 165 traffic sharing the path and even result in congestion collapse. 166 Applications that support an uncontrolled or unadaptive transmission 167 behavior SHOULD NOT do so by default and SHOULD instead require users 168 to explicitly enable this mode of operation. 170 2.1.2. Low Data-Volume Applications 172 All of the recommendations in section 3.1.2 of [RFC5405] are 173 applicable to multicast as well. 175 2.1.3. UDP Tunnels 177 All of the recommendations in section 3.1.3 of [RFC5405] are 178 applicable to multicast carried inside of unicast UDP tunnels. There 179 are, however deployment cases and solutions where the outer header of 180 a UDP tunnel contains a multicast destination address, such as 181 [RFC6513], but these are primarily deployed in bandwidth reserved 182 environments within a single administrative domain, or between two 183 domains where a bi-laterally agreed upon path and bandwidth is in 184 place and so congestion control is not an issue. 186 2.1.4. Message Size Guidelines 187 IP fragmentation lowers the efficiency and reliability of Internet 188 communication. The loss of a single fragment results in the loss of 189 an entire fragmented packet, because even if all other fragments are 190 received correctly, the original packet cannot be reassembled and 191 delivered. This fundamental issue with fragmentation exists for both 192 IPv4 and IPv6, unicast and multicast packets. In addition, some 193 network address translators (NATs) and firewalls drop IP fragments. 194 The network address translation performed by a NAT only operates on 195 complete IP packets, and some firewall policies also require 196 inspection of complete IP packets. Even with these being the case, 197 some NATs and firewalls simply do not implement the necessary 198 reassembly functionality, and instead choose to drop all fragments. 199 Finally, [RFC4963] documents other issues specific to IPv4 200 fragmentation. 202 Due to these issues, a multicast application SHOULD NOT send UDP 203 datagrams that result in IP packets that exceed the effective MTU as 204 described in section 3 of [RFC6807]. Consequently, an application 205 SHOULD either use the effective MTU information provided by the 206 Population Count Extensions to Protocol Independent Multicast 207 [RFC6807] or implement path MTU discovery itself 208 [RFC1191][RFC1981][RFC4821] to determine whether the path to each 209 destination will support its desired message size without 210 fragmentation. 212 If the multicast application is incapable of, or choose not to 213 implement a worst-cast path MTU solution, the application SHOULD 214 assume the maximum MTU of any link will be affected by multiple 215 levels of encapsulation and SHOULD NOT send any packet larger than 216 1280 bytes. 218 3. Acknowledgements 220 This template was derived from an initial version written by Pekka 221 Savola and contributed by him to the xml2rfc project. 223 This document is part of a plan to make xml2rfc indispensable 224 [DOMINATION]. 226 4. IANA Considerations 228 This memo includes no request to IANA. 230 All drafts are required to have an IANA considerations section (see 231 the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] 232 for a guide). If the draft does not require IANA to do anything, the 233 section contains an explicit statement that this is the case (as 234 above). If there are no requirements for IANA, the section will be 235 removed during conversion into an RFC by the RFC Editor. 237 5. Security Considerations 239 All drafts are required to have a security considerations section. 240 See RFC 3552 [RFC3552] for a guide. 242 6. References 244 6.1. Normative References 246 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 247 August 1980. 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, March 1997. 252 [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 254 6.2. Informative References 256 [DOMINATION] 257 Mad Dominators, Inc., "Ultimate Plan for Taking Over the 258 World", 1984, . 260 [I-D.narten-iana-considerations-rfc2434bis] 261 Narten, T. and H. Alvestrand, "Guidelines for Writing an 262 IANA Considerations Section in RFCs", draft-narten-iana- 263 considerations-rfc2434bis-09 (work in progress), March 264 2008. 266 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 267 RFC 1112, August 1989. 269 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 270 November 1990. 272 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 273 for IP version 6", RFC 1981, August 1996. 275 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 276 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 277 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 278 S., Wroclawski, J., and L. Zhang, "Recommendations on 279 Queue Management and Congestion Avoidance in the 280 Internet", RFC 2309, April 1998. 282 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 283 June 1999. 285 [RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R., 286 Vicisano, L., and M. Luby, "The Reliable Multicast Design 287 Space for Bulk Data Transfer", RFC 2887, August 2000. 289 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 290 Floyd, S., and M. Luby, "Reliable Multicast Transport 291 Building Blocks for One-to-Many Bulk-Data Transfer", RFC 292 3048, January 2001. 294 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 295 Jacobson, "RTP: A Transport Protocol for Real-Time 296 Applications", STD 64, RFC 3550, July 2003. 298 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 299 Video Conferences with Minimal Control", STD 65, RFC 3551, 300 July 2003. 302 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 303 Text on Security Considerations", BCP 72, RFC 3552, July 304 2003. 306 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 307 Control (WEBRC) Building Block", RFC 3738, April 2004. 309 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 310 IP", RFC 4607, August 2006. 312 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 313 Congestion Control (TFMCC): Protocol Specification", RFC 314 4654, August 2006. 316 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 317 Discovery", RFC 4821, March 2007. 319 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 320 Errors at High Data Rates", RFC 4963, July 2007. 322 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 323 for Application Designers", BCP 145, RFC 5405, November 324 2008. 326 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 327 "NACK-Oriented Reliable Multicast (NORM) Transport 328 Protocol", RFC 5740, November 2009. 330 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 331 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 332 April 2010. 334 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 335 VPNs", RFC 6513, February 2012. 337 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 338 "FLUTE - File Delivery over Unidirectional Transport", RFC 339 6726, November 2012. 341 [RFC6807] Farinacci, D., Shepherd, G., Venaas, S., and Y. Cai, 342 "Population Count Extensions to Protocol Independent 343 Multicast (PIM)", RFC 6807, December 2012. 345 Appendix A. Additional Stuff 347 This becomes an Appendix. 349 Author's Address 351 Greg Shepherd (editor) 352 Cisco Systems 353 Tasman Drive 354 San Jose 355 USA 357 Email: gjshep@gmail.com