GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5594

Network Working Group J. Peterson Request for Comments: 5594 NeuStar Category: Informational A. Cooper

                                     Center for Democracy & Technology
                                                             July 2009
Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure,
                            May 28, 2008

Abstract

 This document reports the outcome of a workshop organized by the
 Real-time Applications and Infrastructure Area Directors of the IETF
 to discuss network delay and congestion issues resulting from
 increased Peer-to-Peer (P2P) traffic volumes.  The workshop was held
 on May 28, 2008 at MIT in Cambridge, MA, USA.  The goals of the
 workshop were twofold: to understand the technical problems that ISPs
 and end users are experiencing as a result of high volumes of P2P
 traffic, and to begin to understand how the IETF may be helpful in
 addressing these problems.  Gaining an understanding of where in the
 IETF this work might be pursued and how to extract feasible work
 items were highlighted as important tasks in pursuit of the latter
 goal.  The workshop was very well attended and produced several work
 items that have since been taken up by members of the IETF community.

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

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.

Peterson & Cooper Informational [Page 1] RFC 5594 P2P Infrastructure July 2009

Table of Contents

 1. Introduction ....................................................3
 2. Scoping of the Problem and Solution Spaces ......................4
 3. Service Provider Perspective ....................................4
    3.1. DOCSIS Architecture and Upstream Contention ................4
    3.2. TCP Flow Fairness and Service Flows ........................5
    3.3. Service Provider Responses .................................6
 4. Application Provider Perspective ................................7
 5. Potential Solution Areas ........................................7
    5.1. Improving Peer Selection: Information Sharing,
         Localization, and Caches ...................................8
         5.1.1. Leveraging AS Numbers ...............................9
         5.1.2. P4P: Provider Portal for P2P Applications ...........9
         5.1.3. Multi-Layer, Tracker-Based Architecture ............10
         5.1.4. ISP-Aided Neighbor Selection .......................11
         5.1.5. Caches .............................................12
         5.1.6. Potential IETF Work ................................12
    5.2. New Approaches to Congestion Control ......................14
         5.2.1. End-to-End Congestion Control ......................15
         5.2.2. Weighted Congestion Control ........................15
    5.3. Quality of Service ........................................16
 6. Applications Opening Multiple TCP Connections ..................17
 7. Costs and Congestion ...........................................18
 8. Next Steps .....................................................18
    8.1. Transport Issues ..........................................19
    8.2. Improved Peer Selection ...................................19
 9. Security Considerations ........................................19
 10. Acknowledgements ..............................................19
 11. Informative References ........................................20
 Appendix A.  Program Committee ....................................21
 Appendix B.  Workshop Participants ................................21
 Appendix C.  Workshop Agenda ......................................24
 Appendix D.  Slides and Position Papers  ..........................25

Peterson & Cooper Informational [Page 2] RFC 5594 P2P Infrastructure July 2009

1. Introduction

 Increasingly, large ISPs are encountering issues with P2P traffic.
 The transfer of static, delay-tolerant data between nodes on the
 Internet is a well-understood problem, but traditional management of
 fairness at the transport level is under strain from applications
 designed to achieve the best end-user transfer rates.  At peak times,
 this results in networks running near absolute capacity, causing all
 traffic to incur delays; the applications that bear the brunt of this
 additional latency are real-time applications like Voice over IP
 (VoIP) and Internet gaming.  To explore how IETF standards work could
 be useful in addressing these issues, the Real-time Applications and
 Infrastructure area directors organized a "P2P Infrastructure"
 workshop and invited contributions from subject matter experts in the
 problem and solution spaces.
 The goals of the workshop were twofold: to understand the technical
 problems that ISPs and end users are experiencing as a result of high
 volumes of P2P traffic, and to begin to understand how the IETF may
 be helpful in addressing these problems.  Gaining an understanding of
 where in the IETF this work might be pursued and how to extract
 feasible work items were highlighted as important tasks in pursuit of
 the latter goal.  The workshop's focus was on engineering solutions
 that promise some imminent benefit to the Internet as a whole, as
 opposed to longer-term research or closed proprietary solutions.
 While public policy must inform work in this space, crafting or
 debating public policy was outside the scope of the workshop.
 Position papers were solicited in the weeks prior to the workshop,
 and a limited number of speakers were invited to present their views
 at the workshop based on these submissions.  This report is a summary
 of all participants' contributions.  The program committee and
 participant list are attached in Appendices A and B, respectively.
 The agenda of the workshop can be found in Appendix C.  A link to the
 presentations given at the workshop and the position papers submitted
 prior to the workshop is in Appendix D.
 The workshop showcased the IETF community's recognition of the impact
 of P2P and other high-volume applications on the Internet as a whole.
 Participants welcomed the opportunity to discuss potential
 standardization work that network operators, applications providers,
 and end users would all find mutually beneficial.  Two transport-
 related work items gained significant traction: designing a protocol
 for very deferential end-to-end congestion control for delay-tolerant
 applications, and producing an informational document about the
 reasoning behind and effects of applications opening multiple
 transport connections at once.  A separate area of interest that
 emerged at the workshop focused on improving peer selection by having

Peterson & Cooper Informational [Page 3] RFC 5594 P2P Infrastructure July 2009

 networks make more information available to applications.  Finally,
 presenters also covered traditional approaches to multiple service-
 tier queuing such as Diffserv.

2. Scoping of the Problem and Solution Spaces

 The genesis for the Peer-to-Peer Infrastructure (P2PI) workshop grew
 in large part out of specific pain points that ISPs are experiencing
 as a result of high volumes of P2P traffic.  However, several
 workshop participants felt that the IETF should approach a more
 general space of problems, of which P2P-related congestion may be
 merely one instance.
 For example, high-volume applications besides P2P, whether they
 already exist or have yet to be developed, could cause congestion
 issues similar to those caused by P2P.  The general class of
 congestion problems attributable to always-on, high-volume
 applications require the development of solutions that are reasonable
 for operators, applications, and subscribers.  And while much
 attention has been paid to congestion on access links, increased
 traffic volumes could impact other parts of the network.  Although
 the workshop focused primarily on the specific causes and effects of
 current P2P traffic volumes, it will likely be useful in the future
 for the IETF to consider how to pursue solutions to these larger
 problems.
 Obtaining more data about Internet congestion may also be a helpful
 step before the IETF pursues solutions.  This data collection could
 focus on where in the network congestion is occurring, its duration
 and frequency, its effects, and its root causes.  Although individual
 service providers expressed interest in sharing congestion data,
 strategies for reliably and regularly obtaining and disseminating
 such data on a broad scale remain elusive.

