idnits 2.17.1 draft-livingood-woundy-p4p-experiences-02.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 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 395. 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 28, 2008) is 5652 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: May 1, 2009 October 28, 2008 8 Comcast's ISP Experiences In a Recent P4P Technical Trial 9 draft-livingood-woundy-p4p-experiences-02 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 May 1, 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 4.1. Impact on Downloads, or Downstream Traffic . . . . . . . . 4 52 4.2. Other Impacts and Interesting Data . . . . . . . . . . . . 5 53 5. Differences Between the P4P iTrackers Used . . . . . . . . . . 6 54 5.1. P4P Fine Grain . . . . . . . . . . . . . . . . . . . . . . 6 55 5.2. P4P Coarse Grain . . . . . . . . . . . . . . . . . . . . . 6 56 5.3. P4P Generic Weighted . . . . . . . . . . . . . . . . . . . 7 57 6. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 61 10. Normative References . . . . . . . . . . . . . . . . . . . . . 8 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 63 Intellectual Property and Copyright Statements . . . . . . . . . . 10 65 1. Requirements Language 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [RFC2119]. 71 2. Introduction 73 Comcast is a large broadband ISP, based in the U.S., serving the 74 majority of its customers via cable modem technology. A trial was 75 recently conducted with Pando Networks, Yale, and several ISP members 76 of the P4P Working Group, which is part of the Distributed Computing 77 Industry Association (DCIA). Comcast is a member of the P4P Working 78 Group, whose mission is to work with Internet service providers 79 (ISPs), peer to peer (P2P) companies, and technology researchers to 80 develop "P4P" mechanisms that accelerate distribution of content and 81 optimize utilization of ISP network resources. P4P theoretically 82 allows P2P networks to optimize traffic within each ISP, reducing the 83 volume of data traversing the ISP's infrastructure and creating a 84 more manageable flow of data. P4P can also accelerate P2P downloads 85 for end users. 87 P4P's so-called "iTracker" technology was conceptually discussed with 88 the IETF at the Peer to Peer Infrastructure (P2Pi) Workshop held on 89 May 22, 2008, at the Massachusetts Institute of Technology (MIT). 90 This work was discussed in greater detail at the 72nd meeting of the 91 IETF, in Dublin, Ireland, in the ALTO BoF on July 29, 2008. Since 92 that time, discussion of iTrackers has continued with participants of 93 the ALTO BoF and P2Pi Workshop, as the IETF community plans for a 94 second BoF at the 73rd meeting of the IETF in November, 2008. At 95 IETF 72, Comcast offered to share P4P trial data with the community, 96 and to present this in some detail at the next ALTO BoF. 98 The P4P trial was conducted, in cooperation with Pando, Yale, and 99 three other P4P member ISPs, from July 2 to July 17, 2008. This was 100 the first P4P trial over a cable broadband network. The trial used a 101 Pando P2P client, and Pando distributed a special 21 MB licensed 102 video file as in order to measure the effectiveness of P4P iTrackers. 103 A primary objective of the trial was to measure the effects that 104 increasing the localization of P2P swarms would have on P2P uploads, 105 P2P downloads, and ISP networks, in comparison to normal P2P 106 activity. 108 3. High-Level Details 110 There were five different swarms for the content used in the trial. 112 The first was a random P2P swarm, as a control group. The second, 113 third, and fourth used different P4P iTrackers: Generic, Coarse 114 Grained, and Fine Grained. The fifth was a proprietary Pando 115 mechanism. (The results of the fifth swarm, while very good, are not 116 included here since our focus is on open standards and a mechanism 117 which may be leveraged for the benefit of the entire community of P2P 118 clients.) During the trial, there were 15,518 downloads to Comcast- 119 based P2P clients. Comcast deployed an iTracker server in our 120 production network to support this trial, and configured multiple 121 iTracker files to provide varying levels of localization to clients. 123 In the trial itself, a P2P client begins a P2P session by querying a 124 pTracker, which runs and manages the P2P network. The pTracker 125 occasionally queries the iTracker, which in this case was maintained 126 by Comcast, the ISP. Other ISPs either managed their own iTracker or 127 used Pando or Yale to host their iTracker files. The iTracker 128 returns network topology information to the pTracker, which then 129 communicates with P2P clients, in order to enable P2P clients to make 130 network-aware decisions regarding peers. 132 4. High-Level Trial Results 134 Trial data was collected by Pando Networks and Yale University, and 135 raw trial results were shared with Comcast and all of the other ISPs 136 involved in the trial. Analysis of the raw results was performed by 137 Pando and Yale, and these organizations delivered an analysis of the 138 P4P trial. Using the raw data, Comcast also analyzed the trial 139 results. Furthermore, the raw trial results for Comcast were shared 140 with Net Forecast, Inc., which performed an independent analysis of 141 the trial for Comcast. 143 4.1. Impact on Downloads, or Downstream Traffic 145 The results of the trial indicated that P4P can improve the speed of 146 downloads to P2P clients. In addition, P4P was effective in 147 localizing P2P traffic within the Comcast network. 149 Impact of P4P on Downloads: 151 +--------------+------------+------------+-------------+------------+ 152 | Swarm | Global Avg | Change | Comcast Avg | Change | 153 | | bps | | bps | | 154 +--------------+------------+------------+-------------+------------+ 155 | Random | 144,045 | n/a | 254,671 bps | n/a | 156 | (Control) | bps | | | | 157 | ---------- | ---------- | ---------- | ---------- | ---------- | 158 | P4P Fine | 162,344 | +13% | 402,043 bps | +57% | 159 | Grained | bps | | | | 160 | ---------- | ---------- | ---------- | ---------- | ---------- | 161 | P4P Generic | 163,205 | +13% | 463,782 bps | +82% | 162 | Weight | bps | | | | 163 | ---------- | ---------- | ---------- | ---------- | ---------- | 164 | P4P Coarse | 166,273 | +15% | 471,218 bps | +85% | 165 | Grained | bps | | | | 166 +--------------+------------+------------+-------------+------------+ 168 Table 1: Data Collected with Pando Networks and Yale University 170 4.2. Other Impacts and Interesting Data 172 An analysis of the effects of P4P on upstream utilization and 173 Internet transit was also interesting. It did not appear that P4P 174 significantly increased upstream utilization in our access network; 175 in essence uploading was already occurring no matter what and P4P in 176 and of itself did not appear to materially increase uploading for 177 this specific, licensed content. (P4P is not intended as a solution 178 for the potential of network congestion to occur.) Random was 179 143,236 MB and P4P Generic Weight was 143,143 MB, while P4P Coarse 180 Grained was 139,669 MB. We also observed that P4P reduced outgoing 181 Internet traffic by an average of 34% at peering points. Random was 182 134,219 MB and P4P Generic Weight was 91,979 MB, while P4P Coarse 183 Grained was 86,652 MB. 185 In terms of downstream utilization, we observed that P4P reduced 186 incoming Internet traffic by an average of 80% at peering points. 187 Random was 47,013 MB and P4P Generic Weight was 8,610 MB, while P4P 188 Coarse Grained was 7,764 MB. However, we did notice that download 189 activity in our access network increased somewhat, from 56,030 MB for 190 Random, to 59,765 MB for P4P Generic Weight, and 60,781 MB for P4P 191 Coarse Grained. 193 During the trial, downloads peaked at 24,728 per day, per swarm, or 194 nearly 124,000 per day for all five swarms. The swarm size peaked at 195 11,703 peers per swarm, or nearly 57,000 peers for all five swarms. 196 We observed a comparable number of downloads in each of the five 197 swarms. 199 5. Differences Between the P4P iTrackers Used 201 Given the size of the Comcast network, it was felt that in order to 202 truly evaluate the iTracker application we would need to test various 203 network topologies that reflected our network and would help gauge 204 the level of effort and design requirements necessary to get correct 205 statistical data out of the trial. In all cases, iTrackers were 206 configured with automation in mind, so that any successful iTracker 207 configuration would be automatically updating, rather than manually 208 configured on an on-going basis. All iTrackers were hosted on the 209 same small server, and it appeared to be relatively easy and 210 inexpensive to scale up an iTracker infrastructure should P4P-like 211 mechanisms become standardized and widely adopted. 213 5.1. P4P Fine Grain 215 The Fine Grain topology was the first and most complex iTracker that 216 we built for this trial. It was a detailed mapping of Comcast 217 backbone-connected network Autonomous System Numbers (ASN) to IP 218 Aggregates which were weighted based on priority and distance from 219 each other. Included in this design was a prioritization of all Peer 220 and Internet transit connected ASNs to our backbone to ensure that 221 P4P traffic would prefer settlement free and lower cost networks 222 first, and then more expensive transit links. This attempted to 223 optimize and lower transit costs associated with this traffic. We 224 then took the additional step of detailing each ASN and IP aggregate 225 into IP subnets down to our Optical Transport Nodes (OTN) where all 226 Cable Modem Termination Systems (CMTS) reside. This design gave a 227 highly localized and detailed description of our network for the 228 iTracker to disseminate. This design defined 1,182 iTracker node 229 identifiers, and resulted in a 210,727 line configuration file. 231 This iTracker was obviously the most time-consuming to create and the 232 most complex to maintain. Trial results indicated that this level of 233 localization was too high, and was less effective compared to lower 234 levels of localization. 236 5.2. P4P Coarse Grain 238 Given the level of detail in the Fine Grain design, it was important 239 that we also enable a high-level design which still used priority and 240 weighting mechanisms for our backbone and transit links. The Coarse 241 Grain design was a limited or summarized version of the Fine Grain 242 design, which used the ASN to IP Aggregate and weighted data for 243 transit links, but removed all additional localization data. This 244 insured we would get similar data sets from the Fine Grain design, 245 but without the more detailed localization of each of our networks 246 off of our backbone. This design defined 22 iTracker node 247 identifiers, and resulted in a 1,461 line configuration file. 249 From an overall cost, complexity, risk, and effectiveness standpoint, 250 this was judged to be the optimal iTracker for Comcast. Importantly, 251 this did not require revealing the complex, internal network topology 252 that the Fine Grain did. Updates to this iTracker were also far 253 simpler to automate, which will better ensure that it is accurate 254 over time, and keeps administrative overhead relatively low. 255 However, the differences, costs, and benefits of Coarse Grain and 256 Generic Weighted (see below) likely merit further study. 258 5.3. P4P Generic Weighted 260 The Generic Weighted design was a copy of the Coarse Grained design 261 but instead of using our ISP-designated priority and weights, all 262 weights were defaulted to pre-determined parameters that the Yale 263 team had designed. All other data was replicated from the Coarse 264 Grain design. Providing the information necessary to support the 265 Generic Weighted iTracker was roughly the same as for Coarse Grain. 267 6. Next Steps 269 One objective of this document is to share with the IETF community 270 the results of one P4P trial in a large broadband network, given 271 skepticism regarding both the benefits to P2P users and to ISPs. 272 From the perspective of P2P users, P4P potentially delivers faster 273 P2P downloads. At the same time, ISPs can increase the localization 274 of swarms, enabling them to reduce bytes flowing over transit points, 275 while also delivering an optimized P2P experience to customers. 276 However, an internal analysis of varying levels of iTracker adoption 277 by ISPs leads us to believe that, while P4P-type mechanisms are 278 valuable on a single ISP basis, the value of P4P increases 279 dramatically as many ISPs choose to deploy it. 281 We believe these results can inform the technical discussion in the 282 IETF over how to use iTracker mechanisms. Should such a mechanism be 283 standardized, the use of ISP-provided iTrackers should probably be an 284 opt-in feature for P2P users, or at least a feature of which they are 285 explicitly aware of and which has been enabled by default in a 286 particular P2P client. In this way, P2P users could choose to opt-in 287 either explicitly or by their choice of P2P client in order to choose 288 to use the iTracker to improve performance, which benefits both the 289 user and the ISP at the same time. Importantly in terms of privacy, 290 the iTracker makes available only network topology information, and 291 would not in its current form enable an ISP, via the iTracker, to 292 determine what P2P clients were downloading what content. 294 It is also possible that an iTracker type of mechanism, in 295 combination with a P2P cache, could further improve P2P download 296 performance, which merits further study. In addition, this was a 297 limited trial that, while very promising, indicates a need for 298 additional technical investigation and trial work. Such follow-up 299 study should explore the effects of P4P when more P2P client software 300 variants are involved, with larger swarms, and with additional and 301 more technically diverse content (file size, file type, duration of 302 content, etc.). 304 7. Security Considerations 306 There are no security considerations to include at this time. 308 8. IANA Considerations 310 There are no IANA considerations in this document. 312 9. Acknowledgements 314 The authors wish to acknowledge the hard work of all of the P4P 315 working group members, and specifically the focused efforts of the 316 teams at both Pando and Yale for the trial itself. Finally, the 317 authors recognize and appreciate Peter Sevcik and John Bartlett, of 318 NetForecast, Inc., for their valued independent analysis of the trial 319 results. 321 10. Normative References 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, March 1997. 326 Authors' Addresses 328 Chris Griffiths 329 Comcast Cable Communications 330 One Comcast Center 331 1701 John F. Kennedy Boulevard 332 Philadelphia, PA 19103 333 US 335 Email: chris_griffiths@cable.comcast.com 336 URI: http://www.comcast.com 338 Jason Livingood 339 Comcast Cable Communications 340 One Comcast Center 341 1701 John F. Kennedy Boulevard 342 Philadelphia, PA 19103 343 US 345 Email: jason_livingood@cable.comcast.com 346 URI: http://www.comcast.com 348 Richard Woundy 349 Comcast Cable Communications 350 27 Industrial Avenue 351 Chelmsford, MA 01824 352 US 354 Email: richard_woundy@cable.comcast.com 355 URI: http://www.comcast.com 357 Full Copyright Statement 359 Copyright (C) The IETF Trust (2008). 361 This document is subject to the rights, licenses and restrictions 362 contained in BCP 78, and except as set forth therein, the authors 363 retain all their rights. 365 This document and the information contained herein are provided on an 366 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 367 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 368 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 369 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 370 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 371 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 373 Intellectual Property 375 The IETF takes no position regarding the validity or scope of any 376 Intellectual Property Rights or other rights that might be claimed to 377 pertain to the implementation or use of the technology described in 378 this document or the extent to which any license under such rights 379 might or might not be available; nor does it represent that it has 380 made any independent effort to identify any such rights. Information 381 on the procedures with respect to rights in RFC documents can be 382 found in BCP 78 and BCP 79. 384 Copies of IPR disclosures made to the IETF Secretariat and any 385 assurances of licenses to be made available, or the result of an 386 attempt made to obtain a general license or permission for the use of 387 such proprietary rights by implementers or users of this 388 specification can be obtained from the IETF on-line IPR repository at 389 http://www.ietf.org/ipr. 391 The IETF invites any interested party to bring to its attention any 392 copyrights, patents or patent applications, or other proprietary 393 rights that may cover technology that may be required to implement 394 this standard. Please address the information to the IETF at 395 ietf-ipr@ietf.org.