[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

                                                            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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/