3. Service Provider Perspective

 To help participants gain a fuller understanding of one specific
 network operator's view of P2P-induced congestion, Jason Livingood
 and Rich Woundy provided an overview of Comcast's network and
 approach to management of P2P traffic.

3.1. DOCSIS Architecture and Upstream Contention

 In the Data Over Cable Service Interface Specification (DOCSIS)
 architecture [DOCSIS] that is used for many cable systems, there may
 be a single Cable Modem Termination System (CMTS) serving hundreds or
 thousands of residential cable customers.  Each CMTS has multiple

Peterson & Cooper Informational [Page 4] RFC 5594 P2P Infrastructure July 2009

 DOCSIS domains, each of which typically has a single downstream link
 and a number of upstream links.  Each CMTS is connected through a
 hybrid fiber-coaxial (HFC) network to subscribers' cable modems.
 The limiting resource in this architecture is usually bandwidth, so
 bandwidth is typically the measure used for capacity planning.  As
 with all networks, congestion manifests itself when instantaneous
 load exceeds available capacity.
 In the upstream direction, any cable modem connected to a CMTS can
 make a request to the CMTS to transmit, and requests are randomized
 to minimize collisions.  With many cable modems issuing requests at
 once, the requests may collide, resulting in delays.  DOCSIS does not
 specify a size for cable modem buffers, but buffer delays of one to
 four seconds have been observed with various cable modems from
 different vendors.
 Once the CMTS has granted a cable modem the ability to transmit its
 data PDU, the modem can piggyback its next request on top of that
 data PDU.  In situations with a lot of upstream traffic, piggybacking
 happens more often, which sends heavy upstream users to the front of
 the CMTS queue, ahead of interactive but less-upstream-intensive
 applications.  For example, if the CMTS is granting requests
 approximately every one to three milliseconds, then a cable modem
 transmitting data for a service like VoIP with a packetization delay
 of 20-30 milliseconds may get into contention with another modem on
 the same CMTS that is constantly transmitting upstream and
 piggybacking each new request.  This may explain how heavy upstream
 users ultimately dominate the pipe over more interactive
 applications.  Consequentially, it is imperative that assessments of
 the problem space and potential solutions are mindful of the
 influence that specific layer-2 networks may exert on the behavior of
 Internet traffic, especially when considering the alleviation of
 congestion in an access network.

3.2. TCP Flow Fairness and Service Flows

 How TCP flow fairness applies to upstream requests to the CMTS is an
 open question.  A CMTS sees many service flows, each of which could
 be a single TCP flow or many TCP flows (or UDP).  The CMTS is not
 aware of the source or destination IP address of a packet until it
 has already been transmitted upstream, so those cannot be used to
 impose flow fairness.
 A particular cable modem can have multiple service flows defined.
 For example, a modem that is also a VoIP endpoint can provision a
 service flow for VoIP that would allow VoIP traffic to avoid the
 upstream request process to the CMTS (and thereby avoid contention

Peterson & Cooper Informational [Page 5] RFC 5594 P2P Infrastructure July 2009

 with other modems).  The service flow would have upstream capacity
 provisioned for it.  The modem would have a separate service flow for
 best efforts traffic.  Some ISPs provision such a flow for their own
 VoIP offerings; others allow subscribers to pay extra to have
 particular traffic assigned to a provisioned service flow.
 It may also be possible for an ISP to provision such a flow on the
 fly when it recognizes the need for it.  Diffserv [RFC2475] bits set
 by the customer premises equipment could be used to classify flows,
 for example.

3.3. Service Provider Responses

 In 2005, ISP customers began increasingly complaining about the
 performance of delay-sensitive traffic (VoIP and gaming), due in part
 to the issues arising out of the DOCSIS architecture as described
 above.  At the same time, ISPs were seeing heavy growth in P2P
 traffic and an increasing correlation between high levels of P2P
 activity and packet loss.
 In responding to this situation, cable ISPs have several avenues to
 pursue.  The newest generation of the DOCSIS specification, DOCSIS
 3.0, enables faster transfer rates than most cable systems currently
 support.  While the rollout of DOCSIS 3.0 will provide additional
 capacity, it will likely not obviate the need for congestion
 management in an environment where client software is designed to
 maximize bandwidth consumption regardless of available capacity.
 Congestion management can take many forms; Jason and Rich explained
 the new protocol-agnostic approach that Comcast is currently
 trialing.  Prior to these trials, all traffic was marked as "best
 efforts".  During the trials, all traffic is re-classified as
 "priority".  When a CMTS is approaching peak congestion on a
 particular upstream or downstream port (the "Near Congestion State"),
 some subscribers will have traffic re-classified as "best efforts".
 Both the threshold for determining when a CMTS port is in Near
 Congestion State and the number of minutes it remains in this state
 are parameters being explored during the trials.  To re-classify
 upstream traffic, a new default DOCSIS service flow is used that has
 the same provisioned bandwidth as the "priority" stream but that is
 treated with lower priority.
 The subscribers whose traffic is re-marked will be selected by
 determining whether they have temporarily entered a "Long Duration
 Bulk Consumption State".  This state is achieved by consuming a
 certain amount of bandwidth over a certain period of minutes (both
 are tweakable parameters being explored during the trials).  These
 thresholds will depend on the subscriber's service tier --

