idnits 2.17.1 draft-li-piara-cost-model-00.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-27) 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 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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 (June 1996) is 10178 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. 'Rekhter' -- Possible downref: Normative reference to a draft: ref. 'Resnick' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Li 3 INTERNET-DRAFT Juniper Networks 4 Expire in six months Y. Rekhter 5 cisco Systems 6 June 1996 8 Towards a Cost Model for Routing and Addressing 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Introduction 31 The IP address space is a fixed size, fully recyclable resource which 32 must be shared amongst the entire Internet community in order to 33 achieve global connectivity. Similarly, the routing table entries in 34 the routers that comprise the backbone are a scarce resource. 35 Squandering either of these resources can lead to an Internet in 36 which some systems have significantly reduced reachability. 38 There are a variety of mechanisms which could be employed to ensure 39 that neither address space nor routing table space is needlessly 40 wasted. Some have proposed [Rekhter, Resnick] that a market based 41 approach is a practical and reasonable allocation of these scarce 42 resources. 44 This memo is a preliminary investigation into a cost model for 45 routing and addressing services, in an attempt to understand the 46 interaction between the address market and the routing table entry 47 market. As this is a preliminary model, it makes some significant 48 simplifications. It's hoped that this memo will also interest those 49 more skilled in the art of cost modeling to correct and refine this 50 model. 52 The Intuitive Model 54 We begin by constructing the model based on the costs that the user 55 sees when provisioning Internet service. We make the simplifying 56 assumption that the user needs to provision a singly homed, non- 57 transit domain (a.k.a., a stub network) that can be addresse entirely 58 by a single prefix (i.e., a contiguous power of two range of 59 addresses). Note that the following analysis can be extended for 60 multiple prefixes by extending the cost functions to take vectors of 61 prefixes as arguments. 63 In purchasing such an Internet service, we posit that there are three 64 significant costs: the cost of bandwidth, the cost of addressing, and 65 the cost of routing. We'll proceed by describing these components 66 intuitively and then turn to a more formal description. The cost of 67 bandwidth includes the cost of the link, both in installation and 68 periodic charges, and the hardware necessary to support both ends of 69 the link (e.g., routers, CSU/DSU's, cables, etc.). There will also 70 be an administrative component to support the link and other non- 71 addressing and non-routing services, which we will consider to be 72 part of the cost of bandwidth in order to simplify this analysis. 73 Note that this implies that the cost of bandwidth is a function of 74 the bandwidth requested and the service provider that it's requested 75 from. Also note that we make the simplifying assumption that 76 bandwidth from all providers is identical, implying a consistent 77 level of service from all competitors in a local market. 79 The cost of addressing is the amount that the user must pay to borrow 80 a particular prefix from an address broker. The bandwidth provider 81 may or may not be an address broker. This cost would include any 82 charges for the administrative costs of lending out the prefix, such 83 as DNS PTR record maintenance. Thus, the cost of addressing is a 84 function of the prefix and the address broker. It's likely that the 85 addressing cost is charged periodically. 87 The cost of routing is the amount that the user must pay to the 88 provider for routing information to the remainder of the Internet. 89 This may involve making configuration changes in a series of routers, 90 in a routing registry, or in the administrative databases of several 91 domains. In the common case where the bandwidth provider is also the 92 address broker, it is likely that the cost of routing is amortized 93 across all customers sharing the particular address block that 94 contains the user's prefix and that the cost of routing is a periodic 95 charge. 97 Note that not all of these costs may be apparent today. This is not 98 to say that these costs do not exist, just that they're not charged 99 for separately. 101 The Formal Model 103 In this section, we describe all of the above in a more formal 104 manner. First, we let the cost of bandwidth be a function Cbw : BW X 105 Prov -> $, where BW is the space of possible bandwidths, Prov is the 106 space of possible providers, and $ is the space of monetary cost. We 107 will also write this as Cbw(bw, P), where bw is the bandwidth and P 108 is the provider. 110 Second, we let the cost of addressing be a function Ca : Pref X Brok 111 -> $, where Pref is the space of possible address prefixes, and Brok 112 is the space of address brokers. We will also write this as Ca(p, 113 B). Note that the space of address brokers may intersect with the 114 space of service providers. 116 Third, we let the cost of routing be a function Cr : Pref X Prov -> 117 $. We will write this as Cr(p, P). We assume that Cr is not 118 sensitive the size of prefix p, but it is sensitive to the allocation 119 of prefix p. Thus, it costs the same to route a /16 or a /8 prefix. 120 However, a /16 from another provider may cost more to route that a 121 /16 where P = B. 123 Finally, we let the total cost be the function C : BW X Prov X Brok X 124 Pref -> $. We will write this as C(bw, P, B, p). Further, as this 125 is simply the sum of the previous three functions, we have: 127 C(bw,P,B,p) = Cbw(bw,P) + Ca(p,B) + Cr(p,P) (1) 129 Some Observations 131 We make the simplifying assumptions that the market always has 132 perfect information and that the consumer will always minimize the 133 overall cost C. 135 Observation 1: If Ca(p,B) is insensitive to the size of prefix p, 136 then address space will be squandered. 138 In this situation, there is no negative feedback to the user for 139 wasting address space. As there is potential benefit in having 140 future address space available, it is in the user's best interest to 141 overstate their addressing needs. Subsequently, demand for addresses 142 will increase, and Ca(p,B) will rise. If it rises sufficiently, then 143 those who have borrowed an address will subdivide their unused 144 addresses, becoming brokers themselves, thus resulting in a Ca(p,B) 145 which is sensitive to the size of the prefix. This is to say that an 146 insensitive Ca(p,B) is self-correcting. 148 Corollary 1: If Ca(p,B) is 0, then address space will be squandered. 150 Observation 2: If Ca(p,B) << C(bw,P,B,p), then address space will be 151 squandered. 153 By reasoning similar to that of Observation 1, the marginal cost of 154 unnecessary address space must exceed the user's marginal benefit of 155 such space, given the user's cost sensitivity or address space will 156 be wasted. For example, consider the case where Ca is only 0.01% of 157 C, and doubling the size of the prefix results in doubling Ca. The 158 resulting Ca is only 0.02% of C, which is not a significant deterrent 159 to wasting addresses. 161 Corollary 2: If Ca(p,B) << Cr(p,P), then address space will be 162 squandered. 164 Observation 3: We call a prefix which is borrowed from the service 165 provider a 'local prefix'. We call a prefix which borrowed from a 166 broker who is not the service provider a 'foreign prefix'. If 167 Cr(p,P) is insensitive to whether a prefix is local or foreign, then 168 routing table entries will be squandered. 170 Note that we also make the simplifying assumption that proxy 171 aggregation is not effective. In the above scenario, if the local 172 and foreign prefixes are identical in cost, then it the user will 173 optimize wholly based on the independent costs of bandwidth and 174 address space, obtaining address space from any address broker, 175 regardless of the possibilities of aggregation. Normal entropy at 176 this point will eventually flood the backbone routing tables. Note 177 that a Cr(p,P) which is insensitive to foreign prefixes is also self 178 correcting as it will increase demand on routing table entries, 179 thereby encouraging aggregation. 181 Corollary 3: If Cr(p,P) = 0 for a foreign prefix, routing table 182 entries will be squandered. 184 Observation 4: If Cr(p,P) << C(bw,P,B,p) then routing table entries 185 will be squandered. 187 By reasoning similar to observation 2. 189 Corollary 4: If Ca(p,B) >> Cr(p,P), then routing table entries will 190 be squandered. 192 Corollary 5: To encourage conservation, Ca(p,B) and Cr(p,P) must be 193 proportional to Cbw(bw,P), and Ca(p,B) ~= Cr(p,P). 195 From observations 2 and 4 and equation (1), it follows that 196 increasing Cbw(bw,P) must also increase Ca(p,B) and Cr(p,P). From 197 corollaries 2 and 4, it follows that Ca(p,B) and Cr(p,P) must be 198 roughly equal. 200 Observation 5: Within the U.S., Cbw(bw,P) is predominantly a function 201 of the length of the circuit and bandwidth selected. 203 Hardware costs are generally a small fraction of the line costs 204 involved in providing bandwidth, usually due to periodic or usage 205 charges. These charges are a function of the length of the circuit 206 (or distance called) and the bandwidth of the circuit. The 207 granularity of the length of the circuit varies depending on the 208 exact media (e.g., Frame Relay may be sold for a flat rate anywhere 209 within a LATA. Local loops may be charged by the mile.) Outside the 210 U.S., the local tariff structure may have significant political 211 distortions. 213 Corollary 6: To encourage conservation within the U.S., Ca(p,B) and 214 Cr(p,P) must be a significant function of the length and bandwidth of 215 the circuit. 217 Note that this is a non-intuitive result which will be difficult to 218 justify to most customers. We suspect that many providers will not 219 even attempt to do so, instead charging a flat rate for routing 220 services, or basing the charge on prefix length. If this occurs, 221 corollary 5 implies that those who are paying the most for Internet 222 services will see little economic incentive for conservation. 224 It's also interesting to observe that an address broker who is not 225 also the service provider has a particularly difficult situation. 226 For the broker to be an agent of conservation, she must charge 227 varying amounts based on the cost of bandwidth as charged by the 228 service provider. This coupling of costs between different entities 229 has possibly severe legal and logistic implications, not the least of 230 which is the liability of anti-trust action for price fixing. As a 231 result, it seems as if an address broker can never actually price 232 address space in a manner that is consistent with address space 233 conservation. 235 Conclusions 237 This memo has attempted to posit a simple cost model for Internet 238 addressing and routing in order to help understand the possible 239 markets for address space and routing services. The model focused on 240 the costs as seen by an end user. The implications of the model are 241 rather disturbing. If the end user does see costs that would 242 encourage conservation, then the costs are non-trivial and are 243 proportional to the cost of the bandwidth that he purchases. 244 Further, in such a situation, there appears to be no feasible role 245 for an independent address broker, resulting in users who have to get 246 address space from their service provider. 248 Alternatively, if a 'natural' market for address space and routing 249 services develops, then the costs for these services are independent 250 of the other costs of provisioning Internet services. The 251 implication is that those who are not cost sensitive will not be well 252 motivated to conserve scarce resources. 254 We further observe that perfect allocation of scarce resources cannot 255 occur unless there is a perfectly accurate measurement of each users 256 need for address space and routing services. The willingness to pay 257 for a resource is only slightly correlated with true need. Thus, any 258 scheme which depends on cost for resource allocation is inherently 259 flawed and can at best provide a first order approximation. The only 260 alternative to such a cost based scheme is political allocation, 261 which has a variety of its own problems. 263 Acknowledgements 265 Tony Li's contribution to this work was supported in part by cisco 266 Systems, Inc. 268 References 270 [Rekhter] Rekhter, Yakov, "Charging for Routes", Presentation at the 35th 271 IETF, March 1996 273 [Resnick] Resnick, Paul, "Suggestions for Market-Based Allocation of IP 274 Address Blocks", Internet Draft, 275 draft-ietf-cidrd-mktbased-alloc-00.txt, Feb. 1996 277 Authors' Addresses 279 Tony Li 280 Juniper Networks, Inc. 281 101 University Ave Ste 240 282 Palo Alto, CA 94301 283 Phone: +1 (415) 614 4145 284 Email: tli@jnx.com 286 Yakov Rekhter 287 cisco Systems, Inc. 288 170 Tasman Dr. 290 San Jose, CA 95134 291 Phone: (914) 528-0090 292 Email: yakov@cisco.com