idnits 2.17.1 draft-stiemerling-alto-deployments-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- ** 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 187 has weird spacing: '...logical ser...' == Line 216 has weird spacing: '...logical ser...' -- The document date (March 8, 2010) is 5162 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'I-D.penno-alto-protocol' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'I-D.stiemerling-alto-h1h2-protocol' is defined on line 553, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-02 == Outdated reference: A later version (-05) exists of draft-kiesel-alto-3pdisc-01 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO M. Stiemerling 3 Internet-Draft NEC Europe Ltd. 4 Intended status: Standards Track S. Kiesel 5 Expires: September 9, 2010 University of Stuttgart 6 March 8, 2010 8 ALTO Deployment Considerations 9 draft-stiemerling-alto-deployments-02 11 Abstract 13 Many Internet applications are used to access resources, such as 14 pieces of information or server processes, which are available in 15 several equivalent replicas on different hosts. This includes, but 16 is not limited to, peer-to-peer file sharing applications. The goal 17 of Application-Layer Traffic Optimization (ALTO) is to provide 18 guidance to these applications, which have to select one or several 19 hosts from a set of candidates, that are able to provide a desired 20 resource. The protocol is under specification in the ALTO working 21 group. However, this document discusses the deployment 22 considerations of ALTO and also some preliminary security 23 considerations. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on September 9, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Placement of ALTO Server . . . . . . . . . . . . . . . . . . . 8 67 4. Cascading ALTO Servers . . . . . . . . . . . . . . . . . . . . 11 68 5. API between ALTO Client and Application . . . . . . . . . . . 13 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 6.1. Information Leakage from the ALTO Server . . . . . . . . . 14 71 6.2. ALTO Server Access . . . . . . . . . . . . . . . . . . . . 14 72 6.3. Faking ALTO Guidance . . . . . . . . . . . . . . . . . . . 15 73 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 77 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 80 1. Introduction 82 Many Internet applications are used to access resources, such as 83 pieces of information or server processes, which are available in 84 several equivalent replicas on different hosts. This includes, but 85 is not limited to, peer-to-peer file sharing applications. The goal 86 of Application-Layer Traffic Optimization (ALTO) is to provide 87 guidance to applications, which have to select one or several hosts 88 from a set of candidates, that are able to provide a desired 89 resource. The basic ideas of ALTO are described in the problem space 90 of ALTO is described in [RFC5693] and the set of requirements is 91 discussed in [I-D.kiesel-alto-reqs]. 93 However, there are no considerations about what issues are to be 94 expected once ALTO will be deployed. This includes, but is not 95 limited to, location of the ALTO server, imposed load to the ALTO 96 server, or from whom the queries are performed. 98 Comments and discussions about this memo should be directed to the 99 ALTO working group: alto@ietf.org. 101 2. Overview 103 The ALTO protocol is a client/server protocol, operating between a 104 number of ALTO clients and an ALTO server, as sketched in Figure 1. 106 The ALTO working groups defines the ALTO protocol based on the P4P 107 proposal [I-D.ietf-alto-protocol], but there are also other past and 108 current protocol proposals, such as, H12 [I-D.kiesel-alto-h12], or 109 the oracle approach [I-D.akonjang-alto-proxidor] the infoexport 110 approach [I-D.shalunov-alto-infoexport]. Irrespectively of all 111 mentioned protocols, the common set is always where the ALTO server 112 is located an who is actually the querying entity to that ALTO 113 server. 115 +----------+ 116 | ALTO | 117 | Server | 118 +----------+ 119 ^ 120 _.-----|------. 121 ,-'' | `--. 122 ,' | `. 123 ( Network | ) 124 `. | ,' 125 `--. | _.-' 126 `------|-----'' 127 v 128 +----------+ +----------+ +----------+ 129 | ALTO | | ALTO |...| ALTO | 130 | Client | | Client | | Client | 131 +----------+ +----------+ +----------+ 133 Figure 1: Network Overview of ALTO Protocol 135 An ALTO server stores information about preferences (e.g., a list of 136 preferred autonomous systems, IP ranges, etc) and ALTO clients can 137 retrieve these preferences. However, there are basically two 138 different approaches on where the preferences are actually processed: 140 1. The ALTO server has a list of preferences and clients can 141 retrieve this list via the ALTO protocol. This preference list 142 can be partially updated by the server. The actual processing of 143 the data is done on the client and thus there is no data of the 144 client's operation revealed to the ALTO server . This approach 145 has been proposed by [I-D.shalunov-alto-infoexport]. 147 2. The ALTO server has a list of preferences or preferences 148 calculated during runtime and the ALTO client is sending 149 information of its operation (e.g., a list of IP addresses) to 150 the server. The server is using this operational information to 151 determine its preferences and returns these preferences (e.g., a 152 sorted list of the IP addresses) back to the ALTO client. This 153 approach has been initially described in [ACM.ispp2p], but never 154 been described on the protocol level. 156 Approach 1 (we call it H1) has the advantage (seen from the client) 157 that all operational information stays within the client and is not 158 revealed to the provider of the server. On the other hand, does 159 approach 1 require that the provider of the ALTO server, i.e., the 160 network operator, reveals information about its network structure 161 (e.g., AS numbers, IP ranges, topology information in general) to the 162 ALTO client. 164 Approach 2 (we call it H2) has the advantage (seen from the operator) 165 that all operational information stays with the ALTO server and is 166 not revealed to the ALTO client. On the other hand, does approach 2 167 require that the clients send their operational information to the 168 server. 170 Both approaches have their pros and cons and are extensively 171 discussed on the ALTO mailing list. But there is basically a 172 dilemma: Approach 1 is seen as the only working solution by peer-to- 173 peer software vendors and approach 2 is seen as the only working by 174 the network operators. But neither the software vendors nor the 175 operators seem to willing to change their position. However, there 176 is the need to get both sides on board, to come to a solution. 178 +-----+ 179 **| |** 180 ** +-----+ * 181 ** * * 182 ** * * 183 +-----+ +------+ +-----+** +-----+ * 184 | |.....| |=====| |**********| | * 185 +-----+ +------+ +-----+** +-----+ * 186 Source of ALTO Resource ** * * 187 topological service directory ** * * 188 information ("tracker") ** +-----+ * 189 **| |** 190 +-----+ 191 Peers 192 Legend: 193 === ALTO client protocol 194 *** Application protocol 195 ... Provisioning protocol 197 Figure 2: Overview of protocol interaction between ALTO elements, 198 scenario with tracker 200 However, Figure 2does not denote where the ALTO elements are actually 201 located, i.e., if the tracker and the ALTO server are in the same 202 ISP's domain, or if the tracker and the ALTO server are managed/ 203 owned/located in different domains. The latter is the typical use 204 case, e.g., taking Pirate Bay as example that serves Bittorrent users 205 world-wide. 207 +-----+ 208 =====| |** 209 ==== +-----+ * 210 ==== * * 211 ==== * * 212 +-----+ +------+===== +-----+ * 213 | |.....| |======================| | * 214 +-----+ +------+===== +-----+ * 215 Source of ALTO ==== * * 216 topological service ==== * * 217 information ==== +-----+ * 218 =====| |** 219 +-----+ 220 Legend: 221 === ALTO client protocol 222 *** Application protocol 223 ... Provisioning protocol 225 Figure 3: Overview of protocol interaction between ALTO 226 elements,scenario without tracker 228 Figure 3 shows the operational model for applications that do not use 229 a tracker, such as, edonky, or in if the tracker should be the 230 querying party. This use case also holds true for CDNs. The ALTO 231 server can also be queried by CDNs to get a guidance about where the 232 a particular client accessing data in the CDN is exactly located in 233 the ISP's network. 235 3. Placement of ALTO Server 237 This section discuss where the ALTO server can be placed and which 238 entities are querying the ALTO server from what ALTO client. The 239 section assumes a P2P system relying a tracker to initially find 240 other peers. However, the tracker can be replaced by any other 241 database that provides a rendezvous point for an application. The 242 limitation to a tracker is made for educational purpose, i.e. to ease 243 the general understanding. 244 ,-------. 245 ,---. ,-' `-. +-----------+ 246 ,-' `-. / ISP 1 \ | Peer 1 |***** 247 / \ / +-------------+ \ | | * 248 / ISP X \ +=====>+ ALTO Server | )+-----------+ * 249 / \ = \ +-------------+ / +-----------+ * 250 ; +-----------+ : = \ / | Peer 2 | * 251 | | Tracker |<====+ `-. ,-' | |***** 252 | |ALTO Client|<====+ `-------' +-----------+ ** 253 | +-----------+ | = ,-------. ** 254 : * ; = ,-' `-. +-----------+ ** 255 \ * / = / ISP 2 \ | Peer 3 | ** 256 \ * / = / +-------------+ \ | |***** 257 \ * / +=====>| ALTO Server | )+-----------+ *** 258 `-. * ,-' \ +-------------+ / +-----------+ *** 259 `-*-' \ / | Peer 4 |***** 260 * `-. ,-' | | **** 261 * `-------' +-----------+ **** 262 * **** 263 * **** 264 ***********************************************<****** 265 Legend: 266 === ALTO client protocol 267 *** Application protocol 269 Figure 4: Global tracker accessing ALTO server at various ISPs 271 Figure 4 depicts a tracker-based system, where the tracker embeds the 272 ALTO client. The tracker itself is hosted and operated by an entity 273 different than the ISP hosting and operating the ALTO server. 274 Initially, the tracker has to look-up the ALTO server in charge for 275 each peer where it receives a ALTO query for. Therefore, the ALTO 276 server has to discover the handling ALTO server, as described in 277 [I-D.kiesel-alto-3pdisc]. However, the peers do not have any way to 278 query the server themselves. This setting allows to give the peers a 279 better selection of candidate peers for their operation at an initial 280 time, but does not consider peers learned through direct peer-to-peer 281 knowledge exchange, AKA peer exchange in various peer-to-peer 282 protocols. 284 ,-------. +-----------+ 285 ,---. ,-' `-. +==>| Peer 1 |***** 286 ,-' `-. / ISP 1 \ = |ALTO Client| * 287 / \ / +-------------+<=+ +-----------+ * 288 / ISP X \ | + ALTO Server |<=+ +-----------+ * 289 / \ \ +-------------+ /= | Peer 2 | * 290 ; +---------+ : \ / +==>|ALTO Client|***** 291 | | Global | | `-. ,-' +-----------+ ** 292 | | Tracker | | `-------' ** 293 | +---------+ | ,-------. +-----------+ ** 294 : * ; ,-' `-. +==>| Peer 3 | ** 295 \ * / / ISP 2 \ = |ALTO Client|***** 296 \ * / / +-------------+<=+ +-----------+ *** 297 \ * / | | ALTO Server |<=+ +-----------+ *** 298 `-. * ,-' \ +-------------+ /= | Peer 4 |***** 299 `-*-' \ / +==>|ALTO Client| **** 300 * `-. ,-' +-----------+ **** 301 * `-------' **** 302 * **** 303 ***********************************************<**** 304 Legend: 305 === ALTO client protocol 306 *** Application protocol 308 Figure 5: Global Tracker - Local ALTO Servers 310 The scenario in Figure 5 lets the peers directly communicate with 311 their ISP's ALTO server (i.e., ALTO client embedded in the peers), 312 giving thus the peers the most control on which information they 313 query for, as they can integrate information received from trackers 314 and through direct peer-to-peer knowledge exchange. 316 ,-------. +-----------+ 317 ,---. ,-' ISP 1 `-. ***>| Peer 1 | 318 ,-' `-. /+-------------+\ * | | 319 / \ / + Tracker |<** +-----------+ 320 / ISP X \ | +-----===-----+<** +-----------+ 321 / \ \ +-----===-----+ /* | Peer 2 | 322 ; +---------+ : \+ ALTO Server |/ ***>| | 323 | | Global | | +-------------+ +-----------+ 324 | | Tracker | | `-------' 325 | +---------+ | +-----------+ 326 : ^ ; ,-------. | Peer 3 | 327 \ * / ,-' ISP 2 `-. ***>| | 328 \ * / /+-------------+\ * +-----------+ 329 \ * / / + Tracker |<** +-----------+ 330 `-. *,-' | +-----===-----+ | | Peer 4 |<* 331 `---* \ +-----===-----+ / | | * 332 * \+ ALTO Server |/ +-----------+ * 333 * +-------------+ * 334 * `-------' * 335 *********************************************** 336 Legend: 337 === ALTO client protocol 338 *** Application protocol 340 Figure 6: P4P approach with local tracker and local ALTO server 342 There are some attempts to let ISP's to deploy their own trackers, as 343 shown in Figure 6. In this case, the client has no chance to get 344 guidance from the ALTO server, other than talking to the ISP's 345 tracker. However, the peers would have still chance the contact 346 other trackers, deployed by entities other than the peer's ISP. 348 Figure 6 and Figure 4 ostensibly take peers the possibility to 349 directly query the ALTO server, if the communication with the ALTO 350 server is not permitted for any reason. However, considering the 351 plethora of different applications of ALTO, e.g., multiple tracker 352 and non-tracker based P2P systems and or applications searching for 353 relays, it seems to be beneficial for all participants to let the 354 peers directly query the ALTO server. The peers are also the single 355 point having all operational knowledge to decide whether to use the 356 ALTO guidance and how to use the ALTO guidance. This is a preference 357 for the scenario depicted in Figure Figure 5. 359 4. Cascading ALTO Servers 361 The main assumptions of ALTO seems to be each ISP operates its own 362 ALTO server independently, irrespectively of the ISP's situation. 363 This may true for most envisioned deployments of ALTO but there are 364 certain deployments that may have different settings. Figure 7 shows 365 such setting, were for example, a university network is connected to 366 two upstream providers. ISP2 if the national research network and 367 ISP1 is a commercial upstream provider to this university network. 368 The university, as well as ISP1, are operating their own ALTO server. 369 The ALTO clients, located on the peers will contact the ALTO server 370 located at the university. 372 +-----------+ 373 | ISP1 | 374 | ALTO | 375 | Server | 376 +----------=+ 377 ,-------= ,------. 378 ,-' =`-. ,-' `-. 379 / Upstream= \ / Upstream \ 380 ( ISP1 = ) ( ISP2 ) 381 \ = / \ / 382 `-. =,-' `-. ,-' 383 `---+---= `+------' 384 | = | 385 | ======================= 386 |,-------------. | = 387 ,-+ `-+ +-----------+ 388 ,' University `. |University | 389 ( Network ) | ALTO | 390 `. =======================| Server | 391 `-= +-' +-----------+ 392 =`+------------'| 393 = | | 394 +--------+-+ +-+--------+ 395 | Peer1 | | PeerN | 396 +----------+ +----------+ 398 Figure 7: Cascaded ALTO Server 400 In this setting all "destinations" useful for the peers within ISP2 401 are free-of-charge for the peers located in the university network 402 (i.e., they are preferred in the rating of the ALTO server). 403 However, all traffic that is not towards ISP2 will be handled by the 404 ISP1 upstream provider. Therefore, the ALTO server at the university 405 has also to include the guidance given by the ISP1 ALTO server in its 406 replies to the ALTO clients. This can be called cascaded ALTO 407 servers. 409 5. API between ALTO Client and Application 411 This sections gives some informational guidance on how the interface 412 between the actual application using the ALTO guidance and the ALTO 413 client can look like. 415 This is still TBD. 417 6. Security Considerations 419 The ALTO protocol itself, as well as, the ALTO client and server 420 raise new security issues beyond the one mentioned in 421 [I-D.ietf-alto-protocol] and issues related to message transport over 422 the Internet. For instance, Denial of Service (DoS) is of interest 423 for the ALTO server and also for the ALTO client. A server can get 424 overloaded if too many TCP requests hit the server, or if the query 425 load of the server surpasses the maximum computing capacity. An ALTO 426 client can get overloaded if the responses from the sever are, either 427 intentionally or due to an implementation mistake, too large to be 428 handled by that particular client. 430 6.1. Information Leakage from the ALTO Server 432 The ALTO server will be provisioned with information about the owning 433 ISP's network and very likely also with information about neighboring 434 ISPs. This information (e.g., network topology, business relations, 435 etc) is consider to be confidential to the ISP and must not be 436 revealed. 438 The ALTO server will naturally reveal parts of that information in 439 small doses to peers, as the guidance given will depend on the above 440 mentioned information. This is seen beneficial for both parties, 441 i.e., the ISP's and the peer's. However, there is the chance that 442 one or multiple peers are querying an ALTO server with the goal to 443 gather information about network topology or any other data 444 considered confidential or at least sensitive. It is unclear whether 445 this is a real technical security risk or whether this is more a 446 perceived security risk. 448 6.2. ALTO Server Access 450 Depending on the use case of ALTO, several access restrictions to an 451 ALTO server may or may not apply. For an ALTO server that is solely 452 accessible by peers from the ISP network (as shown in Figure 5), for 453 instance, the source IP address can be used to grant only access from 454 that ISP network to the server. This will "limit" the number of 455 peers able to attack the server to the user's of the ISP (however, 456 including botnet computers). 458 On the other hand, if the ALTO server has to be accessible by parties 459 not located in the ISP's network (see Figure Figure 4), e.g., by a 460 third-party tracker or by a CDN system outside the ISP's network, the 461 access restrictions have to be more loose. In the extreme case, 462 i.e., no access restrictions, each and every host in the Internet can 463 access the ALTO server. This might no the intention of the ISP, as 464 the server is not only subject to more possible attacks, but also on 465 the load imposed to the server, i.e., possibly more ALTO clients to 466 serve and thus more work load. 468 6.3. Faking ALTO Guidance 470 It has not yet been investigated how a faked or wrong ALTO guidance 471 by an ALTO server can impact the operation of the network and also 472 the peers. 474 Here is a list of examples how the ALTO guidance could be faked and 475 what possible consequences may arise: 477 Sorting An attacker could change to sorting order of the ALTO 478 guidance (given that the order is of importance, otherwise the 479 ranking mechanism is of interest), i.e., declaring peers located 480 outside the ISP as peers to be preferred. This will not pose a 481 big risk to the network or peers, as it would mimic the "regular" 482 peer operation without traffic localization, apart from the 483 communication/processing overhead for ALTO. However, it could 484 mean that ALTO is reaching the opposite goal of shuffling more 485 data across ISP boundaries, incurring more costs for the ISP. 487 Preference of a single peer A single IP address (thus a peer) could 488 be marked as to be preferred all over other peers. This peer can 489 be located within the local ISP or also in other parts of the 490 Internet (e.g., a web server). This could lead to the case that 491 quite a number of peers to trying to contact this IP address, 492 possibly causing a Denial of Service (DoS) attack. 494 This section is solely giving a first shot on security issues related 495 to ALTO deployments. 497 7. Conclusion 499 This is the first version of the deployment considerations and for 500 sure the considerations are yet incomplete and imprecise. 502 8. References 504 8.1. Normative References 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 8.2. Informative References 511 [ACM.ispp2p] 512 Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs 513 and P2P systems co-operate for improved performance?", In 514 ACM SIGCOMM Computer Communications Review 515 (CCR), 37:3, pp. 29-40. 517 [I-D.akonjang-alto-proxidor] 518 Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 519 Saucez, "The PROXIDOR Service", 520 draft-akonjang-alto-proxidor-00 (work in progress), 521 March 2009. 523 [I-D.ietf-alto-protocol] 524 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 525 draft-ietf-alto-protocol-02 (work in progress), 526 March 2010. 528 [I-D.kiesel-alto-3pdisc] 529 Kiesel, S. and M. Tomsu, "Third-party ALTO server 530 discovery", draft-kiesel-alto-3pdisc-01 (work in 531 progress), October 2009. 533 [I-D.kiesel-alto-h12] 534 Kiesel, S. and M. Stiemerling, "ALTO H12", 535 draft-kiesel-alto-h12-02 (work in progress), March 2010. 537 [I-D.kiesel-alto-reqs] 538 Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. 539 Yang, "Application-Layer Traffic Optimization (ALTO) 540 Requirements", draft-kiesel-alto-reqs-02 (work in 541 progress), March 2009. 543 [I-D.penno-alto-protocol] 544 Penno, R. and Y. Yang, "ALTO Protocol", 545 draft-penno-alto-protocol-04 (work in progress), 546 October 2009. 548 [I-D.shalunov-alto-infoexport] 549 Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 550 Export Service", draft-shalunov-alto-infoexport-00 (work 551 in progress), October 2008. 553 [I-D.stiemerling-alto-h1h2-protocol] 554 Stiemerling, M. and S. Kiesel, "ALTO H1/H2 Protocol", 555 draft-stiemerling-alto-h1h2-protocol-00 (work in 556 progress), March 2009. 558 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 559 Optimization (ALTO) Problem Statement", RFC 5693, 560 October 2009. 562 Appendix A. Acknowledgments 564 Martin Stiemerling is partially supported by the NAPA-WINE project 565 (Network-Aware P2P-TV Application over Wise Networks, 566 http://www.napa-wine.org), a research project supported by the 567 European Commission under its 7th Framework Program (contract no. 568 214412). The views and conclusions contained herein are those of the 569 authors and should not be interpreted as necessarily representing the 570 official policies or endorsements, either expressed or implied, of 571 the NAPA-WINE project or the European Commission. 573 Authors' Addresses 575 Martin Stiemerling 576 NEC Laboratories Europe/University of Goettingen 577 Kurfuerstenanlage 36 578 Heidelberg 69115 579 Germany 581 Phone: +49 6221 4342 113 582 Fax: +49 6221 4342 155 583 Email: martin.stiemerling@neclab.eu 584 URI: http://www.nw.neclab.eu/ 586 Sebastian Kiesel 587 University of Stuttgart, Computing Center 588 Allmandring 30 589 Stuttgart 70550 590 Germany 592 Email: ietf-alto@skiesel.de