Peterson & Cooper Informational [Page 6] RFC 5594 P2P Infrastructure July 2009

 subscribers who pay for more bandwidth will have higher thresholds.
 The re-marking will not distinguish between multiple users of the
 same subscriber connection, so one family member's P2P usage could
 cause another family member's Web browsing traffic to be lowered in
 priority.  There is no current mechanism for users to determine that
 their traffic has been re-marked.
 By temporarily reducing the traffic priority of subscribers who have
 been consuming bandwidth in bulk for lengthy periods, this congestion
 management technique aims to preserve a good user experience for
 subscribers with burstier traffic patterns, including those using
 real-time applications.  As compared to an approach that reduces
 particular subscribers' bandwidth during periods of congestion, this
 technique eliminates the ability for applications to set their own
 priority levels, but it also avoids the negative connotations that
 some users may associate with bandwidth reductions.
 This approach involves many tweakable parameters.  A large part of
 the trial process is aimed at determining the best settings for these
 parameters, but there may also be opportunities to work with the
 research community to identify the best way to adjust the thresholds
 necessary to optimize the performance of the management technique.

4. Application Provider Perspective

 Stanislav Shalunov provided an overview of BitTorrent's view of the
 impact of increased P2P traffic volumes and potential mitigations.
 The impact is described here; his proposed solutions (comprising the
 bulk of his talk) are addressed in the appropriate subsections of
 Section 5.
 As uptake in P2P usage has grown, so has end-user latency.  For
 example, a user whose uplink capacity is 250-500 Kbps and whose modem
 buffer has a capacity of 32-64 Kbps may easily fill the buffer
 (unless the modem uses Adaptive Queue Management (AQM), which is
 uncommon).  This can result in delay on the order of seconds, with
 disastrous effects on application performance.  On a cable system
 with shared capacity between neighbors, one neighbor could saturate
 the buffer and affect the latency of another neighbor's traffic.
 Even users with dedicated bandwidth can experience delays as their
 own P2P traffic saturates the link and dominates their own more
 latency-sensitive traffic.

5. Potential Solution Areas

 The submissions received in advance of the workshop covered a broad
 array of work addressing specific aspects of P2P traffic volume and
 other related issues.  Solution suggestions generally fell into one

Peterson & Cooper Informational [Page 7] RFC 5594 P2P Infrastructure July 2009

 or more of three topic areas: improving peer selection, new
 approaches to congestion control, and quality-of-service mechanisms.
 The workshop discussions and outcomes in each area are described
 below.

5.1. Improving Peer Selection: Information Sharing, Localization, and

    Caches
 Peer selection is an integral factor in determining the efficiency of
 P2P networks from both the ISP and the P2P client points of view.
 How peers are selected will determine both network load and client
 performance.
 The way that P2P clients select peers today varies from protocol to
 protocol and client to client but, in general, peers are largely
 oblivious to routing-level and network-topology information.  This
 results in P2P topologies that are agnostic of underlay topologies
 and constraints.
 Approaches to closing this gap generally involve an entity that has
 knowledge of network topology, costs, or constraints (e.g., an ISP)
 making some of this information available to P2P clients or trackers.
 This information may be used to localize traffic based on some metric
 of locality or to otherwise alter peer-selection decisions based on
 the provided network information (hereafter referred to simply as
 "localization").  One special case of this kind of approach would
 help peers find caches containing the content they seek.
 Any alteration to current peer-selection algorithms will have
 engineering trade-offs.  BitTorrent, for example, used randomized
 peer selection by design.  Choosing peers randomly out of a large
 selection helps to average out problems among peers and allows for
 connections to good peers that may be far away.  Randomized peer
 selection also supports "rarest first" piece selection, which allows
 swarms to continue even when the original seed disappears and which
 distributes pieces so that more peers are likely to have pieces of
 interest to other peers.  Any move away from randomized selection
 would have to take these factors into account.
 Although localization has the potential to improve peer selection,
 the incentives for both parties to the information exchange are
 complex.  ISPs may want to move traffic off of their own networks,
 which could motivate them to provide information to peers that has
 the opposite effect of what the peers would expect.  Likewise, peers
 will want the use of the information they receive to result in
 performance improvements; otherwise, they have no incentive to
 consult with the network before selecting peers.  Even when both
 parties find the information sharing to be beneficial, user

Peterson & Cooper Informational [Page 8] RFC 5594 P2P Infrastructure July 2009

 experiences will not necessarily be uniform depending on the scope of
 the information provided and the peer's location.  Localization
 information could form one component of a peer-selection decision,
 but it will likely need to be balanced against other factors.
 Workshop participants discussed both current research efforts in this
 area and how IETF standards work may be useful in furthering the
 general concept of improved peer selection.  Those discussions are
 summarized below.

5.1.1. Leveraging AS Numbers

 One simple way to potentially make peer selection more efficient
 would be for a peer to prefer peers within its own Autonomous System
 (AS).  Transfers between peers within the same AS may be faster on
 some networks, although more data is needed to determine the extent
 of the potential improvement.  On mobile networks, for example, the
 utility of AS numbers is limited since they do not correlate to
 geographic location.  Peers may also see improvements by connecting
 to other peers within a specific set of ASes or IP prefixes provided
 by their ISPs.  Some ISPs may have an incentive to expose this
 granularity of information because it will potentially reduce their
 transit costs.
 A case study was conducted with the four most popular BitTorrent
 torrents to determine what the effect of localizing to an AS might
 be.  The swarm sizes for the torrents were 9984, 3944, 2561, and
 2023, with the size distributions appearing to be polynomial.  With
 more than 20 peers in a single AS, peers within an AS could trade
 only with each other, avoiding interdomain traffic.  More than half
 (57%) of peers in the four swarms were in ASes like this.  Thus, in
 these cases connecting to peers within an AS could reduce transit
 traffic by at least 57%.  If the ASes have asymmetric upload and
 download links, however, the resulting user experience may
 deteriorate since each peer's download speed would be limited by
 slower upload speeds.
 With the largest swarm size at 9984, the probability of two peers
 being in the same neighborhood is too low to make localization to the
 neighborhood level worthwhile.  Attempting a simple localization
 scheme, such as the AS localization described above, and determining
 its effectiveness likely makes more sense as a first step.

5.1.2. P4P: Provider Portal for P2P Applications

 The Provider Portal for P2P Applications (P4P) project [P4P] aims to
 design a framework to enable cooperation between providers and
 applications (including P2P), where "providers" may be ISPs, content

