CONEX                                                      H. Tschofenig
Internet-Draft                                    Nokia Siemens Networks
Intended status: Informational                                 A. Cooper
Expires: April 22, 29, 2010                           Center for Democracy &
                                                              Technology
                                                        October 19, 26, 2009

                 Congestion Exposure Problem Statement
                    draft-tschofenig-conex-ps-00.txt
                    draft-tschofenig-conex-ps-01.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 22, 29, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The increasingly ubiquitous availability of broadband connections broadband, together with
   flat-rate
   pricing has pricing, have made the use of new types kinds of peer-to-peer
   applications possible. increasingly common.  From an Internet the perspective of the
   Internet's evolution and its contributions to end user value point of view value, this is
   very exciting.  As a consequence, an increase of user-to-user traffic
   was observable all around the world over the last few years.  With  However, the uptick in peer-to-peer application usage of p2p systems
   has also contributed to the observation can be made that a certain
   group rise of users, called high-consuming users, decided to use "high-consuming users" who take
   their flat-rate contract excessively.  This in turn seems contracts to have caused
   network the limit by continuously file-sharing
   to the maximum extent possible.  Network operators have responded to take actions.
   this phenomenon in a number of different fashions.

   This document discusses the problems created for operators by high-
   consuming users and illustrates a couple number of techniques used by operators
   today are
   currently using to deal cope with excessive high bandwidth usage.  More information can
   improve the decision making process.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  State-of-the-Art Building Blocks . . . . . . . . . . . . . . .  5
     2.1.  Means of Identifying the Causes of Congestion  Accounting . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Potential Actions Operators might take in Response  Deep Packet Inspection . . . . . . . . . . . . . .  6 . . . .  5
   3.  Network Operator Responses to Congestion . . . . . . . . . . .  7
   4.  New Activities . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  9
   5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   5. 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6. 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7. 12
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   8. 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1. 14
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     8.2. 14
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13 14
   Appendix A.  Example Policy Statement  . . . . . . . . . . . . . . 15 16
     A.1.  Fair Usage Policy  . . . . . . . . . . . . . . . . . . . . 15 16
       A.1.1.  What is the Fair Usage Policy? . . . . . . . . . . . . 15 16
       A.1.2.  How do I know I'm a very heavy user? . . . . . . . . . 15 16
       A.1.3.  I have Contract Option 3, does the Fair Usage
               Policy apply to me?  . . . . . . . . . . . . . . . . . 15 16
       A.1.4.  Peer to Peer (P2P) . . . . . . . . . . . . . . . . . . 15 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 18

