idnits 2.17.1 draft-livingood-woundy-p4p-experiences-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- 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 (June 11, 2009) is 5431 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Griffiths 3 Internet-Draft J. Livingood, Ed. 4 Intended status: Informational Comcast 5 Expires: December 13, 2009 L. Popkin 6 Pando 7 R. Woundy, Ed. 8 Comcast 9 Y. Yang 10 Yale 11 June 11, 2009 13 Comcast's ISP Experiences In a P4P Technical Trial 14 draft-livingood-woundy-p4p-experiences-09 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 13, 2009. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 This document describes the experiences of Comcast, a large cable 53 broadband Internet Service Provider (ISP) in the U.S., in a Proactive 54 Network Provider Participation for P2P (P4P) technical trial in July 55 2008. This trial used P4P iTracker technology being considered by 56 the IETF, as part of the Application Layer Transport Optimization 57 (ALTO) working group. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. High-Level Details . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Differences Between the P4P iTrackers Used . . . . . . . . . . 5 64 3.1. P4P Fine Grain . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. P4P Coarse Grain . . . . . . . . . . . . . . . . . . . . . 5 66 3.3. P4P Generic Weighted . . . . . . . . . . . . . . . . . . . 6 67 4. High-Level Trial Results . . . . . . . . . . . . . . . . . . . 6 68 4.1. Swarm Size . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.2. Impact on Download Speed . . . . . . . . . . . . . . . . . 7 70 4.3. General Impacts on Upstream and Downstream Traffic and 71 Other Interesting Data . . . . . . . . . . . . . . . . . . 8 72 5. Important Notes on Data Collected . . . . . . . . . . . . . . 8 73 6. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 77 10. Informative References . . . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 Comcast is a large broadband Internet Service Provider (ISP), based 83 in the U.S., serving the majority of its customers via cable modem 84 technology. A trial was conducted in July 2008 with Pando Networks, 85 Yale, and several ISP members of the P4P Working Group, which is part 86 of the Distributed Computing Industry Association (DCIA). Comcast is 87 a member of the DCIA's P4P Working Group, whose mission is to work 88 with Internet service providers (ISPs), peer-to-peer (P2P) companies, 89 and technology researchers to develop "P4P" mechanisms, such as so- 90 called "iTrackers" (hereafter P4P iTrackers), that accelerate 91 distribution of content and optimize utilization of ISP network 92 resources. P4P iTrackers theoretically allow P2P networks to 93 optimize traffic within each ISP, reducing the volume of data 94 traversing the ISP's infrastructure and creating a more manageable 95 flow of data. P4P iTrackers can also accelerate P2P downloads for 96 end users. 98 P4P's so-called "iTracker" technology [SIGCOMM] was conceptually 99 discussed with the IETF at the Peer-to-Peer Infrastructure (P2Pi) 100 Workshop held on May 28, 2008, at the Massachusetts Institute of 101 Technology (MIT), as documented in [I-D.p2pi-cooper-workshop-report]. 102 This work was discussed in greater detail at the 72nd meeting of the 103 IETF, in Dublin, Ireland, in the ALTO BoF on July 29, 2008. Due to 104 interest from the community, Comcast shared P4P iTracker trial data 105 at the 73rd meeting of the IETF, in Minneapolis, Minnesota, in the 106 ALTO BoF on November 18, 2008. Since that time, discussion of P4P 107 iTrackers and alternative technologies has continued among 108 participants of the ALTO working group. 110 The P4P iTracker trial was conducted, in cooperation with Pando, 111 Yale, and three other P4P member ISPs, from July 2 to July 17, 2008. 112 This was the first P4P iTracker trial over a cable broadband network. 113 The trial used a Pando P2P client, and Pando distributed a special 21 114 MB licensed video file in order to measure the effectiveness of P4P 115 iTrackers. A primary objective of the trial was to measure the 116 effects that increasing the localization of P2P swarms would have on 117 P2P uploads, P2P downloads, and ISP networks, in comparison to normal 118 P2P activity. 120 2. High-Level Details 122 As noted in Section 1 of [Dynamic Swarm Management], a swarm is 123 defined in the following way: "The content and the set of peers 124 distributing it [a file] is usually called a torrent. A peer that 125 only uploads content is called a seed, while a peer that uploads and 126 downloads at the same time is called a leecher. The connected set of 127 peers participating in the piece exchanges of a torrent is referred 128 to as a swarm." 130 There were five different swarms for the content used in the trial. 131 The second, third, and fourth used different P4P iTrackers: Generic, 132 Coarse Grained, and Fine Grained, all of which are described in 133 Section 3. The fifth was a proprietary Pando mechanism. (The 134 results of the fifth swarm, while satisfactory, are not included here 135 since our focus is on open standards and a mechanism which may be 136 leveraged for the benefit of the entire community of P2P clients.) 137 Comcast deployed a P4P iTracker server in its production network to 138 support this trial, and configured multiple iTracker files to provide 139 varying levels of localization to clients. 141 In the trial itself, a P2P client begins a P2P session by querying a 142 pTracker, which runs and manages the P2P network. The pTracker 143 occasionally queries the P4P iTracker, which in this case was 144 maintained by Comcast, the ISP. Other ISPs either managed their own 145 P4P iTracker or used Pando or Yale to host their P4P iTracker files. 146 The P4P iTracker returns network topology information to the 147 pTracker, which then communicates with P2P clients, in order to 148 enable P2P clients to make network-aware decisions regarding peers. 150 The Pando client was enabled to capture extended logging, when the 151 version of the client included support for it. The extended logging 152 included the source and destination IP address of all P2P transfers, 153 the number of bytes transferred, and the start and end timestamps. 154 This information gives a precise measurement of the data flow in the 155 network, allowing computation of data transfer volumes as well as 156 data flow rates at each point in time. With standard logging, Pando 157 captured the start and completion times of every download, as well as 158 the average transfer rate observed by the client for the download. 160 Pando served the data from an origin server external to Comcast's 161 network. This server served about 10 copies of the file, after which 162 all transfers (about 1 million downloads across all ISPs) were 163 performed purely via P2P. 165 The P2P clients in the trial start with tracker-provided peers, then 166 use peer exchange to discover additional peers. Thus, the initial 167 peers were provided according to P4P iTracker guidance (90% guidance 168 based on P4P iTracker topology, and 10% random guidance), then later 169 peers discover the entire swarm via either additional announces or 170 peer exchange. 172 3. Differences Between the P4P iTrackers Used 174 Given the size of the Comcast network, it was felt that in order to 175 truly evaluate the P4P iTracker application we would need to test 176 various network topologies that reflected its network and would help 177 gauge the level of effort and design requirements necessary to get 178 correct statistical data out of the trial. In all cases, P4P 179 iTrackers were configured with automation in mind, so that any 180 successful P4P iTracker configuration would be automatically 181 updating, rather than manually configured on an on-going basis. All 182 P4P iTrackers were hosted on the same small server, and it appeared 183 to be relatively easy and inexpensive to scale up a P4P iTracker 184 infrastructure should P4P iTracker-like mechanisms become 185 standardized and widely adopted. 187 3.1. P4P Fine Grain 189 The Fine Grain topology was the first and most complex P4P iTracker 190 that we built for this trial. It was a detailed mapping of Comcast 191 backbone-connected network Autonomous System Numbers (ASN) to IP 192 Aggregates which were weighted based on priority and distance from 193 each other. Included in this design was a prioritization of all Peer 194 and Internet transit connected ASNs to the Comcast backbone to ensure 195 that P4P traffic would prefer settlement free and lower cost networks 196 first, and then more expensive transit links. This attempted to 197 optimize and lower transit costs associated with this traffic. We 198 then took the additional step of detailing each ASN and IP aggregate 199 into IP subnets down to Optical Transport Nodes (OTN) where all Cable 200 Modem Termination Systems (CMTS, as briefly defined in Section 2.6 of 201 [RFC3083]) reside . This design gave a highly localized and detailed 202 description of the Comcast network for the iTracker to disseminate. 203 This design defined 1,182 P4P iTracker node identifiers, and resulted 204 in a 107,357 line configuration file. 206 This P4P iTracker was obviously the most time-consuming to create and 207 the most complex to maintain. Trial results indicated that this 208 level of localization was too high, and was less effective compared 209 to lower levels of localization. 211 3.2. P4P Coarse Grain 213 Given the level of detail in the Fine Grain design, it was important 214 that we also enable a high-level design which still used priority and 215 weighting mechanisms for the Comcast backbone and transit links. The 216 Coarse Grain design was a limited or summarized version of the Fine 217 Grain design, which used the ASN to IP Aggregate and weighted data 218 for transit links, but removed all additional localization data. 219 This insured we would get similar data sets from the Fine Grain 220 design, but without the more detailed localization of each of the 221 networks attached to the Comcast backbone. This design defined 22 222 P4P iTracker node identifiers, and resulted in a 998 line 223 configuration file. 225 From an overall cost, complexity, risk, and effectiveness standpoint, 226 this was judged to be the optimal P4P iTracker for Comcast. 227 Importantly, this did not require revealing the complex, internal 228 network topology that the Fine Grain did. Updates to this iTracker 229 were also far simpler to automate, which will better ensure that it 230 is accurate over time, and keeps administrative overhead relatively 231 low. However, the differences, costs, and benefits of Coarse Grain 232 and Generic Weighted (see below) likely merit further study. 234 3.3. P4P Generic Weighted 236 The Generic Weighted design was a copy of the Coarse Grained design 237 but instead of using ISP-designated priority and weights, all weights 238 were defaulted to pre-determined parameters that the Yale team had 239 designed. All other data was replicated from the Coarse Grain 240 design. Gathering and providing the information necessary to support 241 the Generic Weighted iTracker was roughly the same level of effort as 242 for Coarse Grain. 244 4. High-Level Trial Results 246 Trial data was collected by Pando Networks and Yale University, and 247 raw trial results were shared with Comcast and all of the other ISPs 248 involved in the trial. Analysis of the raw results was performed by 249 Pando and Yale, and these organizations delivered an analysis of the 250 P4P iTracker trial. Using the raw data, Comcast also analyzed the 251 trial results. Furthermore, the raw trial results for Comcast were 252 shared with Net Forecast, Inc., which performed an independent 253 analysis of the trial for Comcast. 255 4.1. Swarm Size 257 During the trial, downloads peaked at 24,728 per day, per swarm, or 258 nearly 124,000 per day for all five swarms. The swarm size peaked at 259 11,703 peers per swarm, or nearly 57,000 peers for all five swarms. 260 We observed a comparable number of downloads in each of the five 261 swarms. 263 For each swarm, Table 1 below gives the number of downloaders per 264 swarm from Comcast that finished downloading, and the number of 265 downloaders from Comcast that canceled downloading before finishing. 267 Characteristics of P4P iTracker Swarms: 269 +-----------+-----------+---------------+------------+--------------+ 270 | Swarm | Completed | Cancellations | Total | Cancellation | 271 | | Downloads | | Attempts | Rate | 272 +-----------+-----------+---------------+------------+--------------+ 273 | Random | 2,719 | 89 | 2,808 | 3.17% | 274 | (Control) | | | | | 275 | --------- | --------- | ----------- | ---------- | ----------- | 276 | P4P Fine | 2,846 | 64 | 2,910 | 2.20% | 277 | Grained | | | | | 278 | --------- | --------- | ----------- | ---------- | ----------- | 279 | P4P | 2,775 | 63 | 2,838 | 2.22% | 280 | Generic | | | | | 281 | Weight | | | | | 282 | --------- | --------- | ----------- | ---------- | ----------- | 283 | P4P | 2,886 | 52 | 2,938 | 1.77% | 284 | Coarse | | | | | 285 | Grained | | | | | 286 +-----------+-----------+---------------+------------+--------------+ 288 Table 1: Per-Swarm Size and Cancellation Rates 290 4.2. Impact on Download Speed 292 The results of the trial indicated that P4P iTrackers can improve the 293 speed of downloads to P2P clients. In addition, P4P iTrackers were 294 effective in localizing P2P traffic within the Comcast network. 296 Impact of P4P iTrackers on Downloads: 298 +--------------+------------+------------+-------------+------------+ 299 | Swarm | Global Avg | Change | Comcast Avg | Change | 300 | | bps | | bps | | 301 +--------------+------------+------------+-------------+------------+ 302 | Random | 144,045 | n/a | 254,671 bps | n/a | 303 | (Control) | bps | | | | 304 | ---------- | ---------- | ---------- | ---------- | ---------- | 305 | P4P Fine | 162,344 | +13% | 402,043 bps | +57% | 306 | Grained | bps | | | | 307 | ---------- | ---------- | ---------- | ---------- | ---------- | 308 | P4P Generic | 163,205 | +13% | 463,782 bps | +82% | 309 | Weight | bps | | | | 310 | ---------- | ---------- | ---------- | ---------- | ---------- | 311 | P4P Coarse | 166,273 | +15% | 471,218 bps | +85% | 312 | Grained | bps | | | | 313 +--------------+------------+------------+-------------+------------+ 314 Table 2: Per-Swarm Global and Comcast Download Speeds 316 4.3. General Impacts on Upstream and Downstream Traffic and Other 317 Interesting Data 319 An analysis of the effects of P4P iTracker use on upstream 320 utilization and Internet transit was also interesting. It did not 321 appear that P4P iTrackers significantly increased upstream 322 utilization in the Comcast access network; in essence uploading was 323 already occurring no matter what and a P4P iTracker in and of itself 324 did not appear to materially increase uploading for this specific, 325 licensed content. (A P4P iTracker is not intended as a solution for 326 the potential of network congestion to occur.) Random was 143,236 MB 327 and P4P Generic Weight was 143,143 MB, while P4P Coarse Grained was 328 139,669 MB. We also observed that using a P4P iTracker reduced 329 outgoing Internet traffic by an average of 34% at peering points. 330 Random was 134,219 MB and P4P Generic Weight was 91,979 MB, while P4P 331 Coarse Grained was 86,652 MB. 333 In terms of downstream utilization, we observed that the use of a P4P 334 iTracker reduced incoming Internet traffic by an average of 80% at 335 peering points. Random was 47,013 MB, P4P Generic Weight was 8,610 336 MB, and P4P Coarse Grained was 7,764 MB. However, we did notice that 337 download activity in the Comcast access network increased somewhat, 338 from 56,030 MB for Random, to 59,765 MB for P4P Generic Weight, and 339 60,781 MB for P4P Coarse Grained. Note that for each swarm, the 340 number of downloaded bytes according to logging reports is very close 341 to the number of downloaders multiplied by file size. But they do 342 not exactly match due to log report errors and duplicated chunks. 343 One factor contributing to the differences in access network download 344 activity is that different swarms have different numbers of 345 downloaders, due to random variations during uniform random 346 assignment of downloaders to swarms (see Table 1). One interesting 347 observation is that Random has higher cancellation rate (3.17%) than 348 that of the guided swarms (1.77%-2.22%). Whether guided swarms 349 achieve lower cancellation rate is an interesting issue for future 350 research. 352 5. Important Notes on Data Collected 354 Raw data is presented in this document. We did not normalize traffic 355 volume data (e.g. upload and download) by the number of downloads in 356 order to preserve this underlying raw data. 358 We also recommend that readers not focus too much on the absolute 359 numbers, such as bytes downloaded from internal sources and bytes 360 downloaded from external sources. Instead, we recommend readers 361 focus on ratios such as the percentage of bytes downloaded that came 362 from internal sources in each swarm. As a result, the small random 363 variation between number of downloads of each swarm does not distract 364 readers from important metrics like shifting traffic from external to 365 internal sources, among other things. 367 We also wish to note that the data was collected from a sample of the 368 total swarm. Specifically, there were some peers running older 369 versions of the Pando client that did not implement the extended 370 transfer logging. For those nodes, which participated in the swarms 371 but did not report their data transfers, we have download counts. 372 The result of this is that, for example, the download counts 373 generated from the standard logging are a bit higher than the 374 download counts generated by the extended logging. That being said, 375 over 90% of downloads were by peers running the newer software, which 376 we believe shows that the transfer records are highly representative 377 of the total data flow. 379 In terms of which analysis was performed from the standard logging 380 compared to extended logging, all of the data flow analysis was 381 performed using the extended logging. Pando's download counts and 382 performance numbers were generated via standard logging (i.e. all 383 peers report download complete/cancel, data volumes, and measured 384 download speed on the client). Yale's download counts and 385 performance numbers were derived via extended logging (e.g. by 386 summing the transfer records, counting IP addresses reported, etc.). 388 One benefit of having two data sources is that we can compare the 389 two. In this case, the two approaches both reported comparable 390 impacts. 392 6. Next Steps 394 One objective of this document is to share with the IETF community 395 the results of one P4P iTracker trial in a large broadband network, 396 given skepticism regarding the benefits to P2P users as well as to 397 ISPs. From the perspective of P2P users, P4P iTrackers potentially 398 deliver faster P2P downloads. At the same time, ISPs can increase 399 the localization of swarms, enabling them to reduce bytes flowing 400 over transit points, while also delivering an optimized P2P 401 experience to customers. However, an internal analysis of varying 402 levels of P4P iTracker adoption by ISPs leads us to believe that, 403 while P4P iTracker-type mechanisms are valuable on a single ISP 404 basis, the value of P4P iTrackers increases dramatically as many ISPs 405 choose to deploy it. 407 We believe these results can inform the technical discussion in the 408 IETF over how to use P4P iTracker mechanisms. Should such a 409 mechanism be standardized, the use of ISP-provided P4P iTrackers 410 should probably be an opt-in feature for P2P users, or at least a 411 feature of which they are explicitly aware of and which has been 412 enabled by default in a particular P2P client. In this way, P2P 413 users could choose to opt-in either explicitly or by their choice of 414 P2P client in order to choose to use the P4P iTracker to improve 415 performance, which benefits both the user and the ISP at the same 416 time. Importantly in terms of privacy, the P4P iTracker makes 417 available only network topology information, and would not in its 418 current form enable an ISP, via the P4P iTracker, to determine which 419 P2P clients were downloading any specific content, whether to 420 determine for example if content was a song or a movie or even the 421 title. 423 It is also possible that a P4P iTracker type of mechanism, in 424 combination with a P2P cache, could further improve P2P download 425 performance, which merits further study. In addition, this was a 426 limited trial that, while very promising, indicates a need for 427 additional technical investigation and trial work. Such follow-up 428 study should explore the effects of P4P iTrackers when more P2P 429 client software variants are involved, with larger swarms, and with 430 additional and more technically diverse content (file size, file 431 type, duration of content, etc.). 433 7. Security Considerations 435 There are no security considerations in this document. 437 NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO 438 PUBLICATION. 440 8. IANA Considerations 442 There are no IANA considerations in this document. 444 NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO 445 PUBLICATION. 447 9. Acknowledgements 449 The authors wish to acknowledge the hard work of all of the P4P 450 working group members, and specifically the focused efforts of the 451 teams at both Pando and Yale for the trial itself. Finally, the 452 authors recognize and appreciate Peter Sevcik and John Bartlett, of 453 NetForecast, Inc., for their valued independent analysis of the trial 454 results. 456 10. Informative References 458 [Dynamic Swarm Management] 459 Carlsson, N. and G. Dan, "Dynamic Swarm Management for 460 Improved BitTorrent Performance", USENIX 8th International 461 Workshop on Peer-to-Peer Systems, March 2009, . 465 [I-D.p2pi-cooper-workshop-report] 466 Peterson, J. and A. Cooper, "Report from the IETF workshop 467 on P2P Infrastructure, May 28, 2008", 468 draft-p2pi-cooper-workshop-report-01 (work in progress), 469 February 2009. 471 [RFC3083] Woundy, R., "Baseline Privacy Interface Management 472 Information Base for DOCSIS Compliant Cable Modems and 473 Cable Modem Termination Systems", RFC 3083, March 2001. 475 [SIGCOMM] Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and A. 476 Silberschatz, "ACM SIGCOMM 2008 - P4P: Provider Portal for 477 Applications", Association for Computing Machinery SIGCOMM 478 2008 Proceedings, August 2008, 479 . 481 Authors' Addresses 483 Chris Griffiths 484 Comcast Cable Communications 485 One Comcast Center 486 1701 John F. Kennedy Boulevard 487 Philadelphia, PA 19103 488 US 490 Email: chris_griffiths@cable.comcast.com 491 URI: http://www.comcast.com 492 Jason Livingood (editor) 493 Comcast Cable Communications 494 One Comcast Center 495 1701 John F. Kennedy Boulevard 496 Philadelphia, PA 19103 497 US 499 Email: jason_livingood@cable.comcast.com 500 URI: http://www.comcast.com 502 Laird Popkin 503 Pando Networks 504 520 Broadway Street 505 10th Floor 506 New York, NY 10012 507 US 509 Email: laird@pando.com 510 URI: http://www.pando.com 512 Richard Woundy (editor) 513 Comcast Cable Communications 514 27 Industrial Avenue 515 Chelmsford, MA 01824 516 US 518 Email: richard_woundy@cable.comcast.com 519 URI: http://www.comcast.com 521 Richard Yang 522 Yale University 523 51 Prospect Street 524 New Haven, CT 06520 525 US 527 Email: yry@cs.yale.edu 528 URI: http://www.cs.yale.edu