Peterson & Cooper Informational [Page 9] RFC 5594 P2P Infrastructure July 2009

 distribution networks, or caching services.  In this architecture,
 each provider can communicate information to P2P clients through a
 portal known as an iTracker.  An iTracker could be identified through
 a DNS SRV record (perhaps with its own new record type), a whois
 look-up, or a trusted third party.
 An iTracker has different interfaces for different types of
 information that the provider may want to share.  The core interface
 allows the provider to express the "virtual cost" of its intradomain
 or interdomain links.  Virtual cost may reflect any kind of provider
 preferences and may be based on the provider's choice of metrics,
 including utilization, transit costs, or geography.  It is up to the
 provider to decide how dynamic it wants to be in updating its virtual
 cost determinations.
 In tests of this framework, two parallel swarms were created with
 approximately the same number of clients and similar geographical and
 network distributions, both sharing the same file.  One of the swarms
 used the P4P framework, with the ISP's network topology map as input
 to its iTracker, and the other swarm used traditional peer selection.
 The swarm without P4P saw 98% of traffic to and from peers external
 to the ISP, whereas with P4P that number was 50%.  Download
 completion times for the P4P-enabled swarm improved approximately 20%
 on average.

5.1.3. Multi-Layer, Tracker-Based Architecture

 The multi-layer, tracker-based P2P scheme described at the workshop
 is a generic example of an architecture that demonstrates how
 localization may be useful in principle.
 In a traditional, tracker-based P2P system, trackers provide clients
 with information about seeds and peers where clients can find the
 content they seek.  A multi-layered tracker architecture incorporates
 additional "local" trackers that provide the same information, but
 only for content located within their own local network scope.
 Client queries are re-directed from the global tracker to the
 appropriate local trackers.  Local trackers may also exist on
 multiple levels, in which case queries would be further re-directed.
 This sort of architecture could also serve hybrid P2P/content
 delivery networks, where the global tracker functions as both a
 tracker and a content server, and local trackers track locally
 provisioned caches in addition to seeds and peers.

Peterson & Cooper Informational [Page 10] RFC 5594 P2P Infrastructure July 2009

 One challenge in this architecture is determining what "local" means
 for trackers, seeds, and peers.  Locality could be dependent on
 traffic conditions, load balancing, static topology, policy, or some
 other metric.  These same considerations would also be crucial for
 determining appropriate cache placement in a hybrid network.
 This architecture presents in the abstract the problem of re-
 directing from a global entity to a local entity.  Client queries
 need to find their way to the appropriate local tracker.  This can be
 accomplished through an off-path, explicit mechanism where local
 trackers register with the global tracker in advance, or through an
 on-path approach where the network proxies P2P requests.  The off-
 path tracker format approach is preferable for performance and
 reliability reasons.
 Inasmuch as the multi-layer scheme might require ISPs to aid peers in
 finding optimal paths to unauthorized copies of copyrighted content,
 ISPs may be concerned about the legal liability of participating.

5.1.4. ISP-Aided Neighbor Selection

 ISPs have a lot of knowledge about their networks: everything from
 the bandwidth, geography, and service class of particular nodes to
 overarching routing policies, OSPF and BGP metrics, and distances to
 peering points.  The ISP-aided neighbor selection service described
 below seeks to leverage this knowledge without requiring ISPs to
 reveal any information that could not already be discerned through
 reverse-engineering by client applications.
 The service consists of an "oracle" hosted by an ISP.  The oracle
 receives a list of IP addresses from a network node, sorts the list
 according to its own confidential criteria, and returns the sorted
 list to the node.  The peer ranking provided by the oracle could be
 viewed as a special case of the virtual cost interface described in
 the previous section.
 This service could be used by P2P clients or trackers, or by any
 other application that would benefit from learning its ISP's
 connection preferences.  The oracle could be run as a web server or
 UDP service at a known location (perhaps similar to BIND).
 For interdomain ranking, an ISP could rank its own peers first, or it
 could base its ranking on the AS number of the IPs in the provided
 list.  Another option would be for multiple ISPs to work together to
 have their oracles exchange lists with each other.

Peterson & Cooper Informational [Page 11] RFC 5594 P2P Infrastructure July 2009

 The main challenge in implementing the oracle service is scalability.
 If peers need to communicate to the oracle the IP address of every
 peer they know, the size of oracle requests may be inordinately
 large.  Additionally, today's largest swarms approach 10000 peers,
 and with every peer requesting a sorted list, the oracle request
 volume will swell.  With the growth of business models dependent upon
 P2P for distribution of content, swarms in the future may be far
 larger, further exacerbating the problem.  Potential mitigations
 include having trackers, instead of peers, issue oracle requests, and
 using other peers' sorted lists as input, rather than always using an
 unsorted list.
 On the other hand, this approach is advantageous from a legal
 liability perspective, because it does not require ISPs to have any
 knowledge of where particular content might be located or to have any
 role in directing peers to particular content.

5.1.5. Caches

 Deploying caches as peers in P2P networks was suggested as a
 component of multiple proposals put forth at the workshop.  Caches
 may help to ease network load by reducing the need for peers to
 upload to each other and by localizing traffic.
 The two main concerns about P2P caches relate to network capacity and
 legal liability.  For caches to be useful, they will likely need to
 be large (one suggestion was that a 1 TB cache could service 30% of
 requests within a single AS, and a 100 TB cache could service 80% of
 requests).  Large caches will require sizable bandwidth in order to
 avoid contention among peers.  Caches would not be usefully placed
 within an HFC network on a cable system, for example.
 The legal liability attached to hosting a P2P cache likely reduces
 the incentives to do so.  Even under legal regimes where liability
 for caching may be unclear, ISPs and others may view hosting a cache
 as too great of a legal risk to be worthwhile.

5.1.6. Potential IETF Work

 Much of the localization work discussed at the workshop is still in
 its initial stages, and many questions remain about the value that
 localization provides for varying network and overlay architectures.
 More data is needed to evaluate the effects on both traffic load and
 client performance.  Understanding swarm distributions is important;
 swarms with long tails may not particularly benefit from
 localization.

