Accounting Traffic in the Internet Today

[the full article can be seen at http://www.internetsociety.org/sites/default/files/BGP-for-regulators.pdf]

Business Model Changes

In the past, voice traffic was transported over a dedicated voice infrastructure, and the data network infrastructure was established in parallel so that voice and data traffic did not interfere with each other. Traditional voice accounting and performance functions are standardized within SS7 (Common Channel Signaling System No. 7), the global standard for telecommunications, defined by the ITU-T. The success of data networks led to the development of techniques to encapsulate voice traffic in IP packets, and thus Voice over IP (VoIP) was born.

Disrupted Charging Model

Many countries are concerned about the impact of services like Skype on their telephone-originated revenue. Telephone revenue is important for inward investment in telecommunications infrastructure and in some cases also serves to supplement general taxation income. Pricing agreements for domestic telephone calls are purely a national matter and are controlled by regulators. Pricing for international calls is subject to complex multi-party agreements, and charging is often asymmetrical with calls to one country from another costing more than calls in the opposite direction.

If one focuses on voice, the loss of traditional telephony revenues raises the question of detecting VoIP traffic and either charging extra for it or blocking it. Such charges or blocks might be imposed at national borders, and charges might be levied on the VoIP service provider or on the local user. But given that the fundamental communication paradigm has changed, that would seem to miss the point; why require complex new  measures to tax a slender proportion of the whole traffic flow when the fundamental and growing business is in Internet data communications as a whole?

IP Accounting in the Internet: NetFlow and IPFIX

In the late-1990’s, Cisco’s proprietary NetFlow protocol, which built on concepts developed at UCSD, became the de facto IP accounting standard throughout the industry. The basic output of NetFlow is a flow record exported from a device such as a router on which the NetFlow services are enabled. An exporter monitors packets entering a network interface, and creates flow records that describe the sessions that the packets are part of. These flow records are exported to a collector, which uses the information for network monitoring, capacity planning, security analysis, and, in some situations, billing.

IPFIX, which stands for “IP Flow Information eXport,” is an IETF effort to standardize an export protocol similar to NetFlow – specifically, a protocol that exports flow-related information. The IPFIX protocol specifications are largely based on the NetFlow version 9 export protocol. The IPFIX protocol, which is a flexible protocol based on templates, can choose from a long series of information elements for its export: either well-known ones, as registered by the Internet Assigned Numbers Authority (IANA), or enterprise-specific ones.

ITU-T Recommendation D.50 Supplement 1: General Considerations for Traffic Measurement and Options for International Internet Connectivity

A Supplement to ITU-T Recommendation D.50 on International Internet Connection recommends that administrations take appropriate measures nationally to ensure that parties (including operating agencies authorized by Member States) involved in the provision of international Internet connections negotiate and agree to bilateral commercial arrangements, or other arrangements as agreed between administrations, enabling direct international Internet connections that take into account the possible need for compensation between them for the value of elements such as traffic flow, number of routes, geographical coverage and cost of international transmission, and the possible application of network externalities, amongst others. For more information, look here.

In simple language, the message of D.50 Supplement 1 is that BGP could be used to deliver traffic statistics to report on the use of an application such as Skype. It is implied that using these mechanisms, if a Skype call crosses a specific country, that country could be identified and receive some revenue for this call (as would be enabled by SS7).

The subtext of D.50 Supplement 1 might be: “Make the ITU your Standards Development Organization (SDO) for the Internet, and we’ll restore your old telephone revenues.”

However, BGP doesn’t currently deliver traffic statistics; it is a routing protocol, not a measurement and accounting protocol. So, this model simply will not work, for the following reasons:

• BGP ASes are not countries
• Which traffic direction to bill?
• BGP traffic might be asymmetric
• Applications are hard to detect
• Hiding from DPI
• IPFIX and sampling
• Only the BGP routes will be accounted

What if We Could Really Make it Work?

The previous section provides a number of issues that make per-flow billing in the Internet hard or impossible, but let’s assume just for a minute, that we find solutions to all these problems: what would the Internet look like? If a country receives some money for traffic traversing its infrastructure, there will be an incentive to attract more traffic. The model breaks when each country wants to attract the traffic. Indeed, each country will advertise, with BGP announcements, that the rest of the world (any other BGP AS) is available via its own network. That is, instead of a shortest path paradigm for traffic routing, we will arrive at an Internet where traffic is routed through as many countries as possible! In the end, it will result in an unstable Internet, where the user quality of experience (QoE) will be bad if the content is not local.

So What is the Solution?

There is no magic solution to solve the issues of Internet access cost for developing countries. Certainly it is not advisable to try to solve a socio-economic problem with a simple change in technology.

However, small steps are possible. Recently, a new Internet Exchange Point (IXP) was launched in Kinshasa, Democratic Republic of the Congo. The Kinshasa IXP (KINIX) was funded through the Internet Society’s Community Grants Program and is managed by the Democratic Republic of Congo ISP Association (ISPA-DRC), as part of its DRC-IX project, which aims to establish IXPs in Kinshasa, Lubumbashi, and Goma. KINIX will serve as a catalyst for innovation and development of Internet services and applications in the Democratic Republic of Congo, and will support Government efforts to implement E-government services and lower the cost of developing local hosting and application development. The presence of KINIX will improve local Internet resilience by eliminating the dependence on international connectivity for local Internet services and Internet-based communications.

The Internet Society’s Africa Interconnection and Traffic Exchange program has been actively supporting the development of IXPs and regional interconnection in the region. The program aims to have 80% of Internet traffic exchanged in Africa by 2020, keeping local traffic local. This objective has been boosted by the appointment of the Internet Society to implement the African Union’s African Internet Exchange System (AXIS) program.

Maybe increased connectivity between ASes through IXPs will magnify the benefits of Internet connectivity, will attract more local online business, and provide a significant economic stimulus as larger percentages of the population are able to get on line. Perhaps these benefits will go some way to offset the lost revenues from the declining legacy telephone systems. What is the for sure is that using DPI to monitor and charge VoIP calls in the same old way…will simply not work!