1.  Introduction

   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. [traffic] published a paper about the growth of
   residential user-to-user traffic in Japan reported
   that indicates '... a for residential Japanese broadband connections, "a small number
   of users dictate the overall behavior; 4 % 4% of high-consuming users
   account for 75 % 75% of the inbound volume, and the fiber users account
   for 86 % 86% of the inbound volume.'.  The same volume."  A more recent paper published
   December 2008, see [traffic2], 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
   indicates a substantial increase in overall
   traffic growth, namely 37 % growth (37% per
   year according, and not just a different distribution of traffic
   among the users.  At that time 63 % of the residential traffic volume
   is contributed by user-to-user traffic.

   These numbers itself do year).  Operators in other countries have
   experienced similar shifts.

   This trend does not represent necessarily present a problem on its face, as by themself and
   increased traffic volumes do not necessarily automatically lead to congestion.
   However, in some cases where operators very
   likely had different expectations about the were not expecting these
   changes in growth rates and traffic
   consumption of individual users and statistics (used for consumption, their pricing models) did not work out too well for them.  The profit
   margins for models
   and congestion management architectures have proved inadequate.  In
   some countries, fierce competition among Internet access are quite slim due to fierce competition. providers
   has yielded low profit margins.  This puts a lot of has increased the pressure on
   operators to find effective ways to deal with these high- consuming users
   who cost them a lot more money than the bulk of money.  Finally, their subscribers.
   Furthermore, some broadband networks (such as cable networks) may not
   have the ideal characteristics (such as
   the topology for routing traffic) (routing topology, for example) to
   support high volumes of user-to-user traffic (e.g.,
   Cable Networks). traffic.

   Congestion is often mentioned in this context and as cost are closely related.  As stated in RFC 5594 [RFC5594]
   [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,  The upshot for network operators is: 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 options for addressing this
   problem.  There are many factors to consider for each kind of
   solution, including how the solution performs, its cost, what is allowed (legally
   and from a the
   public relation point relations impact of view) using a particular solution might be, and
   what is useful from a
   performance point of view.  The latter aspect can be seen from legal framework exists to support the
   point of view use of a particular
   solution.  The performance considerations must take into account the
   balance between device performance (as and forwarding performance (since
   many of the solution mechanisms
   actually slow down the forwarding performance quite a bit) performance),
   and
   consequently a cost challenge.

   The existence of flat rate pricing contributes this determination is intimiately related to measuring a
   solution's overall cost.

   In some of cases, the
   problems since popularity of flat-rate pricing plans exacerbate
   the congestion problem because an individual's 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
   tied to his or her monthly bill, creating an incentive to use as much
   bandwidth as possible and leaving operators to cover the amount.  As such, costs of all
   their users with essentially equal payments from each.  Operators
   know that
   rarely utilize users appreciate the network pay certainty of having the same bill amount as someone who uses
   P2p filesharing excessively.

   However, from a psychological point of view humans tend to strive to
   avoid uncertainty and hence offerings that reduced uncertainty.  For
   a user there are essentially two aspects to worry about

   o  Uncertainty in
   remain the bill: unpredicable 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 make planning
      difficult.

   o  Uncertainty in the performance: performance degradation as part of
      the actions their connections is not being taken

   True flat rate pricing avoids uncertainty in altered or
   degrated based on how the bill. network operator manages congestion.
   Unfortunately, most of the solutions described below lead to create some
   uncertainty
   performance uncertainty, and thereby increase unhappyness of customers. 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.1.  Means

   Two means of Identifying learning about the Causes of Congestion 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
   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 [RFC2866] and [RFC2865]) and Diameter
   [RFC3588], has increased.  The fact that existence of standardized protocols have
   been available
   has allowed different AAA networks to be interconnected
   and their usage can be found interconnect.  These protocols
   are now used in almost every enterprise and operator network.  The
   initial accounting mechanisms envisioned a rather non-
   real non-real time
   nature in reporting resource consumption but with mechanisms like
   like Diameter Credit Control [RFC4006] allowed real-
   time real-time credit
   control checks.

   It has to be noted that

   Although they are popular, RADIUS and Diameter are not the only
   protocols that can be used to collect usage information and to
   trigger certain actions, even they are fairly popular. responses.  Other approaches, as documented in
   [I-D.livingood-woundy-congestion-mgmt], lead to similar results.

2.2.  Deep Packet Inspection

   Deep packet inspection (DPI) refers to inspecting the observation and analysis
   of traffic that passes through the operators 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 traffic shaping, 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 the number of
   connection setups from a single subscriber. .  Certain end user
   contracts may also allow operators to ban servers from residential
   access.

   Determining the type of application that a subscriber is running was
   seen as necessary