Peterson & Cooper Informational [Page 12] RFC 5594 P2P Infrastructure July 2009

 Against this backdrop, the key task for the IETF (as identified at
 the workshop) is to pinpoint incrementally beneficial work items in
 the spaces discussed above.  In the future, it may be possible to
 standardize entire P2P mechanisms but, as a starting point, it makes
 more sense to single out core manageable components for
 standardization.  The focus should be on items that are not so
 specific to one ISP or P2P network that standardization is rendered
 useless.  Ideally, any mechanisms resulting from this work might
 apply to future applications that exhibit the same bandwidth-
 intensive properties as today's P2P file-sharing.
 In considering any of these items, it will be necessary to ensure
 that the information exchanged by networks and applications does not
 harm any of the parties involved.  Not every piece of information
 exchanged will be beneficial or verifiable, and this fact must be
 recognized and accounted for.  Solutions that leave applications or
 networks worse off than they already are today will not gain any
 traction.
 It should also not be assumed that a particular party will be best
 suited to provide a particular kind of information.  For example, an
 ISP may not know what the connection costs are in other ISPs'
 networks, whereas an overlay network that receives cost information
 from several ISPs may have a better handle on this kind of data.
 Standardization of information sharing should not assume the identity
 of particular parties doing the sharing.
 The list of potential work items discussed at the workshop is
 provided below.  Workshop participants showed particular interest in
 pursuing the first three items further.

5.1.6.1. AS Numbers

 P2P clients are currently reliant on IP-to-AS mapping tables when
 they want to determine AS numbers.  Providing a standard, easier way
 for clients to obtain this information may help to make peer
 selection more efficient on certain networks.

5.1.6.2. Querying for Preferred Peers

 In situations where a peer or tracker can make requests in real time
 to a service that expresses its ISP's peering preferences,
 standardizing a format for requests and responses may be useful.  The
 focus would be on the communication of the information, not on the
 criteria used to decide preferences.  The information provided to
 peers would have to be crafted to ensure that it protects the privacy
 of other peers and safeguards proprietary network information.

Peterson & Cooper Informational [Page 13] RFC 5594 P2P Infrastructure July 2009

5.1.6.3. Local Tracker, iTracker, Oracle, or Cache Discovery

 With the deployment of trackers, iTrackers, oracles, or other
 mechanisms that provide some information specific to a node's
 locality, nodes will need a way to find these resources.  One task
 for the IETF could be to explore a way to do discovery, potentially
 by leveraging an existing discovery protocol (DNS, DHCP, anycast,
 etc.).  Depending on the resource to be discovered, discovery may
 require only a simple look-up, or it may require a more complex
 determination of which resource is "closest" to the node issuing the
 request.

5.1.6.4. ISP Account Usage Information

 Where ISP subscribers are bound by network usage policies or volume-
 based quotas, it may be useful to have a standard way of
 communicating the subscriber's current usage status.  This would be
 similar to information about how many minutes of cell phone airtime
 are left in a subscriber's billing cycle.  Applications could use
 this information to make decisions about when and how to transfer
 data.  One challenge in implementing such a standard would be support
 for potentially limitless different ISP business models.  The level
 of granularity that an ISP is able to provide may also be constrained
 depending on the pricing model and how dynamic the information is
 expected to be.

5.1.6.5. Tracker Formats

 A multi-layered tracker approach could potentially be aided by a
 standard tracker format for re-directing from a global tracker to a
 local tracker.  While the extent to which existing trackers will be
 willing to consult with other trackers is unclear, the re-direction
 format may have an analog in another context -- many HTTP servers
 build their own indexes of mirror information for a similar purpose,
 though these are not standardized.  If the two problem spaces prove
 to be similar enough, there may be room to standardize a format
 across both.

5.2. New Approaches to Congestion Control

 One recent informal survey presented at the workshop found that ISPs
 perceive traffic volumes from heavy users to be a problem, but no
 single congestion management tool has been put to wide use.  Within
 developer and research communities, congestion issues raised by
 increased P2P traffic volumes have spurred new thinking about
 congestion-control mechanisms at both the transport layer and the
 application layer.  The subsections below explore some of these new
 ideas and highlight areas where IETF work may be appropriate.

Peterson & Cooper Informational [Page 14] RFC 5594 P2P Infrastructure July 2009

5.2.1. End-to-End Congestion Control

 As noted previously, uptake in P2P usage can result in perceptible
 end-user latency on the order of seconds for interactive
 applications.  One approach to resolving this "round-trip time (RTT)
 in seconds" problem would be for P2P clients to implement better
 congestion control that keeps the bottleneck full while yielding to
 keep the delay of competing traffic low.  Such an algorithm has been
 implemented in BitTorrent's client by continuously sampling one-way
 delay (separating propagation from queuing delay) and targeting a
 small queuing delay value.  This essentially approximates a scavenger
 service class in an end-to-end congestion-control mechanism by
 forcing bulk, elastic traffic to yield to competitors under
 congestion.
 In a similar vein, the P4P framework supports a component that allows
 applications to mark traffic as "bulk data" (not time sensitive).
 Applications adjust their behavior according to the feedback they
 receive from such markings.
 Experimenting with the standardization of these kinds of techniques
 or any congestion-control framework with design goals that differ
 from those of TCP may be helpful work for the IETF to pursue.

5.2.2. Weighted Congestion Control

 Congestion control has typically been implemented at a protocol level
 as an optional, cooperative effort between endpoints experiencing
 congestion, but in looking for a long-term approach to congestion
 control, we may need a more rigorous way for available bandwidth to
 be allocated by and between the hosts using a network.  The idea
 behind weighted congestion control is to allow hosts to give more
 weight to interactive applications during times of congestion.
 Comparing such an approach with Diffserv showcases its strengths and
 weaknesses.  Unlike Diffserv, weighted congestion control could be
 implemented on hosts with a simple extension to socket APIs (although
 consensus among OSes would be necessary for portability).  Through
 weighted congestion control, control resides with the host, whereas
 even when Diffserv APIs are available, it is difficult for a host to
 know that the network is complying with its classifications.  With
 weighted congestion control, hosts need some disincentive to setting
 their weights at maximum levels, whereas Diffserv was not designed
 for individual users to employ.  Both approaches must rely on traffic
 senders to set policies, meaning that the congestion issues stemming
 from P2P use on the receiver side are not aided by either mechanism.

