B. Carpenter Internet Draft CERN May 1996 Metrics for Internet settlements Abstract draft-carpenter-metrics-00.txt One approach to resolving the current crisis in Internet performance is to institute an efficient system of inter-carrier settlements. This note outlines a set of metrics that could be considered for use in such settlements. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Carpenter Expires Nov 1996 [Page 1] Internet Draft Metrics for Internet settlements May 1996 Table of Contents: Status of this Memo.............................................1 1. Introduction.................................................3 2. The need for metrics.........................................3 3. Settlement metrics...........................................4 4. Technical work needed........................................7 5. Security considerations......................................7 Annex A. Settlement agreements..................................8 Annex B. Types of service provider..............................9 Acknowledgements...............................................10 References.....................................................10 Author's Address...............................................10 Carpenter Expires Nov 1996 [Page 2] Internet Draft Metrics for Internet settlements May 1996 1. Introduction This note has been written to stimulate discussion on metrics for inter-carrier financial settlements in the Internet. Such discussions are understood to be permissible under anti-trust laws, in open meetings, as long as specific sums of money are not mentioned. It is the author's view that the current crisis in Internet performance, although superficially caused by very high growth rates, is to a significant extent due to the lack of efficient financial pressure on service providers to strengthen their infrastructure. One way to fix this is to institute financial settlements between the providers. The approach taken by this note is a practical bottom-up one, consciously avoiding abstract considerations of whether settlements are "a good thing", since they are clearly inevitable anyway. The note suggests some things that could be measured and charged for without too much overhead. It also lists the main features needed in settlement agreements. General discussion of the topic may be found for example in [Crowcroft], [Huston], [OECD]. 2. The need for metrics At the moment the Internet is certainly not payment-free, but it is largely settlement-free, i.e. competing carriers usually exchange traffic with each other free of charge (except for paying the direct costs of the physical exchange). On the other hand, end-users normally pay their direct service provider for some combination of access speed, connection time, and bytes transceived. Further, local service providers normally pay their wide-area carrier(s). Thus, there is a contrast between a "user pays" policy at the local level and a "sender keeps all" policy at the inter-carrier level. Suppose that traffic between subscribers S1 and S2, connected to local providers L1 and L2 respectively, flows through wide-area providers W1, W0, and W2: S1===>L1===>W1====W0====W2<===L2<===S2 The arrowheads indicate where payments are typically made, and hence where market pressure may be assumed. Note that the wide area carriers do not exert direct market pressure on each other. They are presumably competing for business from hundreds of local providers and millions of subscribers. This means that there is limited direct financial pressure on them to improve their collective quality of service (for example, by increasing the transit bandwidth inside W0, or by connecting W1 directly to W2, both at extra cost). Even if L1 discovers a more cost-effective route to L2 by changing its wide-area carrier, this applies no immediate penalty to W0. Carpenter Expires Nov 1996 [Page 3] Internet Draft Metrics for Internet settlements May 1996 Of course this is a grossly simplified example, and one can hardly analyse the real situation with hundreds of providers and millions of subscribers. There are also multiple sources of asymmetry to complicate the situation, including: - expensive trans-oceanic routes with highly asymmetric traffic patterns - services such as MBONE routers or Web caches that replicate traffic locally to reduce traffic on WAN lines - asymmetric routes An expected future complication, with the imminent deployment of RSVP, will be the availability of "better than best effort" quality of service, presumably costing more money to subscribers, and needing a guaranteed share of the total resources. Yet a fair share of the resources must be kept for non-RSVP traffic, and today there is no financial mechanism to ensure this. This note suggests that the most practical approach to these issues is for service providers to agree (bilaterally or multi-laterally) on a set of easily measured metrics, and to reach simple contractual agreements (see Annex A) to make financial settlements based on these metrics. The remainder of this note sketches out a set of possible metrics. They have been chosen to be those most likely (in the author's view) to lead to a useful micro-economic market, i.e. one that tends to optimise Internet infrastructure for the general good. But of course there are risks in this game: choosing a particular set of metrics will make the Internet infrastructure develop in a particular way (so as to maximise carrier revenue from those metrics). Mistakes could be expensive. Note that fully dynamic QOS-related automatic accounting for RSVP [RSVP], such as might be envisaged in a true Integrated Services Internet, is not considered in this note. 3. Settlement metrics It should be noted that since there is no generic notion of a "call" in the Internet, the metrics considered are fundamentally different from those in the telephony world. A variety of operational metrics could be used to compute settlements. However, metrics that require expensive instrumentation such as detailed packet or flow analysis should be avoided as much as possible. Simple bulk measurements on a wire, or off-line measurements, are preferable. Metrics that can be estimated, if necessary, by statistical sampling are preferred. Also, in general, metrics should be symmetric in nature, so that the resulting settlements can be associative and commutative. This also allows settlements to be aggregated by upstream service providers, and Carpenter Expires Nov 1996 [Page 4] Internet Draft Metrics for Internet settlements May 1996 redistributed by transit carriers, in an equitable manner. This section gives a non-exclusive list of metrics, essentially as examples. It can be said, however, that most known retail charging mechanisms in the Internet today are based on the first two metrics below (capacity and connect time). It is suggested that using the next two (total traffic and number of routes announced) between ISPs would rapidly have beneficial effects on the economics of Internet infrastructure. 3.1. Access capacity (bit/sec) Applicable: if common carrier charges for bit rate, or if equipment costs depend on bit rate. Measured by: a priori. 3.2. Connect time (sec) Applicable: if common carrier charges for connect time. Measured by: common carrier metering 3.3. Total traffic (bytes) Applicable: anywhere It is a subtle issue whether this metric concerns traffic in one or both directions, and the answer will depend on the relationship between the parties. If one party is a topological stub, such as an end-user site or a local ISP, then the appropriate metric might be total traffic to and from the stub. However, some ISPs are known already to charge end-users only for traffic delivered to the user, with no charge for traffic sent by the user. On the other hand, if both parties are actually or potentially involved in transit traffic, such as peering ISPs or Internet Exchanges, the appropriate metric might be net traffic, with the net sender paying. (See Annex B for a taxonomy of the types of service provider.) Measured by: router or access server statistics, TCPDUMP sampling, RTFM meters [RTFM], etc. 3.4. Number of announced routes (number) Applicable: at inter-ISP peering points; at connection of subscribers with more than one subnet. Measured by: analysis of routing tables. Carpenter Expires Nov 1996 [Page 5] Internet Draft Metrics for Internet settlements May 1996 3.5. Peak traffic (bit/sec sustained for N sec) Applicable: where carrier overbooks trunks Measured by: see 3.3. 3.6. Information Source (bytes) Applicable: at connection of service provider (such as DNS or RR server) or content provider (such as Web server). Also applicable at connection of information replicator (such as MBONE router or Web cache). If an information source is charged for its total traffic, as under metric 3.3 above, it should be able to charge back at a higher rate for the value of its information or for the replication it has performed. Thus this metric applies to traffic leaving the information provider concerned. Measured by: see 3.3. 3.7. Mean loss rate (%) Applicable: everywhere Measured by: TBD 3.8. Mean RTT (sec) Applicable: everywhere Measured by: TBD 3.9. Route flaps (number) Applicable: at inter-ISP peering points; at connection of multi-homed subscribers. Measured by: TBD Carpenter Expires Nov 1996 [Page 6] Internet Draft Metrics for Internet settlements May 1996 4. Technical work needed It is clear that in order to widely implement settlement agreements, there must be technical mechanisms for measuring the metrics and collecting the results. This is work to be done, most likely in the IETF, to reach more precise definitions of a useful set of metrics and to define appropriate MIBs. 5. Security considerations The collection and transmission of metrics later to be used for the calculation of financial settlements must be authenticated and possibly confidential. This constrains the choice of protocol for the transmission of such data, although there is no reason to expect that a special-purpose security protocol will be needed. Carpenter Expires Nov 1996 [Page 7] Internet Draft Metrics for Internet settlements May 1996 Annex A. Settlement agreements A settlement agreement is an agreement drawn up between two or more service providers (such as defined in Annex B) that specifies an agreed set of metrics (such as defined in Section 3). The agreement should be a contract in law, respecting all applicable civil, criminal and international laws. Whether it is bilateral or multi-lateral will depend on the anti-trust provsions of the jurisdiction concerned. For each metric in the set, the agreement should - define or refer to a measurement method - specify a settlement rate and currency In general, the agreement should - specify settlement dates and financial procedures - specify independent auditing procedures - specify binding arbitration mechanisms (to avoid recourse to the courts) Carpenter Expires Nov 1996 [Page 8] Internet Draft Metrics for Internet settlements May 1996 Annex B. Types of service provider In this document the phrase "service provider" covers a variety of entities, any of which may need to participate in settlements. A single organisation may fulfil multiple of these roles, and the following list is merely indicative. In practice, any corporate entity could participate in a settlement agreement. B.1. Commercial Wide-area Internet Service Provider (CWISP) Supplies and operates inter-city and/or international IP transport for profit. B.2. Commercial Local-access Internet Service Provider (CLISP) Supplies IP access for domestic and business subscribers in a given area. Offers global Internet access via one or more CWISPs. B.3. Private Internet Service Provider (PRISP) Supplies IP access and transport to a specified user community on a non-profit basis (funded by tax money or by a user consortium). Alternatively, provides corporate IP access and transport to a given company, funded by the company for business reasons. B.4. Neutral Internet eXchange Operator (NIXOP) Interconnects multiple CWISPs, CLISPs and PRISPs through a local/metropolitan interconnection technology. Imposes no restrictions on traffic or peering arrangements. B.5. General Service Operator (SERVOP) Operates services such as root name servers, MBONE routers and Web caches for use by multiple ISPs. B.6. Commercial Content Provider (CCP) Provides commercial information content such as Web pages. B.7. Non-profit Content Provider (NPCP) Provides non-profit information content such as Web pages. B.8. Registry Operator (REGOP) Allocates or delegates name space and address space, and operates related information servers, and/or operates routing registry. Carpenter Expires Nov 1996 [Page 9] Internet Draft Metrics for Internet settlements May 1996 Acknowledgements This document is entirely the fault of its author. However, thanks go to Guy Almes, Jon Crowcroft, Geoff Huston... for constructive comments. S.Tanaka of the ITU gave me some useful hints on the existing settlements regime. References [Crowcroft] J.Crowcroft, "Pricing the Internet", personal communication, April 1996. [Huston] G.Huston, "Internet Service Provider Peering", work in progress, December 1994 (available at http://www.iepg.org/settlements.html) [OECD] "INFORMATION INFRASTRUCTURE CONVERGENCE AND PRICING: THE INTERNET", OCDE/GD(96)73, May 1996 (available at http://www.oecd.org/dsti/gd_docs/s96_xxe.html) [RTFM] N.Brownlee, C.Mills, G.Ruth, "Traffic Flow Measurement: Architecture", work in progress (draft-ietf-rtfm-acct-arch-report- 01.txt), March 1996 [RSVP] S.Herzog, "Accounting and Access Control in RSVP", work in progress (draft-ietf-rsvp-lpm-arch-00.txt), March 1996 Author's Address Brian E. Carpenter Group Leader, Communications Systems Phone: +41 22 767-4967 Computing and Networks Division Fax: +41 22 767-7155 CERN European Laboratory for Particle Physics Email: brian@dxcoms.cern.ch 1211 Geneva 23, Switzerland Carpenter Expires Nov 1996 [Page 10]