<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC5594 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5594.xml'>
<!ENTITY RFC2975 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2975.xml'>
<!ENTITY RFC3588 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'>
<!ENTITY RFC3576 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3576.xml'>
<!ENTITY RFC4006 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4006.xml'>
<!ENTITY RFC2866 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2866.xml'>
<!ENTITY RFC2865 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml'>
<!ENTITY I-D.livingood-woundy-congestion-mgmt PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.livingood-woundy-congestion-mgmt.xml'>
<!ENTITY I-D.irtf-p2prg-mythbustering PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.irtf-p2prg-mythbustering.xml'>
]>

<rfc category="info" ipr="trust200902" docName="draft-tschofenig-conex-ps-02.txt">
  <front>
    <title abbrev="Congestion Exposure PS">Congestion Exposure Problem Statement</title>
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>Linnoitustie 6</street>
          <city>Espoo</city>
          <code>FIN-02600</code>
          <country>Finland</country>
        </postal>
        <phone>+358 (50) 4871445</phone>
        <email>Hannes.Tschofenig@gmx.net</email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>
    <!-- 
    <author initials="B." surname="Aboba" fullname="Bernard Aboba">
      <organization>Microsoft Corporation</organization>
      <address>
        <postal>
          <street>One Microsoft Way</street>
          <city>Redmond</city>
          <region>WA</region>
          <code>98052</code>
          <country>US</country>
        </postal>
        <email>bernarda@microsoft.com</email>
      </address>
    </author>
    -->

    <author fullname="Alissa Cooper" initials="A." surname="Cooper">
      <organization>Center for Democracy &amp; Technology</organization>
      <address>
        <postal>
          <street>1634 I Street NW, Suite 1100</street>
          <city>Washington</city>
          <region>DC</region>
          <code/>
          <country>USA</country>
        </postal>
        <email>acooper@cdt.org</email>
      </address>
    </author>
    <date year="2010"/>
    <area>Transport Area</area>
    <workgroup>CONEX</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t> The increasingly ubiquitous availability of broadband, together with flat-rate pricing,
        have made for increasing congestion problems on the network, which are often caused by a small number of users consuming a large amount of bandwidth. In some cases, building out more capacity to handle this new congestion may be infeasible
	        or unwarranted. As a result, network operators have sought other ways to manage congestion both from their own users and from other networks. These different types of solutions have
	        different strengths and weaknesses, but all of them are limited in a number of key ways.</t>
      <t> This document discusses the problems created for operators by high-consuming users and
        describes the strengths and weaknesses of a number of techniques operators are currently using to cope with high bandwidth
        usage. The discussion of these solutions ultimately points to a need for a new kind of congestion accounting.</t>
    </abstract>
  </front>
  <middle>

    <!-- ====================================================================== -->

    <section anchor="introduction" title="Introduction">
      <t> With the growth of "always on" broadband connections, network operators are increasingly
        facing congestion problems caused by a small number of network users occupying a large
        proportion of network capacity <xref target="broadband-traffic-report"/><xref
          target="traffic2"/>. 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. This is
        true of both congestion caused by an operator's own subscribers and congestion caused by an
        interconnecting network. </t>

      <t>In some cases, building out more capacity to handle this new congestion may be infeasible
        or unwarranted. The cost of building new capacity may be prohibitive, especially for network
        operators that charge flat-rate feeds to subscribers and are thus unable to charge heavier
        users more on the basis of their larger contribution to the congestion problem. For an
        operator facing congestion caused by other operators' networks, building out its own
        capacity is unlikely to solve the congestion problem. Operators are thus facing increased
        pressure to find effective solutions to dealing with high-consuming users, other than
        building out new capacity. </t>

      <t>There are many factors to consider for each kind of solution, including how the solution
        performs, its cost, what its public relations impact might be, and what legal framework
        exists to support its use. 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. </t>

      <t>The responses that operators have sought to manage congestion both from their own users and
        from other networks are generally based on one of four factors that the operator can
        observe for each subscriber or hand-off point on the network: volume of bandwidth used,
        rates of data transfer, congestion volume, and applications used. These different types of solutions have
        different strengths and weaknesses, but all of them are limited in a number of key ways.
          <xref target="existing-approaches"/> discusses the specific strengths and weaknesses of
        each approach. <xref target="general-limitations"/>, discusses the limitations that are
        common to all of the approaches.</t>
    </section>
    <!-- ====================================================================== -->

    <section title="Existing Approaches to Congestion Management" anchor="existing-approaches">

      <section title="Volume-Based Approaches">
        <t>The volume of traffic sent or received by a particular user or network is easy to
          measure. Operators have a number of different standardized protocols available to them to
          conduct volume accounting. Many information elements can be sent from an accounting client
          to an accounting server using standardized protocols, such as RADIUS (see <xref
            target="RFC2866"/> and <xref target="RFC2865"/>) and Diameter <xref target="RFC3588"/>,
          to effectuate volume-based accounting. The existence of standardized protocols has allowed
          resource consumption measurement in roaming cases due to the interconnected AAA systems. 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 <xref target="RFC4006"/> allowed real-time credit control checks,
          allowing operators to make fine-grained congestion decisions based on volume. </t>
        <t>If the collected accounting information leads to billable events then this typically leads
          to a quite effective countermeasure against heavy usage. For example, data usage while roaming is often charged per volume (or per time) and heavy usage leads to huge costs. So, user's typically avoid heavy usage unless they are not aware of the fact that they are roaming, which may happen.</t>
        <t>In any case, the drawback
          of all of these approaches is that they tend to be less user friendly nor do they reflect congestion in any way. </t>
      </section>
      
      <section title="Rate-Based Approaches">
        <t>Volume-based protocols are blind to protocols like LEDBAT <xref
          target="ledbat"/> that are specifically designed to be more sensitive to congestion than
          the underlying transport. One way that operators have used volume accounting is by
          including thresholds for baseline usage volume in end user contracts and reducing priority
          (or charging fees) when a user's consumption goes beyond the threshold. Under such a
          scheme, users would not be incentivized to use applications that support protocols like
          LEDBAT, because the volume accounting would not take the congestion benefits of using a
          LEDBAT-style protocol into consideration. </t>
      </section>
      <section title="Congestion-Based Approaches">
        <t>Initial attempts to capture congestion situations have simply focused on the peak hours and aimed at rate limiting heavy users during that time. For example, users who have consumed a certain amount of bandwidth during the last 24 hours got elected as those who get their traffic shaped, in case the total amount of traffic reaches a congestion situation in certain nodes within the operators network.  
        </t>
        <t>More sophisticated schemes were developed to measure the congestion situation at different entities in the network and to take the overall consumption of the user's traffic into account when picking users for packet remarking that could lead, under congestion situation, to packet dropping. The Comcast FairShare solution <xref
          target="I-D.livingood-woundy-congestion-mgmt"/>  belongs to the more sophisticated schemes.
        </t>
</section>      
<section title="Applications-Based Approaches">
        <t>The use of deep packet inspection (DPI) allows operators to observe and analyze traffic
          at the application layer. This capability can be used to determine the applications and/or
          application-layer protocols that subscribers are using and respond on a per-application or
          per-protocol basis. An example of an ISP's fair usage policy describing how it manages
          specific protocols is included in Appendix A.</t>

        <t>If an operator experiences much congestion based on the use of easily identifiable
          applications protocols, or if the DPI capability can also be used for other purposes,
          operators may find this approach attractive. However, the applications-based approach has
          some drawbacks. 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, and its use can
          result in a cat-and-mouse game with applications developers constantly seeking ways to
          work around the packet inspection engine. Public policy concerns -- privacy, operator
          liability, user backlash, and others -- are another drawback. </t>
      </section>

    </section>

    <section title="General Limitations of All Approaches" anchor="general-limitations">

      <t>All three of the approaches discussed above suffer from some general limitations. First,
        they introduce performance uncertainty. Flat-rate pricing plans are popular because
        operators know that users appreciate the certainty of having their monthly 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. </t>

      <t>Second, none of the approaches is able to make use of what may be the most important factor
        in managing congestion: the amount that an endpoint contributes to congestion on the
        network. This information simply is not available to network nodes, and neither volume nor
        rate nor application usage is an adequate proxy for congestion volume, because none of these
        metrics measures a user or network's actual contribution to congestion on the network. [This
        point needs a little more discussion.]</t>

      <t>Finally, none of these solutions accounts for inter-network congestion. 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). [This point needs to be filled in more.] </t>

    </section>

    <!-- ====================================================================== -->

    <section title="New Activities">
      <t> Following the IETF Workshop on Peer-to-Peer (P2P) Infrastructure in 2008 (see <xref
          target="RFC5594"/>), two working groups and one research group were created that relate to
        the congestion issues created by peer-to-peer application usage: :<list style="empty">
          <t> LEDBAT (Low Extra Delay Background Transport) <xref target="ledbat"/> 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. <vspace blankLines="1"/> 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.</t>

          <t>ALTO (Application-Layer Traffic Optimization) <xref target="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. 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. </t>

          <t>Peer to Peer Research Group <xref target="p2prg"/> 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 <xref
              target="I-D.irtf-p2prg-mythbustering"/> 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. </t>
        </list>
      </t>
    </section>

    <!-- ====================================================================== -->

    <section title="Next Steps">
      <t> Congestion is a reality. Operators that would like to counteract the impact of congestion
        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 <xref
          target="I-D.livingood-woundy-congestion-mgmt"/> have demonstrated one way of taking
        congestion information into consideration.</t>

      <t> 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. </t>

    </section>

    <!-- ====================================================================== -->

    <section title="Security Considerations">
      <t> 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. </t>
    </section>

    <!-- ====================================================================== -->

    <section title="IANA Considerations">
      <t>This document does not require actions by IANA.</t>
    </section>

    <!-- ====================================================================== -->

    <section title="Acknowledgments">
      <t> 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, and Jason Livingood 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). </t>
    </section>
  </middle>
  <!-- ====================================================================== -->
  <back>
    <references title="Normative References"> &RFC2119; </references>
    <references title="Informative References"> &RFC5594; &RFC2975; &RFC3588;
      &RFC3576; &RFC4006; &RFC2866; &RFC2865;
      &I-D.livingood-woundy-congestion-mgmt; &I-D.irtf-p2prg-mythbustering; <reference
        anchor="traffic">
        <front>
          <title>The impact and implications of the growth in residential user-to-user traffic</title>
          <author initials="K" surname="Cho" fullname="Kenjiro Cho">
            <organization/>
          </author>
          <author initials="K" surname="Fukuda" fullname="Kensuke Fukuda">
            <organization/>
          </author>
          <author initials="H" surname="Kato" fullname="Hiroshi Kato">
            <organization/>
          </author>
          <author initials="A" surname="Kato" fullname="Akira Kato">
            <organization/>
          </author>
          <date year="2006"/>
        </front>
        <seriesInfo name="SIGCOMM Comput. Commun. Rev." value="36"/>
        <format type="HTML" target="http://doi.acm.org/10.1145/1151659.1159938"/>
      </reference>
      <reference anchor="broadband-traffic-report">
        <front>
          <title>Broadband Traffic Report</title>
          <author initials="K" surname="Cho" fullname="Kenjiro Cho">
            <organization/>
          </author>
          <date year="2009"/>
        </front>
        <seriesInfo name="Internet Infrastructure Review" value="4"/>
        <format type="HTML"
          target="http://www.iij.ad.jp/en/development/iir/pdf/iir_vol04_bband_EN.pdf"/>
      </reference>
      <reference anchor="traffic2">
        <front>
          <title>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</title>
          <author initials="K" surname="Cho" fullname="Kenjiro Cho">
            <organization/>
          </author>
          <author initials="K" surname="Fukuda" fullname="Kensuke Fukuda">
            <organization/>
          </author>
          <author initials="H" surname="Esaki" fullname="Hiroshi Esaki">
            <organization/>
          </author>
          <author initials="A" surname="Kato" fullname="Akira Kato">
            <organization/>
          </author>
          <date year="2008"/>
        </front>
        <seriesInfo name="" value=""/>
        <format type="HTML" target="http://portal.acm.org/citation.cfm?doid=1544012.1544024"/>
      </reference>
      <reference anchor="alto" target="http://www.ietf.org/dyn/wg/charter/alto-charter.html">
        <front>
          <title/>
          <!-- The title's extraneous quote marks in the text ouput will be removed before 
            publication, unless you want to add a title to this reference. -->
          <author>
            <organization/>
          </author>
          <date/>
        </front>
      </reference>
      <reference anchor="ledbat" target="http://www.ietf.org/dyn/wg/charter/ledbat-charter.html">
        <front>
          <title/>
          <!-- The title's extraneous quote marks in the text ouput will be removed before 
            publication, unless you want to add a title to this reference. -->
          <author>
            <organization/>
          </author>
          <date/>
        </front>
      </reference>
      <reference anchor="p2prg" target="http://www.irtf.org/charter?gtype=rg&group=p2prg">
        <front>
          <title/>
          <!-- The title's extraneous quote marks in the text ouput will be removed before 
            publication, unless you want to add a title to this reference. -->
          <author>
            <organization/>
          </author>
          <date/>
        </front>
      </reference>
    </references>

    <section anchor="policy" title="Example Policy Statement">

      <section title="Fair Usage Policy">

        <section title="What is the Fair Usage Policy?">


          <t>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 %). </t>

        </section>
        <section title="How do I know I'm a very heavy user?">

          <t> 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. </t>
        </section>


        <section title="I have Contract Option 3, does the Fair Usage Policy
    apply to me?">

          <t> 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. </t>
        </section>

        <section title="Peer to Peer (P2P)">

          <section
            title="I'm noticing slower P2P speeds at peak times even though I'm not a
    very heavy user, why is this?">
            <t> 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. </t>
            <t>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. </t>
            <t>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. </t>
          </section>

          <section title="Does this mean I can't use Peer-to-Peer (P2P) applications?">

            <t> 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. </t>
          </section>

        </section>
      </section>

    </section>
  </back>

</rfc>
