idnits 2.17.1 draft-gu-alto-redistribution-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 461 has weird spacing: '... ooo peer...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 12, 2010) is 5031 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational draft: draft-ietf-alto-problem-statement (ref. 'I-D.ietf-alto-problem-statement') == Outdated reference: A later version (-05) exists of draft-kiesel-alto-3pdisc-03 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO Y. Gu 3 Internet-Draft Huawei 4 Intended status: BCP R. Alimi 5 Expires: January 13, 2011 Yale University 6 R. Even 7 Huawei 8 July 12, 2010 10 ALTO Information Redistribution 11 draft-gu-alto-redistribution-03 13 Abstract 15 The ALTO protocol proposes several mechanisms to increase 16 scalability. One of the proposed mechanisms is ALTO information 17 redistribution. This document concretely defines ALTO Information 18 Redistribution, indicates suggested extensions to the ALTO Protocol 19 to support redistribution, and shows how redistribution could be used 20 in practice. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 13, 2011. 39 Copyright Notice 41 Copyright (c) 2010 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 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminologies and concepts . . . . . . . . . . . . . . . . . . 4 58 3. Redistribution Framework . . . . . . . . . . . . . . . . . . . 4 59 3.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 5 60 3.2. ALTO Information Types . . . . . . . . . . . . . . . . . . 5 61 3.3. Redistribution Scheme Design . . . . . . . . . . . . . . . 6 62 4. ALTO Redistribution Solutions Analysis . . . . . . . . . . . . 6 63 4.1. PUSH Information into Overlay . . . . . . . . . . . . . . 7 64 4.1.1. General Requirements for PUSH . . . . . . . . . . . . 7 65 4.1.2. Tracker Acts as Redistribution Proxy . . . . . . . . . 8 66 4.1.3. Supernode Acts as Redistribution Proxy . . . . . . . . 8 67 4.1.4. Advantages of PUSH . . . . . . . . . . . . . . . . . . 8 68 4.2. PULL Inforamtion into Overlay . . . . . . . . . . . . . . 9 69 4.2.1. PULL Use Cases . . . . . . . . . . . . . . . . . . . . 9 70 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 73 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 When providing an ALTO service, Network Providers offer information 79 to clients with the goal of helping P2P applications to perform 80 better peer selection and improving network efficiency. The ALTO 81 Service becomes a distribution point of network information for ALTO 82 Clients within its network. A Network Provider may deploy an ALTO 83 Service using techniques such as load balancing and caching to handle 84 a large number of subscribers. In this document, we discuss an 85 additional mechanism to distribute ALTO information to ALTO Clients: 86 ALTO Information Redistribution. Consider a scenario where a large 87 number (e.g., millions) of users start their P2P live streaming 88 clients just before the start of a popular event. Each client 89 requests ALTO information directly from the ALTO Service within their 90 ISP if it has not yet been retrieved or needs to be refreshed. For 91 certain content (e.g., content with broad interest), even the number 92 of streaming clients within a single ISP may be extremely large. For 93 example, tens of millions of people watched the United States 94 Presidential Inauguration in Jan. 2009 via the Internet through such 95 sites as CNN. During the 2009 Spring Festival Evening in China, an 96 audience of about 24 million watched the program on the Internet. In 97 such a case, an ISP's ALTO Service may not be able to handle the load 98 and provide ALTO information directly to each client. 100 Many mechanisms, such as load balancing, can be used to increase 101 scalability of an ALTO Service. [I-D.penno-alto-protocol] proposes 102 ALTO Information Redistribution as one technique. Using ALTO 103 Information Redistribution, ALTO Clients may distribute ALTO 104 information to each other instead of requesting directly from the 105 ALTO Server. For example, a P2P infrastructure can be used to 106 distribute ALTO information to a large number of ALTO Clients with 107 small load on the ALTO Server. 109 This document serves three primary purposes: 111 1) Defines basic requirements for redistributing ALTO information, 112 and considerations for developing a redistribution scheme. 114 2) Propose extensions to the ALTO Protocol to support ALTO 115 Information redistribution to meet the defined requirements. 117 3) Provide use cases showing how redistribution may be applied in 118 practice. 120 We envision that multiple redistribution schemes are possible, and 121 the design may depend on the particular setting, such as scalability 122 requirements and existing application protocols. Thus, 123 standardization of a redistribution scheme for all kinds of scenario 124 is not an object. This BCP intends to extract the fundamental for 125 real-world practice, and to provide use cases for most common 126 scenario of ALTO Redistribution. 128 Note that certain design changes during the development of the ALTO 129 Protocol may affect ALTO information redistribution. This document 130 will be updated to track the progress of the ALTO Protocol. 132 2. Terminologies and concepts 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in[RFC2119]. 138 The document uses terms defined in 139 [I-D.ietf-alto-problem-statement]and [I-D.penno-alto-protocol]. 141 3. Redistribution Framework 143 Before defining requirements for ALTO Information Redistribution, we 144 first give a concrete model for ALTO Information Redistribution that 145 we use in this document: 147 1. A set of ALTO Servers {S1, S2, S3, ...} are deployed, each 148 possibly serving a different network region. 150 2. A set of ALTO Clients are running. We assume that each ALTO 151 Client can be mapped to one of the available ALTO Servers by the 152 ALTO discovery process [I-D.song-alto-server-discovery]. Let 153 Clients(Si) denote the set of ALTO Clients mapped to ALTO Server 154 Si. 156 3. An ALTO Client wishes to obtain a particular set of information 157 from the ALTO Server. The desired information is fully specified 158 by: (1) the ALTO Server (hostname and port), and (2) the query 159 and input parameters that would be sent to the ALTO Server. See 160 Section 6 for a discussion of behavior when criteria other than 161 the input parameters are used by an ALTO Server to generate a 162 response. 164 4. An ALTO Client may obtain the information either directly from 165 its ALTO Server Si, or it may obtain the information from a 166 member of Clients(Si). 168 5. For a particular query to ALTO Server Si, at least one member of 169 Clients(Si) directly fetches from Si. The remaining members of 170 Clients(Si) obtain the information from some other member in 171 Clients(Si). 173 3.1. Basic Requirements 175 A redistribution scheme should satisfy some basic requirements in 176 order to successfully redistribute an ALTO Server's response to a set 177 of ALTO Client. 179 1. The ALTO Client should be able to identify the desired 180 redistributed data based only on the ALTO Server hostname and 181 port, and the input parameters. 183 2. The ALTO Client should be able to check the validity of the 184 information once it is retrieved. That is, the ALTO Client 185 should be able to determine if the retrieved information was 186 indeed generated by its ALTO Server, , and is generated based on 187 the particular input parameters. 189 3.2. ALTO Information Types 191 In general, it should be possible to redistribute the response from a 192 particular ALTO Server that does not depend on anything except query 193 input parameters. However, redistribution may only be worthwhile for 194 queries that are made by a large number of ALTO Clients. In the 195 context of [I-D.penno-alto-protocol], we provide an example list of 196 information types that may be commonly used across many ALTO Clients, 197 and hence benefit from redistribution. The example list the most 198 obvious examples to our best knowledge, and there might be other 199 information types that are suitable for redistribution. 201 o Server Capability which indicates the capabilities implemented by 202 an ALTO Server. 204 o Full Network Map which lists the PIDs and IP prefixes that are 205 contained within each PID. 207 o Full Path Cost Map among all PIDs, which indicates the Path Cost 208 between each pair of PIDs. 210 [I-D.penno-alto-protocol]also specifies certain queries that may not 211 benefit from redistribution. For example, if a peer requests ordinal 212 Path Costs (i.e., a ranked list) for a set of individual endpoint 213 addresses (i.e., Resource Providers), the response may not be useful 214 to other ALTO Clients. This is because other ALTO Clients may be 215 running different applications or have a different set of available 216 peers (e.g., participating in a different swarm, or be in contact 217 with a different set of peers within the same swarm). 219 3.3. Redistribution Scheme Design 221 While this document does not fully specify a particular 222 redistribution scheme, we provide a sampling of decisions that should 223 be considered when designing an implementing a redistribution scheme. 224 This list can be used as a guide for implementers when designing a 225 redistribution scheme for a particular setting. Considerations for a 226 redistribution scheme include: 228 o Who places the ALTO Information onto overlay, and how the ALTO 229 Information is published on the overlay 231 o How could peers decide whether to get ALTO Information from ALTO 232 Server or to get from Overlay? 234 o What method is used for peers to locate redistributed ALTO 235 information? 237 o What protocol is used for retrieving redistributed ALTO 238 information? 240 o How could peers verify the Redistributed Information it obtained. 242 o How to update the Redistributed Information on time and who is 243 responsible for updating. 245 o What naming scheme is used to specify the ALTO Server hostname, 246 port, and input parameters in the protocol for locating 247 redistributed ALTO information? For example, the naming scheme 248 could define how to compute the 'key' in a DHT. 250 o How is the redistributed information encoded? Note that the 251 original response from the ALTO Service may be reformatted (e.g., 252 compressed) for redistribution. Note that if this approach is 253 taken and ALTO Clients still wish to verify received information, 254 ALTO Clients should be able to reconstruct the ALTO Service's 255 original response (e.g., via decompression). If a lossy 256 transformation is used (e.g., filtering), ALTO Clients may not be 257 able to verify the received information. 259 4. ALTO Redistribution Solutions Analysis 261 In this section, we present our considerations on Redistribution 262 Implementation. In the previous section, several questions have been 263 enumerated, and the answer to the first question is the baseline of 264 ALTO Redistribution. There are two distinct ways to place the ALTO 265 Information into the overlay: Redistribution Proxy PUSH the 266 Information into the overlay or components of the overlay PULL the 267 Information into the Overlay. 269 The main difference betwen PUSH and PULL is as follows. 271 o In PUSH, the Redistribution Proxy can publish the updated 272 redistribution Information into the overlay. Since the 273 Redistribution Proxy can be much intelligent than a normal peer, 274 e.g. Redistribution Proxy has overall understanding of the 275 overlay, it can make decision on how to distribute the Information 276 in order to utilize the overlay much efficient. For example, 277 integration with DECADE, distribution via a CDN (many P2P apps are 278 integrating CDNs now). We will add more use case for PUSH in our 279 later version. 281 o While In PULL, peers individually pull/request updated ALTO 282 information from an overlay or ALTO server. Considering the 283 general size of a redistributable information, there might be an 284 out-of-control flooding through the overlay. 286 In the following text, we introduces some consideration of both PUSH 287 and PULL, and conclude other features of PUSH and PULL. 289 4.1. PUSH Information into Overlay 291 In PUSH method, we introduce a new terminology, Redistribution Proxy. 293 A Redistribution Proxy can be a Tracker in Tracker-based P2P Overlay 294 or a supernode either in Tracker-based or Trackerless P2P Overlay. 295 The duty of Redistribution Proxy to accecpt the redistributable 296 information from ALTO Server and push the information into the 297 overlay. There are two options on obtaining redistributable 298 inforamtion from ALTO Server. One is Redistribution Proxy request 299 and ALTO Server answers or ALTO Server positively update the 300 information to the Redistribution Proxy. Since the number of 301 Redistribution Proxy is much fewer than the total number of ALTO 302 Clients, so the latter option does not occupy much connection 303 resources on ALTO Server. In our draft, we introduce the PUSH based 304 on the latter option, which is ALTO Server pushes the uptaed 305 information to Redistribution Proxy positivly. 307 4.1.1. General Requirements for PUSH 309 To make PUSH feasible, the following requirements must be satisfied. 311 o Redistribution Proxy MUST has public IP Addresse, so that both 312 ALTO server and Peers can connect with it without NAT issue. 314 o ALTO server MUST know Redistribution proxy's IP Address. 316 o Redistribution Proxy MUST be reliable. 318 4.1.2. Tracker Acts as Redistribution Proxy 320 If Tracker is deployed as Redistribution Proxy, it has two choices. 322 Tracker can publish the ALTO Information into overlay, then peers can 323 search and obtain the Information through Overlay. 325 Or Tracker can store the Information on itself, and answer peers' 326 particular request based on the Information. For those information 327 that is not redistributable, peers can request directly from ALTO 328 server or ask Tracker to request from ALTO server and answer. 330 In both case, an indication is necessary for telling peers where to 331 get ALTO Service. For example, peers should know that for those 332 redistributable type of Information, peers should first request from 333 Tracker, and for those unredistributable, they should request from 334 ALTO Sever. Which can be configured by application. The definition 335 of indication configuration is out of the scope of ALTO. 337 4.1.3. Supernode Acts as Redistribution Proxy 339 If Supernode is deployed as Redistribution Proxy, it has two choices 340 as well. 342 Supernode store the Information and answer peers request. In this 343 case, peers should learn Supernode's IP Address in advance. 345 Or Supernode just publish the Information into the overlay and then 346 peers search and get the Information through the overlay. 348 In both case, an indication is necessary as well. 350 4.1.4. Advantages of PUSH 352 The advantages of PUSH is obvious. 354 1 Intelligence. Refer to the text that explain the main difference 355 between PUSH and PULL. 357 2 Scalability. PUSH can significantly reduce the request directly 358 sent to ALTO Server, which can reduce the load on ALTO Server. 360 3 Quick updating. Once the ALTO Information is updated in Server, 361 ALTO server can notify the Redistribution Proxy with new 362 Information. 364 4 Good Consistency, because redistributed Informaiton can be updated 365 in time. 367 5 Never expiration, because the redistributed Information is always 368 as new as those in the server. 370 6 Safe. Redistribution Proxy is reliable. 372 7 Low latency, because peers do not need to search and locate the 373 redistribution Information on the overlay, which is extremely 374 meaningful for time sensitive application, e.g. Live streaming. 376 4.2. PULL Inforamtion into Overlay 378 There could be Tracker or peers who PULL the ALTO Information into 379 the overlay. 381 If it's peer that pull ALTO information into the overlay, several 382 aspects should be considered. 384 1 Where to request for ALTO Information first, ALTO server or 385 overlay? This can be configured by application, e.g. always 386 request redistributable type of ALTO Information through Overlay 387 first. If appliction configuration recommends peer to request 388 from ALTO Server first, this won't be any good to ALTO 389 Redistribution. 391 2 Publishing mechanism. Should peer store the Information on itself 392 and publish the resource into the overlay, or should peer store 393 the Information on the corresponding responsible peer on the 394 overlay? However, this won't make much difference. 396 3 How to authenticate the Information? We have introduce a security 397 method with Signature, which is now in ALTP Protocol, while the 398 question is where to get the Public Key. 400 4.2.1. PULL Use Cases 402 The architecture of a particular P2P application will affect the 403 redistribution mechanism. Generally speaking, there are two kinds of 404 P2P applications: trackerless, and those using a tracker. In 405 Tracker-based applications, a resource directory is maintained on a 406 tracker, and peers contact the tracker to learn about new peers. In 407 a Trackerless overlay, peers are organized through a particular 408 algorithm, e.g. DHT, and they publish or find resources by routing 409 through the overlay. 411 4.2.1.1. Tracker-based redistribution 413 1. The Tracker finds the ALTO server on behalf of a peer, queries 414 the necessary ALTO information and replies to the peer with the 415 ALTO information as well as the candidate list. 416 [I-D.kiesel-alto-3pdisc] describes several methods by which 417 Tracker can find the right ALTO server. Note that the Tracker 418 might omit the 'more preferred' peers when making the original 419 selection. However, the ALTO Information can be applied to peers 420 learned from other sources (e.g., Peer Exchange and/or DHT). 422 2. A peer asks for a Resource and Tracker replies without any ALTO 423 information. The peer queries the ALTO server for ALTO 424 information, and selects peers. In order to help lessen the 425 burden on ALTO server, as well as to help other peers who want 426 the same ALTO information, the peer publishes the ALTO 427 information on the Tracker (if the Tracker allows this behavior). 428 Peers may then distribute the ALTO information just as any other 429 Resource. The method introduced here can be regard as a 430 complementary process to (1). 432 +-------------+ 433 | | 434 | ALTO | 435 | Server | 436 | | 437 +-------------+ 438 | 439 | (1) Query 440 | and 441 | Response 442 ^^^^^^^^^^^^^^^|^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 443 ^ +-----------------+ +----------------+ ^ 444 ^ | | | | ^ 445 ^ | Peer A | | Peer B | ^ 446 ^ | (ALTO Client) | | (ALTO Client) | ^ 447 ^ +-----------------+ +----------------+ ^ 448 ^ * (3) * o ^ 449 ^ * Redistribution * o (2) ^ 450 ^ ************************** o peer ^ 451 ^ o request ^ 452 ^ o ^ 453 ^ o ^ 454 ^ +---------------+ ^ 455 ^ | | ^ 456 ^ | Tracker | ^ 457 ^ | | ^ 458 ^ +---------------+ ^ 459 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 460 --- ALTO query and response protocol 461 ooo peer request protocol in p2p overlay (out of scope) 462 *** ALTO information redistribution in overlay 464 Information redistribution among peers in Tracker-based P2P 465 Application 467 4.2.1.2. Trackerless redistribution 469 In a Trackerless overlay, peers obtain the ALTO information, then 470 publish it via a P2P protocol (e.g., in a DHT). Peers can also 471 locate and retrieve ALTO information through the protocol. 473 +------------+ 474 | | 475 | ALTO | 476 | Server | 477 | | 478 +------------+ 479 | 480 | (1) Query 481 | and 482 | Response 483 ^^^^^^^^^^^^^^^|^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 484 ^ +------------------+ +-------------------+ ^ 485 ^ | | | | ^ 486 ^ | Peer A | | Peer B | ^ 487 ^ | (ALTO Client) | | (ALTO Client) | ^ 488 ^ +------------------+ +--------------------+ ^ 489 ^ * (2) * ^ 490 ^ * Overlay redistribution * ^ 491 ^ *************************** ^ 492 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 493 --- ALTO query and response protocol 494 *** ALTO information searching and redistribution 495 by using P2P Protocol 497 Information redistribution among peers in Trackerless P2P Overlay 499 4.2.1.2.1. Lookup in DHT 501 When searching for a piece of data in a DHT, a node constructs an 502 identifier for the desired data. We propose here a simple naming 503 scheme that can be used to lookup ALTO Information in a DHT. This is 504 provided as a suggestion for an implementation technique, and is not 505 a requirement on redistribution implementations employing a DHT. 507 Also note that the ALTO Information does not need to be included 508 directly in the DHT. A mechanism such as the Distributed Tracker 509 implemented in Vuze [http://www.vuze.com] could be used to locate an 510 ALTO Client that in turn provides access to the ALTO Information. 512 This naming scheme allows redistribution of ALTO information 513 requested using HTTP GET requests in [I-D.penno-alto-protocol] Since 514 REST-style URLs are used, input parameters are included directly in 515 the URL (along with ALTO Server hostname and port). Thus, we compute 516 a hash of the form: 518 hash("alto:REQUEST_URL") 519 hash("alto:REQUEST_URL") 521 where REQUEST_URL is the full HTTP URL that would have been used to 522 request ALTO information from the ALTO Server directly. The 523 resulting string can be used as the lookup key in the DHT. 525 The following simple examples show how the scheme applies to the 526 Information Types in Section 3.2: 528 1) Server Capability 530 hash("alto:http://alto.example.com:80/capability"). 532 2) Full Network Map. 534 hash("alto:http://alto.example.com:80/prop/pid/map"). 536 3) Full Path Cost among all PIDs 538 hash("alto:http://alto.example.com:80/cost/pid/map"). 540 5. Acknowledgments 542 The authors would like to give special thanks to Jan Seedorf and many 543 others for the illuminative discussion in the mailing list. The 544 authors also thank David Bryan for providing comments on preliminary 545 versions of the draft. 547 6. References 549 6.1. Normative References 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, March 1997. 554 [I-D.ietf-alto-problem-statement] 555 Seedorf, J. and E. Burger, "Application-Layer Traffic 556 Optimization (ALTO) Problem Statement", 557 draft-ietf-alto-problem-statement-04 (work in progress), 558 September 2009. 560 6.2. Informative References 562 [I-D.penno-alto-protocol] 563 Penno, R. and Y. Yang, "ALTO Protocol", 564 draft-penno-alto-protocol-04 (work in progress), 565 October 2009. 567 [I-D.kiesel-alto-3pdisc] 568 Kiesel, S., Tomsu, M., Schwan, N., Scharf, M., and M. 569 Stiemerling, "Third-party ALTO server discovery", 570 draft-kiesel-alto-3pdisc-03 (work in progress), July 2010. 572 [I-D.song-alto-server-discovery] 573 Yongchao, S., Tomsu, M., Garcia, G., Wang, Y., and V. 574 Avila, "ALTO Service Discovery", 575 draft-song-alto-server-discovery-03 (work in progress), 576 July 2010. 578 Authors' Addresses 580 Gu Yingjie 581 Huawei 582 Baixia Road No. 91 583 Nanjing, Jiangsu Province 210001 584 P.R.China 586 Phone: +86-25-84565868 587 Fax: +86-25-84565888 588 Email: guyingjie@huawei.com 590 Richard Alimi 591 Yale University 593 Email: richard.alimi@yale.edu 595 Roni Even 596 Huawei 598 Email: ron.even.tlv@gmail.com