Multicast UDP Usage Guidelines for Application Designers
Author(s): Greg Shepherd
The multi-recipient nature of Multicast prevents the use of any pont- to-point connection-oriented transport, therefore restricts all Multicast data to be sent over the User Datagram Protocol (UDP). UDP provides a minimal message-passing transport that has no inherent...
IETF G. Shepherd, Ed. Internet-Draft Cisco Systems Intended status: Best Current Practice June 12, 2013 Expires: December 14, 2013 Multicast UDP Usage Guidelines for Application Designers draft-shepherd-multicast-udp-guidelines-01 Abstract The multi-recipient nature of Multicast prevents the use of any pont- to-point connection-oriented transport, therefore restricts all Multicast data to be sent over the User Datagram Protocol (UDP). UDP provides a minimal message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use Multicast UDP as an Internet service must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of UDP for the designers of multicast applications and higher-level protocols. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 14, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Shepherd Expires December 14, 2013 [Page 1] Internet-Draft Abbreviated Title June 2013 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Multicast UDP Usage Guidelines . . . . . . . . . . . . . . . 3 2.1. Congestion Control Guidelines . . . . . . . . . . . . . . 3 2.1.1. Bulk Transfer Applications . . . . . . . . . . . . . 3 2.1.2. Low Data-Volume Applications . . . . . . . . . . . . 4 2.1.3. UDP Tunnels . . . . . . . . . . . . . . . . . . . . . 4 2.1.4. Message Size Guidelines . . . . . . . . . . . . . . . 4 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 6 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The User Datagram Protocol (UDP) [RFC0768] provides a minimal, unreliable, best-effort, message-passing transport to applications and upper-layer protocols (both simply called "applications" in the remainder of this document). [RFC5405] is scoped to provide guidelines for unicast applications only, but all of the general requirements, references, and use cases apply to multicast [RFC1112][RFC4607] UDP application designers as well. This document chooses to only make recommendations in requirements, use cases, and references where they differ from [RFC5405]or are unique for applications sending multicast UDP data (simply called "multicast" in the remainder of this document). 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] Shepherd Expires December 14, 2013 [Page 2] Internet-Draft Abbreviated Title June 2013 2. Multicast UDP Usage Guidelines 2.1. Congestion Control Guidelines [RFC2309] discusses the dangers of congestion-unresponsive flows and states that "all UDP-based streaming applications should incorporate effective congestion avoidance mechanisms". Many large-scale multicast deployments are within a single administrative domain, and are provisioned over a bandwidth-reserved path or paths where congestion control is less relevant. But there are a growing number of deployment cases where multicast is transiting multiple domains, is tunneled across the unicast Internet, or transits the Internet through a unicast overlay network. This document is only concerned with the latter case of multicast data transiting the larger Internet, either as native IP multicast or encapsulated in a unicast tunnel and does not apply to administratively scoped deployments. When the multicast traffic exits the administrative domain of a single network or the bi-laterally agreed path between networks, or is tunneled across the unicast Internet either to another multicast network or to an end device, the application SHOULD provide a TCP- compatible aggregate flow over the end-to-end path to each leaf. There are currently two models of multicast delivery: the Any-Source Multicast (ASM) model as defined in [RFC1112] and the Source-Specific Multicast (SSM) model as defined in [RFC4607]. ASM group members will receive all data sent to the group by any source, while SSM constrains the distribution tree to only one single source. Many congestion-controlled transport protocols are often not applicable to multicast distribution services, or simply won't scale well to very large multicast trees since they require bi-directional communication and adapt the data-rate to accommodate the network conditions to a single receiver. Multicast distribution trees can often fan out to massive numbers of receivers limiting the scalability of an in-band return channel to control the data-rate, and the one-to-many nature of multicast distribution trees prevent adapting the data-rate to individual receiver requirements. For this reason, TCP-compatible aggregate flow for Internet multicast data, either native or tunneled, is the responsibility of the application. 2.1.1. Bulk Transfer Applications Applications that perform bulk transmission of data over a multicast distribution tree, i.e., applications that exchange more than a small number of UDP datagrams per maximum receiver RTT, SHOULD implement Asynchronous Layered Coding (ALC) [RFC5775], TCP-Friendly Multicast Congestion Control (TFMCC) [RFC4654], Wave and Equation Based Rate Control (WEBRC) [RFC3738], NACK-Oriented Reliable Multicast (NORM) Shepherd Expires December 14, 2013 [Page 3] Internet-Draft Abbreviated Title June 2013 transport protocol [RFC5740], File Delivery over Unidirectional Transport (FLUTE) [RFC6726], Real Time Protocol/Control Protocol (RTP /RTCP), [RFC 3550] or another congestion control scheme following the guidelines of [RFC2887]and utilizing the framework of [RFC3048]. Bulk transfer applications that choose not to implement [RFC4654], [RFC5775], [RFC3738], [RFC5740], [RFC6726], or [RFC 3550] SHOULD implement a congestion control scheme that results in bandwidth use that competes fairly with TCP within an order of magnitude. Section 2 of [RFC3551] suggests that applications SHOULD monitor the packet loss rate to ensure that it is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path under the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than that of the UDP flow. The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in timescale and throughput. Finally, some bulk transfer applications may choose not to implement any congestion control mechanism and instead rely on transmitting across reserved path capacity. This might be an acceptable choice for a subset of restricted networking environments, but is by no means a safe practice for operation in the Internet. When the multicast traffic of such applications leaks out on unprovisioned Internet paths, it can significantly degrade the performance of other traffic sharing the path and even result in congestion collapse. Applications that support an uncontrolled or unadaptive transmission behavior SHOULD NOT do so by default and SHOULD instead require users to explicitly enable this mode of operation. 2.1.2. Low Data-Volume Applications All of the recommendations in section 3.1.2 of [RFC5405] are applicable to multicast as well. 2.1.3. UDP Tunnels All of the recommendations in section 3.1.3 of [RFC5405] are applicable to multicast carried inside of unicast UDP tunnels. There are, however deployment cases and solutions where the outer header of a UDP tunnel contains a multicast destination address, such as [RFC6513], but these are primarily deployed in bandwidth reserved environments within a single administrative domain, or between two domains where a bi-laterally agreed upon path and bandwidth is in place and so congestion control is not an issue. 2.1.4. Message Size Guidelines Shepherd Expires December 14, 2013 [Page 4] Internet-Draft Abbreviated Title June 2013 IP fragmentation lowers the efficiency and reliability of Internet communication. The loss of a single fragment results in the loss of an entire fragmented packet, because even if all other fragments are received correctly, the original packet cannot be reassembled and delivered. This fundamental issue with fragmentation exists for both IPv4 and IPv6, unicast and multicast packets. In addition, some network address translators (NATs) and firewalls drop IP fragments. The network address translation performed by a NAT only operates on complete IP packets, and some firewall policies also require inspection of complete IP packets. Even with these being the case, some NATs and firewalls simply do not implement the necessary reassembly functionality, and instead choose to drop all fragments. Finally, [RFC4963] documents other issues specific to IPv4 fragmentation. Due to these issues, a multicast application SHOULD NOT send UDP datagrams that result in IP packets that exceed the effective MTU as described in section 3 of [RFC6807]. Consequently, an application SHOULD either use the effective MTU information provided by the Population Count Extensions to Protocol Independent Multicast [RFC6807] or implement path MTU discovery itself [RFC1191][RFC1981][RFC4821] to determine whether the path to each destination will support its desired message size without fragmentation. If the multicast application is incapable of, or choose not to implement a worst-cast path MTU solution, the application SHOULD assume the maximum MTU of any link will be affected by multiple levels of encapsulation and SHOULD NOT send any packet larger than 1280 bytes. 3. Acknowledgements This template was derived from an initial version written by Pekka Savola and contributed by him to the xml2rfc project. This document is part of a plan to make xml2rfc indispensable [DOMINATION]. 4. IANA Considerations This memo includes no request to IANA. Shepherd Expires December 14, 2013 [Page 5] Internet-Draft Abbreviated Title June 2013 All drafts are required to have an IANA considerations section (see the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor. 5. Security Considerations All drafts are required to have a security considerations section. See RFC 3552 [RFC 3552] for a guide. 6. References 6.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 0768, August 1980. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 6.2. Informative References [DOMINATION] Mad Dominators, Inc., "Ultimate Plan for Taking Over the World", 1984, <http://www.example.com/dominator.html>. [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana- considerations-rfc2434bis-09 (work in progress), March 2008. [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC1112, August 1989. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC1191, November 1990. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC1981, August 1996. [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, Shepherd Expires December 14, 2013 [Page 6] Internet-Draft Abbreviated Title June 2013 S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC2309, April 1998. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC2629, June 1999. [RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R., Vicisano, L., and M. Luby, "The Reliable Multicast Design Space for Bulk Data Transfer", RFC2887, August 2000. [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001. [RFC 3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC3551, July 2003. [RFC 3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC3738, April 2004. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC4607, August 2006. [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, August 2006. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC4821, March 2007. [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC4963, July 2007. [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC5405, November 2008. Shepherd Expires December 14, 2013 [Page 7] Internet-Draft Abbreviated Title June 2013 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC5740, November 2009. [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC5775, April 2010. [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC6513, February 2012. [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, November 2012. [RFC6807] Farinacci, D., Shepherd, G., Venaas, S., and Y. Cai, "Population Count Extensions to Protocol Independent Multicast (PIM)", RFC6807, December 2012. Appendix A. Additional Stuff This becomes an Appendix. Author's Address Greg Shepherd (editor) Cisco Systems Tasman Drive San Jose USA Email: firstname.lastname@example.org Shepherd Expires December 14, 2013 [Page 8]