idnits 2.17.1 draft-ietf-mboned-limit-rate-guide-00.txt: ** The Abstract section seems to be numbered 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-25) 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. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (18 August 1997) is 9747 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'PRUNING' Summary: 10 errors (**), 0 flaws (~~), 0 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT D. Junkins 3 draft-ietf-mboned-limit-rate-guide-00.txt NorthWestNet 4 Category: Best Current Practice 18 February 1997 5 Expires 18 August 1997 7 Guidelines for Rate Limits on the MBONE 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 2. Abstract 29 Much confusion and misunderstanding exists in the Internet community 30 on the use of rate limits on the Multicast Backbone (MBONE). This 31 document dispels some of the misunderstandings of rate limits and 32 describes the best current practices for when to implement rate 33 limits on MBONE links. 35 It is a product of the Multicast Deployment Working Group in the 36 Operational Requirements area of the Internet Engineering Task Force. 37 Submit comments to or the author. 39 3. History of DVMRP Tunnel Rate Limits 41 The MBone (Multicast Backbone) of the Internet is composed of a DVMRP 42 backbone connected to regions that may be running other multicast 43 routing protocols. These multicast islands are connected together by 44 DVMRP tunnels across the unicast Internet backbone. 46 The original multicast router for the MBONE was mrouted. Mrouted, 47 through version 3.8, has a rate limit of 512 kbps enabled by default 48 on each tunnel interface. This rate limit was included in mrouted 49 because of concern that multicast traffic could consume all available 50 bandwidth on some links of the Internet. Other multicast router 52 Expires 18 August 1997 INTERNET-DRAFT 18 February 1997 54 implementations include support for rate limits on interfaces but 55 they are not enabled by default. 57 Several things have changed in the Internet and IP multicasting that 58 make the idea of a global rate limit for the MBONE no longer 59 necessary. First, the size of provider's backbone circuits has 60 increased greatly. It is no longer a valid concern that a single 61 multicast transmitter could send enough multicast traffic to 62 completely fill a national providers backbone circuit since those 63 circuits have moved from DS-1 (1.536 Mbps) to DS-3 (44.210 Mbps). 65 Second, multicast pruning is now widely deployed across the MBONE and 66 is being mandated as a requirement for MBONE multicast routers 67 [PRUNING]. Pruning prevents multicast routers from forwarding 68 multicast traffic to neighbors that have no receivers for the 69 destination multicast group. With the original implementation of 70 mrouted, pruning was not implemented so multicast traffic sent to the 71 MBONE was distributed across the entire backbone. 73 Because of the original lack of pruning and the default rate limiting 74 of 512 kbps enabled on mrouted, many people believe that there is a 75 total capacity of 512 kbps for the aggregate traffic sent on the 76 MBONE. In fact, many people have used this as a reason not to 77 develop multicast applications. With increased bandwidth in the 78 national service providers networks and with pruning multicast 79 routers deployed widely on the MBONE, neither of the previous 80 constraints on MBONE traffic are valid any longer. 82 4. Current Use of Rate Limits 84 Backbone providers that are tunneling multicast traffic across their 85 networks are encouraged to raise the default rate limit on mrouted 86 boxes to a more useful limit. It is essential to encourage the use 87 of multicast traffic as a more scalable alternative to unicast 88 streaming technologies. 90 This is not to say that rate limits no longer are required anywhere 91 on the MBONE. End-points on the MBONE may still require rate limits 92 their tunnels to prevent multicast users from consuming all available 93 bandwidth on the customer's access link. End-points should determine 94 how much of their bandwidth they want to allow multicast traffic to 95 consume and should request that their tunnel provider only allow that 96 much traffic traffic on the tunnel. Some multicast routers also 97 permit the configuration of an inbound rate limit to prevent 98 congestion within the router. 100 Rate limits are also very useful on congested links due to the fact 101 that the current DVMRP implementation does not retransmit prunes. If 102 the prune message is lost, the group will continue to be transmitted 103 across the tunnel. 105 Expires 18 August 1997 INTERNET-DRAFT 18 February 1997 107 Backbone providers may also choose to set a rate limit on their 108 tunnels that is high enough not to impede normal multicast traffic 109 but low enough to protect against denial-of-service attacks. The 110 potential for denial of service attacks on a multicast group are 111 similar to "flood pinging" against a unicast targe, except the 112 potential exists to hit more that one path through the network at the 113 same time. 115 In all applications of rate limits, it is important to remember that, 116 with pruning, these rate limits will only apply to multicast groups 117 that have receivers at the other end of the tunnel. At no time does 118 a rate limit applied to a DVMRP tunnel imply a total aggregate 119 capacity of the MBONE. 121 5. Security Considerations 123 The removal of rate limits altogether on backbone provider's MBONE 124 tunnels could possibly lead to denial-of-service attacks by sending 125 large amounts of traffic to a global multicast group such as the SDR 126 group. 128 6. References 130 [PRUNING] J. Hawkinson, "Multicast pruning a necessity", Work in 131 progress (internet-draft). 133 7. Author's Address 135 Doug Junkins 136 NorthWestNet 137 15400 30th Place SE, Suite 202 138 Bellevue, WA 98007 140 phone: +1 206 649 7419 141 email: junkins@nwnet.net