Peterson & Cooper Informational [Page 15] RFC 5594 P2P Infrastructure July 2009

 With Diffserv, a light user may waste his or her priority connecting
 to a heavy user on another network, which is not a problem with host-
 controlled weighting.
 Weighted congestion control is just one example of a generalized set
 of features that characterize useful approaches to congestion
 control.  These characteristics include full user control of
 priorities within a user's own scope and no possibility of
 interpreting ISP behavior as discriminatory.  The former means that
 ISPs should not override user decisions arbitrarily (though this does
 not preclude an ISP from offering prioritization as an option).  The
 latter means that the metric for decision-making needs to obviate
 suspicion of ISP motivations.
 One metric that meets these criteria is a harm (cost) metric, where
 cost is equal to the amount of data that was not served to its
 destination.  Using this metric, cost is greatest when traffic peaks
 are greatest.  It allows for a policy of not sending too much data
 during times of congestion, without specifying exactly how much is
 too much.  The cost metric could be used either for a Diffserv
 approach or for weighted congestion control.
 One important limitation on ISPs from a congestion-control
 perspective is that they do not have a window into congestion on
 other ISPs' networks.  Solving this problem requires a separate
 mechanism to express congestion across domains.
 One potential avenue for the IETF or IRTF to pursue would be to
 establish a long-term design team to assess congestion problems in
 general and the long-term effects of any proposed quick fixes.  These
 issues are not necessarily confined to P2P and should be viewed in
 the broader context of massive increases in bandwidth use.

5.3. Quality of Service

 Although ISPs have implemented a wide variety of short-term
 approaches to dealing with congestion, several of these may not be
 viable in the long term.  For example, some ISPs have found that
 using deep packet inspection to change the delivery characteristics
 of certain traffic at times of congestion is more cost effective than
 adding additional bandwidth.  Over time, this approach could lead to
 a cat-and-mouse game where applications providers continually adapt
 to avoid being correctly classified by Deep Packet Inspection (DPI)
 equipment.  Similarly, ISPs implementing traffic analysis to identify
 P2P traffic may find that, in the long run, the overhead required of
 an effective classification scheme will be excessive.

Peterson & Cooper Informational [Page 16] RFC 5594 P2P Infrastructure July 2009

 Quality of service (QoS) arrangements may be more suitable in the
 long term.  One approach that distinguishes certain classes of
 traffic during times of congestion was described in Section 3.3.  A
 standardized mechanism that may be useful for implementing QoS is
 Differentiated Services Code Points (DSCP) [RFC2474].
 With DSCP, devices at the edge of the network mark packets with the
 service level they should receive.  Nodes within the network do not
 need to remember anything about service flows, and applications do
 not need to request a particular service level.  Users effectively
 avoid self-interference through service classification.
 Although DSCP may have many uses, perhaps the most relevant to the
 P2P congestion issue is its ability to facilitate usage-based
 charging.  User pricing agreements that charge a premium for real-
 time traffic and best-effort traffic could potentially shape user
 behavior, resulting in reduced congestion (although ISPs would need a
 mechanism to mitigate the risk of charging subscribers for things
 like unintentional malware downloads or DoS attacks).  DSCP could
 also be used to limit a user's supply of high-priority bandwidth,
 resulting in a similar effect.
 Equipment to support DSCP is already available.  Although there has
 been some concern about a perceived lack of DSCP deployment, it is
 widely used by enterprise customers, and growth has been strong due
 to uptake in VoIP at the enterprise level.
 However, DSCP still faces deployment hurdles on many networks.
 Perhaps the largest barrier of all to wide deployment is the lack of
 uniform code points to be used across networks.  For example, the
 latest Windows Vista API marks voice traffic as CS7, above the
 priority reserve for router traffic.  To properly take advantage of
 this change, every switch will need to re-mark all traffic.  In
 addition, disparate ISPs are currently without a means of verifying
 each others' markings and thus may be unwilling to trust the markings
 they receive.

6. Applications Opening Multiple TCP Connections

 The workshop discussions about P2P congestion spurred a related
 discussion about applications (P2P or otherwise) that open multiple
 TCP connections.  With multiple users sharing one link, TCP flow
 fairness gives users with multiple open connections a larger
 proportion of bandwidth.  Since some P2P protocols use multiple open
 connections for a single file transfer and users often pursue
 multiple transfers at once, this can cause a P2P user to have many
 more open connections at once than other users on the same link.  The
 same is true for users of other applications that open multiple

Peterson & Cooper Informational [Page 17] RFC 5594 P2P Infrastructure July 2009

 connections.  A single user with multiple open connections is not
 necessarily a problem on its face, but the fact that fairness is
 determined per flow rather than per user leaves that impression.
 Workshop participants thought it may be useful for the IETF to
 provide some information about such situations.

7. Costs and Congestion

 Workshop participants expressed diverging opinions about how much the
 cost of transferring data -- as experienced by ISPs and, by
 extension, their subscribers -- should factor into IETF thinking on
 P2P traffic issues.
 On one hand, bandwidth costs may be significant, even when viewed in
 isolation from congestion issues.  Some estimates put the total cost
 of shipping 1 GB between $0.10 and $2.  The cost of transit bandwidth
 in markets where subscribers are charged flat rates appears to have
 leveled off and may no longer be getting cheaper.  Thus, it may be
 reasonable to expect more service providers to move to volume-based
 pricing (where they have not already done so) as a means to control
 congestion and increase revenues.  This is only feasible if bandwidth
 consumption is visible to end users, which argues for some mechanism
 of exposing quotas and usage to applications.  However, expressing
 cost information may be outside of the technical purview of the IETF.
 On the other hand, 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.
 Workshop participants felt that the issues highlighted here may be
 useful fodder for IRTF work.

8. Next Steps

 The IETF community recognizes the significance of both increasing P2P
 traffic volumes and network load at large.  The importance of
 addressing the impact of high-volume, delay-tolerant data transfer on
 end-user experiences was highly apparent at the workshop.
 At the conclusion of the workshop and in the days following, it
 became clear that the largest areas of interest fell into two
 categories: transport-related issues and improved peer selection.

Peterson & Cooper Informational [Page 18] RFC 5594 P2P Infrastructure July 2009

8.1. Transport Issues

 Two main transport-related work items evolved out of the workshop.
 The first was the creation of a standardized, delay-based, end-to-end
 congestion-control mechanism that applications such as P2P clients
 could use to reduce their own impact on interactive applications in
 use on shared links (as described in Section 5.2.1).  The second was
 an informational document that describes the current practice of P2P
 applications opening multiple transport connections and that makes
 recommendations about the best practices for doing so (as discussed
 in Section 6).

