idnits 2.17.1 draft-mankin-reliable-multicast-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-18) 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. ** 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 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. ** The abstract seems to contain references ([Floyd97], [RMMinutes1997]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (May 1998) is 9470 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: 'Jacobson88' is mentioned on line 184, but not defined == Unused Reference: 'RMMinutes 1997' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'Jacobson 1988' is defined on line 386, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'RMMinutes 1997' -- Possible downref: Non-RFC (?) normative reference: ref. 'Floyd97' -- Possible downref: Non-RFC (?) normative reference: ref. 'DiffServBOF97' ** Downref: Normative reference to an Informational RFC: RFC 1458 (ref. 'DeprRFCs') -- Possible downref: Non-RFC (?) normative reference: ref. 'DiotCrow97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Obraczka98' ** Obsolete normative reference: RFC 1264 (ref. 'Routing91') (Obsoleted by RFC 4794) ** Obsolete normative reference: RFC 2001 (ref. 'CongAvoid97') (Obsoleted by RFC 2581) -- Possible downref: Non-RFC (?) normative reference: ref. 'Jacobson 1988' Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Allison Mankin 3 INTERNET-DRAFT USC/ISI 4 Allyn Romanow 5 MCI 6 Scott Bradner 7 Harvard University 8 Vern Paxson 9 LBL 10 With the TSV 11 Area Directorate 12 May 1998 14 IETF Criteria for Evaluating Reliable Multicast Transport 15 and Application Protocols 17 19 Status of this Memo 20 This document is an Internet Draft. Internet Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its Areas, 22 and its Working Groups. Note that other groups may also distribute 23 working documents as Internet 25 Internet Drafts are draft documents valid for a maximum of six 26 months. Internet Drafts may be updated, replaced, or obsoleted by 27 other documents at any time. It is not appropriate to use Internet 28 Drafts as reference material or to cite them other than as a "working 29 draft" or "work in progress." 31 To learn the current status of any Internet-Draft, please check the 32 "1id-abstracts.txt" listing contained in the internet-drafts Shadow 33 Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) 34 ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) 35 munnari.oz.au (Pacific Rim) 37 Abstract 38 This memo describes the procedures and criteria for reviewing 39 reliable multicast protocols within the Transport Area (TSV) of the 40 IETF. Within today's Internet, important applications exist for a 41 reliable multicast service. Some examples that are driving reliable 42 multicast technology are collaborative workspaces (such as 43 whiteboard), data and software distribution, and (more speculatively) 44 web caching protocols. Due to the nature of the technical issues, a 45 single commonly accepted technical solution that solves all the 46 demands for reliable multicast is likely to be infeasible [RMMinutes 47 1997]. 49 A number of reliable multicast protocols have already been developed 50 to solve a variety of problems for various types of applications. 51 [Floyd97] describes one widely deployed example. How should these 52 protocols be treated within the IETF and how should the IETF guide 53 the development of reliable multicast in a direction beneficial for 54 the general Internet? 56 The TSV Area Directors and their Directorate have outlined a set of 57 review procedures that address these questions and set criteria and 58 processes for the publication as RFCs of Internet-Drafts on reliable 59 multicast transport protocols. 61 1.0 Background on IETF Processes and Procedures 63 In the IETF, work in an area is directed and managed by the Area 64 Directors (ADs), who have authority over the chartering of working 65 groups (WGs). 67 In addition, ADs review individually submitted (not by WGs) Internet- 68 Drafts about work that is relevant to their areas prior to 69 publication as RFCs (Experimental, Informational or, in rare cases, 70 Standards Track). The review is done according to the guidelines set 71 out in the Internet Standards Process, RFC 2026 [InetStdProc96]. 73 The purpose of this document is to present the criteria that will be 74 used by the TSV ADs in reviewing reliable multicast Internet-Drafts 75 for Standards Track RFCs. 77 2.0 Introduction 79 There is a strong application demand for reliable multicast. 80 Widespread use of the Internet makes the economy of multicast 81 transport attractive. The current Internet multicast model offers 82 best-effort many-to-many delivery service and offers no guarantees. 83 Reliable multicast transports add delivery guarantees, not 84 necessarily like those of reliable unicast TCP, to the group-delivery 85 model of multicast. A panel of some major users of the Internet, 86 convened at the 38th IETF, articulated reliable bulk transfer 87 multicast as one of their most critical requirements [DiffServBOF97]. 88 Examples of applications that could use reliable bulk multicast 89 transfer include collaborative tools, distributed virtual reality, 90 and software upgrade services. 92 To meet the growing demand for reliable multicast, there is a large 93 number of protocol proposals. A few were published as RFCs before 94 the impact of congestion from reliable multicast was fully 95 appreciated, and these should be deprecated [DeprRFCs]. Two surveys 96 of other publications are [DiotCrow97], [Obraczka98]. 98 As we discuss in Section 3, the issues raised by reliable multicast 99 are considerably more complex than those related to reliable unicast. 100 In particular, in today's Internet, reliable multicast protocols 101 could do great damage through causing congestion disasters if they 102 are widely used and do not provide adequate congestion control. 104 Because of the complexity of the technical issues, and the abundance 105 of proposed solutions, we are putting in place review procedures that 106 are more explicit than usual. We compare this action with an IESG 107 action taken in 1991, RFC 1264 [Routing91], when community experience 108 with standard Internet dynamic routing protocols was still limited, 109 and extra review was deemed necessary to assure that the protocols 110 introduced would be effective, correct and robust. 112 Section 3 describes in detail the nature of the particular challenges 113 posed by reliable multicast. Section 4 describes the process for 114 considering reliable multicast solutions. Section 5 details the 115 additional requirements that need to be met by proposals to be 116 published as Standards Track RFCs. 118 3.0 Issues in Reliable Multicast 120 Two aspects of reliable multicast make standardization particularly 121 challenging. First, the meaning of reliability varies in the context 122 of different applications. Secondly, if special care is not taken, 123 reliable multicast protocols can cause a particular threat to the 124 operation of today's global Internet. These issues are discussed in 125 detail in this section. 127 3.1 One or Many Reliable Multicast Protocols or Frameworks? 129 Unlike reliable unicast, where a single transport protocol (TCP) is 130 currently used to meet the reliable delivery needs of a wide range of 131 applications, reliable multicast does not necessarily lend itself to 132 a single application interface or to a single underlying set of 133 mechanisms. For unicast transport, the requirements for reliable, 134 sequenced data delivery are fairly general. TCP, the primary 135 transport protocol for reliable unicast, is a mature protocol with 136 delivery semantics that suit a wide range of applications. 138 In contrast, different multicast applications have widely different 139 requirements for reliability. For example, some applications require 140 that message delivery obey a total ordering while others do not. 141 Some applications have many or all the members sending data while 142 others have only one data source. Some applications have replicated 143 data, for example in an n-redundant file store, so that several 144 members are capable of transmitting a data item, while for others all 145 data originates at a single source. Some applications are restricted 146 to small fixed-membership multicast groups, while other applications 147 need to scale dynamically to thousands or tens of thousands of 148 members (or possibly more). Some applications have stringent delay 149 requirements, while others do not. Some applications such as file- 150 transfer are high-bandwidth, while other applications such as 151 interactive collaboration tools are more likely to be bursty but use 152 low bandwidth overall. These requirements each impact the design of 153 reliable multicast protocols in a different way. 155 In addition, even for a specific application where the application's 156 requirements for reliable multicast are well understood, there are 157 many open questions about the underlying mechanisms for providing 158 reliable multicast. A key question concerns the robustness of the 159 underlying reliable multicast mechanisms as the number of senders or 160 the membership of the multicast group grows. 162 One challenge to the IETF is to end up with the right match between 163 applications' requirements and reliable multicast mechanisms. While 164 there is general agreement that a single reliable multicast protocol 165 or framework is not likely to meet the needs of all Internet 166 applications, there is less understanding and agreement about the 167 exact relationship between application-specific requirements and more 168 generic underlying reliable mutlicast protocols or mechanisms. There 169 are also open questions about the appropriate integration between an 170 application and an underlying reliable multicast framework, and the 171 potential generality of a single applications interface for that 172 framework. 174 3.2 Congestion Control 176 A particular concern for the IETF is the impact of reliable multicast 177 traffic on other traffic in the Internet in times of congestion, in 178 particular the effect of reliable multicast traffic on competing TCP 179 traffic. The success of the Internet relies on the fact that best- 180 effort traffic responds to congestion on a link (currently as 181 indicated by packet drops) by reducing the load presented to the 182 network. Congestion collapse in today's Internet is prevented only 183 by the congestion control mechanisms in TCP, standardized by RFC 2001 184 [CongAvoid97, Jacobson88]. 186 There are a number of reasons to be particularly attentive to the 187 congestion-related issues raised by reliable multicast proposals. 188 Multicast applications in general have the potential to do more 189 congestion-related damage to the Internet than do unicast 190 applications. One factor is that a single multicast flow can be 191 distributed along a large, global multicast tree reaching throughout 192 the entire Internet. 194 Unreliable multicast applications such as audio and video are, at the 195 moment, usually accompanied by a person at the receiving end, and 196 people typically unsubscribe from a multicast group if congestion is 197 so heavy that the audio or video stream is unintelligible. Reliable 198 multicast applications such as group file transfer applications, on 199 the other hand, are likely to be between computers, with no humans in 200 attendance monitoring congestion levels. 202 In addition, reliable multicast applications do not necessarily have 203 the natural time limitations typical of current unreliable multicast 204 applications. For a file transfer application, for example, the data 205 transfer might continue until all of the data is transferred to all 206 of the intended receivers, resulting in a potentially-unlimited 207 duration for an individual flow. Reliable multicast applications 208 also have to contend with a potential explosion of complex patterns 209 of control traffic (e.g., ACKs, NACKs, status messages). The design 210 of congestion control mechanisms for reliable multicast for large 211 multicast groups is currently an area of active research. 213 The challenge to the IETF is to encourage research and 214 implementations of reliable multicast, and to enable the needs of 215 applications for reliable multicast to be met as expeditiously as 216 possible, while at the same time protecting the Internet from the 217 congestion disaster or collapse that could result from the widespread 218 use of applications with inappropriate reliable multicast mechanisms. 219 Because of the setbacks and costs that could result from the 220 widespread deployment of reliable multicast with inadequate 221 congestion control, the IETF must exercise care in the 222 standardization of a reliable multicast protocol that might see 223 widespread use. 225 The careful review and cautious acceptance procedures for proposals 226 submitted as Internet-Drafts reflects our concern to meet the 227 challenges described here. 229 4. IETF Process for Review and Publication of Reliable Multicast 230 Protocol Specifications 232 In the general case of individually submitted Internet-Drafts 233 (proposals not produced by an IETF WG), the process of publication as 234 some type of RFC is described in RFC 2026 (4.2.3) [InetStdProc96]. 235 This specifies that if the submitted Internet-Draft is closely 236 related to work being done or expected to be done in the IETF, the 237 ADs may recommend that the document be brought within the IETF and 238 progressed in the IETF context. Otherwise, the ADs may recommend 239 that the Internet-Draft be published as an Experimental or 240 Informational RFC, with or without an IESG annotation of its 241 relationship to the IETF context. 243 The procedure for Reliable Multicast proposal publication will have 244 as its default RFC status Experimental, when the technical criteria 245 listed in Section 5 are deemed to be fulfilled. Both the criteria and 246 the procedure reflect the AD's technical assessment of the current 247 state of reliable multicast technology. It does not reflect the 248 origins of the proposals, which we expect will be equally from 249 commercial vendors with initial products and from researchers. 251 Work on the development and engineering of protocols that may 252 eventually meet the review criteria could take place either in the 253 IRTF Reliable Multicast Research Group (http://www.irtf.org) or a 254 focused short IETF WG with an Experimental product. 256 When the work in reliable multicast technology has matured enough to 257 be considered for standardization within the IETF, the TSV Area may 258 charter appropriate working groups to develop standards track 259 documents. The criteria for evaluation of standards track technology 260 will be at least as stringent as those described herein (next 261 section). 263 5. Technical Criteria for Reliable Multicast 265 The Internet-Draft must (in itself or a companion draft): 267 a. Analyze the behavior of the protocol. 268 The vulnerabilities and performance problems must be shown through 269 analysis. Especially the protocol behavior must be explained in 270 detail with respect to scalability, congestion control, error 271 recovery, and robustness. 273 For example the following questions should be answered: 275 How scalable is the protocol to the number of users in a group, 276 number of groups, wide dispersion of group members? If 277 appropriate, how scalable is the protocol to the number of 278 senders? 280 Identify the mechanisms which limit scalability and estimate 281 those limits. 283 How does the protocol protect the Internet from congestion? How 284 well does it perform? When does it fail? 285 Under what circumstances will the protocol fail to perform the 286 functions needed by the applications it serves? 287 Is there a congestion control mechanism? How well does it 288 perform? When does it fail? Note that congestion control 289 mechanisms that operate on the network more aggressively than 290 TCP will face a great burden of proof that they don't threaten 291 network stability. 293 b. Include a description of trials and/or simulations which support 294 the development of the protocol and the answers to the above 295 questions. 297 c. Include an analysis of whether the protocol has congestion 298 avoidance mechanisms strong enough to cope with deployment in the 299 Global Internet, and if not, clearly document the circumstances in 300 which congestion harm can occur. How are these circumstances to 301 be prevented? 303 d. Include a description of any mechanisms which contain the traffic 304 within limited network environments. It is likely that some 305 answers to a. and c. will mean that such mechanisms are required. 306 We recognize that the confinement of Internet applications is an 307 open research area. 309 e. Reliable multicast protocols must include an analysis of how they 310 address a number of security and privacy concerns. If the 311 protocol can be used in different modes of secure operation, then 312 each mode must be analyzed. 314 The analysis must document which of the various parties -- 315 senders, routers (more generally, data forwarders), receivers, 316 retransmission sources -- must be trusted in order to ensure 317 secure operation and privacy of the transmitted data, to what 318 degree, and why. (One issue to address here are "man-in-the- 319 middle" attacks.) 321 To what degree can data be manipulated so that at least a 322 subset of the receivers receive different copies? Does the 323 protocol allow a group of receivers to determine whether they 324 all received the same data? 326 What limitations are placed on the retransmission mechanism to 327 prevent it from being abused to flood network links with 328 excessive traffic? Which parties must be trusted to ensure 329 this, and to what degree, and why? The presumption will be that 330 either a congestion control mechanism will inherently limit the 331 volume of retransmission traffic, and that this limiting 332 influence is robust under concerted attack; or that 333 retransmission requests will be signed in a cryptographically 334 strong manner so that abuses of the mechanism can be traced 335 back to their source. Protocols that do not provide either of 336 these forms of protection face a great burden of proof that 337 they don't threaten network stability. 339 What sort of key management does the protocol require, and 340 provide for? 342 6. Security Considerations 344 This memo specifies in Section 5.e. that reliable multicast Internet- 345 Drafts reviewed by the Transport Area Directors must explicitly 346 explore the security aspects of the proposed design. 348 7. Acknowledgments 350 Sally Floyd, Steve McCanne, Mark Handley, Steve Bellovin and Mike 351 Reiter gave especially helpful comments on drafts of this document. 353 8. References 355 [RMMinutes 1997], Minutes the Second Reliable Multicast Research 356 Group Meeting. September 1997. http://www.east.isi.edu/rm 358 [Floyd97] Floyd, S., Jacobson, V., Liu, C., McCanne, S., and Zhang, 359 L., A Reliable Multicast Framework for Light-weight Sessions and 360 Application Level Framing. IEEE/ACM Transactions on Networking, 361 December 1997 An online version of the paper is at 362 http://ee.lbl.gov/floyd/srm-paper.html. 364 [InetStdProc96] Bradner, S., The Internet Standards Process -- 365 Revision 3, RFC 2026, October 1996. 367 [DiffServBOF97] [6] http://www.ietf.org/proceedings/97apr - 368 Transport Area - FDDIFS BOF, April 1997. 370 [DeprRFCs]. Freier, A. Multicast Transport Protocol, RFC 1301, 371 February 1992. and Braudes, R., Zabele, S., Requirements for 372 Multicast Protocols, RFC 1458, May 1993. 374 [DiotCrow97], Diot, C., Crowcroft, J., Multicast Transport Survey. 375 Journal of Selected Areas in Communications, 1997. 377 [Obraczka98] Obraczka, K., Multicast Transport Mechanisms: A Survey 378 and Taxonomy. To appear in IEEE Communications, 1998. 380 [Routing91] Hinden, R. M., Internet Engineering Task Force internet 381 routing protocol standardization criteria, RFC 1264, October 1991 383 [CongAvoid97] Stevens, W. R., TCP Slow Start, Congestion Avoidance, 384 Fast Retransmit, and Fast Recovery Algorithms, RFC 2001, January 1997 386 [Jacobson 1988] Jacobson, V., Congestion Avoidance and Control, 387 Proceedings of SIGCOMM '88, August 1988, pp. 314-329. An updated 388 version of this paper is available at 389 "ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z". 391 9. Authors Addresses 393 Allison Mankin - Past TSV Area Director 394 USC/ISI East 395 4350 N. Fairfax Dr., Suite 620 396 Arlington VA 22203 397 USA 398 703 812 3706 399 mankin@east.isi.edu 401 Allyn Romanow - Past TSV Area Director 402 MCI Corporation 403 2560 North First Street 404 San Jose, CA 9531 405 USA 406 408 922 7143 407 allyn@mci.net 409 Scott Bradner - TSV Co-Area Director 410 Harvard University 411 1350 Mass. Ave., Rm 876 412 Cambridge MA 02138 413 USA 414 617 495 3864 415 sob@harvard.edu 417 Vern Paxson - TSV Co-Area Director 418 MS 50B/2239 419 Lawrence Berkeley National Laboratory 420 University of California 421 Berkeley, CA 94720 422 USA 423 510-486-7504 424 vern@ee.lbl.gov