< draft-tschofenig-conex-ps-00.txt   draft-tschofenig-conex-ps-01.txt >
CONEX H. Tschofenig CONEX H. Tschofenig
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Informational A. Cooper Intended status: Informational A. Cooper
Expires: April 22, 2010 Center for Democracy & Expires: April 29, 2010 Center for Democracy &
Technology Technology
October 19, 2009 October 26, 2009
Congestion Exposure Problem Statement Congestion Exposure Problem Statement
draft-tschofenig-conex-ps-00.txt draft-tschofenig-conex-ps-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
The availability of broadband connections together with flat-rate The increasingly ubiquitous availability of broadband, together with
pricing has made new types of peer-to-peer applications possible. flat-rate pricing, have made the use of new kinds of peer-to-peer
From an Internet evolution and end user value point of view this is applications increasingly common. From the perspective of the
very exciting. As a consequence, an increase of user-to-user traffic Internet's evolution and its contributions to end user value, this is
was observable all around the world over the last few years. With very exciting. However, the uptick in peer-to-peer application usage
the usage of p2p systems the observation can be made that a certain has also contributed to the rise of "high-consuming users" who take
group of users, called high-consuming users, decided to use their their flat-rate contracts to the limit by continuously file-sharing
flat-rate contract excessively. This in turn seems to have caused to the maximum extent possible. Network operators have responded to
network operators to take actions. this phenomenon in a number of different fashions.
This document illustrates a couple of techniques used by operators This document discusses the problems created for operators by high-
today to deal with excessive bandwidth usage. More information can consuming users and illustrates a number of techniques operators are
improve the decision making process. currently using to cope with high bandwidth usage.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. State-of-the-Art Building Blocks . . . . . . . . . . . . . . . 5 2. State-of-the-Art Building Blocks . . . . . . . . . . . . . . . 5
2.1. Means of Identifying the Causes of Congestion . . . . . . 5 2.1. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Potential Actions Operators might take in Response . . . . 6 2.2. Deep Packet Inspection . . . . . . . . . . . . . . . . . . 5
3. New Activities . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Network Operator Responses to Congestion . . . . . . . . . . . 7
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. New Activities . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
Appendix A. Example Policy Statement . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
A.1. Fair Usage Policy . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Example Policy Statement . . . . . . . . . . . . . . 16
A.1.1. What is the Fair Usage Policy? . . . . . . . . . . . . 15 A.1. Fair Usage Policy . . . . . . . . . . . . . . . . . . . . 16
A.1.2. How do I know I'm a very heavy user? . . . . . . . . . 15 A.1.1. What is the Fair Usage Policy? . . . . . . . . . . . . 16
A.1.2. How do I know I'm a very heavy user? . . . . . . . . . 16
A.1.3. I have Contract Option 3, does the Fair Usage A.1.3. I have Contract Option 3, does the Fair Usage
Policy apply to me? . . . . . . . . . . . . . . . . . 15 Policy apply to me? . . . . . . . . . . . . . . . . . 16
A.1.4. Peer to Peer (P2P) . . . . . . . . . . . . . . . . . . 15 A.1.4. Peer to Peer (P2P) . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
In 2006 K. Cho et al. [traffic] published a paper about the growth of In recent years, network operators around the world have begun to
residential user-to-user traffic in Japan that indicates '... a small feel the affects of "high-consuming users" -- those who use the
number of users dictate the overall behavior; 4 % of high-consuming maximum amount of bandwidth possible, usually for the purpose of
users account for 75 % of the inbound volume, and the fiber users peer-to-peer file sharing. In 2006 K. Cho et al. [traffic] reported
account for 86 % of the inbound volume.'. The same paper also that for residential Japanese broadband connections, "a small number
indicates a substantial increase in traffic growth, namely 37 % per of users dictate the overall behavior; 4% of high-consuming users
year according, and not just a different distribution of traffic account for 75% of the inbound volume, and the fiber users account
among the users. At that time 63 % of the residential traffic volume for 86% of the inbound volume." A more recent paper published
is contributed by user-to-user traffic. December 2008, see [traffic2], confirms that the distribution has not
changed much. User-to-user traffic comprised 63% of overall
These numbers itself do not represent a problem as by themself and do residential traffic volume. The authors noted not only a changing
not necessarily lead to congestion. However, some operators very traffic distribution, but also a substantial increase in overall
likely had different expectations about the growth rates and traffic traffic growth (37% per year). Operators in other countries have
consumption of individual users and statistics (used for their experienced similar shifts.
pricing models) did not work out too well for them. The profit
margins for Internet access are quite slim due to fierce competition.
This puts a lot of pressure on operators to deal with these high-
consuming users who cost them a lot of money. Finally, some
broadband networks may not have the ideal characteristics (such as
the topology for routing traffic) for user-to-user traffic (e.g.,
Cable Networks).
Congestion is often mentioned in this context and as stated in RFC
5594 [RFC5594] "... 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.".
To summarize in a simplistic way, those who produce a lot of traffic
cost a lot.
Operators are now facing a range of options, see sections below, that
can be taken and there is a tradeoff between what is allowed (legally
and from a public relation point of view) and what is useful from a
performance point of view. The latter aspect can be seen from the
point of view of a device performance (as many of the mechanisms
actually slow down the forwarding performance quite a bit) and
consequently a cost challenge.
The existence of flat rate pricing contributes to some of the
problems since the bandwidth usage in total needs to be covered by
the money obtained from broadband customers but the usage of
individual users is not reflected in the amount. As such, users that
rarely utilize the network pay the same amount as someone who uses
P2p filesharing excessively.
However, from a psychological point of view humans tend to strive to This trend does not necessarily present a problem on its face, as
avoid uncertainty and hence offerings that reduced uncertainty. For increased traffic volumes do not automatically lead to congestion.
a user there are essentially two aspects to worry about 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.
o Uncertainty in the bill: unpredicable costs that make planning Congestion and cost are closely related. As stated in RFC 5594
difficult. [RFC5594], "... 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.
o Uncertainty in the performance: performance degradation as part of Operators are now facing a range of options for addressing this
the actions being taken 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.
True flat rate pricing avoids uncertainty in the bill. In some cases, the popularity of flat-rate pricing plans exacerbate
Unfortunately, most of the solutions described below lead to some the congestion problem because an individual's bandwidth usage is not
uncertainty and thereby increase unhappyness of customers. 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.
2. State-of-the-Art Building Blocks 2. State-of-the-Art Building Blocks
2.1. Means of Identifying the Causes of Congestion 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.
2.1. Accounting
RFC 2975 [RFC2975] describes accounting as "The collection of RFC 2975 [RFC2975] describes accounting as "The collection of
resource consumption data for the purposes of capacity and trend resource consumption data for the purposes of capacity and trend
analysis, cost allocation, auditing, and billing.". analysis, cost allocation, auditing, and billing.".
Over the years the number of information elements that can be sent Over the years the number of information elements that can be sent
from an accounting client to an accounting server using standardized from an accounting client to an accounting server using standardized
protocols, such as RADIUS (see [RFC2866] and [RFC2865]) and Diameter protocols, such as RADIUS (see [RFC2866] and [RFC2865]) and Diameter
[RFC3588], has increased. The fact that standardized protocols have [RFC3588], has increased. The existence of standardized protocols
been available allowed different AAA networks to be interconnected has allowed different AAA networks to interconnect. These protocols
and their usage can be found in almost every enterprise and operator are now used in almost every enterprise and operator network. The
network. The initial accounting mechanisms envisioned a rather non- initial accounting mechanisms envisioned a rather non-real time
real time nature in reporting resource consumption but with nature in reporting resource consumption but with mechanisms like
mechanisms like like Diameter Credit Control [RFC4006] allowed real- like Diameter Credit Control [RFC4006] allowed real-time credit
time credit control checks. control checks.
It has to be noted that RADIUS and Diameter are not the only Although they are popular, RADIUS and Diameter are not the only
protocols that can be used to collect usage information and to protocols that can be used to collect usage information and to
trigger certain actions, even they are fairly popular. Other trigger responses. Other approaches, as documented in
approaches, as documented in [I-D.livingood-woundy-congestion-mgmt], [I-D.livingood-woundy-congestion-mgmt], lead to similar results.
lead to similar results.
Deep packet inspection refers to inspecting traffic that passes 2.2. Deep Packet Inspection
through the operators networks up to the application layer.
Depending on the configuration of the device traffic shaping, packet Deep packet inspection (DPI) refers to the observation and analysis
dropping/blocking and other usages might be applied. For example, of traffic that passes through operator networks up to the
content sharing p2p applications maintain many simultaneous TCP application layer. This allows operators to determine the
connections with other nodes for the purpose of simultaneous applications and/or application-layer protocols that subscribers are
downloads. An operator may, for example, limit the number of using and respond on a per-application or per-protocol basis.
connection setups from a single subscriber. Certain end user
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 contracts may also allow operators to ban servers from residential
access. access.
Determining the type of application that a subscriber is running was 3. Network Operator Responses to Congestion
seen as necessary to throttle only certain applications, instead of
impacting the full range of traffic a subscriber is using. A side-
effect is the additional investment for the device and operational
costs. The process of inspecting traffic is performance intensive
and continous software updates are necessary to ensure that the
detection engine recognizes the latest protocol variants.
Additionally, the attempt to selectively deal with applications (even
though these applications might be the reason for the high traffic
volume) has not been received well by the users.
2.2. Potential Actions Operators might take in Response 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:
What actions are taken based on the collected information and in what Wholistic traffic shaping:
time frame is largely left to the choice of those who run the
infrastructure. In the context of this discussion the collected
information may be used to charge the user per volume, per time and
in various different combinations. Additionally, the RADIUS and
Diameter allow the server side with a server-initiated message (see
Change of Authorization in [RFC3576], and the functionality provided
in the Diameter Base specification [RFC3588]) to push decisions to
the AAA clients, typically edge nodes, acting as enforcement nodes.
These decisions include actions like shaping or packet marking.
Shaping: End user contracts often offer a combination of 'flat-rate' End user contracts often provide users with a certain threshold
scheme whereby a fixed price tariff is used up to a certain usage for baseline usage volume (which is typically quite high).
volume (typically quite high for regular usage). Subsequently, if Subsequently, if consumption goes beyond the threshold, all of the
the consumption goes beyond a certain threshold then the entire user's traffic is given reduced priority vis a vis other users on
traffic is given lower priority and potentially shaped. 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).
In many countries operators have to offer a clear description Per-application or per-protocol shaping:
of the service they offer and since the term 'flat-rate' is
already associated with a certain meaning the term 'Unlimited
Data Rate' is often used for this type of service. Contracts
typically contain statements that allow certain actions to be
taken. An example of such a fair use statement can be found in
Appendix A.
Note that traffic shaping is often only applied to high-consuming Network operators that can identify particular applications or
users (since they are known based on the accounting procedures) or protocols creating congestion may decide to throttle only those
the effect becomes only visible during peak hours when the network applications or protocols. They may also take indirect steps that
fills up. 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.
Class-Based Assignment: In this technique users are classified into Class-Based Assignment:
a set of classes depending on their past behavior. Subsequently,
the traffic is treated according to the associated class. It is
ensured that the traffic of lightweight users, users that really
rarely use their Internet connection, cannot be pushed away by
heavy users. This mechanism again requires some form of DiffServ
marking to be in place.
Charging for Excessive Traffic: As a possible action a user might In this technique users are classified into a set of classes
get charged differently for traffic that exeeds a certain depending on their past behavior. Subsequently, their traffic is
threshold compared to the traffic that falls within the agreed treated according to their associated classes. This may prevent
limits. 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.
Discontinuing Contracts: In some rare cases ISP also decided to cut Pricing/contract-based options include:
connectivity under certain condition. In fact this might be
justified in certain cases. For example, in case of new botnets
malware distribution when the operator recognizes an infected
machine and hotlines the entire traffic of that particular machine
to a separate network and, like in WLAN hotspots, HTTP traffic is
intercepted to display further information. In some cases the
same technique has been applied with excessive usage of P2P
traffic, either intentionally or due to a false alarm caused by a
statistical traffic analysis technique.
In France the HADOPI law adopted in parliament that allowed an Charging for Excessive Traffic: Network operators may charge
'independent authority' to punish copyright violators with a users differently for traffic that exeeds a certain threshold
temporary suspension of their Internet access has raised compared to the traffic that falls below the threshold.
discussions within Europe about the fundamental right to
'communicate and express' and its applicability to the Internet
access. Although this discussion is still ongoing the French
Supreme Court had striked down portions of the law arguing that
any restriction of such a right can only be decided by a judge.
3. New Activities Suspending or Discontinuing Contracts: 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.
In response to the P2P infrastructure workshop in 2008 (with a 4. New Activities
summary documented [RFC5594]) two working groups and one research
group has been created that focus on a certain area of the Following the IETF Workshop on Peer-to-Peer (P2P) Infrastructure in
application space: 2008 (see [RFC5594]), 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) [ledbat] is designed LEDBAT (Low Extra Delay Background Transport) [ledbat] is designed
to allow to keep the latency across the congested bottleneck low to keep the latency across a congested bottleneck low even as it
even as it is saturated. This allows applications that send large is saturated. This allows applications that send large amounts of
amounts of data, particularly upstream on home connections, such data, particularly upstream on home connections (such as peer-to-
as peer-to-peer application, to operate without destroying the peer applications) to operate without destroying the user
user experience in interactive applications. experience in interactive applications.
LEDBAT is a promising approach when applied widely in P2P clients. LEDBAT holds substantial promise should P2P clients adopt it
This solution has been focused P2P applications, and its widely. This solution has been focused on P2P applications, and
applicability to other applications, such as video using H.264, is its applicability to other applications, such as video using
unclear. H.264, is unclear.
ALTO (Application-Layer Traffic Optimization) [alto] aims to ALTO (Application-Layer Traffic Optimization) [alto] aims to
design and specify mechanisms that will provide applications, design and specify mechanisms that will provide applications,
typically P2P applications, with information to perform better- typically P2P applications, with information to perform better-
than-random initial peer selection to increase their performance than-random initial peer selection to increase their performance
and at the same time to avoid excessive cross-domain traffic that and at the same time to avoid excessive cross-domain traffic that
tends to be more expensive for the operator. For legal content tends to be more expensive for the operator. ALTO services may
ALTO mechanisms with the ability for ISPs to deploy proxies appear take different approaches at balancing factors such as maximum
to be a viable solution. However, a lot of the content being bandwidth, minimum cross-domain traffic, or lowest cost to the
distributed in P2P filesharing networks today is not legal and user, but in all cases the goal is to expose information that can
caching such content by operators could turn out problematic for ameliorate the interactions between peer-to-peer usage and other
them. usages of shared networks.
Peer to Peer Research Group [p2prg] aims to provide a discussion Peer to Peer Research Group [p2prg] aims to provide a discussion
forum for resarchers related to all sorts of challenges of P2P forum for resarchers related to all sorts of challenges presented
systems in general, such as P2P streaming, interconnecting by P2P systems in general, such as P2P streaming, interconnecting
distinct P2P application overlays, security and privacy, etc. distinct P2P application overlays, security and privacy. Current
[I-D.irtf-p2prg-mythbustering] provides a number of literature work on exposing myths about peer-to-peer filesharing
references to support some of the claimed benefits of ALTO [I-D.irtf-p2prg-mythbustering] provides a number of references to
solutions mechanisms, such as the expected decrease in cross- support some of the claimed benefits of ALTO solutions mechanisms,
domain traffic. such as the expected decrease in cross- domain traffic.
4. Summary 5. Summary
Heavy users are a reality. Operators that would like to counteract High-consuming users are a reality. Operators that would like to
the impact of heavy users on their networks have a fair number of counteract the impact of heavy users on their networks have a fair
tools at their disposal. These tools may allow operators to identify number of tools at their disposal. These tools may allow operators
heavy users, collect performance and usage indications, and choose to identify heavy users, collect performance and usage indications,
from a variety of mitigating steps depending on the operator's and choose from a variety of mitigating steps depending on the
preferred business practices. Subscriber-specific information, operator's preferred business practices. Subscriber-specific
including policies, resource consumption information, and details information, including policies, resource consumption information,
about the current network attachment point, may be available in and details about the current network attachment point, may be
accounting servers. Information about the network topology and the available in accounting servers. Information about the network
state of particular topology elements may be available in the network topology and the state of particular topology elements may be
management infrastructure. Solution approaches similar to available in the network management infrastructure. Solution
[I-D.livingood-woundy-congestion-mgmt] have demonstrated one way of approaches similar to [I-D.livingood-woundy-congestion-mgmt] have
taking congestion information into consideration. demonstrated one way of taking congestion information into
consideration.
The currently available mechanisms for identifying and mitigating The currently available mechanisms for identifying and mitigating
congestion largely run wholly within an operator's network and congestion largely run wholly within an operator's network and
without a lot of information exchange about congestion information to without a lot of information exchange about congestion information to
or from end hosts or other network operators. Exposing this or from end hosts or other network operators. Exposing this
information may allow end devices to make more informed decisions information may allow end devices to make more informed decisions
(although policy enforcement would still be required by the (although policy enforcement would still be required by the
operator). operator).
The collection of congestion information poses the challenge of The collection of congestion information poses the challenge of
skipping to change at page 10, line 5 skipping to change at page 11, line 5
different nodes is a complex task. An approach that collects this different nodes is a complex task. An approach that collects this
congestion information along the path of the data packet (via inband congestion information along the path of the data packet (via inband
signaling) would simplify this task. Regardless of the technical signaling) would simplify this task. Regardless of the technical
solution utilized for collecting information, certain users will solution utilized for collecting information, certain users will
undoubtedly observe the effects of decisions that operators make undoubtedly observe the effects of decisions that operators make
about how to handle congestion. Allowing users to understand these about how to handle congestion. Allowing users to understand these
decisions will be crucial and having a channel to send feedback to decisions will be crucial and having a channel to send feedback to
the end device and/or subscriber would be a helpful step towards the end device and/or subscriber would be a helpful step towards
increased transparency. increased transparency.
5. Security Considerations 6. Security Considerations
This document highlights approaches for dealing with heavy network This document highlights approaches for dealing with high-consuming
usage and all of them raise security and privacy concerns. This network users and all of them raise security and privacy concerns.
document does, however, not introduce new mechanism and hence the It does not introduce new mechanisms. The security considerations
reader is referred to the description of the respective mechanism. for the existing mechanisms mentioned apply.
6. IANA Considerations 7. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
7. Acknowledgments 8. Acknowledgments
The authors would like to thank Alan DeKok, Jens-Peter Haack, Jouni The authors would like to thank Alan DeKok, Jens-Peter Haack,
Korhonen, Tommy Lindgren, Lars Eggert, for their time to discuss the Alexander Bachmutsky, Jonne Soininen, Joachim Charzinski, Hannu
topic. Additionally, we would like to thank Marcin Matuszewski for Flinck, Joachim Kross, Jouni Korhonen, Mayutan Arumaithurai, Richard
his help with the P2P infrastructure workshop paper (as it was used Woundy, Daniel Correa Lobato, Luca Caviglione, Tommy Lindgren, Lars
as a starting point). 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).
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 9.2. Informative References
[I-D.irtf-p2prg-mythbustering] [I-D.irtf-p2prg-mythbustering]
Marocco, E., Fusco, A., Rimac, I., and V. Gurbani, Marocco, E., Fusco, A., Rimac, I., and V. Gurbani,
"Improving Peer Selection in Peer-to-peer Applications: "Improving Peer Selection in Peer-to-peer Applications:
Myths vs. Reality", draft-irtf-p2prg-mythbustering-00 Myths vs. Reality", draft-irtf-p2prg-mythbustering-00
(work in progress), August 2009. (work in progress), August 2009.
[I-D.livingood-woundy-congestion-mgmt] [I-D.livingood-woundy-congestion-mgmt]
Bastian, C., Klieber, T., Livingood, J., Mills, J., and R. Bastian, C., Klieber, T., Livingood, J., Mills, J., and R.
Woundy, "Comcast's Protocol-Agnostic Congestion Management Woundy, "Comcast's Protocol-Agnostic Congestion Management
skipping to change at page 15, line 5 skipping to change at page 15, line 14
[ledbat] "", [ledbat] "",
<http://www.ietf.org/dyn/wg/charter/ledbat-charter.html>. <http://www.ietf.org/dyn/wg/charter/ledbat-charter.html>.
[p2prg] "", <http://www.irtf.org/charter?gtype=rg&group=p2prg>. [p2prg] "", <http://www.irtf.org/charter?gtype=rg&group=p2prg>.
[traffic] Cho, K., Fukuda, K., Kato, H., and A. Kato, "The impact [traffic] Cho, K., Fukuda, K., Kato, H., and A. Kato, "The impact
and implications of the growth in residential user-to-user and implications of the growth in residential user-to-user
traffic", SIGCOMM Comput. Commun. Rev. 36, 2006. traffic", SIGCOMM Comput. Commun. Rev. 36, 2006.
[traffic2]
Cho, K., Fukuda, K., Esaki, H., and A. Kato, "Observing
slow crustal movement in residential user traffic, in
International Conference On Emerging Networking
Experiments And Technologies, Proceedings of the 2008 ACM
CoNEXT Conference, Madrid, Spain, Article No. 12", ,
2008.
Appendix A. Example Policy Statement Appendix A. Example Policy Statement
A.1. Fair Usage Policy A.1. Fair Usage Policy
A.1.1. What is the Fair Usage Policy? A.1.1. What is the Fair Usage Policy?
The Fair Usage Policy is designed to ensure that the service received The Fair Usage Policy is designed to ensure that the service received
by the vast majority of our customers is not negatively impacted by the vast majority of our customers is not negatively impacted
because of extremely heavy usage by a very small minority of because of extremely heavy usage by a very small minority of
customers. This is why ISP X continuously monitors network customers. This is why ISP X continuously monitors network
 End of changes. 45 change blocks. 
232 lines changed or deleted 248 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/