Congestion Exposure Problem Statement

In recent years, network operators around the world have begun to feel the affects of "high-consuming users" -- those who use the maximum amount of bandwidth possible, usually for the purpose of peer-to-peer file sharing. In 2006 K. Cho et al. reported that for residential Japanese broadband connections, "a small number of users dictate the overall behavior; 4% of high-consuming users account for 75% of the inbound volume, and the fiber users account for 86% of the inbound volume." A more recent paper published December 2008, see , confirms that the distribution has not changed much. User-to-user traffic comprised 63% of overall residential traffic volume. The authors noted not only a changing traffic distribution, but also a substantial increase in overall traffic growth (37% per year). Operators in other countries have experienced similar shifts. This trend does not necessarily present a problem on its face, as increased traffic volumes do not automatically lead to congestion. However, in some cases where operators were not expecting these changes in growth rates and traffic consumption, their pricing models and congestion management architectures have proved inadequate. In some countries, fierce competition among Internet access providers has yielded low profit margins. This has increased the pressure on operators to find effective ways to deal with high- consuming users who cost them more money than the bulk of their subscribers. Furthermore, some broadband networks (such as cable networks) may not have the ideal characteristics (routing topology, for example) to support high volumes of user-to-user traffic. Congestion and cost are closely related. As stated in RFC 5594 , "... congestion can be viewed merely as a manifestation of cost. An ISP that invests in capacity could be considered to be paying to relieve congestion. Or, if subscribers are charged for congesting the network, then cost and congestion could be viewed as one and the same. The distinction between them may thus be artificial.". The upshot for network operators is: those who produce a lot of traffic cost a lot. Operators are now facing a range of options for addressing this problem. There are many factors to consider for each kind of solution, including how the solution performs, its cost, what the public relations impact of using a particular solution might be, and what legal framework exists to support the use of a particular solution. The performance considerations must take into account the balance between device performance and forwarding performance (since many of the solution mechanisms slow down forwarding performance), and this determination is intimiately related to measuring a solution's overall cost. In some cases, the popularity of flat-rate pricing plans exacerbate the congestion problem because an individual's bandwidth usage is not tied to his or her monthly bill, creating an incentive to use as much bandwidth as possible and leaving operators to cover the costs of all their users with essentially equal payments from each. Operators know that users appreciate the certainty of having the bill amount remain the same for each billing period, allowing users to plan their costs accordingly. But while flat-rate pricing avoids billing uncertainty, it creates performance uncertainty: users cannot be sure that the performance of their connections is not being altered or degrated based on how the network operator manages congestion. Unfortunately, most of the solutions described below create some performance uncertainty, and thus users are unlikely to view them as ideal solutions, despite users' well known preference for flat-rate pricing.

Two means of learning about the resource consumption and the traffic traveling through the network that are in use today are accounting and deep packet inspection.

RFC 2975 describes accounting as "The collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing.". Over the years the number of information elements that can be sent from an accounting client to an accounting server using standardized protocols, such as RADIUS (see and ) and Diameter , has increased. The existence of standardized protocols has allowed different AAA networks to interconnect. These protocols are now used in almost every enterprise and operator network. The initial accounting mechanisms envisioned a rather non-real time nature in reporting resource consumption but with mechanisms like like Diameter Credit Control allowed real-time credit control checks. Although they are popular, RADIUS and Diameter are not the only protocols that can be used to collect usage information and to trigger responses. Other approaches, as documented in , lead to similar results.

Deep packet inspection (DPI) refers to the observation and analysis of traffic that passes through operator networks up to the application layer. This allows operators to determine the applications and/or application-layer protocols that subscribers are using and respond on a per-application or per-protocol basis. The process of inspecting traffic, particularly in real time, can be highly performance-intensive. DPI equipment may also require continous software updates to ensure that the detection engine recognizes the latest protocol variants. There may be a number of other factors that contribute to a network operator's decision to use DPI, including potential user backlash, privacy impact, and legal concerns. Depending on the configuration of the device doing the inspection, packet dropping/blocking and other usages might be applied. For example, content sharing p2p applications maintain many simultaneous TCP connections with other nodes for the purpose of simultaneous downloads. An operator may, for example, limit . Certain end user contracts may also allow operators to ban servers from residential access.

