idnits 2.17.1 draft-ietf-decade-problem-statement-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (October 12, 2011) is 4578 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-18 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DECADE H. Song 3 Internet-Draft N. Zong 4 Intended status: Informational Huawei 5 Expires: April 14, 2012 Y. Yang 6 Yale University 7 R. Alimi 8 Google 9 October 12, 2011 11 DECoupled Application Data Enroute (DECADE) Problem Statement 12 draft-ietf-decade-problem-statement-04 14 Abstract 16 Peer-to-peer (P2P) applications have become widely used on the 17 Internet today and make up a large portion of the traffic in many 18 networks. In P2P applications, one technique for reducing the 19 transit and uplink P2P traffic is to introduce storage capabilities 20 within the network (the download traffic may increase because the in- 21 network storage is likely much better connected). Traditional caches 22 (e.g., P2P and Web caches) provide such storage, but they are complex 23 (due to explicitly supporting individual P2P application protocols 24 and cache refreshing mechanisms) and they do not have the feature to 25 allow users to manage access to content in the cache. For example, 26 Content Providers cannot easily control cache access and resource 27 usage policies to satisfy their own requirements. In this document, 28 a content provider is also the user of in-network storage. This 29 document discusses the introduction of in-network storage for P2P 30 applications, and shows the need for a standard protocol for 31 accessing this storage. It can also be used by other applications 32 with similar requirements. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 14, 2012. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 5 69 3. The Problems . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. P2P infrastructural stress and inefficiency . . . . . . . 6 71 3.2. P2P cache: a complex in-network storage . . . . . . . . . 6 72 3.3. Ineffective integration of P2P applications . . . . . . . 7 73 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 8 75 5.1. BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.2. Content Publisher . . . . . . . . . . . . . . . . . . . . 9 77 5.3. CDN/P2P hybrid . . . . . . . . . . . . . . . . . . . . . . 10 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 6.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 11 80 6.2. Copyright and Legal Issues . . . . . . . . . . . . . . . . 11 81 6.3. Privacy issue . . . . . . . . . . . . . . . . . . . . . . 11 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 84 9. Informative References . . . . . . . . . . . . . . . . . . . . 12 85 Appendix A. Other Related Work in IETF . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 P2P applications, including both P2P streaming and P2P filesharing 91 applications, make up a large fraction of the traffic in many ISP 92 networks today. One way to reduce bandwidth usage by P2P 93 applications is to introduce storage capabilities in the networks. 94 Allowing P2P applications to store and retrieve data from inside 95 networks can reduce traffic on the last-mile uplink, as well as 96 backbone and transit links. 98 P2P caches provide in-network storage and have been deployed in some 99 networks. But the current P2P caching architecture poses challenges 100 to both P2P cache vendors and P2P application developers. For P2P 101 cache vendors, it is challenging to support a number of continuously 102 evolving P2P application protocols, due to lack of documentation, 103 ongoing protocol changes, and rapid introduction of new features by 104 P2P applications. For P2P applications, closed P2P caching systems 105 limit P2P applications from effectively utilizing in-network storage. 106 In particular, P2P caches typically do not allow users to explicitly 107 store content into in-network storage. They do not allow users to 108 implement control over the content that has been placed into the in- 109 network storage either. 111 Both of these challenges can be effectively addressed by using an 112 open, standard protocol to access in-network storage. P2P 113 applications can store and retrieve content in the in-network 114 storage, as well as control resources (e.g., bandwidth, connections) 115 consumed by peers in a P2P application. As a simple example, a peer 116 of a P2P application may upload to other peers through its in-network 117 storage, saving its usage of last-mile uplink bandwidth. 119 In this document, we distinguish between two functional components of 120 the native P2P application protocol: signaling and data access. 121 Signaling includes operations such as handshaking and discovering 122 peer and content availability. The data access component transfers 123 content from one peer to another. 125 This document introduces DECADE, a standard interface for various P2P 126 applications to access storage and data transport services in the 127 network to improve their efficiency and reduce load on the network 128 infrastructure. 130 With DECADE, P2P applications can still use their native protocols 131 for signaling and data transport. However, they may use a standard 132 protocol for data access incorporating in-network storage, and fall 133 back to their native data transport protocols if in-network storage 134 is not available or not used. 136 In essence, an open, standard protocol to access in-network storage 137 provides an alternative mechanism for P2P application data access 138 that is decoupled from P2P application control and signaling. This 139 decoupling leads to many advantages, which is explained further in 140 Section 4. 142 And further, either the existing P2P cache or any new type of in- 143 network storage should be deployed near the edge of the ISP's network 144 so as to gain better performance. 146 2. Terminology and Concepts 148 The following terms have special meaning in the definition of the in- 149 network storage system. 151 In-network Storage: A service inside a network that provides 152 storage and bandwidth to network applications. In-network storage 153 may reduce upload/transit/backbone traffic and improve network 154 application performance. 156 P2P Cache (Peer to Peer Cache): a kind of in-network storage that 157 understands the signaling and transport of specific P2P 158 application protocols, it caches the content for those specific 159 P2P applications in order to serve peers and reduce traffic on 160 certain links. 162 Content Publisher: An entity that originates content. 164 3. The Problems 166 The emergence of peer-to-peer (P2P) as a major network application 167 (esp. P2P file sharing and streaming apps) has led to substantial 168 opportunities. The P2P paradigm can be utilized in designing highly 169 scalable and robust applications at low cost, compared with 170 traditional client-server paradigms. For example, CNN reported that 171 P2P streaming by Octoshape played a major role in its distribution of 172 the historic inauguration address of President Obama[Octoshape]. 173 PPLive, one of the largest P2P streaming vendors, is able to 174 distribute large-scale, live streaming programs to more than 2 175 million users with only a handful of servers[PPLive]. 177 However, P2P applications also face substantial design challenges. A 178 particular problem facing P2P applications is the substantial stress 179 that they place on the network infrastructure. Also, lack of 180 infrastructure support can lead to unstable P2P application 181 performance during peer churns and flash crowd. Here flash crowds 182 means a large group of application users begin to access the same 183 service during a very short period of time, which is a challenge to 184 the system. Below we elaborate on the problems in more detail. 186 3.1. P2P infrastructural stress and inefficiency 188 A particular problem of the P2P paradigm is the stress that P2P 189 application traffic places on the infrastructure of Internet service 190 providers (ISPs). Multiple measurements (e.g., [ipoque]) have shown 191 that P2P traffic has become a major type of traffic on some networks. 192 Furthermore, network-agnostic peering (P2P transmission level) leads 193 to unnecessary traversal across network domains or spanning the 194 backbone of a network, leading to network inefficiency [RFC5693]. 196 An ALTO (Application Layer Traffic Optimization) server provides P2P 197 applications with network information so that they can perform 198 better-than-random initial peer selection [RFC5693]. However, there 199 are limitations on what ALTO can achieve alone. For example, network 200 information alone cannot reduce P2P traffic in access networks, as 201 the total access upload traffic is equal to the total access download 202 traffic in a pure P2P system. On the other hand, it is reported that 203 P2P traffic is becoming the dominant traffic on the access networks 204 of some networks, reaching as high as 50-60% at the down-links and 205 60-90% at the uplinks ([DCIA], [ICNP], [ipoque.P2P_survey.], 206 [P2P_file_sharing]). Consequently, it becomes increasingly important 207 to complement the ALTO effort and reduce upload access traffic, in 208 addition to cross-domain and backbone traffic. 210 The IETF Low Extra Delay Background Transport (LEDBAT) Working Group 211 is focusing on techniques that allow large amounts of data to be 212 consistently transmitted without substantially affecting the delays 213 experienced by other users and applications. It is expected that 214 some P2P applications would start using such techniques, thereby 215 somewhat alleviating the perceivable impact (at least on other 216 applications) of their high volume traffic. However, such techniques 217 may not be adopted by all P2P applications. Also, when adopted, 218 these techniques do not remove all inefficiencies, such as those 219 associated with traffic being sent upstream as many times as there 220 are remote peers interested in getting the corresponding information. 221 For example, the P2P application transfer completion times remain 222 affected by potentially (relatively) slow upstream transmission. 223 Similarly, the performance of real-time P2P applications may be 224 affected by potentially (relatively) higher upstream latencies. 226 3.2. P2P cache: a complex in-network storage 228 An effective technique to reduce P2P infrastructural stress and 229 inefficiency is to introduce in-network storage. 231 In the current Internet, in-network storage is introduced as P2P 232 caches, either transparently or explicitly as a P2P peer. To provide 233 service to a specific P2P application, the P2P cache server must 234 support the specific signaling and transport protocols of the 235 specific P2P application. This can lead to substantial complexity 236 for the P2P Cache vendor. 238 First, there are many P2P applications on the Internet (e.g., 239 BitTorrent, eMule, Flashget, and Thunder for file sharing; Abacast, 240 Kontiki, Octoshape, PPLive, PPStream, and UUSee for P2P streaming). 241 Consequently, a P2P cache vendor faces the challenge of supporting a 242 large number of P2P application protocols, leading to product 243 complexity and increased development cost. 245 Furthermore, a specific P2P application protocol may be evolving 246 continuously, to add new features or fix bugs. This forces a P2P 247 cache vendor to continuously update to track the changes of the P2P 248 application, leading to product complexity, high cost, and low 249 reliability. 251 Third, many P2P applications use proprietary protocols or support 252 end-to-end encryption. This can render P2P caches ineffective. 254 3.3. Ineffective integration of P2P applications 256 As P2P applications evolve, it is becoming increasingly clear that 257 they will need in-network resources to provide positive user 258 experiences. For example, multiple P2P streaming systems seek 259 additional in-network resources during a flash crowd, such as just 260 before a major live streaming event. In asymmetric networks when the 261 aggregated upload bandwidth of a channel cannot meet the download 262 demand, a P2P application may seek additional in-network resources to 263 maintain a stable system. 265 A requirement by some P2P applications in using in-network 266 infrastructural resources, however, is flexibility in implementing 267 resource allocation policies. A major competitive advantage of many 268 successful P2P systems is their substantial expertise in how to most 269 efficiently utilize peer and infrastructural resources. For example, 270 many live P2P systems have specific algorithms to select those peers 271 that behave as stable, higher bandwidth sources. They continue to 272 fine-tune such algorithms. In other words, in-network storage should 273 expose basic mechanisms and allow as much flexibility as possible to 274 P2P applications to implement specific policies. This conforms to 275 the end-to-end systems principle and allows innovation and 276 satisfaction of specific business goals. Existing techniques for P2P 277 application in-network storage lack these capabilities. 279 4. Motivation 281 DECADE aims to provide access to storage and data transport services 282 in the network to P2P applications to improve their efficiency and 283 reduce the stress on the network infrastructure. Unlike the existing 284 P2P caching architecture, DECADE aims to provide a standard interface 285 for various P2P applications (both content publishers and end users) 286 to access in-network storage. This decoupling of P2P data access 287 from P2P application control and signaling reduces the complexity of 288 in-network storage services. Furthermore, DECADE is aimed to provide 289 basic access mechanisms and allows P2P applications to implement 290 flexible policies to create an ecosystem for application innovation 291 and various business goals. Besides that, it also improves the 292 availability of P2P contents because the in-network storage is 293 always-on. 295 -----------+ 296 | DECADE | 297 | v 298 +--------------------+ 299 | In-network Storage | 300 +--------------------+ 301 DECADE ^ DECADE ^ 302 | | 303 +-------------v-+ +-v-------------+ 304 | P2P | | Content | 305 | application | | publishers | 306 | clients | +---------------+ 307 +---------------+ 308 | ^ 309 | | 310 +-------------+ 311 P2P application 312 native protocol 314 Figure 1 Overview 316 5. Usage Scenarios 318 Usage scenarios are presented to illustrate how DECADE in-network 319 storage may be used in both CDN and P2P scenarios. Interactions with 320 in-network storage are described at an abstract level so as not to 321 constrain future protocol development. 323 5.1. BitTorrent 325 BitTorrent may be integrated with DECADE to be more network efficient 326 and reduce the bandwidth consumed on ISP networks. When a BitTorrent 327 client uploads a block to peers, the block traverses the last-mile 328 uplink once for each peer. With DECADE, however, the BitTorrent 329 client may upload the block to its in-network storage. Peers may 330 retrieve the block from the in-network storage, reducing the amount 331 of data on the last-mile uplink. 333 We now describe in more detail how BitTorrent can utilize DECADE. 334 For illustration, we assume that both the BitTorrent client (A) and 335 its peer (B) utilize in-network storage. When A requests a block, 336 peer B replies with a 'redirect' message indicating that the content 337 should be retrieved from in-network storage. If the peer B had not 338 previously stored the content in in-network storage, it uploads the 339 block before A retrieves it. If there is support, A may first copy 340 the block to in-network storage that is nearer to it before 341 retrieving it. 343 Note that this requires extensions to the BitTorrent protocol. While 344 there are multiple ways to do so, this example assumes the native 345 BitTorrent 'request' message is extended to carry additional 346 information and that a new 'redirect' message is added. Upload and 347 download to/from in-network storage uses a standard protocol. 349 This example has illustrated how utilizing DECADE can increase 350 BitTorrent's network efficiency. First, notice that peer B does not 351 utilize any uplink bandwidth if the block was already present in its 352 in-network storage. Second, notice that the block may be copied to 353 in-network storage nearer to A. When A wishes to share the block with 354 another peer (say, peer C) that supports DECADE, it may upload 355 directly from its in-network storage, again avoiding usage of the 356 last-mile uplink. 358 This technique can be applied to other P2P applications as well. 359 Since P2P applications use a standard for communicating with in- 360 network storage, they no longer require in-network storage to 361 explicitly support their protocol. P2P applications retain the 362 ability to explicitly manage which content is placed in in-network 363 storage, as well as access and resource control polices. 365 5.2. Content Publisher 367 Content Publishers may also utilize in-network storage. For example, 368 consider a P2P live streaming application. A Content Publisher 369 typically maintains a small number of sources, each of which 370 distributes blocks in the current play buffer to a set of the P2P 371 peers. 373 Consider a case where the Content Publisher owns an in-network 374 storage account within ISP A. If there are multiple P2P peers within 375 ISP A, the Content Publisher may utilize DECADE to distribute content 376 to the peers. 378 First, the Content Publisher stores a block in the in-network 379 storage, configures necessary access control, and notifies peers in 380 ISP A. Second, each peer may then download from the Content 381 Publisher's in-network storage. 383 In this example, the block is distributed in a more network efficient 384 way (the content only traverses the ISP's interdomain link once), 385 while the Content Publisher retains explicit control over access to 386 the content placed in its own storage. The Content Publisher can 387 remove content from its in-network storage when it is stale or needs 388 to be replaced, and grant access and resources to only the desired 389 peers. 391 Note that Content Publishers and individual peers can each use in- 392 network storage. For example, after downloading content from the 393 Content Publisher's in-network storage, peers may each utilize their 394 own in-networks storage similar to the usage scenario in Section 5.1. 395 This can have the benefit of increased network efficiency, while 396 Content Publishers and peers still retain control over content placed 397 in their own in-network storage. 399 If it desires, a content publisher may still apply DRM to the 400 payload. This is independent of any authentication or authorization 401 provided by DECADE. 403 5.3. CDN/P2P hybrid 405 Some applications use a hybrid content distribution approach 406 incorporating both P2P and CDN modes. As an example, Internet TV may 407 be implemented as a hybrid CDN/P2P application by distributing 408 content from central servers via a CDN, and also incorporating a P2P 409 mode amongst endhosts and set-top boxes. 411 DECADE may be beneficial to hybrid CDN/P2P applications as well. 412 However, if only the endhost can store content in the DECADE server, 413 the content must be downloaded and then uploaded over the last-mile 414 access link before another peer may retrieve it from a DECADE server. 415 Thus, in this deployment scenario, it may be advantageous for a 416 Content Publisher or CDN provider to store content to DECADE servers. 418 6. Security Considerations 420 There are multiple security considerations. We can not enumerate all 421 of them but focus on three main concerns in this section. 423 6.1. Denial of Service Attacks 425 An attacker can try to consume a large portion of the in-network 426 storage, or exhaust the connections of the in-network storage through 427 a Denial of Service (DoS) attack. 429 6.2. Copyright and Legal Issues 431 Copyright and other laws may prevent the distribution of certain 432 content in various localities. While in-network storage operators 433 may adopt system-wide ingress or egress filters to implement 434 necessary policies for storing or retrieving content, and 435 applications may still apply DRM to the data stored in the network 436 storage, the specification and implementation of such policies (e.g., 437 filtering and DRM) is outside of the scope of this working group. 439 6.3. Privacy issue 441 If the content stored in the provider-based in-network storage, there 442 may be a privacy risk that the provider can correlate the people who 443 are accessing the same data object using the same object identity. 445 7. IANA Considerations 447 There are no IANA considerations in this document. 449 8. Acknowledgments 451 We would like to thank the following people for contributing to this 452 document: 454 David Bryan 456 Kar Ann Chew 458 Roni Even 460 Lars Eggert 462 Yingjie Gu 463 Francois Le Faucheur 465 Hongqiang Liu 467 Tao Ma 469 Borje Ohlman 471 Akbar Rahman 473 Yu-shun Wang 475 Richard Woundy 477 Yunfei Zhang 479 9. Informative References 481 [ipoque.com] 482 "http://www.ipoque.com/resources/internet-studies/ 483 internet-study-2008_2009". 485 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 486 Optimization (ALTO) Problem Statement", RFC 5693, 487 October 2009. 489 [I-D.ietf-p2psip-base] 490 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 491 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 492 Base Protocol", draft-ietf-p2psip-base-18 (work in 493 progress), August 2011. 495 [DCIA] http://www.dcia.info, "Distributed Computing Industry 496 Association". 498 [ipoque.P2P_survey.] 499 "Emerging Technologies Conference at MIT", Sept. 2007. 501 [P2P_file_sharing] 502 Parker, A., "The true picture of peer-to-peer 503 filesharing", July 2004. 505 [Octoshape] 506 "http://www.octoshape.com/?page=company/about". 508 [PPLive] "http://www.synacast.com/products/". 510 [ICNP] Wu, H., "Challenges and opportunities of Internet 511 developments in China, ICNP 2007 Keynote", Oct. 2007. 513 Appendix A. Other Related Work in IETF 515 Note that DECADE is independent of current IETF work on P2P. The ALTO 516 work as described above is aimed for better peer selection and the 517 RELOAD [I-D.ietf-p2psip-base] protocol is used for P2P overlay 518 maintenance and resource discovery. 520 The Peer to Peer Streaming Protocol effort in the IETF is 521 investigating the specification of signaling protocols (called the 522 PPSP tracker protocol and peer protocol) for multiple entities (e.g. 523 intelligent endpoints, caches, content distribution network nodes, 524 and/or other edge devices) to participate in P2P streaming systems in 525 both fixed and mobile Internet. As discussed in the PPSP problem 526 statement, one important PPSP use case is the support of an in- 527 network edge cache for P2P Streaming. However, this approach to 528 providing in-network cache has different applicability, different 529 objectives and different implications for the in-network cache 530 operator. A DECADE service can be used for any application 531 transparently to the DECADE in-network storage operator: it can be 532 used for any P2P Streaming application (whether it supports PPSP 533 protocols or not), for any other P2P application, and for non P2P 534 applications that simply want to benefit from in-network storage. So 535 with DECADE the operator is providing a generic in-network storage 536 service that can be used by any application without application 537 involvement or awareness by the operator; in the PPSP cache use case, 538 the cache operator is participating in the specific P2P streaming 539 service. 541 DECADE and PPSP can both contribute independently, and (where 542 appropriate) simultaneously, to making content available closer to 543 peers. Here are a number of example scenarios: 545 A given network supports DECADE in-network storage, and its CDN 546 nodes do not participate as PPSP Peers for a given "stream" (e.g. 547 because no CDN arrangement has been put in place between the 548 Content Provider and the particular network provider). In that 549 case, PPSP Peers will all be "off-net" but will be able to use 550 DECADE in-network storage to exchange chunks. 552 A given network does not support DECADE in-network storage, and 553 (some of) its CDN nodes participate as PPSP Peers for a given 554 "stream" (e.g. say because an arrangement has been put in place 555 between the Content Provider and the particular network provider). 556 In that case, the CDN nodes will participate as in-network PPSP 557 Peers. The off-net PPSP Peers (i.e., end users) will be able to 558 get chunks from the in-network CDN nodes (using PPSP protocols 559 with the CDN nodes). 561 A given network supports DECADE in-network storage, and (some of) 562 its CDN nodes participate as PPSP Peers for a given "stream" (e.g. 563 say because an arrangement has been put in place between the 564 Content Provider and the particular network provider). In that 565 case, the CDN nodes will participate as in-network PPSP Peers. 566 The off-net PPSP Peers (i.e., end users) will be able to get 567 chunks from the in-network CDN nodes (using PPSP protocols with 568 the CDN nodes) as well as be able to get chunks / share chunks 569 using DECADE in-network storage populated by PPSP Peers (both off- 570 net end-users and in-network CDN Nodes). 572 PPSP and DECADE jointly to provide P2P streaming service for 573 heterogeneous networks including both fixed and mobile connections 574 and enables the mobile nodes to use DECADE. In this case there 575 may be some solutions to require more information in PPSP tracker 576 protocol, e.g., the mobile node can indicate its DECADE in-network 577 proxy to PPSP tracker and the following requesting peer can finish 578 data transfer with the DECADE proxy. 580 Authors' Addresses 582 Haibin Song 583 Huawei 584 101 Software Avenue, Yuhua District, 585 Nanjing, Jiangsu Province 210012 586 China 588 Phone: +86-25-56624792 589 Email: haibin.song@huawei.com 591 Ning Zong 592 Huawei 593 101 Software Avenue, Yuhua District, 594 Nanjing, Jiangsu Province 210012 595 China 597 Phone: +86-25-56624760 598 Email: zongning@huawei.com 599 Y. Richard Yang 600 Yale University 602 Email: yry@cs.yale.edu 604 Richard Alimi 605 Google 607 Email: ralimi@google.com