doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc5632.txt b/doc/rfc/rfc5632.txt
new file mode 100644
index 0000000..1834d0c
--- /dev/null
+++ b/doc/rfc/rfc5632.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                       C. Griffiths
+Request for Comments: 5632                                  J. Livingood
+Category: Informational                                          Comcast
+                                                               L. Popkin
+                                                                   Pando
+                                                               R. Woundy
+                                                                 Comcast
+                                                                 Y. Yang
+                                                                    Yale
+                                                          September 2009
+
+
+Comcast's ISP Experiences in a Proactive Network Provider Participation
+                     for P2P (P4P) Technical Trial
+
+Abstract
+
+   This document describes the experiences of Comcast, a large cable
+   broadband Internet Service Provider (ISP) in the U.S., in a Proactive
+   Network Provider Participation for P2P (P4P) technical trial in July
+   2008.  This trial used P4P iTracker technology, which is being
+   considered by the IETF as part of the Application Layer Transport
+   Optimization (ALTO) working group.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Griffiths, et al.            Informational                      [Page 1]
+
+RFC 5632                Comcast P4P Experiences           September 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  High-Level Details . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Differences between the P4P iTrackers Used . . . . . . . . . .  4
+     3.1.  P4P Fine Grain . . . . . . . . . . . . . . . . . . . . . .  4
+     3.2.  P4P Coarse Grain . . . . . . . . . . . . . . . . . . . . .  5
+     3.3.  P4P Generic Weighted . . . . . . . . . . . . . . . . . . .  5
+   4.  High-Level Trial Results . . . . . . . . . . . . . . . . . . .  5
+     4.1.  Swarm Size . . . . . . . . . . . . . . . . . . . . . . . .  6
+     4.2.  Impact on Download Speed . . . . . . . . . . . . . . . . .  7
+     4.3.  General Impacts on Upstream and Downstream Traffic and
+           Other Interesting Data . . . . . . . . . . . . . . . . . .  7
+   5.  Important Notes on Data Collected  . . . . . . . . . . . . . .  8
+   6.  Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
+   9.  Informative References . . . . . . . . . . . . . . . . . . . . 10
+
+1.  Introduction
+
+   Comcast is a large broadband Internet Service Provider (ISP), based
+   in the U.S., serving the majority of its customers via cable modem
+   technology.  A trial was conducted in July 2008 with Pando Networks,
+   Yale, and several ISP members of the P4P working group, which is part
+   of the Distributed Computing Industry Association (DCIA).  Comcast is
+   a member of the DCIA's P4P Working Group, whose mission is to work
+   with Internet Service Providers (ISPs), peer-to-peer (P2P) companies,
+   and technology researchers to develop "P4P" mechanisms, such as so-
+   called "iTrackers" (hereafter P4P iTrackers), that accelerate
+   distribution of content and optimize utilization of ISP network
+   resources.  P4P iTrackers theoretically allow P2P networks to
+   optimize traffic within each ISP, reducing the volume of data
+   traversing the ISP's infrastructure and creating a more manageable
+   flow of data.  P4P iTrackers can also accelerate P2P downloads for
+   end users.
+
+   P4P's iTracker technology [SIGCOMM] was conceptually discussed with
+   the IETF at the Peer-to-Peer Infrastructure (P2Pi) Workshop held on
+   May 28, 2008, at the Massachusetts Institute of Technology (MIT), as
+   documented in [RFC5594].  This work was discussed in greater detail
+   at the 72nd meeting of the IETF, in Dublin, Ireland, in the ALTO BoF
+   (Birds of a Feather meeting) on July 29, 2008.  Due to interest from
+   the community, Comcast shared P4P iTracker trial data at the 73rd
+   meeting of the IETF, in Minneapolis, Minnesota, in the ALTO BoF on
+   November 18, 2008.  Since that time, discussion of P4P iTrackers and
+   alternative technologies has continued among participants of the ALTO
+   working group.
+
+
+
+Griffiths, et al.            Informational                      [Page 2]
+
+RFC 5632                Comcast P4P Experiences           September 2009
+
+
+   The P4P iTracker trial was conducted, in cooperation with Pando,
+   Yale, and three other P4P member ISPs, from July 2 to July 17, 2008.
+   This was the first P4P iTracker trial over a cable broadband network.
+   The trial used a Pando P2P client, and Pando distributed a special
+   21-MB licensed video file in order to measure the effectiveness of
+   P4P iTrackers.  A primary objective of the trial was to measure the
+   effects that increasing the localization of P2P swarms would have on
+   P2P uploads, P2P downloads, and ISP networks, in comparison to normal
+   P2P activity.
+
+2.  High-Level Details
+
+   As noted in Section 1 of [DynamicSwarmMgmt], a swarm is defined in
+   the following way:
+
+      The content and the set of peers distributing it [a file] is
+      usually called a torrent.  A peer that only uploads content is
+      called a seed, while a peer that uploads and downloads at the same
+      time is called a leecher.  The connected set of peers
+      participating in the piece exchanges of a torrent is referred to
+      as a swarm.
+
+   There were five different swarms for the content used in the trial.
+   The second, third, and fourth used different P4P iTrackers: Generic,
+   Coarse Grained, and Fine Grained, all of which are described in
+   Section 3.  The fifth was a proprietary Pando mechanism.  (The
+   results of the fifth swarm, while satisfactory, are not included here
+   since our focus is on open standards and a mechanism that may be
+   leveraged for the benefit of the entire community of P2P clients.)
+   Comcast deployed a P4P iTracker server in its production network to
+   support this trial, and configured multiple iTracker files to provide
+   varying levels of localization to clients.
+
+   In the trial itself, a P2P client begins a P2P session by querying a
+   pTracker, which runs and manages the P2P network.  The pTracker
+   occasionally queries the P4P iTracker, which in this case was
+   maintained by Comcast, the ISP.  Other ISPs either managed their own
+   P4P iTracker or used Pando or Yale to host their P4P iTracker files.
+   The P4P iTracker returns network topology information to the
+   pTracker, which then communicates with P2P clients, in order to
+   enable P2P clients to make network-aware decisions regarding peers.
+
+   The Pando client was enabled to capture extended logging, when the
+   version of the client included support for it.  The extended logging
+   included the source and destination IP address of all P2P transfers,
+   the number of bytes transferred, and the start and end timestamps.
+   This information gives a precise measurement of the data flow in the
+   network, allowing computation of data transfer volumes as well as
+
+
+
+Griffiths, et al.            Informational                      [Page 3]
+
+RFC 5632                Comcast P4P Experiences           September 2009
+
+
+   data flow rates at each point in time.  With standard logging, Pando
+   captured the start and completion times of every download, as well as
+   the average transfer rate observed by the client for the download.
+
+   Pando served the data from an origin server external to Comcast's
+   network.  This server served about 10 copies of the file, after which
+   all transfers (about 1 million downloads across all ISPs) were
+   performed purely via P2P.
+
+   The P2P clients in the trial start with tracker-provided peers, then
+   use peer exchange to discover additional peers.  Thus, the initial
+   peers were provided according to P4P iTracker guidance (90% guidance
+   based on P4P iTracker topology and 10% random guidance), then later
+   peers discover the entire swarm via either additional announces or
+   peer exchange.
+
+3.  Differences between the P4P iTrackers Used
+
+   Given the size of the Comcast network, it was felt that in order to
+   truly evaluate the P4P iTracker application we would need to test
+   various network topologies that reflected its network and would help
+   gauge the level of effort and design requirements necessary to get
+   correct statistical data out of the trial.  In all cases, P4P
+   iTrackers were configured with automation in mind, so that any
+   successful P4P iTracker configuration would be automatically
+   updating, rather than manually configured on an ongoing basis.  All
+   P4P iTrackers were hosted on the same small server, and it appeared
+   to be relatively easy and inexpensive to scale up a P4P iTracker
+   infrastructure should P4P iTracker-like mechanisms become
+   standardized and widely adopted.
+
+3.1.  P4P Fine Grain
+
+   The Fine Grain topology was the first and most complex P4P iTracker
+   that we built for this trial.  It was a detailed mapping of Comcast
+   backbone-connected network Autonomous System Numbers (ASNs) to IP
+   Aggregates, which were weighted based on priority and distance from
+   each other.  Included in this design was a prioritization of all Peer
+   and Internet transit connected ASNs to the Comcast backbone to ensure
+   that P4P traffic would prefer settlement-free and lower-cost networks
+   first, and then more expensive transit links.  This attempted to
+   optimize and lower transit costs associated with this traffic.  We
+   then took the additional step of detailing each ASN and IP Aggregate
+   into IP subnets down to Optical Transport Nodes (OTNs) where all
+   Cable Modem Termination Systems (CMTS, as briefly defined in Section
+   2.6 of [RFC3083]) reside .  This design gave a highly localized and
+   detailed description of the Comcast network for the iTracker to
+   disseminate.  This design defined 1,182 P4P iTracker node
+
+
+
+Griffiths, et al.            Informational                      [Page 4]
+
+RFC 5632                Comcast P4P Experiences           September 2009
+
+
+   identifiers, and resulted in a 107,357-line configuration file.
+
+   This P4P iTracker was obviously the most time-consuming to create and
+   the most complex to maintain.  Trial results indicated that this
+   level of localization was too high, and was less effective compared
+   to lower levels of localization.
+
+3.2.  P4P Coarse Grain
+
+   Given the level of detail in the Fine Grain design, it was important
+   that we also enable a high-level design, which still used priority
+   and weighting mechanisms for the Comcast backbone and transit links.
+   The Coarse Grain design was a limited or summarized version of the
+   Fine Grain design, which used the ASN to IP Aggregate and weighted
+   data for transit links, but removed all additional localization data.
+   This ensured we would get similar data sets from the Fine Grain
+   design, but without the more detailed localization of each of the
+   networks attached to the Comcast backbone.  This design defined 22
+   P4P iTracker node identifiers, and resulted in a 998-line
+   configuration file.
+
+   From an overall cost, complexity, risk, and effectiveness standpoint,
+   this was judged to be the optimal P4P iTracker for Comcast.
+   Importantly, this did not require revealing the complex, internal
+   network topology that the Fine Grain did.  Updates to this iTracker
+   were also far simpler to automate, which will better ensure that it
+   is accurate over time, and keeps administrative overhead relatively
+   low.  However, the differences, costs, and benefits of Coarse Grain
+   and Generic Weighted (see below) likely merit further study.
+
+3.3.  P4P Generic Weighted
+
+   The Generic Weighted design was a copy of the Coarse Grained design,
+   but instead of using ISP-designated priority and weights, all weights
+   were defaulted to pre-determined parameters that the Yale team had
+   designed.  All other data was replicated from the Coarse Grain
+   design.  Gathering and providing the information necessary to support
+   the Generic Weighted iTracker was roughly the same level of effort as
+   for Coarse Grain.
+
+4.  High-Level Trial Results
+
+   Trial data was collected by Pando Networks and Yale University, and
+   raw trial results were shared with Comcast and all of the other ISPs
+   involved in the trial.  Analysis of the raw results was performed by
+   Pando and Yale, and these organizations delivered an analysis of the
+   P4P iTracker trial.  Using the raw data, Comcast also analyzed the
+   trial results.  Furthermore, the raw trial results for Comcast were
+
+
+
+Griffiths, et al.            Informational                      [Page 5]
+
+RFC 5632                Comcast P4P Experiences           September 2009
+
+
+   shared with Net Forecast, Inc., which performed an independent
+   analysis of the trial for Comcast.
+
+4.1.  Swarm Size
+
+   During the trial, downloads peaked at 24,728 per day, per swarm, or
+   nearly 124,000 per day for all five swarms.  The swarm size peaked at
+   11,703 peers per swarm, or nearly 57,000 peers for all five swarms.
+   We observed a comparable number of downloads in each of the five
+   swarms.
+
+   For each swarm, Table 1 below gives the number of downloads per swarm
+   from Comcast that finished downloading, and the number of downloads
+   from Comcast that canceled downloading before finishing.
+
+                  Characteristics of P4P iTracker Swarms:
+
+   +-----------+-----------+---------------+------------+--------------+
+   |   Swarm   | Completed | Cancellations |    Total   | Cancellation |
+   |           | Downloads |               |  Attempts  |     Rate     |
+   +-----------+-----------+---------------+------------+--------------+
+   |   Random  |   2,719   |       89      |    2,808   |     3.17%    |
+   | (Control) |           |               |            |              |
+   | --------- | --------- |  -----------  | ---------- |  ----------- |
+   |  P4P Fine |   2,846   |       64      |    2,910   |     2.20%    |
+   |  Grained  |           |               |            |              |
+   | --------- | --------- |  -----------  | ---------- |  ----------- |
+   |    P4P    |   2,775   |       63      |    2,838   |     2.22%    |
+   |  Generic  |           |               |            |              |
+   |   Weight  |           |               |            |              |
+   | --------- | --------- |  -----------  | ---------- |  ----------- |
+   |    P4P    |   2,886   |       52      |    2,938   |     1.77%    |
+   |   Coarse  |           |               |            |              |
+   |  Grained  |           |               |            |              |
+   +-----------+-----------+---------------+------------+--------------+
+
+              Table 1: Per-Swarm Size and Cancellation Rates
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Griffiths, et al.            Informational                      [Page 6]
+
+RFC 5632                Comcast P4P Experiences           September 2009
+
+
+4.2.  Impact on Download Speed
+
+   The results of the trial indicated that P4P iTrackers can improve the
+   speed of downloads to P2P clients.  In addition, P4P iTrackers were
+   effective in localizing P2P traffic within the Comcast network.
+
+                   Impact of P4P iTrackers on Downloads:
+
+   +--------------+------------+------------+-------------+------------+
+   |     Swarm    | Global Avg |   Change   | Comcast Avg |   Change   |
+   |              |     bps    |            |     bps     |            |
+   +--------------+------------+------------+-------------+------------+
+   |    Random    |   144,045  |     n/a    | 254,671 bps |     n/a    |
+   |   (Control)  |     bps    |            |             |            |
+   |  ----------  | ---------- | ---------- |  ---------- | ---------- |
+   |   P4P Fine   |   162,344  |    +13%    | 402,043 bps |    +57%    |
+   |    Grained   |     bps    |            |             |            |
+   |  ----------  | ---------- | ---------- |  ---------- | ---------- |
+   |  P4P Generic |   163,205  |    +13%    | 463,782 bps |    +82%    |
+   |    Weight    |     bps    |            |             |            |
+   |  ----------  | ---------- | ---------- |  ---------- | ---------- |
+   |  P4P Coarse  |   166,273  |    +15%    | 471,218 bps |    +85%    |
+   |    Grained   |     bps    |            |             |            |
+   +--------------+------------+------------+-------------+------------+
+
+           Table 2: Per-Swarm Global and Comcast Download Speeds
+
+4.3.  General Impacts on Upstream and Downstream Traffic and Other
+      Interesting Data
+
+   An analysis of the effects of P4P iTracker use on upstream
+   utilization and Internet transit was also interesting.  It did not
+   appear that P4P iTrackers significantly increased upstream
+   utilization in the Comcast access network; in essence, uploading was
+   already occurring no matter what and a P4P iTracker in and of itself
+   did not appear to materially increase uploading for this specific,
+   licensed content.  (A P4P iTracker is not intended as a solution for
+   the potential of network congestion to occur.)  Random was 143,236 MB
+   and P4P Generic Weight was 143,143 MB, while P4P Coarse Grained was
+   139,669 MB.  We also observed that using a P4P iTracker reduced
+   outgoing Internet traffic by an average of 34% at peering points.
+   Random was 134,219 MB and P4P Generic Weight was 91,979 MB, while P4P
+   Coarse Grained was 86,652 MB.
+
+   In terms of downstream utilization, we observed that the use of a P4P
+   iTracker reduced incoming Internet traffic by an average of 80% at
+   peering points.  Random was 47,013 MB, P4P Generic Weight was 8,610
+   MB, and P4P Coarse Grained was 7,764 MB.  However, we did notice that
+
+
+
+Griffiths, et al.            Informational                      [Page 7]
+
+RFC 5632                Comcast P4P Experiences           September 2009
+
+
+   download activity in the Comcast access network increased somewhat,
+   from 56,030 MB for Random, to 59,765 MB for P4P Generic Weight, and
+   60,781 MB for P4P Coarse Grained.  Note that for each swarm, the
+   number of downloaded bytes according to logging reports is very close
+   to the number of downloads multiplied by file size.  But they do not
+   exactly match due to log report errors and duplicated chunks.  One
+   factor contributing to the differences in access network download
+   activity is that different swarms have different numbers of
+   downloaders, due to random variations during uniform random
+   assignment of downloaders to swarms (see Table 1).  One interesting
+   observation is that Random has higher cancellation rate (3.17%) than
+   that of the guided swarms (1.77%-2.22%).  Whether guided swarms
+   achieve lower cancellation rate is an interesting issue for future
+   research.
+
+5.  Important Notes on Data Collected
+
+   Raw data is presented in this document.  We did not normalize traffic
+   volume data (e.g., upload and download) by the number of downloads in
+   order to preserve this underlying raw data.
+
+   We also recommend that readers not focus too much on the absolute
+   numbers, such as bytes downloaded from internal sources and bytes
+   downloaded from external sources.  Instead, we recommend readers
+   focus on ratios such as the percentage of bytes downloaded that came
+   from internal sources in each swarm.  As a result, the small random
+   variation between number of downloads of each swarm does not distract
+   readers from important metrics like shifting traffic from external to
+   internal sources, among other things.
+
+   We also wish to note that the data was collected from a sample of the
+   total swarm.  Specifically, there were some peers running older
+   versions of the Pando client that did not implement the extended
+   transfer logging.  For those nodes, which participated in the swarms
+   but did not report their data transfers, we have download counts.
+   The result of this is that, for example, the download counts
+   generated from the standard logging are a bit higher than the
+   download counts generated by the extended logging.  That being said,
+   over 90% of downloads were by peers running the newer software, which
+   we believe shows that the transfer records are highly representative
+   of the total data flow.
+
+   In terms of which analysis was performed from the standard logging
+   compared to extended logging, all of the data flow analysis was
+   performed using the extended logging.  Pando's download counts and
+   performance numbers were generated via standard logging (i.e., all
+   peers report download complete/cancel, data volumes, and measured
+   download speed on the client).  Yale's download counts and
+
+
+
+Griffiths, et al.            Informational                      [Page 8]
+
+RFC 5632                Comcast P4P Experiences           September 2009
+
+
+   performance numbers were derived via extended logging (e.g., by
+   summing the transfer records, counting IP addresses reported, etc.).
+
+   One benefit of having two data sources is that we can compare the
+   two.  In this case, the two approaches both reported comparable
+   impacts.
+
+6.  Next Steps
+
+   One objective of this document is to share with the IETF community
+   the results of one P4P iTracker trial in a large broadband network,
+   given skepticism regarding the benefits to P2P users as well as to
+   ISPs.  From the perspective of P2P users, P4P iTrackers potentially
+   deliver faster P2P downloads.  At the same time, ISPs can increase
+   the localization of swarms, enabling them to reduce bytes flowing
+   over transit points, while also delivering an optimized P2P
+   experience to customers.  However, an internal analysis of varying
+   levels of P4P iTracker adoption by ISPs leads us to believe that,
+   while P4P iTracker-type mechanisms are valuable on a single ISP
+   basis, the value of P4P iTrackers increases dramatically as many ISPs
+   choose to deploy it.
+
+   We believe these results can inform the technical discussion in the
+   IETF over how to use P4P iTracker mechanisms.  Should such a
+   mechanism be standardized, the use of ISP-provided P4P iTrackers
+   should probably be an opt-in feature for P2P users, or at least a
+   feature of which they are explicitly aware of and which has been
+   enabled by default in a particular P2P client.  In this way, P2P
+   users could choose to opt-in either explicitly or by their choice of
+   P2P client in order to choose to use the P4P iTracker to improve
+   performance, which benefits both the user and the ISP at the same
+   time.  Importantly in terms of privacy, the P4P iTracker makes
+   available only network topology information, and would not in its
+   current form enable an ISP, via the P4P iTracker, to determine which
+   P2P clients were downloading any specific content, whether to
+   determine, for example, if content was a song or a movie or even the
+   title.
+
+   It is also possible that a P4P iTracker type of mechanism, in
+   combination with a P2P cache, could further improve P2P download
+   performance, which merits further study.  In addition, this was a
+   limited trial that, while very promising, indicates a need for
+   additional technical investigation and trial work.  Such a follow-up
+   study should explore the effects of P4P iTrackers when more P2P
+   client software variants are involved, with larger swarms, and with
+   additional and more technically diverse content (file size, file
+   type, duration of content, etc.).
+
+
+
+
+Griffiths, et al.            Informational                      [Page 9]
+
+RFC 5632                Comcast P4P Experiences           September 2009
+
+
+7.  Security Considerations
+
+   This document does not propose any kind of protocol, practice or
+   standard.
+
+   The experiment did show that an ISP can improve performance without
+   exposing fine-grained details about network structure, which might
+   otherwise be a security concern (see Section 3.1 (P4P Fine Grain) and
+   Section 3.2 (P4P Coarse Grain).  Section 6 (Next Steps) mentions that
+   the opt-in architecture allows P2P users to maintain privacy.
+
+   Other security aspects were not considered in the experiment, which
+   focused on performance measurements.
+
+8.  Acknowledgements
+
+   The authors wish to acknowledge the hard work of all of the P4P
+   working group members, and specifically the focused efforts of the
+   teams at both Pando and Yale for the trial itself.  Finally, the
+   authors recognize and appreciate Peter Sevcik and John Bartlett of
+   NetForecast, Inc., for their valued independent analysis of the trial
+   results.
+
+9.  Informative References
+
+   [DynamicSwarmMgmt]
+              Carlsson, N. and G. Dan, "Dynamic Swarm Management for
+              Improved BitTorrent Performance", USENIX 8th International
+              Workshop on Peer-to-Peer Systems, March 2009,
+              <http://www.usenix.org/events/iptps09/tech/full_papers/
+              dan/dan_html/>.
+
+   [RFC3083]  Woundy, R., "Baseline Privacy Interface Management
+              Information Base for DOCSIS Compliant Cable Modems and
+              Cable Modem Termination Systems", RFC 3083, March 2001.
+
+   [RFC5594]  Peterson, J. and A. Cooper, "Report from the IETF Workshop
+              on Peer-to-Peer (P2P) Infrastructure, May 28, 2008",
+              RFC 5594, July 2009.
+
+   [SIGCOMM]  Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and A.
+              Silberschatz, "ACM SIGCOMM 2008 - P4P: Provider Portal for
+              Applications", Association for Computing Machinery SIGCOMM
+              2008 Proceedings, August 2008,
+              <http://ccr.sigcomm.org/online/files/p351-xieA.pdf>.
+
+
+
+
+
+
+Griffiths, et al.            Informational                     [Page 10]
+
+RFC 5632                Comcast P4P Experiences           September 2009
+
+
+Authors' Addresses
+
+   Chris Griffiths
+   Comcast Cable Communications
+   One Comcast Center
+   1701 John F. Kennedy Boulevard
+   Philadelphia, PA  19103
+   US
+
+   EMail: chris_griffiths@cable.comcast.com
+   URI:   http://www.comcast.com
+
+
+   Jason Livingood
+   Comcast Cable Communications
+   One Comcast Center
+   1701 John F. Kennedy Boulevard
+   Philadelphia, PA  19103
+   US
+
+   EMail: jason_livingood@cable.comcast.com
+   URI:   http://www.comcast.com
+
+
+   Laird Popkin
+   Pando Networks
+   520 Broadway Street
+   10th Floor
+   New York, NY  10012
+   US
+
+   EMail: laird@pando.com
+   URI:   http://www.pando.com
+
+
+   Richard Woundy
+   Comcast Cable Communications
+   27 Industrial Avenue
+   Chelmsford, MA  01824
+   US
+
+   EMail: richard_woundy@cable.comcast.com
+   URI:   http://www.comcast.com
+
+
+
+
+
+
+
+
+Griffiths, et al.            Informational                     [Page 11]
+
+RFC 5632                Comcast P4P Experiences           September 2009
+
+
+   Richard Yang
+   Yale University
+   51 Prospect Street
+   New Haven, CT  06520
+   US
+
+   EMail: yry@cs.yale.edu
+   URI:   http://www.cs.yale.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Griffiths, et al.            Informational                     [Page 12]
+