8.2. Improved Peer Selection

 Participants expressed strong interest in further pursuing the range
 of concepts described in Section 5.1 that support mechanisms for
 information sharing between networks and applications to help improve
 peer selection.  Adding to the appeal of this topic is its potential
 utility for applications other than P2P that may also benefit from
 information about the network.  Because the scope of potential
 solutions discussed at the workshop was broad, extracting out the
 most feasible pieces to pursue is the necessary first step.

9. Security Considerations

 The workshop discussions covered a range of potential engineering
 activities, each with its own security considerations.  For example,
 if networks are to provide preference or topology information to
 applications, the applications may desire some means of verifying the
 authenticity of the information.  As the IETF community begins to
 pursue specific avenues arising out of this workshop, addressing
 relevant security requirements will be crucial.

10. Acknowledgements

 The IETF would like to thank MIT, which hosted the workshop, and all
 those people at MIT and elsewhere who assisted with the organization
 and logistics of the workshop.
 The IETF is grateful to the program committee (listed in Appendix A)
 for their time and energy in organizing the workshop, reviewing the
 position papers, and crafting an event of value for all participants.
 The IETF would also like to thank the scribes, Spencer Dawkins and
 Alissa Cooper, who diligently recorded the proceedings during the
 workshop.

Peterson & Cooper Informational [Page 19] RFC 5594 P2P Infrastructure July 2009

 A special thanks to all the participants in the workshop (listed in
 Appendix B) who took the time, came to the workshop to participate in
 the discussions, and put in the effort to make this workshop a
 success.  The IETF especially appreciates the effort of those that
 prepared and made presentations at the workshop.

