next up previous contents
Next: Scaling Internet Technologies to Up: The Need for Traffic Previous: Planning of Infrastructural Development

Traffic Measurement and Accounting

The commercialization of the Internet has not only resulted in an increase of the number of users. Probably the most important problem that arises is the accounting of the transferred data. Traditionally, the Internet was a network between research and educational institutions. The connected institutions usually payed a fixed fee for their connection. Nowadays, Internet providers would like to charge their clients depending on the volume of data they transfer. To do this, they need powerful tools that are able to count the transferred amount of data. The higher the line speeds are, the more difficult this is.

It is still a very common practice for providers to charge fixed monthly fees for Internet access. Very often the only reason for this is that they have no means to do an exact accounting for all clients.

Traditional solutions for volume based traffic charging include:

Reading the SNMP Octet Counters from the Routers
Most if not all modern networking equipment offers the possibility to gather statistics about the amount of data that was transferred via its interfaces. For this purposes, usually counters for bytes and/or packets that are transferred over each interface are provided. These counters can be queried using the SNMP procotol.
The disadvantage of this is that only the total amount of traffic transferred can be accounted. It is not possible to apply different prices depending on the kind of traffic. Additionally, since the SNMP counters are only maintained once for each hardware port, a separate port is necessary for each client that is to be accounted. These additional expenses for hardware make this solution very unattractive.
Using RMON / RMON2 probes
The RMON standard, which is described in RFC1757 [40], was designed to provide proactive monitoring and diagnostics for distributed LAN-based networks. Special monitoring devices, called agents or probes, allow the monitoring of critical network segments and to set off user-defined alarms. RMON has been implemented in special stand-alone hardware, embedded in switches and as a program running on a PC or workstation. Communication with the probes is implemented using the SNMP protocol.
In theory, the RMON standard would be suitable for higher line speeds. It has however shown that it is difficult to adapt RMON to protocols like 100VG-AnyLan or ATM. No RMON implementations for those protocols are available at this time. For ATM, a first attempt was AMON (ATM Circuit Steering MIB), which defines a way to copy traffic from a virtual circuit (VC) to a location where an external probe can decode it. AMON - which was proposed by Fore - has been discussed in the ATM Forum since summer 1995. However, progress has been so slow that the forum threatened to suspend the AMON MIB group's work. In march 1996 Cisco -- although one of the founder members of the ATM Forum -- has surprised the networking community by submitting a draft for an ``ATM RMON MIB'' to the IETF rather than to the ATM Forum. Cisco has developed the ATM RMON MIB without discussing it with other manufacturers of ATM hardware. This unusual way of presenting their proposal has been the reason for controversial discussions. It is therefore not very likely that their proposal will become a standard in the near future.
Using a PC or Workstation running tcpdump
The tcpdump tool mentioned above can be used to monitor all traffic that passes through a network adapter in a PC or workstation. Using it permits as well to count the data that is received by this network adapter. However as mentioned above the interrupt load using tcpdump is a problem when the data is being received at higher line speeds. When the load is getting too high, the probability for packet losses is growing. This technique is used at a local Internet provider in Stuttgart[*], and it was found that even on transfer rates of about 10 Mbit/s (standard ethernet) there is already a probability for packet loss in the range of 1%. Obviously this solution is only practicable for lower line speeds. It nevertheless offers maximum flexibility since a user-written program can be used to analyze a trace of all the headers from the packets the machine receives.

next up previous contents
Next: Scaling Internet Technologies to Up: The Need for Traffic Previous: Planning of Infrastructural Development