idnits 2.17.1 draft-kiesel-alto-h12-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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 26 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2010) is 5163 days in the past. Is this intentional? 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 475, but no explicit reference was found in the text 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 S. Kiesel 3 Internet-Draft University of Stuttgart 4 Intended status: Standards Track M. Stiemerling 5 Expires: September 9, 2010 NEC Europe Ltd. 6 March 8, 2010 8 ALTO H12 9 draft-kiesel-alto-h12-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 applications, which have to select one or several hosts 19 from a set of candidates, that are able to provide a desired 20 resource. This memo proposes the Simple ALTO (H12) protocol. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 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 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 9, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Protocol Framework . . . . . . . . . . . . . . . . . . . . . . 4 64 3. H12 Operational Model . . . . . . . . . . . . . . . . . . . . 6 65 4. Proposed Protocol Semantics . . . . . . . . . . . . . . . . . 8 66 4.1. Locating the H12 Server Capabilities . . . . . . . . . . . 8 67 4.2. Learning the H12 Server Capabilities . . . . . . . . . . . 8 68 4.3. Redirection . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.4. Querying the ALTO Server . . . . . . . . . . . . . . . . . 9 70 4.5. ALTO Server Response . . . . . . . . . . . . . . . . . . . 12 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 76 Appendix 1. Full XML-Response . . . . . . . . . . . . . . . . . . 17 77 Appendix 2. Acknowledgments . . . . . . . . . . . . . . . . . . . 21 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 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. This memo proposes the Simple ALTO (H12) protocol. The 90 H12 protocol is a client/server protocol between ALTO clients and 91 ALTO servers, where ALTO clients can be either peer-to-peer 92 applications residing on end hosts or peer-to-peer tracker servers. 94 The basic ideas of ALTO are described in the problem space of ALTO is 95 described in [RFC5693] and the set of requirements is discussed in 96 [I-D.kiesel-alto-reqs]. 98 Comments and discussions about this protocol proposal should be 99 directed to the ALTO working group: alto@ietf.org. 101 2. Protocol Framework 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 +----------+ 107 | ALTO | 108 | Server | 109 +----------+ 110 ^ 111 _.-----|------. 112 ,-'' | `--. 113 ,' | `. 114 ( Network | ) 115 `. | ,' 116 `--. | _.-' 117 `------|-----'' 118 v 119 +----------+ +----------+ +----------+ 120 | ALTO | | ALTO |...| ALTO | 121 | Client | | Client | | Client | 122 +----------+ +----------+ +----------+ 124 Figure 1: Network Overview of ALTO Protocol 126 An ALTO server stores information about preferences (e.g., a list of 127 preferred autonomous systems, IP ranges, etc) and ALTO clients can 128 retrieve these preferences. However, there are basically two 129 different approaches on where the preferences are actually processed: 131 1. The ALTO server has a list of preferences and clients can 132 retrieve this list via the ALTO protocol. This preference list 133 can be partially updated by the server. The actual processing of 134 the data is done on the client and thus there is no data of the 135 client's operation revealed to the ALTO server . This approach 136 has been proposed by [I-D.shalunov-alto-infoexport]. 138 2. The ALTO server has a list of preferences or preferences 139 calculated during runtime and the ALTO client is sending 140 information of its operation (e.g., a list of IP addresses) to 141 the server. The server is using this operational information to 142 determine its preferences and returns these preferences (e.g., a 143 sorted list of the IP addresses) back to the ALTO client. This 144 approach has been initially described in [ACM.ispp2p], but never 145 been described on the protocol level. 147 Approach 1 (we call it H1) has the advantage (seen from the client) 148 that all operational information stays within the client and is not 149 revealed to the provider of the server. On the other hand, does 150 approach 1 require that the provider of the ALTO server, i.e., the 151 network operator, reveals information about its network structure 152 (e.g., AS numbers, IP ranges, topology information in general) to the 153 ALTO client. 155 Approach 2 (we call it H2) has the advantage (seen from the operator) 156 that all operational information stays with the ALTO server and is 157 not revealed to the ALTO client. On the other hand, does approach 2 158 require that the clients send their operational information to the 159 server. 161 Both approaches have their pros and cons and are extensively 162 discussed on the ALTO mailing list. But there is basically a 163 dilemma: Approach 1 is seen as the only working solution by peer-to- 164 peer software vendors and approach 2 is seen as the only working by 165 the network operators. But neither the software vendors nor the 166 operators seem to willing to change their position. However, there 167 is the need to get both sides on board, to come to a solution. 169 Therefore, this does memo proposes to integrate both approaches in 170 one protocol and offer a way for clients and servers to learn each 171 preferred way of operating. 173 3. H12 Operational Model 175 The P4P protocol proposal [I-D.penno-alto-protocol] assumes that the 176 ALTO server maintains two different databases that store the server- 177 side information necessary to guide ALTO clients. There is the 178 network map that provides a mapping between network prefixes and a 179 macro called partition ID (PID) and the cost map that relates PIDs to 180 costs. 182 H12 assumes also that the H12 server internally maintains two maps, 183 one for the network partitioning and the other for the associated 184 costs, but does not need that the information stored in these maps is 185 also conveyed to the H12 client in one piece. However, this memo is 186 not specifying how the server is implemented, it is only specifying 187 the ALTO protocol. 189 The client puts one or several host location attributes, about which 190 it wants to receive a rating, in the query message. 192 The server replies with a list of network location attributes, in the 193 same format as in the query, and the respective ratings for the 194 requested attributes. However, the number of lines in this list may 195 be shorter or longer than in the query, and the prefix lengths may be 196 different: 198 o The server may decide not to give any rating for a specific 199 location attribute. In this case, a default value applies. 201 o Instead of rating several location attributes with long prefix 202 lengths (in particular: individual IP addresses) individually, the 203 server may decide to give only one rating for a broader address 204 range (i.e., prefix length is shorter). 206 o Instead of giving one rating for a large address range, the server 207 may decide to give several ratings for smaller ranges (i.e., i.e., 208 each returned entry has a prefix length that is longer that 209 requested). 211 The actual rating is given for each rating criterion as a signed 212 integer value. A value of zero (0) means "default value". This 213 value is to be used if the server has no information regarding this 214 (network location attribute, rating criteria) tuple, or if it does 215 not want to disclose it. Positive values mean that this location is 216 "better" than default and therefore should be preferred for peer 217 selection, while negative values indicate the location to be "worse" 218 than default and therefore that it should be avoided. The meaning of 219 "better" and "worse", as well as the scale has to be defined 220 individually for each rating criterion. 222 This approach gives both sides, i.e., server and clients, to still 223 exchange their desired information and level of precision, but also 224 gives the chance to hide information if necessary and desired. 226 4. Proposed Protocol Semantics 228 H12 uses HTTP/1.1 and TCP as transport protocol between H12 clients 229 and H12 servers. The encoding of the message body is done with XML. 230 The usage of HTTP is similar to [I-D.penno-alto-protocol] also with 231 the intention to reuse existing HTTP software and deployments. 233 H12 is aiming at keeping the level of involvement of the application 234 that is using ALTO as low as possible. I.e., requiring an 235 application, such as p2p file sharing, to use ALTO is already a 236 considerable step. The implementers of the application must be able 237 to use ALTO with a very low effort. It is assumed that the 238 complexity of ALTO, in terms of implementation and operational 239 effort, is mainly handled at the server. 241 Unlike the H1H2 protocol[I-D.stiemerling-alto-h1h2-protocol] the H12 242 protocol does not have several modes of operation, which have to be 243 negotiated at the startup. Instead it allows the client and the 244 server some flexibility in the requests and the responses while using 245 only on mode of operation. 247 4.1. Locating the H12 Server Capabilities 249 H12 clients initially need to locate the right H12 server that is in 250 charge of serving them. This step and the technical solution to 251 locate such ALTO server is currently discussed within the ALTO 252 working group. This memo does not yet define such H12 server 253 discovery. 255 4.2. Learning the H12 Server Capabilities 257 This section describes how an ALTO client can learn about the 258 capabilities of the ALTO server. 260 H12 clients initially need to locate the right H12 server that is in 261 charge of serving them. This step and the technical solution to 262 locate such ALTO server is currently discussed within the ALTO 263 working group. This memo does not yet define such H12 server 264 discovery. 266 The first step for a H12 client, before it can start querying for 267 ALTO guidance, is to request the H12 server capabilities. The server 268 capabilities are, e.g., administrative information (operator of the 269 server, contact addresses, etc), the supported host location 270 attributes (IP addresses or IP prefixes), the supported rating 271 criteria, and the URIs to query for ALTO guidance. The H12 protocol 272 uses only a single static URI path for retrieving the capability 273 information. All other query URIs are announced by the server during 274 the capability retrieval. 276 4.3. Redirection 278 There are basically two cases where a H12 server has to redirect 279 request to other locations: 281 a. the queried H12 server is overload and can tell about other H12 282 server; 284 b. the queried H12 server is overload and cannot tell about other 285 H12 server; 287 c. the queried H12 server is solely used as entry point and 288 redirects the actual H12 server; 290 d. the querying host in not allowed to use this ALTO server (e.g., 291 host in ISP1 is querying ALTO server in ISP2) (which is a sub 292 case of (a)). 294 4.4. Querying the ALTO Server 296 An ALTO client can query on its own or on behalf of other peers 297 (e.g., a tracker). This is indicated in the resource consumer host 298 location attribute rc_hla in the ALTO query. The query body itself 299 contains the list of IP addresses or IP prefixes the ALTO client is 300 asking guidance for. This shows a example list Figure 2 of IP 301 addresses queried for 302 195.37.70.39/32 # mito.netlab.nec.de 303 193.141.139.237/32 # www.nec.de 304 58.89.210.171/32 # www.nec.co.jp 305 122.224.8.143/32 # www.huawei.cn 306 202.103.147.132/32 # www.zte.com.cn 307 135.245.1.29/32 # www.alcatel.de 308 139.15.248.12/32 # www.bosch.de 309 141.113.97.34/32 # www.daimler.de 310 129.206.0.0/16 # university of heidelberg 311 129.13.0.0/16 # university of karlsruhe 312 129.69.0.0/16 # university of stuttgart 313 130.83.0.0/16 # university of darmstadt 314 130.149.0.0/16 # university of berlin (TU) 315 171.67.0.0/16 # stanford university 316 129.78.64.24 # university of sidney 317 12.110.110.204/32 # www.nsa.gov 318 85.180.57.61/32 # some random residential DSL user (ALICE) 319 84.56.180.139/32 # some random residential DSL user (Arcor) 320 62.227.16.206/32 # some random residential DSL user (DTAG) 321 80.238.206.25/32 # some random residential DSL user in .ch 323 Figure 2: Example Candidate IPs for Query 325 The query is constructed as show in the below exampleFigure 3. The 326 client requests guidance for the IP prefixes out of Figure 2 for its 327 own IP address (prefix='195.37.70.39/32') stated in the rc_hla. 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 359 Figure 3: XML encoded Query 361 This ipprefix tag carries a full IP address or an IP address prefix, 362 leaving the client the choice how much of an IP address it wants to 363 reveal to the server. That is, the client can request information 364 for one or several specific IP addresses (prefix length equal 32 or 365 128), for address ranges, or for "the whole Internet" (prefix length 366 equal 0). However, the "whole Internet" is not really referring to 367 the whole Internet as such, as no single entity can have such a big 368 knowledge, but to whatever broader scope the server can give guidance 369 about. This scope can include, for instance, its own complete 370 network. 372 Furthermore, the client specifies one or several rating criteria, 373 such as operator preference, lower bound for delay, etc. Here is a 374 work-in-progress list of such rating criteria, consisting of two 375 levels of rating criteria offered to the client are: 377 o Primary rating criterion 379 o Further rating criteria 381 The offered rating criteria are: 383 o operator's relative preference 385 o Topological distance (Number of AS hops) 387 o minimum boundary for upload bandwidth 389 4.5. ALTO Server Response 391 This section discussions at this of point of time only a positive 392 reply. All other cases are TBD in this write-up. The listed 393 response is shortened, see Section 1 for the full answer. The 394 examplatory answer is listed for the IP address 193.141.139.237/32 395 and 202.103.147.132/32, and for the IP prefix 129.13.0.0/16. 397 The rating response given in the candidate host location attributes 398 (cnd_hla) is different for the single requests, depending on what 399 information can be delivered by the server. For 193.141.139.237/32, 400 the server replies with two prefixes belonging to the same ISP. For 401 202.103.147.132/32, the server replies with even more details about 402 other prefixes belonging to the same operator. The ensures that the 403 client automatically learns even more prefixes the operator gives the 404 same guidance for. A simple response is shown for the query about 405 129.13.0.0/16, where the response contains only the same prefixes as 406 in the request. 408 409 411 412 413 414 415 416 418 419 420 421 422 423 424 425 426 427 428 429 431 432 433 434 435 437 438 439 440 441 442 443 444 446 Figure 4: XML encoded Query 448 The response contains also a resource consumer host location 449 attribute (rc_hla). This rc_hla echos partially the information from 450 the request, but gives actually guidance to the ALTO client in what 451 scope this information can be distributed amongst other peers. In 452 this response, the server allows the redistribution of the received 453 guidance to peers with the IP prefix 195.37.0.0/16. 455 5. Security Considerations 457 This initial version of this memo does not yet a full security 458 considerations, but they will be added in future revision. 460 minimum boundary for upload bandwidth (AKA provisioned upload 461 bandwidth): criminal suspects can easily re-use the geographical 462 coordinates of an IP address (taken from whois) and google maps to 463 correlate IP addresses and wealth of subscribers of that IP address. 465 6. Conclusion 467 This memo presents a very basic protocol, for sure work in progress, 468 and is requesting feedback from the ALTO working group. Sebastian 469 Kiesel is implementing the herein proposed protocol. 471 7. References 473 7.1. Normative References 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, March 1997. 478 7.2. Informative References 480 [ACM.ispp2p] 481 Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs 482 and P2P systems co-operate for improved performance?", In 483 ACM SIGCOMM Computer Communications Review 484 (CCR), 37:3, pp. 29-40. 486 [I-D.kiesel-alto-reqs] 487 Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. 488 Yang, "Application-Layer Traffic Optimization (ALTO) 489 Requirements", draft-kiesel-alto-reqs-02 (work in 490 progress), March 2009. 492 [I-D.penno-alto-protocol] 493 Penno, R. and Y. Yang, "ALTO Protocol", 494 draft-penno-alto-protocol-04 (work in progress), 495 October 2009. 497 [I-D.shalunov-alto-infoexport] 498 Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 499 Export Service", draft-shalunov-alto-infoexport-00 (work 500 in progress), October 2008. 502 [I-D.stiemerling-alto-h1h2-protocol] 503 Stiemerling, M. and S. Kiesel, "ALTO H1/H2 Protocol", 504 draft-stiemerling-alto-h1h2-protocol-00 (work in 505 progress), March 2009. 507 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 508 Optimization (ALTO) Problem Statement", RFC 5693, 509 October 2009. 511 1. Full XML-Response 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 655 656 657 658 659 660 661 662 663 665 Figure 5: XML encoded Query 667 2. Acknowledgments 669 Martin Stiemerling is partially supported by the NAPA-WINE project 670 (Network-Aware P2P-TV Application over Wise Networks, 671 http://www.napa-wine.org), a research project supported by the 672 European Commission under its 7th Framework Program (contract no. 673 214412). The views and conclusions contained herein are those of the 674 authors and should not be interpreted as necessarily representing the 675 official policies or endorsements, either expressed or implied, of 676 the NAPA-WINE project or the European Commission. 678 Authors' Addresses 680 Sebastian Kiesel 681 University of Stuttgart, Computing Center 682 Allmandring 30 683 Stuttgart 70550 684 Germany 686 Email: ietf-alto@skiesel.de 688 Martin Stiemerling 689 NEC Laboratories Europe/University of Goettingen 690 Kurfuerstenanlage 36 691 Heidelberg 69115 692 Germany 694 Phone: +49 6221 4342 113 695 Fax: +49 6221 4342 155 696 Email: stiemerling@cs.uni-goettingen.de