11. Informative References

 [DOCSIS]   CableLabs, "DOCSIS Specifications - DOCSIS 2.0 Interface",
            2008, <http://www.cablemodem.com/specifications/
            specifications20.html>.
 [P4P]      Xie, H., Yang, Y., Krishnamurthy, A., and A. Silberschatz,
            "P4P: Provider Portal for Applications", August 2008,
            <http://uwnews.org/relatedcontent/2008/August/
            rc_parentID43281_thisID43282.pdf>.
 [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
            "Definition of the Differentiated Services Field (DS
            Field) in the IPv4 and IPv6 Headers", RFC 2474,
            December 1998.
 [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
            and W. Weiss, "An Architecture for Differentiated
            Services", RFC 2475, December 1998.

Peterson & Cooper Informational [Page 20] RFC 5594 P2P Infrastructure July 2009

Appendix A. Program Committee

    Dave Clark, MIT
    Lars Eggert, TSV AD
    Cullen Jennings, RAI AD
    John Morris, Center for Democracy and Technology
    Jon Peterson, RAI AD
    Danny Weitzner, MIT

Appendix B. Workshop Participants

    Vinay Aggarwal, Deutsche Telekom Labs, TU Berlin
    Marvin Ammori, Free Press
    Loa Andersson, Acreo AB
    Jari Arkko, Ericsson
    Alan Arolovitch, PeerApp
    Timothy Balcer
    Mary Barnes, Nortel
    Colby Barth, Cisco Systems
    John Barlett, NetForecast
    Salman Baset, Columbia University
    Chris Bastian, Comcast
    Matthew Bell, Charter Communications
    Donald Bowman, Sandvine Inc.
    Scott Bradner, Harvard University
    Bob Briscoe, British Telecom
    David Bryan, SIPeerior Technologies

Peterson & Cooper Informational [Page 21] RFC 5594 P2P Infrastructure July 2009

    Rex Bullinger, National Cable & Telecommunications Association
    Gonzalo Camarillo, Ericsson
    Mary-Luc Champel, Thomson
    William Check, NCTA
    Alissa Cooper, Center for Democracy and Technology
    Patrick Crowley, Washington University
    Leslie Daigle, Internet Society
    Spencer Dawkins
    John Dickinson, Bright House Networks
    Lisa Dusseault, CommerceNet
    Lars Eggert, Nokia Research Center
    Joe Godas, Cablevision
    Vernon Groves, Microsoft
    Daniel Grunberg, Immedia Semiconductor
    Carmen Guerrero, University Carlos III Madrid
    Vijay Gurbani, Bell Laboratories/Alcatel-Lucent
    William Hawkins III, ITT
    Volker Hilt, Bell Labs, Alcatel-Lucent
    Russell Housley, Vigil Security, LLC
    Robert Jackson, Camiant
    Cullen Jennings, Cisco Systems
    Paul Jessop, RIAA
    XingFeng Jiang, Huawei
    Michael Kelsen, Time Warner Cable

Peterson & Cooper Informational [Page 22] RFC 5594 P2P Infrastructure July 2009

    Tom Klieber, Comcast
    Eric Klinker, BitTorrent Inc.
    Umesh Krishnaswamy
    Gregory Lebovitz, Juniper
    Erran Li, Bell-Labs
    Jason Livingood, Comcast
    Andrew Malis, Verizon
    Enrico Marocco, Telecom Italia Lab
    Marcin Matuszewski, Nokia
    Danny McPherson, Arbor Networks, Inc.
    Michael Merritt, AT&T
    Lyle Moore, Bell Canada
    John Morris, Center for Democracy and Technology
    Jean-Francois Mule, Cablelabs
    David Oran, Cisco Systems
    Reinaldo Penno, Juniper Networks
    Jon Peterson, NeuStar
    Howard Pfeffer, Time Warner Cable
    Laird Popkin, Pando Networks
    Stefano Previdi, Cisco systems
    Satish Putta
    Eric Pescorla
    Benny Rodrig, Avaya
    Damien Saucez, UCLouvain (UCL)

Peterson & Cooper Informational [Page 23] RFC 5594 P2P Infrastructure July 2009

    Henning Schulzrinne, Columbia University
    Michael Sheehan, Juniper Networks
    Don Shulzrinne, Immedia Semiconductor
    David Sohn, Center for Democracy and Technology
    Martin Stiemerling, NEC
    Clint Summers, Cox Communications
    Robert Topolski
    Mark Townsley, Cisco Systems
    Yushun Wang, Microsoft
    Hao Wang, Yale University
    Ye Wang, Yale University
    David Ward, Cisco
    Nicholas Weaver, ICSI
    Daniel Weitzner, MIT
    Magnus Westerlund, Ericsson
    Thomas Woo, Bell Labs
    Steve Worona, EDUCAUSE
    Richard Woundy, Comcast
    Haiyong Xie
    Richard Yang, Yale University

Appendix C. Workshop Agenda

 1.  Welcome/Note Well/Intro Slides
     Cullen Jennings
 2.  Service Provider Perspective (Comcast)
     Rich Woundy and Jason Livingood

Peterson & Cooper Informational [Page 24] RFC 5594 P2P Infrastructure July 2009

 3.  Application Designer Perspective (BitTorrent)
     Stanislav Shalunov
 4.  Lightning Talks & General Discussion
     Robb Topoloski
     Nick Weaver
     Leslie Daigle
 5.  Localization and Caches
     Laird Popkin and Haiyong Xie
     Yu-Shun Wang
     Vinay Aggrawal
 6.  New Approaches to Congestion
     Bob Briscoe
     Marcin Matuszewski
 7.  Quality of Service
     Mary Barnes
     Henning Schulzrinne
 8.  Conclusions & Wrap-Up

Appendix D. Slides and Position Papers

 Slides and position papers are available at http://
 trac.tools.ietf.org/area/rai/trac/wiki/PeerToPeerInfrastructure.
 Position papers:
 Nick Weaver - The case for "Ugly Now" User Fairness
 Paul Jessop - Position paper of the RIAA
 Nikloaos Laotaris, Pablo Rodriguez, Laurent Massoulie - ECHOES: Edge
 Capacity Hosting Overlays of Nano Data Centers
 Bruce Davie, Stefano Previdi, Jan Medved, Albert Tian - Peer
 Selection Guidance
 Marie-Jose Montpetit - Community Networks: getting P2P out of prison
 - the next steps
 D. Bryan, S. Dawkins, B. Lowekamp, E. Shim - Infrastructure-related
 Attributes of App Scenarios for P2PSIP
 Jiang XingFeng - Analysis of the Service Discovery in DHT network

Peterson & Cooper Informational [Page 25] RFC 5594 P2P Infrastructure July 2009

 R. Penno - P2P Status and Requirements
 Patrick Crowley and Shakir James - Symbiotic P2P: Resolving the
 conflict between ISPs and BitTorrent through mutual cooperation
 Robb Topolski - Framing Peer to Peer File Sharing
 M. Stiemerling, S. Niccolini, S. Kiesel, J. Seedorf - A Network
 Cooperative Overlay System
 Y. Wang, S. Tan, R. Grove - Traffic Localization with Multi-Layer,
 Tracker-Based Peer-to-Peer Content Distribution Architecture
 Haiyong Xie, Y. Richard Yang, Avi Silberschatz, Arvind Krishnamurthy,
 Laird Popkin - P4P: Provider Portal for P2P Applications
 Michael Merritt, Doug Pasko, Laird Popkin - Network-Friendly Peer-to-
 Peer Services
 Camiant (Jackson) - Camiant Submission
 Jason Livingood, Rich Woundy - Comcast Submission
 Benny Rodrig - Enterprise IP Networks and the P2P Traffic Load Impact
 Ted Hardie - Peer-to-Peer traffic and "Unattended Consequences"
 Jiang XingFeng, Ning Zong - Content Replication for Internet P2P
 Applications
 Sandvine (Dundas) - Analysis of Traffic Demographics in Broadband
 networks
 Sandvine (Dundas) - Traffic Management in a World with Network
 Neutrality
 Stanislav Shalunov - Users want P2P, we make it work
 R. Cuevas, A. Cuevas, I. Martinez-Yelmo, C. Guerrero - Internet scale
 mobility service: a case study on building a DHT based service for
 ISPs
 M. Barnes, B. McCormick - Peer to Peer Infrastructure Considerations
 Henning Schulzrinne - Encouraging Bandwidth Efficiency for Peer-to-
 Peer Applications

Peterson & Cooper Informational [Page 26] RFC 5594 P2P Infrastructure July 2009

 Damien Saucez, Benoit Donnet, Olivier Bonaventure, Dimitri
 Papdimitriou - Towards an Open Path Selection Architecture
 Eric Rescorla - Notes on P2P Blocking and Evasion
 Vinay Aggrawal, Anja Feldmann - ISP-Aided Neighbor Selection in P2P
 Systems
 Enrico Marocco, Vijay K. Gurbani, Volker Hilt, Ivica Rimac, Marco
 Tomsu - Peer-to-Peer Infrastructure: A Survey of Research on the
 Application-Layer Traffic Optimization Problem and the Need for Layer
 Cooperation
 Tony Moncaster, Bob Briscoe, Louise Burness - Is There a Problem With
 Peer-to-peer Traffic?
 David Sohn, Alissa Cooper - Peer-to-Peer Infrastructure
 Considerations
 Bob Briscoe, Lou Burness, Tony Moncaster, Phil Eardley - Solving this
 traffic management problem... and the next, and the next
 Hannes Tschofenig, Marcin Matuszewski - Dealing with P2P Traffic in
 an Operator Network
 Jean-Francois Mule - CableLabs submission
 Alan Arolovitch - Peer-to-peer infrastructure: Case for cooperative
 P2P caching
 Leslie Daigle - Defining Success: Questions for the Future of the
 Internet and Bandwidth-Intensive Activities
 William Check, Rex Bullinger -- NCTA Position Paper
 Jari Arkko - Incentives and Deployment Considerations for P2PI
 Solutions

Peterson & Cooper Informational [Page 27] RFC 5594 P2P Infrastructure July 2009

Authors' Addresses

 Jon Peterson
 NeuStar
 USA
 EMail: jon.peterson@neustar.biz
 Alissa Cooper
 Center for Democracy & Technology
 1634 Eye St. NW, Suite 1100
 Washington, DC  20006
 USA
 EMail: acooper@cdt.org

Peterson & Cooper Informational [Page 28]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5594.txt · Last modified: 2009/07/31 19:42 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki