CURRENT_MEETING_REPORT_
Reported by Cindy Mills/ BBN
Summary
This was the first meeting of the Internet Accounting Working Group. We
outlined a hierarchical architecture for accounting within routers and
discussed the types of meters to be used at each level.
Agenda
o Accounting Architecture
o Technical Reports
- Internet Accounting Model
- Liaison Activities (ANTF, OSI)
o Open Discussion
o Working Group Administration
- Review Charter & Minutes
- Identify and Assign Action Items
ACCOUNTING ARCHITECTURE
Due to performance constraints and the explosion in complexity, we
believe that it is not practical to perform detailed accounting to the
user-id level within all networks. [Ed. The reasons should be
documented in the Meter Services Document.]
Therefore we identified 4 levels of accounting interest/architecture:
Backbones/National ---------------------------
/ \
Regional ------------ --------------
/ \ \ / / \
Stub/Enterprise --- --- --- --- ---
Host
Note that mesh architectures can also be built out of these components.
Each network performs accounting functions for its immediate subscribers
/ connections. Subscribers come in two flavors - subscriber networks
and subscriber hosts (end-users from the networking perspective).
We define backbone networks as bulk carriers that have only other
networks as subscribers. Individual hosts are not directly connected to
a backbone.
1
Backbones and regionals are closely related, and differ only in size,
the number of networks connected via each port, and ``geographical''
coverage. Smaller Regionals may also have a few directly connected
hosts, acting as hybrid regional/stub networks. We consider a regional
network as a subscriber network to the backbone.
Stub networks have hosts as direct connects, although they may be
combined by Enterprise networks treated in the same fashion as stub
networks. For the stub/enterprise network provider, hosts are the
end-users, the accountable entities. For the stub/enterprise network
provider, host addresses are the finest-granularity accountable entities
available at the IP level.
Hosts are ultimately responsible for identifying the end user. This
information may be shared with the network, but it is the host's
responsibility to do so. Host accounting is not discussed in detail,
since homogeneous Internet Accounting is most practical at the network
provider level, and should be performed within the network routers under
the control of the network provider. (After all, the host is the
customer, and if I were selling network services. I'm not sure I'd rely
on the customer to tell me how much he owes without having a mechanism
to keep the customer honest...) In addition, implementing accounting in
the routers spares us from requiring that each host variation (various
hardware platforms and operating system versions) retrofit TCP/IP
implementations to include accounting as a condition for being attached
to a network which relies on accounting information.
ENTITIES: Each of the higher-level network (backbone and regional)
account for two sets of entities - one set corresponds to the network's
immediate subscribers and a parallel set (optional?) covers the
subscribers of the network below. This two-tiered system enables:
o verification between provider and subscriber
o reconstruction of accounting information around a single transit
network which does not perform accounting functions.
Backbone Level Entities: Adjacent Network (Port),Source/Dest Net Number
Regional Level Entities: Src/Dest Network Number,Src/Dest Host Adr
Stub Level Entities: Source/Dest Host Address
(End-user ID pair optional)
Host Level Entities: Operating System dependent.Use OS accounting.
This allocation of accountable entities to network levels bears further
examination. Particularly, it is important to understand what
complexity is accounting introduces at each network level.
Backbone Level Complexity: Collects by port ID, and can further
subdivide by network numbers from the IP address.
2
Regional Level Complexity: Collects by host address pair only, since
network numbers can be derived from the host traffic matrix off-line.
Stub Complexity: Collect host address pair in any case. Approaches:
1. Leave all else up to the local stub network and proprietary means
if further information is required.
2. Define IP option containing accounting information.
3. Piggyback on the policy-based routing option and recommend how to
use it.
Note on including destination addresses in the entity identifier:
Maintaining a traffic matrix at all levels seems to be a fair amount of
overhead, but destination information is required so often that it seems
reasonable to include it. This way policy arrangements about who is
billed for communicating pairs can be independent of the originator of
the traffic.
SUB-ENTITIES: If we are aggregating information, the counts attributed
to a single entity may need sub-categories. Suggested sub-categories
are:
o protocol type
o quality of service
o types of counts
TYPES OF COUNTS: All networks count both packets and bytes for the
accountable entities.
TIME-OF-DAY: We need to be able to register start and stop times of
flows. These trigger times should automatically start new aggregations
for the affected aggregate meters (i.e. cause meters to send their data
along with the start and end times, and restart the meter at 0.).
QUALITY OF SERVICE: Unresolved. What quality of service items should we
be able to specify? QOS distinctions come in many forms. For services
such as throughput, reliability, and delay there is a question of how
detailed the information should be about:
o what level of service was requested
o what level of service was offered (negotiated)
o what level of service was actually provided (considering outages,
etc.)
Technical Reports
1. INTERNET ACCOUNTING MODEL
See attached slides
2. LIASON ACTIVITIES
The ANSI Accounting WG has OSI Accounting Drafts available.
3
Report on April Autonomous Network Task Force (ANTF) Meeting on
Internet Billing:
o Billing Models discussed:
- Fixed Fee
- Usage Sensitive Billing
- Quality of Service Sensitive Billing
- Quotas
- Subsidy Issues
- Campus/Stub AD aggregate vs. end-user feedback
o Issues raised:
- high speed counting
- fraud
- credit limits
- cooperation between stub and backbone networks
- how heterogeneous can the models be?
- interaction with congestion control, access control, routing
o Liaison Activities
- IETF Internet Accounting
- SMDS Accounting
- OSI Accounting
o Suggested Experiments
- Flow-based instrumentation (use this to identify and play
with flows)
- Resource reservation (We should suggest ST-2 or MacHip, a
St. Louis sponsored entry)
- Instrument applications to provide feedback window (have a
window with a * amount to meter applications)
3. OPEN DISCUSSION
END-USER FEEDBACK - Can end-users influence policy? How about the
ability to provide accounting feedback mechanisms to network users
real-time as they use it, what that might look like and so forth?
[Ed. This is somewhat orthogonal to the group charter at the
application level, but was an interesting discussion worth keeping
in mind.]
POLICY-BASED ROUTING - Their relation to us is in their use of the
IP header's options field. We might put in a Kerberos-style
identifier that associates a particular machine/user/virtual
circuit with a unique token. This scheme might work between
adjacent networks to track FLOWS though them, but would be
difficult (!!!) to pull off on an internet-wide basis. Some one
or two of us should attend the policy-based routing sessions
regularly since they're working on similar problems. Negotiating
quality of service is in the province of policy-based routing?
GRANULARITY OF DISTINGUISHABLE ENTITY - Two positions were
discussed:
(a) IP-based accounting with only existing IP header information is
sufficient.
(b) One should try to accommodate users and perform accounting by
the user-id where it is feasible.
IDEAS ON IDENTIFYING THE END-USER TO THE ACCOUNTING MECHANISM
(a) PARSING TCP and APPLICATION LAYER PROTOCOLS FOR USER
4
INFORMATION? What about parsing more than the IP header?
Considered untenable in a router. Even if we dismiss the
violation of protocol layering as "purist", we still must
contend with higher processing overhead. Hosts would still
need to be modified to ensure that the user information is
present. But passive "watchers" like scopes could be employed
on LANs.
(b) MODIFY THE IP HEADER TO ADD ACCOUNTING INFORMATION? We don't
believe it'll get implemented by all existing hosts. (i.e.
practically impossible).
(c) USE IP OPTIONS? Router perspective: putting user-based
accounting stuff in a router is too much processing overhead.
Counter-Example: Tymnet billing is on a per-user id.
Compromise: At a minimum, an IP packet that has user-level
accounting information might be afforded a lower priority in
the router's processing queue.
(d) VANISHING OPTIONS? Vollbrecht points out that router-to-router
accounting and ES - IS accounting are separable problems. This
led to a discussion of how to leave the user-id option in for
the stub network's use and strip it from the header when
sending the packet to the regional to reduce regional overhead.
Still a performance issue, and what about the checksum? This
should be investigated more thoroughly.
SERVERS - How does one account for mail that explodes at a list
server? Is it the responsibility of the host, the list, or the
person who sends to the server?
OSI ACCOUNTING - Since they're not defining meters yet, we will
probably influence the OSI standard with our choices.
ADMINISTRATIVE DETAILS
(a) REVIEW OF CHARTER
o Examine existing and hypothetical policies to understand
what set of information is required to satisfy usage
reporting requirements.
o Define specifications of accounting meters, local storage
requirements, and aggregation granularities.
o Recommend a data collection protocol and representations for
processingby accounting applications.
o Develop test scenarios to verify model.
o Guess we have to recommend mechanisms for formulating
policy, though we don't want to sink in the policy swamp.
Also need to consider implementation issues since they are
practical and affect the ``reasonableness'' of
recommendations.
(b) Internet Accounting Action Items
Can we live with the proposed schedule? Sure.
The following areas should be addressed in preparation for the
August 1990 IETF meeting except where otherwise noted.
5
o Outline of Meter Service Document => C.Mills
o Architecture Discussion => Mailing List
- Levels of Metering (Do we have the right model?)
- Define Meters
* Entities (Done. Review only.)
* Quantities (Done. Review only.)
* Time of Day (Further development.)
* Quality of Service (How to approach this?)
o Liaison Activities
- ANTF => Z.Su
- OSI Accounting => B.Handspicker, M.Seger
- SMDS => Z.Su
o Explanation of Concepts (writeups due to mailing list)
- R.Reschly suggested that accounting on a backbone is the
integral of bandwidth utilization and that proportional
utilization rather than absolute measure is a useful
measure.
- J.Galvin proposed to write up some of the discussion.
- M.Roselinsky will expand upon the user-id/cookie for the
IP options field.
- C.Mills will summarize the applicability of policy-based
to accounting.
- D.Hirsh will summarize current policy/practice in the
internet community (eg digest the FARnet study,
summarize BBN/SRI activity, etc.) in light of the
proposal for meters. (First step towards test
scenarios.)
o Unassigned Tasks (may be deferred) => Mailing List
- Define Accounting Log Formats
* Local Storage Requirements
* Compatibility with Existing Protocols
- Develop Testbed/Prototypes
6
ATTENDEES
Peblo Brenner sparte!pbrenner@uunet
Martina Chan mchan@mot.com
James Galvin galvin@tis.com
Don Hirsh hirsh@magic.meridiantc.com
Keith McCloghrie sytek!kzm@hplabs.hp.com
Robert Reschly reschly@brl.mil
Milt Roselinsky cmcvax!milt@hvb.vcsb.edu
Mark Seger seger@mjs1.ogo.dec.com
Brad Strand bstrand@cray.com
Zaw-Sing Su zsu@tsca.istc.sri.com
John Vollbrecht jrv@merit.edu
7