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