idnits 2.17.1 draft-crowcroft-pricing-the-i-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-24) 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 7 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 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 146 has weird spacing: '...omewhat bias ...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Crowcroft 3 Expire in six months UCL CS 4 July 3 1996 6 Pricing the Internet 7 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet- Drafts as 18 reference material or to cite them other than as ``work in 19 progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 23 Shadow 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 Abstract 29 This is a brief note about pricing the Internet. The focus is the use 30 of pricing for usage of the infrastructure for transmitting and 31 receiving IP packets, rather than of services such as WWW, FTP, 32 Archie, Gopher etc. In this we propose subscription based pricing, 33 and a mechanism based on dynamic host address allocation drawn from a 34 set of seperately routed addresses to give priority levels. 36 The idea of subscriptions here is not that all service pricing should 37 be achieved through subscriptions per se. They are seen as a way of 38 policing priority access to service bottlenecks, and thus can be 39 deployed incrementally at weak interconnection points in a network, 40 or between ISPs. Users of these subscriptions could easily be entire 41 organisations (represented by network numbers, or CIDRized 42 collections of network numbers, or ASs and so on). These 43 organisations could employ refinement techniques to provide more 44 usage oriented charging if needed. 46 Introduction 48 To date, it has been argued by many in the Internet that usage based 49 charges are not required for the following reasons 50 1. Applications are elastic, and as the number of users for a given 51 capacity bottleneck increase, the current queuing and TCP flow 52 control and congestion control mechanisms schemes effectively share 53 out the capacity fairly. This means that so long as a user gets any 54 capacity at all, then the total utility increases with the number of 55 users, and therefore all is well. (Say we have 100 users and charge 56 them 1 ECU per year and they get 1 picobit per second; if we have 200 57 users, they get 1/2 a picobit per second; we can charge them 1/2 an 58 ECU, make the same profit; if the don't care about when their picobit 59 is transferred, we have more happy users.) 61 2. If a user doesn't get good enough response (latency or throughput 62 - it comes to the same thing whether they want a character echoed, a 63 web page to pop up, or an FTP to finish so they can print a 64 document), they can try again when the net is less busy. 66 3. Incentives - you bill someone so they can STOP someone else using 67 the net? Why not just increase subsidy to the common good network, 68 and keep all the users happy? 70 These arguments are actually not clearcut. For example: 1/ TCP 71 mechanisms do not operate well below 1 packet per round trip time 72 with current FIFO "drop tail" routers - even with Random Early Drop 73 routers, the types of load we are seeing on some links (e.g. the UK 74 US link is currently operating on a 24 hour average at 300 new 75 connection attempts per second) will never allow any TCP to stabalise 76 even if it were long lived (and statistics from NLANR and the UK 77 National caches show remarkable agreement that the traffic on the net 78 is 70-90% WWW, and the average web page is around 2K bytes, making 79 for an average TCP lifetime of 11 packets). In fact, there are large 80 charges associated with having lots of users - there are router state 81 overheads, billing overheads, access line (modem) overheads etc etc) 83 2/ Nowadays,users write programs to drive the network when they get 84 poor human response. 86 3/ The majority of users in today's Internet do not share a common 87 goal, so subsidy based network support is not viable (except possibly 88 to some extent in portions of the net such as the UK academic one) 90 voice, (CU-SeeMe,) and the mbone...vat 'n vic applications... 92 we could take a look at the requirements for a new model for pricing 93 for the Internet on 3 timescales: 95 Now(e.g. motivated by the Fat Pipe congestion between the UK and US) 97 Medium Term - e.g. what we can do with existing IP hosts and routers, 98 and network management and applications, given some modest new 99 technology. 101 Longer Term- what can be done with RSVP and the Integrated Services 102 Internet traffic model profiles (and related technology, like IPv6). 104 This note is mostly about NOW. 106 The Reality Now 108 Actually, we have pricing, at least from most commercial ISPs - its 109 based on the access line speed from a subscriber to a provider, and 110 at a higher level, on the interconnect speed between ISPs. How do 111 they determine access speeds? They keep TCP and UDP statistics 112 (traffic matrices), and build a backbone with sufficient capacity for 113 the number of typical active hosts from all sites t get some minimal 114 latency - no-one has publicly stated this latency, but my guess is 115 that it will depend on the "profile" of the ISP. A "High Quality" 116 (Rolls Royce) ISP would offer throughput and latency that would 117 match the access line speed closely - e.g. a dialup user at 28kbps 118 would see most of their line speed to any server site on the ISP. 119 This doesn't mean that the net has to have backbone capacity at the 120 sum of the access lines, since many users are idle at any time - and 121 unlike CBR voice/video traffic, it takes a user request to cause 122 traffic (though compressed silence suppressed voice, and motion 123 detecting video sources might behave similarly). 125 If a typical user just gets web pages and sends email, and maybe 126 retrieves 100 items a day, they are responsible for bursts of traffic 127 for which a backbone can be dimensioned quite easily. 129 E.g. a net with 100,000 users with access lines at 64kbps, or 8Kbytes 130 per sec, and a user expecting to see almost instantaneous response 131 for their 11 packet exchange: 133 If the users make 100 requests a day, there are 10M requests in say 134 10 hours (assuming the night is idle - a dangerous assumption, but 135 this is just for illustration). To accommodate the 277 requests per 136 second, at 2Kbytes, we need back bone switching at 4Mbps. This would 137 in fact give around 1/4 the performance a user might expect (assuming 138 the backbone has buffering enough for peak arrival, and TCP 139 retransmits don't mess things up). To accommodate all users as if 140 there is no other user, we need a backbone speed of 16Mbps. By 141 contrast, if we ignored the traffic, and just looked at the lines as 142 if they might be running 64kbps flatout, we'd need 6Gbps. 144 Of course, the picture is not this simple since users have quite well 145 known synchronise busy times (e.g. 9am, just after lunch, etc etc). 146 [assuming Poisson arrivals would give a somewhat bias view - most 147 traffic on networks is well known to be self similar, or heavy 148 tailed...) 150 However, given this, with 64kbps a high end access speed so far, and 151 users accesses, not aggregated typically, but arriving at a router on 152 the backbone, we have a traceable design and pricing problem. 154 We can choose a latency by selecting an effective bandwidth (or 155 utilisation) that the user will get from their 157 ISP to ISP 159 Between service providers, we have the same picture, except that one 160 ISP does not know the number of users or traffic profiles of another 161 ISP. However, they can still measure them at least in a restricted 162 way (they can measure the sources that venture off the other ISP 163 only, obviously). 165 There is a deployment problem for end to end (user to ISP, ISP to 166 ISP, and ISP to user) billing: charges have to behave in some 167 reasonable approximation to associative/commutative (perfection 168 probably isn't called for, but at least close) or obvious unstable 169 markets develop. 171 The Problem. 173 There are two possible sources of problem for the simple approach 174 above: 176 1. The price that such the backbone would cost if all users are given 177 an equal share may not be affordable. 179 2. Users may offer traffic that IS a significant percentage of their 180 access link speed (this has the same effect, but sooner). 182 In this case, we need a way to extract extra money from some users 183 (priority users). They can subscribe to a service (which implies we 184 only need classify their traffic, and could authenticate out of band) 185 or they can reserve the priority on demand (which means we need to 186 authenticate the reservation in band), and they may want to pay only 187 for what they actually use, or may be prepared to pay whether they se 188 it or not (makes the accounting easier - simply start-end time 189 based). 191 [Lets ignore payment here - assume logging or something is done - 192 payment is just matching database to a billing point - its irrelevant 193 (albeit a complex system, it has no bearing once we have a model for 194 what we control and what we monitor). 196 The Future 198 From the user interface (at the Graphical user interface to a human, 199 or the API for the novel application programmer) we expect to present 200 a quality choice - how long will this FTP take, how urgent is this 201 WWW transaction, how important is this video conference. 203 However, this can be reflected in the architecture for accounting and 204 billing quite a few different ways: 206 The basic choice is: Subscription versus tokens versus online 207 charges. 209 At the internal interface (NNI in ATM language) between ISP and ISP, 210 we can envisage transferring individual charges. We can also envisage 211 transferring some notion of collective quality (e,g in phone nets, 212 call blocking probability: in the Internet, packet loss or delay 213 probability; with RSVP, reservation rejection probability, or for a 214 high risk ISP, breach of contract for QoS (e.g. exceeding negotiated 215 CDV, or packet loss delay contract, or minimum cell or packet rate 216 for an agreed connection). 218 Priority 220 One way we could envisage implementing priorities would be to sell 221 addresses that are treated differently in the routers or are routed 222 over links which are deliberately shared out to fewer sources. To do 223 this, we would need routers that could route based on source address 224 (as well as destination), or we would need to replicate the routing 225 state for sources that wished to to use a priority based on such a 226 scheme (or both!). An address might correspond to a range of services 227 subscribed to (not just to one single one), and those services might 228 have a limited lifespan (token limited to a maximum usage as a 229 percentage of one's access line speed per 24*7 for example). This 230 provides spatial and temporal aggregation of "reservations" again. 232 Some routers now implement WFQ on a variety of input - typically, by 233 application, and by input port on a router - it should be possible to 234 partition up the address space so that a number of net/host from a 235 site arrive at a bottleneck router VIA a different port (through 236 policy routes making the default route taken by normal addressed 237 packets not visible, for example). it would require leaf routers to 238 participate in the scheme though... [Aside: note some WFQ 239 implementations are limited in the range of mappings from traffic 240 class to weighted queue - in general, WFQ can be implemented to a 241 very fine grain of allocation quite efficiently, however.] 243 Aggregation and Deployability 245 The Internet has very good aggregation of information for many 246 purposes - address aggregation (and name aggregation, and route 247 aggregation, with CIDRized addresses) all make the net highly 248 deployable and cheap to manage. We would like subscriptions to be 249 aggregateable - clearly address based subscriptions would work fairly 250 well in this regard. 252 The Cost of Charging 254 Keeping the cost of charging down is a good idea - this is why 255 subscription based schemes seem to be sensible - we can see that they 256 ought to scale only slightly worse than the current flat fee system. 258 We can implement on-demand reservations by dynamic address 259 allocation, instead of via a new protocol, too which can then be 260 locally accounted - this then has the nice property of completely 261 distributing the onus of charging and authentication, and leaving 262 policies for how users obtain a priority up to the edge networks 263 instead of the center. 265 Archive, Mirrors, Smoke and Caches 267 Archive servers often confuse debates about charging. However, if we 268 model a mirror or archive or Web Cache server as an ISP, we have a 269 good handle on how to include them in our billing model - we simply 270 regard traffic between a server and a subscriber to a remote ISP as 271 _transitting_ the ISP that sponsors the server. 273 Sharing of unused "reservations" - subsidy and policy 275 Link share has been seen to be important - in fact, it may be key to 276 deploying any scheme for pricing resources, since the normal 277 demand/price models don't seem to work well for information 278 transmission... 280 Problem 281 Address Space and router memory are both running out - this scheme 282 will only work if we can reclaim addresses - we can make it a 283 precondition of getting "priority addresses" that a 284 university/customer renumber all their systems to allow the provider 285 to regain some breathing space. 287 Problem with schemne - routers don't currently do WFQ on source 288 address - however, adding soruce address as a possible hash field to 289 geet to a WFQ is pretty simple. Failing this, assuming that outbound 290 traffic is subject to the wsame queue on the return path, (at least 291 for Web access this is true), then basing it on destinatio nat the 292 far end will also sort of approximate to the same result, except for 293 one important class of traffic - mbone. 295 Refinements 297 A user organisation could purchase address space that is treated with 298 priority access, is at liberty to _re-sell_ use of that space in lost 299 of ways. One example could be that inside a university, the addresses 300 in that space are allocated through DHCP, and users get some number 301 of tokens that are time based, for how long they can use part of the 302 address space. Another example might be a public Mbone phone box, 303 where coins are used to gain adccess to an address. Other schemes are 304 possible... 306 Interaction 308 Settlements and Recursive Settlements - from the middle of the 309 network outwards. Clearly, if we use an address space that gives 310 guarantees at one bottleneck (e.g. between the first and second hop 311 ISPs) There is no guarantee that it works on the next hop too. 313 However, there is an incentive that can be created between ISPs (and 314 between bottle-neck providers, or BNPs as we might term them) - lossy 315 BNPs can be billed by guaranteeing ISPs, for failing to match the 316 service agreement. This could form the basis for settlements very 317 easily. 319 The service contract should be stated, perhaps using the same 320 parameter set as defined in tspecs and rspecs in RSVP, and through 321 the same Policy Modules, so that we have a deployment scheme for RSVP 322 too. 324 References 326 B.Carpenter Metrics for Internet settlements draft-carpenter- 327 metrics-00.txt 329 Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting Background", 330 RFC 1272, Bolt Beranek and Newman Inc., Meridian Technology 331 Corporation, November 1991. 333 Nevil Brownlee INTERNET-DRAFT draft-ietf-rtfm-acct-meter-mib-01.txt" 334 Traffic Flow Measurement: Architecture 336 Brownlee, N., "Traffic Flow Measurement: Meter MIB," Internet Draft, 337 'Working draft' to become an experimental RFC. 339 F. P. Kelly, "Tariffs and Effective Bandwidths in Multiservice 340 Networks", Proc. 14th Int. Teletraffic Cong., 6-10 June 1994 North- 341 Holland Elsevier Science B.V., 1, 1994, 387--410 343 F. P. Kelly, "Routing in Circuit-Switched Networks: Optimization, 344 Shadow prices and Decentralization", Adv. Appl. prob., Vol. 20, :, 345 112-144, 1988 347 R. Braden, L.Zhang, S.Berson, S.Herzog, S.Jamin File: draft-ietf- 348 rsvp-spec-12.txt Resource ReSerVation Protocol (RSVP) -- Version 1 349 Functional Specification draft-ietf-rsvp-spec-12.txt 351 Author's Address 352 Jon Crowcroft 353 UCL 354 Gower St 355 London WC1E 6BT 356 England 358 Tel +44 171 380 7296 359 Fax +44 171 387 1397 360 Email: jon@cs.ucl.ac.uk