3.  Network Operator Responses to throttle only certain applications, instead Congestion

   Once they have collected congestion information using either of
   impacting the full range of traffic
   techniques described above or others, network operators have a subscriber is using.  A side-
   effect is the additional investment number
   of options for the device and operational
   costs.  The process how to respond.  For all of inspecting traffic these options, it is performance intensive
   and continous software updates are necessary up to ensure that the
   detection engine recognizes the latest protocol variants.
   Additionally,
   the attempt operator 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

   What actions are taken based on decide the collected information breadth and in what
   time frame is largely left to the choice of those who run the
   infrastructure.  In the context depth of this discussion the collected
   information may its response: which
   users will be used to charge affected, the user per volume, per time and frame in various different combinations.  Additionally, the RADIUS which congestion will be
   managed, whether specific applications or protocols will be targeted,
   and
   Diameter allow the server side with a server-initiated message (see
   Change of Authorization in [RFC3576], so forth.  Operators can chose from both technical 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: pricing/
   contract-based options.  Technical options include:

   Wholistic traffic shaping:

      End user contracts often offer a combination of 'flat-rate'
      scheme whereby a fixed price tariff is used up to provide users with a certain threshold
      for baseline usage volume (typically (which is typically quite high for regular usage). high).
      Subsequently, if
      the consumption goes beyond a certain threshold then the entire threshold, all of the
      user's traffic is given lower reduced priority and potentially shaped.

         In many countries operators have to offer vis a clear description
         of the service they offer and since vis other users on
      the term 'flat-rate' is
         already associated with network.  Some operators may only shape traffic during times
      of congestion or peak usage periods (even if a certain meaning user has exceeded
      his or her baseline threshold).

   Per-application or per-protocol shaping:

      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 term 'Unlimited
         Data Rate' is often used for this type shaping of service.  Contracts
         typically contain statements that allow only certain actions to be
         taken. 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 such a an ISP's fair use statement can be found usage policy describing how it manages specific
      protocols is included in Appendix A.

      Note that traffic shaping is often only applied to high-consuming
      users (since they are known based on the accounting procedures) or
      the effect becomes only visible during peak hours when the network
      fills up.

   Class-Based Assignment:

      In this technique users are classified into a set of classes
      depending on their past behavior.  Subsequently,
      the their traffic is
      treated according to the their associated class.  It is
      ensured that the traffic of classes.  This may prevent
      lightweight users, users that really
      rarely use their Internet connection, cannot be pushed away by from feeling the effects of sharing network
      capacity with heavy users.  This mechanism again requires some form of DiffServ
      packet marking to be in place. able to differentiate light users from heavy
      users.

   Pricing/contract-based options include:

      Charging for Excessive Traffic:  As a possible action a user might
      get charged  Network operators may charge
         users differently for traffic that exeeds a certain threshold
         compared to the traffic that falls within below the agreed
      limits. threshold.

      Suspending or Discontinuing Contracts:  In some rare cases ISP also decided ISPs
         may decide to cut
      connectivity under certain condition. suspend or terminate the contracts of heavy
         users.  In fact some cases this might response may be
      justified in certain cases.  For example, in case of new botnets
      malware distribution associated with a
         security issue; when the an operator recognizes an infected a botnet-infected
         machine and hotlines generating excessive traffic, it may hotline all the entire
         traffic of that particular machine to a separate network and, like in WLAN hotspots, HTTP traffic is
      intercepted to display further information. network, and
         ultimately suspend or terminate the machine's connection.  In
         some cases the same technique has been applied with excessive usage of to users engaged
         in heavy P2P
      traffic, usage, 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
      'independent authority' to punish copyright violators with a
      temporary suspension of their Internet access has raised
      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. analysis.

4.  New Activities

   In response to

   Following the P2P infrastructure workshop IETF Workshop on Peer-to-Peer (P2P) Infrastructure in
   2008 (with a
   summary documented [RFC5594]) (see [RFC5594]), two working groups and one research group has been were
   created that focus on a certain area of relate to the congestion issues created by peer-to-peer
   application space: usage: :

      LEDBAT (Low Extra Delay Background Transport) [ledbat] is designed
      to allow to keep the latency across the a congested bottleneck low even as it
      is saturated.  This allows applications that send large amounts of
      data, particularly upstream on home connections, such connections (such as peer-to-peer application, peer-to-
      peer applications) to operate without destroying the user
      experience in interactive applications.

      LEDBAT is a promising approach when applied widely in holds substantial promise should P2P clients. 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) [alto] 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.  For legal content  ALTO mechanisms with the ability for ISPs to deploy proxies appear services may
      take different approaches at balancing factors such as maximum
      bandwidth, minimum cross-domain traffic, or lowest cost to be a viable solution.  However, a lot of the content being
      distributed
      user, but in P2P filesharing networks today all cases the goal is not legal to expose information that can
      ameliorate the interactions between peer-to-peer usage and
      caching such content by operators could turn out problematic for
      them. other
      usages of shared networks.

      Peer to Peer Research Group [p2prg] aims to provide a discussion
      forum for resarchers related to all sorts of challenges of presented
      by P2P systems in general, such as P2P streaming, interconnecting
      distinct P2P application overlays, security and privacy, etc. privacy.  Current
      work on exposing myths about peer-to-peer filesharing
      [I-D.irtf-p2prg-mythbustering] provides a number of literature references to
      support some of the claimed benefits of ALTO solutions mechanisms,
      such as the expected decrease in cross- domain traffic.

4.

5.  Summary

   Heavy

   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 [I-D.livingood-woundy-congestion-mgmt] 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.

5.

6.  Security Considerations

   This document highlights approaches for dealing with heavy high-consuming
   network
   usage users and all of them raise security and privacy concerns.  This
   document does, however,
   It does not introduce new mechanism and hence the
   reader is referred to the description of mechanisms.  The security considerations
   for the respective mechanism.

6. existing mechanisms mentioned apply.

7.  IANA Considerations

   This document does not require actions by IANA.

7.

8.  Acknowledgments

   The authors would like to thank Alan DeKok, Jens-Peter Haack,
   Alexander Bachmutsky, Jonne Soininen, Joachim Charzinski, Hannu
   Flinck, Joachim Kross, 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 (as (since it was used as a starting point).

8. point
   for the work on this memo).