Once they have collected congestion information using either of the techniques described above or others, network operators have a number of options for how to respond. For all of these options, it is up to the operator to decide the breadth and depth of its response: which users will be affected, the time frame in which congestion will be managed, whether specific applications or protocols will be targeted, and so forth. Operators can chose from both technical and pricing/contract-based options. Technical options include: End user contracts often provide users with a certain threshold for baseline usage volume (which is typically quite high). Subsequently, if consumption goes beyond the threshold, all of the user's traffic is given reduced priority vis a vis other users on the network. Some operators may only shape traffic during times of congestion or peak usage periods (even if a user has exceeded his or her baseline threshold). Network operators that can identify particular applications or protocols creating congestion may decide to throttle only those applications or protocols. They may also take indirect steps that result in the shaping of only certain applications, such as limiting the number of simultaneous TCP connection setups from a single subscriber (to handle peer-to-peer traffic), or preventing users from hosting servers on residential connections. An example of an ISP's fair usage policy describing how it manages specific protocols is included in Appendix A. In this technique users are classified into a set of classes depending on their past behavior. Subsequently, their traffic is treated according to their associated classes. This may prevent lightweight users from feeling the effects of sharing network capacity with heavy users. This mechanism requires some form of packet marking to be able to differentiate light users from heavy users. Network operators may charge users differently for traffic that exeeds a certain threshold compared to the traffic that falls below the threshold. In some rare cases ISPs may decide to suspend or terminate the contracts of heavy users. In some cases this response may be associated with a security issue; when an operator recognizes a botnet-infected machine generating excessive traffic, it may hotline all the traffic of that particular machine to a separate network, and ultimately suspend or terminate the machine's connection. In some cases the same technique has been applied to users engaged in heavy P2P usage, either intentionally or due to a false alarm caused by a statistical traffic analysis.

Following the IETF Workshop on Peer-to-Peer (P2P) Infrastructure in 2008 (see ), two working groups and one research group were created that relate to the congestion issues created by peer-to-peer application usage: : LEDBAT (Low Extra Delay Background Transport) is designed to keep the latency across a congested bottleneck low even as it is saturated. This allows applications that send large amounts of data, particularly upstream on home connections (such as peer-to-peer applications) to operate without destroying the user experience in interactive applications. LEDBAT holds substantial promise should P2P clients adopt it widely. This solution has been focused on P2P applications, and its applicability to other applications, such as video using H.264, is unclear. ALTO (Application-Layer Traffic Optimization) aims to design and specify mechanisms that will provide applications, typically P2P applications, with information to perform better- than-random initial peer selection to increase their performance and at the same time to avoid excessive cross-domain traffic that tends to be more expensive for the operator. ALTO services may take different approaches at balancing factors such as maximum bandwidth, minimum cross-domain traffic, or lowest cost to the user, but in all cases the goal is to expose information that can ameliorate the interactions between peer-to-peer usage and other usages of shared networks. Peer to Peer Research Group aims to provide a discussion forum for resarchers related to all sorts of challenges presented by P2P systems in general, such as P2P streaming, interconnecting distinct P2P application overlays, security and privacy. Current work on exposing myths about peer-to-peer filesharing provides a number of references to support some of the claimed benefits of ALTO solutions mechanisms, such as the expected decrease in cross- domain traffic.

High-consuming users are a reality. Operators that would like to counteract the impact of heavy users on their networks have a fair number of tools at their disposal. These tools may allow operators to identify heavy users, collect performance and usage indications, and choose from a variety of mitigating steps depending on the operator's preferred business practices. Subscriber-specific information, including policies, resource consumption information, and details about the current network attachment point, may be available in accounting servers. Information about the network topology and the state of particular topology elements may be available in the network management infrastructure. Solution approaches similar to have demonstrated one way of taking congestion information into consideration. The currently available mechanisms for identifying and mitigating congestion largely run wholly within an operator's network and without a lot of information exchange about congestion information to or from end hosts or other network operators. Exposing this information may allow end devices to make more informed decisions (although policy enforcement would still be required by the operator). The collection of congestion information poses the challenge of deciding where in the network to put the metering agents to ensure that enough information is collected at the right point in time. Distributed collection and the correlation of the information across different nodes is a complex task. An approach that collects this congestion information along the path of the data packet (via inband signaling) would simplify this task. Regardless of the technical solution utilized for collecting information, certain users will undoubtedly observe the effects of decisions that operators make about how to handle congestion. Allowing users to understand these decisions will be crucial and having a channel to send feedback to the end device and/or subscriber would be a helpful step towards increased transparency.

This document highlights approaches for dealing with high-consuming network users and all of them raise security and privacy concerns. It does not introduce new mechanisms. The security considerations for the existing mechanisms mentioned apply.

This document does not require actions by IANA.

The authors would like to thank Alan DeKok, Jens-Peter Haack, Alexander Bachmutsky, Jonne Soininen, Joachim Charzinski, Hannu Flinck, Joachim Kroß, Jouni Korhonen, Mayutan Arumaithurai, Richard Woundy, Daniel Correa Lobato, Luca Caviglione, Tommy Lindgren, Lars Eggert, for their time to discuss the topic. Additionally, we would like to thank Marcin Matuszewski for his help with the P2P infrastructure workshop paper (since it was used as a starting point for the work on this memo).