idnits 2.17.1 draft-carpenter-metrics-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-23) 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 1) being 64 lines 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. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 253 has weird spacing: '...ful set of me...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 1996) is 10205 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. 'Crowcroft' -- Possible downref: Non-RFC (?) normative reference: ref. 'Huston' -- Possible downref: Non-RFC (?) normative reference: ref. 'OECD' -- Unexpected draft version: The latest known version of draft-ietf-rtfm-acct-arch-report is -00, but you're referring to -01. ** Downref: Normative reference to an Experimental draft: draft-ietf-rtfm-acct-arch-report (ref. 'RTFM') -- No information found for draft-ietf-rsvp-lpm-arch - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RSVP' Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 B. Carpenter 3 Internet Draft CERN 4 May 1996 6 Metrics for Internet settlements 8 Abstract 10 draft-carpenter-metrics-00.txt 12 One approach to resolving the current crisis in Internet performance 13 is to institute an efficient system of inter-carrier settlements. 14 This note outlines a set of metrics that could be considered for use 15 in such settlements. 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 31 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 32 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 33 Rim). 35 Table of Contents: 37 Status of this Memo.............................................1 38 1. Introduction.................................................3 39 2. The need for metrics.........................................3 40 3. Settlement metrics...........................................4 41 4. Technical work needed........................................7 42 5. Security considerations......................................7 43 Annex A. Settlement agreements..................................8 44 Annex B. Types of service provider..............................9 45 Acknowledgements...............................................10 46 References.....................................................10 47 Author's Address...............................................10 49 1. Introduction 51 This note has been written to stimulate discussion on metrics for 52 inter-carrier financial settlements in the Internet. Such discussions 53 are understood to be permissible under anti-trust laws, in open 54 meetings, as long as specific sums of money are not mentioned. 56 It is the author's view that the current crisis in Internet 57 performance, although superficially caused by very high growth rates, 58 is to a significant extent due to the lack of efficient financial 59 pressure on service providers to strengthen their infrastructure. One 60 way to fix this is to institute financial settlements between the 61 providers. 63 The approach taken by this note is a practical bottom-up one, 64 consciously avoiding abstract considerations of whether settlements 65 are "a good thing", since they are clearly inevitable anyway. The 66 note suggests some things that could be measured and charged for 67 without too much overhead. It also lists the main features needed in 68 settlement agreements. 70 General discussion of the topic may be found for example in 71 [Crowcroft], [Huston], [OECD]. 73 2. The need for metrics 75 At the moment the Internet is certainly not payment-free, but it is 76 largely settlement-free, i.e. competing carriers usually exchange 77 traffic with each other free of charge (except for paying the direct 78 costs of the physical exchange). On the other hand, end-users 79 normally pay their direct service provider for some combination of 80 access speed, connection time, and bytes transceived. Further, local 81 service providers normally pay their wide-area carrier(s). Thus, 82 there is a contrast between a "user pays" policy at the local level 83 and a "sender keeps all" policy at the inter-carrier level. 85 Suppose that traffic between subscribers S1 and S2, connected to 86 local providers L1 and L2 respectively, flows through wide-area 87 providers W1, W0, and W2: 89 S1===>L1===>W1====W0====W2<===L2<===S2 91 The arrowheads indicate where payments are typically made, and hence 92 where market pressure may be assumed. Note that the wide area 93 carriers do not exert direct market pressure on each other. They are 94 presumably competing for business from hundreds of local providers 95 and millions of subscribers. This means that there is limited direct 96 financial pressure on them to improve their collective quality of 97 service (for example, by increasing the transit bandwidth inside W0, 98 or by connecting W1 directly to W2, both at extra cost). Even if L1 99 discovers a more cost-effective route to L2 by changing its wide-area 100 carrier, this applies no immediate penalty to W0. 102 Of course this is a grossly simplified example, and one can hardly 103 analyse the real situation with hundreds of providers and millions of 104 subscribers. There are also multiple sources of asymmetry to 105 complicate the situation, including: 107 - expensive trans-oceanic routes with highly asymmetric traffic 108 patterns 110 - services such as MBONE routers or Web caches that 111 replicate traffic locally to reduce traffic on WAN lines 113 - asymmetric routes 115 An expected future complication, with the imminent deployment of 116 RSVP, will be the availability of "better than best effort" quality 117 of service, presumably costing more money to subscribers, and needing 118 a guaranteed share of the total resources. Yet a fair share of the 119 resources must be kept for non-RSVP traffic, and today there is no 120 financial mechanism to ensure this. 122 This note suggests that the most practical approach to these issues 123 is for service providers to agree (bilaterally or multi-laterally) on 124 a set of easily measured metrics, and to reach simple contractual 125 agreements (see Annex A) to make financial settlements based on these 126 metrics. The remainder of this note sketches out a set of possible 127 metrics. They have been chosen to be those most likely (in the 128 author's view) to lead to a useful micro-economic market, i.e. one 129 that tends to optimise Internet infrastructure for the general good. 131 But of course there are risks in this game: choosing a particular set 132 of metrics will make the Internet infrastructure develop in a 133 particular way (so as to maximise carrier revenue from those 134 metrics). Mistakes could be expensive. 136 Note that fully dynamic QOS-related automatic accounting for RSVP 137 [RSVP], such as might be envisaged in a true Integrated Services 138 Internet, is not considered in this note. 140 3. Settlement metrics 142 It should be noted that since there is no generic notion of a "call" 143 in the Internet, the metrics considered are fundamentally different 144 from those in the telephony world. 146 A variety of operational metrics could be used to compute 147 settlements. However, metrics that require expensive instrumentation 148 such as detailed packet or flow analysis should be avoided as much as 149 possible. Simple bulk measurements on a wire, or off-line 150 measurements, are preferable. Metrics that can be estimated, if 151 necessary, by statistical sampling are preferred. Also, in general, 152 metrics should be symmetric in nature, so that the resulting 153 settlements can be associative and commutative. This also allows 154 settlements to be aggregated by upstream service providers, and 155 redistributed by transit carriers, in an equitable manner. 157 This section gives a non-exclusive list of metrics, essentially as 158 examples. 160 It can be said, however, that most known retail charging mechanisms 161 in the Internet today are based on the first two metrics below 162 (capacity and connect time). It is suggested that using the next two 163 (total traffic and number of routes announced) between ISPs would 164 rapidly have beneficial effects on the economics of Internet 165 infrastructure. 167 3.1. Access capacity (bit/sec) 169 Applicable: if common carrier charges for bit rate, or if equipment 170 costs depend on bit rate. 172 Measured by: a priori. 174 3.2. Connect time (sec) 176 Applicable: if common carrier charges for connect time. 178 Measured by: common carrier metering 180 3.3. Total traffic (bytes) 182 Applicable: anywhere 184 It is a subtle issue whether this metric concerns traffic in one or 185 both directions, and the answer will depend on the relationship 186 between the parties. If one party is a topological stub, such as an 187 end-user site or a local ISP, then the appropriate metric might be 188 total traffic to and from the stub. However, some ISPs are known 189 already to charge end-users only for traffic delivered to the user, 190 with no charge for traffic sent by the user. 192 On the other hand, if both parties are actually or potentially 193 involved in transit traffic, such as peering ISPs or Internet 194 Exchanges, the appropriate metric might be net traffic, with the net 195 sender paying. (See Annex B for a taxonomy of the types of service 196 provider.) 198 Measured by: router or access server statistics, TCPDUMP sampling, 199 RTFM meters [RTFM], etc. 201 3.4. Number of announced routes (number) 203 Applicable: at inter-ISP peering points; at connection of subscribers 204 with more than one subnet. 206 Measured by: analysis of routing tables. 208 3.5. Peak traffic (bit/sec sustained for N sec) 210 Applicable: where carrier overbooks trunks 212 Measured by: see 3.3. 214 3.6. Information Source (bytes) 216 Applicable: at connection of service provider (such as DNS or RR 217 server) or content provider (such as Web server). Also applicable at 218 connection of information replicator (such as MBONE router or Web 219 cache). 221 If an information source is charged for its total traffic, as under 222 metric 3.3 above, it should be able to charge back at a higher rate 223 for the value of its information or for the replication it has 224 performed. Thus this metric applies to traffic leaving the 225 information provider concerned. 227 Measured by: see 3.3. 229 3.7. Mean loss rate (%) 231 Applicable: everywhere 233 Measured by: TBD 235 3.8. Mean RTT (sec) 237 Applicable: everywhere 239 Measured by: TBD 241 3.9. Route flaps (number) 243 Applicable: at inter-ISP peering points; at connection of multi-homed 244 subscribers. 246 Measured by: TBD 248 4. Technical work needed 250 It is clear that in order to widely implement settlement agreements, 251 there must be technical mechanisms for measuring the metrics and 252 collecting the results. This is work to be done, most likely in the 253 IETF, to reach more precise definitions of a useful set of metrics 254 and to define appropriate MIBs. 256 5. Security considerations 258 The collection and transmission of metrics later to be used for the 259 calculation of financial settlements must be authenticated and 260 possibly confidential. This constrains the choice of protocol for 261 the transmission of such data, although there is no reason to expect 262 that a special-purpose security protocol will be needed. 264 Annex A. Settlement agreements 266 A settlement agreement is an agreement drawn up between two or more 267 service providers (such as defined in Annex B) that specifies an 268 agreed set of metrics (such as defined in Section 3). 270 The agreement should be a contract in law, respecting all applicable 271 civil, criminal and international laws. Whether it is bilateral or 272 multi-lateral will depend on the anti-trust provsions of the 273 jurisdiction concerned. 275 For each metric in the set, the agreement should 277 - define or refer to a measurement method 278 - specify a settlement rate and currency 280 In general, the agreement should 282 - specify settlement dates and financial procedures 283 - specify independent auditing procedures 284 - specify binding arbitration mechanisms (to avoid recourse to the 285 courts) 287 Annex B. Types of service provider 289 In this document the phrase "service provider" covers a variety of 290 entities, any of which may need to participate in settlements. A 291 single organisation may fulfil multiple of these roles, and the 292 following list is merely indicative. In practice, any corporate 293 entity could participate in a settlement agreement. 295 B.1. Commercial Wide-area Internet Service Provider (CWISP) 297 Supplies and operates inter-city and/or international IP transport 298 for profit. 300 B.2. Commercial Local-access Internet Service Provider (CLISP) 302 Supplies IP access for domestic and business subscribers in a given 303 area. Offers global Internet access via one or more CWISPs. 305 B.3. Private Internet Service Provider (PRISP) 307 Supplies IP access and transport to a specified user community on a 308 non-profit basis (funded by tax money or by a user consortium). 309 Alternatively, provides corporate IP access and transport to a given 310 company, funded by the company for business reasons. 312 B.4. Neutral Internet eXchange Operator (NIXOP) 314 Interconnects multiple CWISPs, CLISPs and PRISPs through a 315 local/metropolitan interconnection technology. Imposes no 316 restrictions on traffic or peering arrangements. 318 B.5. General Service Operator (SERVOP) 320 Operates services such as root name servers, MBONE routers and Web 321 caches for use by multiple ISPs. 323 B.6. Commercial Content Provider (CCP) 325 Provides commercial information content such as Web pages. 327 B.7. Non-profit Content Provider (NPCP) 329 Provides non-profit information content such as Web pages. 331 B.8. Registry Operator (REGOP) 333 Allocates or delegates name space and address space, and operates 334 related information servers, and/or operates routing registry. 336 Acknowledgements 338 This document is entirely the fault of its author. However, thanks go 339 to Guy Almes, Jon Crowcroft, Geoff Huston... for constructive 340 comments. S.Tanaka of the ITU gave me some useful hints on the 341 existing settlements regime. 343 References 345 [Crowcroft] J.Crowcroft, "Pricing the Internet", personal 346 communication, April 1996. 348 [Huston] G.Huston, "Internet Service Provider Peering", work in 349 progress, December 1994 (available at 350 http://www.iepg.org/settlements.html) 352 [OECD] "INFORMATION INFRASTRUCTURE CONVERGENCE AND PRICING: THE 353 INTERNET", OCDE/GD(96)73, May 1996 (available at 354 http://www.oecd.org/dsti/gd_docs/s96_xxe.html) 356 [RTFM] N.Brownlee, C.Mills, G.Ruth, "Traffic Flow Measurement: 357 Architecture", work in progress (draft-ietf-rtfm-acct-arch-report- 358 01.txt), March 1996 360 [RSVP] S.Herzog, "Accounting and Access Control in RSVP", work in 361 progress (draft-ietf-rsvp-lpm-arch-00.txt), March 1996 363 Author's Address 365 Brian E. Carpenter 366 Group Leader, Communications Systems Phone: +41 22 767-4967 367 Computing and Networks Division Fax: +41 22 767-7155 368 CERN 369 European Laboratory for Particle Physics Email: brian@dxcoms.cern.ch 370 1211 Geneva 23, Switzerland