Internet DRAFT - draft-carpenter-metrics
draft-carpenter-metrics
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]
