idnits 2.17.1 draft-livingood-woundy-p4p-experiences-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 306. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 330. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2008) is 5659 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Griffiths 3 (ALTO) J. Livingood 4 Internet-Draft R. Woundy 5 Intended status: Informational Comcast 6 Expires: April 30, 2009 October 27, 2008 8 Comcast's ISP Experiences In a Recent P4P Technical Trial 9 draft-livingood-woundy-p4p-experiences-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 30, 2009. 36 Abstract 38 This document describes the experiences of Comcast, a large cable 39 broadband Internet Service Provider (ISP) in the U.S., in a recent 40 Proactive Network Provider Participation for P2P (P4P) technical 41 trial. This trial used iTracker technology being considered by the 42 IETF, as part of what is currently known as the Application Layer 43 Transport Optimization (ALTO) Birds of a Feather (BoF). 45 Table of Contents 47 1. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 48 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. High-Level Details . . . . . . . . . . . . . . . . . . . . . . 3 50 4. High-Level Trial Results . . . . . . . . . . . . . . . . . . . 4 51 5. Differences Between P4P iTrackers . . . . . . . . . . . . . . . 6 52 5.1. P4P Fine Grained . . . . . . . . . . . . . . . . . . . . . 6 53 5.2. P4P Coarse Grained . . . . . . . . . . . . . . . . . . . . 6 54 5.3. P4P Generic Weighted . . . . . . . . . . . . . . . . . . . 6 55 6. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 58 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 59 10. Normative References . . . . . . . . . . . . . . . . . . . . . 7 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 61 Intellectual Property and Copyright Statements . . . . . . . . . . 9 63 1. Requirements Language 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119 [RFC2119]. 69 2. Introduction 71 Comcast is a large broadband ISP, based in the U.S., serving the 72 majority of its customers via cable modem technology. A trial was 73 recently conducted with Pando Networks, Yale, and several ISP members 74 of the P4P Working Group, which is part of the Distributed Computing 75 Industry Association (DCIA). Comcast is a member of the P4P Working 76 Group, whose mission is to work with Internet service providers 77 (ISPs), peer to peer (P2P) companies, and technology researchers to 78 develop "P4P" mechanisms that accelerate distribution of content and 79 optimize utilization of ISP network resources. P4P theoretically 80 allows P2P networks to optimize traffic within each ISP, reducing the 81 volume of data traversing the ISP's infrastructure and creating a 82 more manageable flow of data. P4P can also accelerate P2P downloads 83 for end users. 85 P4P's so-called "iTracker" technology was conceptually discussed with 86 the IETF at the Peer to Peer Infrastructure (P2Pi) Workshop held on 87 May 22, 2008, at the Massachusetts Institute of Technology (MIT). 88 This work was discussed in greater detail at the 72nd meeting of the 89 IETF, in Dublin, Ireland, in the ALTO BoF on July 29, 2008. Since 90 that time, discussion of iTrackers has continued with participants of 91 the ALTO BoF and P2Pi Workshop, as the IETF community plans for a 92 second BoF at the 73rd meeting of the IETF in November, 2008. At 93 IETF 72, Comcast offered to share P4P trial data with the community, 94 and to present this in some detail at the next ALTO BoF. 96 The P4P trial was conducted, in cooperation with Pando, Yale, and 97 three other P4P member ISPs, from July 2 to July 17, 2008. This was 98 the first P4P trial over a cable broadband network. The trial used a 99 Pando P2P client, and Pando distributed a special 21 MB licensed 100 video file as in order to measure the effectiveness of P4P iTrackers. 101 A primary objective of the trial was to measure the effects that 102 increasing the localization of P2P swarms would have on P2P uploads, 103 P2P downloads, and ISP networks, in comparison to normal P2P 104 activity. 106 3. High-Level Details 108 There were five different swarms for the content used in the trial. 110 The first was a random P2P swarm, as a control group. The second, 111 third, and fourth used different P4P iTrackers: Generic, Coarse 112 Grained, and Fine Grained. The fifth was a proprietary Pando 113 mechanism. (The results of the fifth swarm, while very good, are not 114 included here since our focus is on open standards and a mechanism 115 which may be leveraged for the benefit of the entire community of P2P 116 clients.) During the trial, there were 15,518 downloads to Comcast- 117 based P2P clients. Comcast deployed an iTracker server in our 118 production network to support this trial, and configued multiple 119 iTracker files to provide varying levels of localization to clients. 121 In the trial itself, a P2P client begins a P2P session by querying a 122 pTracker, which runs and manages the P2P network. The pTracker 123 occasionally queries the iTracker, which in this case was maintained 124 by Comcast, the ISP. Other ISPs either managed their own iTracker or 125 used Pando or Yale to host their iTracker files. The iTracker 126 returns network toplogy information to the pTracker, which then 127 communicates with P2P clients, in order to enable P2P clients to make 128 network-aware decisions regarding peers. 130 4. High-Level Trial Results 132 Trial data was collected by Pando Networks and Yale University, and 133 raw trial results were shared with Comcast and all of the other ISPs 134 involved in the trial. Analysis of the raw results was performed by 135 Pando and Yale, and these organizations delivered an analysis of the 136 P4P trial. Using the raw data, Comcast also analyzed the trial 137 results. Furthermore, the raw trial results for Comcast were shared 138 with Net Forecast, Inc., which performed an independent analysis of 139 the trial for Comcast. 141 The results of the trial indicated that P4P can improve the speed of 142 downloads to P2P clients. In addition, P4P was effective in 143 localizing P2P traffic within the Comcast network. 145 +--------------+------------+------------+-------------+------------+ 146 | Swarm | Global Avg | Change | Comcast Avg | Change | 147 | | bps | | bps | | 148 +--------------+------------+------------+-------------+------------+ 149 | Random | 144,045 | n/a | 254,671 bps | n/a | 150 | (Control) | bps | | | | 151 | ---------- | ---------- | ---------- | ---------- | ---------- | 152 | P4P Fine | 162,344 | +13% | 402,043 bps | +57% | 153 | Grained | bps | | | | 154 | ---------- | ---------- | ---------- | ---------- | ---------- | 155 | P4P Generic | 163,205 | +13% | 463,782 bps | +82% | 156 | Weight | bps | | | | 157 | ---------- | ---------- | ---------- | ---------- | ---------- | 158 | P4P Coarse | 166,273 | +15% | 471,218 bps | +85% | 159 | Grained | bps | | | | 160 +--------------+------------+------------+-------------+------------+ 162 Data from trial. 164 Table 1: IETF Meetings in 2005 166 An analysis of the effects of P4P on upstream utilization and 167 Internet transit was also interesting. It did not appear that P4P 168 significantly increased upstream utilization in our access network; 169 in essence uploading was already occuring no matter what and P4P in 170 and of itself did not appear to materially increase uploading for 171 this specific, licensed content. (P4P is not intended as a solution 172 for the potential of network congestion to occur.) Random was 173 143,236 MB and P4P Generic Weight was 143,143 MB, while P4P Coarse 174 Grained was 139,669 MB. We also observed that P4P reduced outgoing 175 Internet traffic by an average of 34% at peering points. Random was 176 134,219 MB and P4P Generic Weight was 91,979 MB, while P4P Coarse 177 Grained was 86,652 MB. 179 In terms of downstream utilization, we observed that P4P reduced 180 incoming Internet traffic by an average of 80% at peering points. 181 Random was 47,013 MB and P4P Generic Weight was 8,610 MB, while P4P 182 Coarse Grained was 7,764 MB. However, we did notice that download 183 activity in our access network increased somewhat, from 56,030 MB for 184 Random, to 59,765 MB for P4P Generic Weight, and 60,781 MB for P4P 185 Coarse Grained. 187 During the trial, downloads peaked at 24,728 per day, per swarm, or 188 nearly 124,000 per day for all five swarms. The swarm size peaked at 189 11,703 peers per swarm, or nearly 57,000 peers for all five swarms. 190 We observed a comparable number of downloads in each of the five 191 swarms. 193 5. Differences Between P4P iTrackers 195 5.1. P4P Fine Grained 197 To be completed 199 5.2. P4P Coarse Grained 201 To be completed 203 5.3. P4P Generic Weighted 205 To be completed 207 6. Next Steps 209 One objective of this document is to share with the IETF community 210 the results of one P4P trial in a large broadband network, given 211 skepticism regarding both the benefits to P2P users and to ISPs. 212 From the perspective of P2P users, P4P potentially delivers faster 213 P2P downloads. At the same time, ISPs can increase the localization 214 of swarms, enabling them to reduce bytes flowing over transit points, 215 while also delivering an optimized P2P experience to customers. 217 We believe these results can inform the technical discussion in the 218 IETF over how to use iTracker mechanisms. Should such a mechanism be 219 standardized, the use of ISP-provided iTrackers should probably be an 220 opt-in feature for P2P users, or at least a feature of which they are 221 explicitly aware of and which has been enabled by default in a 222 particular P2P client. In this way, P2P users could choose to opt-in 223 either explicitly or by their choice of P2P client in order to choose 224 to use the iTracker to improve performance, which benefits both the 225 user and the ISP at the same time. Importantly in terms of privacy, 226 the iTracker makes available only network topology information, and 227 would not in its current form enable an ISP, via the iTracker, to 228 determine what P2P clients were downloading what content. 230 It is also possible that an iTracker type of mechanism, in 231 combination with a P2P cache, could further improve P2P download 232 performance, which merits further study. In addition, this was a 233 limited trial that, while very promising, indicates a need for 234 additional technical investigation and trial work. Such follow-up 235 study should explore the effects of P4P when more P2P client software 236 variants are involved, with larger swarms, and with additional and 237 more technically diverse content (file size, file type, duration of 238 content, etc.). 240 7. Security Considerations 242 To be developed. 244 8. IANA Considerations 246 There are no IANA considerations in this document. 248 9. Acknowledgements 250 The authors wish to acknowledge the hard work of all of the P4P 251 working group members, and specifically the focused efforts of the 252 teams at both Pando and Yale for the trial itelf. Finally, the 253 authors recognize and appreciate Peter Sevcik and John Bartlett, of 254 NetForecast, Inc., for their valued independent analysis of the trial 255 results. 257 10. Normative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 Authors' Addresses 264 Chris Griffiths 265 Comcast Cable Communications 266 One Comcast Center 267 1701 John F. Kennedy Boulevard 268 Philadelphia, PA 19103 269 US 271 Email: chris_griffiths@cable.comcast.com 272 URI: http://www.comcast.com 273 Jason Livingood 274 Comcast Cable Communications 275 One Comcast Center 276 1701 John F. Kennedy Boulevard 277 Philadelphia, PA 19103 278 US 280 Email: jason_livingood@cable.comcast.com 281 URI: http://www.comcast.com 283 Richard Woundy 284 Comcast Cable Communications 285 27 Industrial Avenue 286 Chelmsford, MA 01824 287 US 289 Email: richard_woundy@cable.comcast.com 290 URI: http://www.comcast.com 292 Full Copyright Statement 294 Copyright (C) The IETF Trust (2008). 296 This document is subject to the rights, licenses and restrictions 297 contained in BCP 78, and except as set forth therein, the authors 298 retain all their rights. 300 This document and the information contained herein are provided on an 301 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 302 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 303 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 304 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 305 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 306 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 308 Intellectual Property 310 The IETF takes no position regarding the validity or scope of any 311 Intellectual Property Rights or other rights that might be claimed to 312 pertain to the implementation or use of the technology described in 313 this document or the extent to which any license under such rights 314 might or might not be available; nor does it represent that it has 315 made any independent effort to identify any such rights. Information 316 on the procedures with respect to rights in RFC documents can be 317 found in BCP 78 and BCP 79. 319 Copies of IPR disclosures made to the IETF Secretariat and any 320 assurances of licenses to be made available, or the result of an 321 attempt made to obtain a general license or permission for the use of 322 such proprietary rights by implementers or users of this 323 specification can be obtained from the IETF on-line IPR repository at 324 http://www.ietf.org/ipr. 326 The IETF invites any interested party to bring to its attention any 327 copyrights, patents or patent applications, or other proprietary 328 rights that may cover technology that may be required to implement 329 this standard. Please address the information to the IETF at 330 ietf-ipr@ietf.org.