9.  References

8.1.

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.

9.2.  Informative References

   [I-D.irtf-p2prg-mythbustering]
              Marocco, E., Fusco, A., Rimac, I., and V. Gurbani,
              "Improving Peer Selection in Peer-to-peer Applications:
              Myths vs. Reality", draft-irtf-p2prg-mythbustering-00
              (work in progress), August 2009.

   [I-D.livingood-woundy-congestion-mgmt]
              Bastian, C., Klieber, T., Livingood, J., Mills, J., and R.
              Woundy, "Comcast's Protocol-Agnostic Congestion Management
              System", draft-livingood-woundy-congestion-mgmt-01 (work
              in progress), September 2009.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

   [RFC2975]  Aboba, B., Arkko, J., and D. Harrington, "Introduction to
              Accounting Management", RFC 2975, October 2000.

   [RFC3576]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
              Aboba, "Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS)", RFC 3576,
              July 2003.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC4006]  Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
              Loughney, "Diameter Credit-Control Application", RFC 4006,
              August 2005.

   [RFC5594]  Peterson, J. and A. Cooper, "Report from the IETF Workshop
              on Peer-to-Peer (P2P) Infrastructure, May 28, 2008",
              RFC 5594, July 2009.

   [alto]     "",
              <http://www.ietf.org/dyn/wg/charter/alto-charter.html>.

   [ledbat]   "",
              <http://www.ietf.org/dyn/wg/charter/ledbat-charter.html>.

   [p2prg]    "", <http://www.irtf.org/charter?gtype=rg&group=p2prg>.

   [traffic]  Cho, K., Fukuda, K., Kato, H., and A. Kato, "The impact
              and implications of the growth in residential user-to-user
              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

A.1.  Fair Usage Policy

A.1.1.  What is the Fair Usage Policy?

   The Fair Usage Policy is designed to ensure that the service received
   by the vast majority of our customers is not negatively impacted
   because of extremely heavy usage by a very small minority of
   customers.  This is why ISP X continuously monitors network
   performance and may restrict the speed available to very heavy users
   during peak time.  This applies to customers on all Options.  Note if
   you are a heavy user we will only restrict your speed, service will
   not be stopped so ability to upload and download remains.  No
   restrictions will be imposed outside of the peak times.  Only a very
   small minority of customers will ever be affected by this (less than
   1 %).

A.1.2.  How do I know I'm a very heavy user?

   There is no hard and fast usage limit that determines if you are a
   heavy user as the parameters that determine heavy use vary with the
   demands placed on the network at that given time.  If you have a
   query about fair usage related restrictions on your line please call
   us.

A.1.3.  I have Contract Option 3, does the Fair Usage Policy apply to
        me?

   Yes, the Fair Usage Policy applies to all customers on all Options,
   including Option 3.  Option 3 allows unlimited downloads and uploads
   inclusive of the monthly rental price, so you will not be charged for
   over-use, however this does not preclude ISP X from restricting your
   speed at peak times if you are a heavy user.  If you are an Option 3
   heavy user this does not prevent you from continuing to use your
   service, nor does it cost you any more but it ensures that you do not
   negatively impact the majority of our customers who share the
   available bandwidth with you.

A.1.4.  Peer to Peer (P2P)

A.1.4.1.  I'm noticing slower P2P speeds at peak times even though I'm
          not a very heavy user, why is this?

   P2P is the sharing and delivery of files amongst groups of people who
   are logged on to a file sharing network.  P2P consumes a significant
   and highly disproportionate amount of bandwidth when in use even by
   small numbers of users.

   This is why we have a peak time policy where we limit P2P speeds to
   manage the amount of bandwidth that is used by this application in
   particular.

   Without these limits all our customers using their broadband service
   at peak times would suffer, regardless of whether they are using P2P
   or not.  It's important to remember that P2P isn't a time-critical
   application so if you do need to download large files we advise you
   to do this at off-peak times when no restrictions are placed, not
   only will you be able to download faster but your usage will not
   negatively impact other users.

A.1.4.2.  Does this mean I can't use Peer-to-Peer (P2P) applications?

   No, we are not stopping you from using any P2P service, P2P will just
   be slowed down at peak times.  Again, P2P is not generally a time-
   sensitive application.

Authors' Addresses

   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  FIN-02600
   Finland

   Phone: +358 (50) 4871445
   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at

   Alissa Cooper
   Center for Democracy & Technology
   1634 I Street NW, Suite 1100
   Washington, DC
   USA

   Email: acooper@cdt.org