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