CURRENT_MEETING_REPORT_
Reported by Cyndi Mills/BBN
AGENDA
o Bounding the Charter.
o Form a Working Group
o Requirements Discussion: Draft Minutes below.
Minutes
1. Summary
Agreed to form an Internet Accounting working group. Cyndi Mills
will chair it and write the charter. This working group is in the
Network Management Area under Dave Crocker.
2. Bounding the Charter:
We need to examine a wide range of policies to understand what set
of information is required to satisfy the billing and reporting
requirements, bearing in mind realistic requirements and
restrictions regarding:
o Availability of Information,
o Performance, and
o Accuracy.
Policy Disclaimer: Neither issues surrounding how policies are set
nor how they are formulated will be addressed by this group.
2.1 OSI Accounting
Brian Handspicker, ANSI X3T5.4 OSI Management Accounting Ad Hoc
Group Leader, presented the OSI view of accounting. The OSI
Accounting working group is defining the collection service and
protocols. The OSI group is not addressing the content information
to be measured and reported by the collection service. Suggest
that the IETF working group coordinate with the OSI accounting
group so as not to duplicate effort.
Meter <--> Collector <--> Application
Application: The application manipulates the billing data in
accordance with policy, and determines which information will be
requested from the metering devices.
Collector: The collector is responsible for integrity and security
of the data during transport from the meter to the application.
Meters: Meters perform the measurement and aggregate the results.
The characteristics of the meter may be implementation-specific.
2.2 Data Generation vs. Data Collection vs. Billing Application
The generation of accounting data (the meter function) is the focus
of this IETF group. First, we need to determine what information
will satisfy the widest possible range of policies, and what the
constraints are. Secondly, we should cover local storage and
aggregation techniques.
1
Data collection protocols, i.e. methods for carrying accounting
data, are under development in ANSI. Accounting data may be carried
by a combination of protocols, including network management
protocols such as OSI Accounting, SNMP, CMIP. The selection of
collection protocol(s) should be deferred until the structure and
constraints of the carried data are known.
The billing process, i.e. the processing of the accounting data,
is beyond the scope of this group. Billing methods, tariffs, and
exceptions tend to be unique to each organization.
2.3 Network-Level vs. Host-Level
The information available to the meter depends on its location in
the network. One of the major issues here is attribution - with
what granularity can we account for the source and destination of
network traffic? Can we track the source/destination of a packet
to the autonomous network, the network number, the host address,
the user, or to a charge number on one of a user's many projects?
For network meters, a function attached to the routers, this
information is limited to what can be extracted from the IP packet
flow. Various counters may be implemented, but attribution of the
packet to a source is limited to the information available in the
IP address (and the protocol ID of the protocol carried). There is
no unique identifier in the packet for a user.
Host meters are more flexible. They have direct knowledge of the
user and his operation, and are in a position to implement
user-level accounting in accordance with the behavior of a specific
operating system.
This working group will concentrate on network-level meters. The
discussion section covers a number of background arguments for this
restriction.
3. Discussion
The Internet community is made up of:
o Network providers, e.g. backbone and regional networks, who
usually own the transmission media, regulate or own the
routers, but disown the hosts. Internet accounting is for the
benefit of the network provider, an aid in the implementation
of the network provider's policy. In networks with chargeback
policies, accounting may be the sole source of funding for the
network.
o Network users, e.g. hosts, individual users, and projects.
These are the consumers of network services. From an
accounting point of view, these are the end-users, the finest
granularity of attribution.
o Stuck in the middle. These are the entities that are both
providers and consumers of network services. Hosts and
regional networks are frequently in this category. They
receive service from the network and provide network service to
the user. In addition to compensating other network providers
for network services rendered, they must assist in allocating
responsibility for those services received and provided to
end-users.
The phone company analogy was used frequently to illustrate several
interrelated points.
o Regional/Local Operating Providers: The Bell Operating
2
Companies (BOCs) serve as the network connection point for
subscribers. They maintain directories and connectivity
information, because they control the end-users' connections.
o Long-Distance Providers: AT&T and MCI are backbone services.
o PBX Installations: A subscriber may be a single telephone, or
a private telephone network. The private telephone network is
analogous to the LAN: it receives a bulk bill from the regional
BOC and it is responsible for maintaining its own records to
allocate costs back to its local users.
The potential billing models between a long-distance provider and a
middleman (BOC) provider in the phone company model illustrated some of
the issues.
Under the existing policy, the BOCs bill users for long-distance
services as a courtesy to the long- distance companies, who set the
rates. Two hypothetical models for implementing this service were
discussed.
The long-distance company provides per-call detail to the BOC. The BOC
maintains the accounting data and the association of usage data with its
end-users. The BOC generates the bill.
The BOC provides per-call "tags" to identify its end users to the
long-distance provider. The long- distance carrier maintains the
accounting data and the association of usage data with those tags. The
long- distance carrier generates the bills' contents. The BOC simply
forwards the bill to the user associated with its "tags".
Under a hypothetical policy, BOCs receive an aggregate bill for
long-distance services from the backbone provider. The BOC is treated
as a single billable entity by the long-distance service. In this case,
the BOC is solely responsible for maintaining the accounting data and
policies which allocate those costs to users. The BOC provides no
user-level information to the backbone provider, nor does the backbone
provider give detailed per-call accounting to the BOC. (Not
interactively, at least.)
DEFINE THE BILLABLE ENTITY FIRST. We are examining the nature of
traffic, interesting but too much for simple accounting purposes. Start
with the definition of the "billable entity" and build up to what you
need.
DON'T INCLUDE NETWORK DESIGN AND ANALYSIS DATA. Accounting needs very
precise data about certain kinds of traffic. Network design and
analysis needs different data, and frequently works with sampling
techniques inappropriate for accounting. Although much of the
accounting information may be useful for network design and analysis,
covering network design and analysis requirements will overburden the
scope of this group.
3
NEED TO KEEP THE ENTITY MATRIX SIMPLE. There are inherent limits in the
current situation. Routers can't handle keeping a matrix of counters
for every possible user-user combination. Some kind of hierarchical
billing is required. One division is for hosts to be billed in
aggregate by the network, and leave the hosts responsible for allocating
costs to users. However even host-host matrices can get very large. If
each datagram entering a router is on a different source- destination
pair, thrashing could be easily induced.
WATCH OUT FOR OVERHEAD. Accounting for every packet in a fine- grain way
could result in 100may have more than 50it can be appropriately
attributed to users. 50off point for feasibility.
DIFFERENT ALGORITHMS FOR LOCAL AND LONG-DISTANCE SERVICES: Note that the
phone company uses different algorithms for local and long distance
services. Long distance calls are handled with detailed call accounting
or aggregate counts (message units). Local calls are handled with
simple aggregate counts (message units) or flat fees regardless of
usage.
The lesson here is that where the cost of accounting is huge in
comparison with the cost of providing the basic service, many
subscribers prefer a policy which allocates usage as a flat fee. Some
subscribers, however, (message units), still want usage-based fees.
Phone companies provide a wide variety of such combinations of service.
WHAT ABOUT SPECIAL END-USERS? Suppose I am a long-distance carrier and I
want a particular research group to get a special rate. In the various
models how can I ensure that their traffic and only their traffic is
billed at the reduced rate? How do government clients get a bulk rate?
We need to consider the interaction between government and commercial
entities, e.g., what does GEC Marconi do when it wants to communicate
with NASA on commercial issues?
NEED A SET OF TEST QUESTIONS FOR PRELIMINARY VERIFICATION OF THE MODEL.
What is an accountable unit? Examples of questions that should be
answered are how to deal with rate periods (time-of-day), special
end-users, etc. Need many more questions.
ON FORMING A WORKING GROUP: We will see commercial services in the
Internet. This will require accounting. The IETF should get the
process set up first. Good value for traffic and capacity planning, as
well. Suggest we talk to people who are planning to offer commercial
Internet service (PSI, UUNET, Finnish PTT, SMDS) to see what kinds of
charging strategies they use. The RACE program, with Ira Richer, is
also working on accounting issues.
ATTENDEES
Cerf, Vinton vcerf@nri.reston.va.us
4
Crocker, Dave dcrocker@nsl.dec.com
Crocker, Steve crocker@tis.com
Fernandez, Louis lfernandez@bbn.com
Handspicker, Brian D. bd@vines.dec.com
Kirstein, Peter kirstein@cs.ucl.ac.uk
Lazear, Walter lazear@gateway.mitre.org
Little, Mike little@saic.com
Morris, Dennis morris@imo-uvax.dca.mil
Newkerk, Oscar newkerk@decwet.dec.com
Pace, Donald pace@fsu1.cc.fsu.edu
Saperia, Jon saperia%tcpjon@decwrl.dec.com
Su, Zaw-Sing zsu@tsca.istc.sri.com
Youssef, Mary mary@ibm.com
Yuan, Aileen aileen@gateway.mitre.org
5