idnits 2.17.1 draft-dulinski-alto-inter-problem-statement-01.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 (July 11, 2011) is 4673 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-09 == Outdated reference: A later version (-03) exists of draft-jenkins-alto-cdn-use-cases-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO Working Group Z. Dulinski 3 Internet-Draft Jagiellonian University 4 Intended status: Informational P. Wydrych 5 Expires: January 12, 2012 R. Stankiewicz 6 AGH University of Science and 7 Technology 8 July 11, 2011 10 Inter-ALTO Communication Problem Statement 11 draft-dulinski-alto-inter-problem-statement-01 13 Abstract 15 This draft considers an approach to the optimization of the traffic 16 generated by the overlay (peer-to-peer) applications, where some 17 information on inter-AS (Autonomous System) paths is obtained with 18 the usage of dedicated communication scheme known as inter-ALTO 19 communication. 21 The large amount of network traffic generated by overlay applications 22 requires effective management. This traffic traverses inter-AS links 23 and thus generates substantial costs for the operators and poses 24 problems with overload on the external and internal links. The 25 traffic is not time-stable as the peers connect and disconnect very 26 often. Additionally, when the overlay traffic is observed on 27 inter-AS links, it can be seen that sources and destinations change 28 in a very short period of time. The ALTO (Application-Layer Traffic 29 Optimization) service provides the information that enables more 30 efficient management of the overlay traffic. Such applications can 31 use the information to perform better-than-random peer selection. 32 The ALTO servers are responsible for a pre-selection procedure; the 33 final selection is done by overlay clients and then the ALTO protocol 34 conveys network information to applications. To be credible, this 35 information should be as close to real network situation as possible. 36 However, some types of data are not hold by an operator, but they 37 should be gained on the basis of the additional information exchange 38 with other AS operators. This document presents rationale for the 39 need of introduction of the inter-ALTO communication. 41 Status of this Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on January 12, 2012. 58 Copyright Notice 60 Copyright (c) 2011 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 3. The Problem and Motivation . . . . . . . . . . . . . . . . . . 6 80 3.1. Route Asymmetry . . . . . . . . . . . . . . . . . . . . . 8 81 3.2. Many ASes within One ISP . . . . . . . . . . . . . . . . . 8 82 3.3. Different Types of Business Relations . . . . . . . . . . 9 83 3.4. Congestion Avoidance . . . . . . . . . . . . . . . . . . . 9 84 3.5. Proximity Awareness . . . . . . . . . . . . . . . . . . . 9 85 3.6. Remote ISP's Preference . . . . . . . . . . . . . . . . . 10 86 3.7. Coordination of ISPs' Policies . . . . . . . . . . . . . . 10 87 3.8. Sensitivity of Topology Information . . . . . . . . . . . 11 88 3.9. Outdated Information . . . . . . . . . . . . . . . . . . . 11 89 3.10. Mobile Networks . . . . . . . . . . . . . . . . . . . . . 11 90 3.11. Route Aggregation . . . . . . . . . . . . . . . . . . . . 12 92 4. Usage of the Mechanisms Offered by the ALTO Protocol . . . . . 12 94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 98 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 101 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 102 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 106 1. Introduction 108 This document describes the rationale for a communication to be used 109 between ALTO servers located in different autonomous systems (AS). 110 Such an inter-ALTO communication extends the ALTO service 111 [RFC5693]capabilities and provides additional information on remote 112 peers, i.e., peers located in other ASes. To make the consideration 113 more clear we distinguish local AS and remote ASes. Local AS is the 114 one from which perspective we describe the communication. Local 115 peers are located in the local AS and are served by a local ALTO 116 server. On the contrary, all other peers are located in remote ASes. 117 Those peers are referred to as remote and are served by remote ALTO 118 server. This basic terminology adheres to majority of considerations 119 in this document. 121 The motivation for the ALTO service as discussed in the ALTO problem 122 statement [RFC5693] focuses on the overlay traffic optimization based 123 on information gathered from the Internet Service Provider (ISP) 124 domain, i.e., an Autonomous System (AS). Due to the suggested 125 approach, information on the AS internal topology and some routing 126 information obtained from the global Internet (the BGP routing 127 tables) may be used for the peer selection procedures. The data 128 transfer cost can be also incorporated. However, there are some 129 parameters which can be used for the better peer selection mechanism, 130 but they are not available in the local AS and must be obtained from 131 outside, i.e., from a remote AS. For example, the BGP routing 132 information available in the AS identifies only the upstream traffic. 133 The information about the downstream traffic is not present or is 134 incomplete and the full BGP information for this traffic could be 135 obtained from the remote AS containing the subnetwork where the peer 136 sending downstream traffic is attached. In order to obtain such 137 data, we propose the inter-ALTO communication. 139 It is assumed that the ALTO servers are deployed in the local and 140 remote ASes. The ALTO server located in the client AS can request 141 desired information from the ALTO server which is located in the 142 remote AS. Each server is managed by a respective ISP. Each ISP 143 decides what type of information can be exposed to the requesting 144 party. The ALTO server responds with the type of information that 145 was previously agreed to exchange. Each local ALTO server has to 146 discover the address of the remote ALTO server before starting the 147 communication. The discovery procedure may use the IP addresses of 148 remote peers for the establishment of IP addresses of remote ALTO 149 servers. The detailed analysis of this functionality is out of scope 150 of this document. 152 The information delivered by remote ALTO servers may be used by a 153 local ALTO server to perform advanced rating/ranking procedure of 154 peers. The general idea is as follows. 156 1. A peer receives a list of other peers from a tracker, i.e., a 157 list of potential candidates to communicate with. 159 2. A peer uses the ALTO protocol [I-D.ietf-alto-protocol] to send 160 the list of peers to its local ALTO server. 162 3. Local ALTO server obtains additional information on remote peers 163 by communicating respective remote ALTO servers. If sufficient 164 information is available locally and the inter-ALTO communication 165 is not needed, this step is omitted. 167 4. Using ISP specific policies and values of parameters associated 168 with remote peers the local ALTO server performs rating/ranking 169 procedure. 171 5. Sorted/rated list of peers is sent back to the peer with usage of 172 the ALTO protocol. 174 The requirements, syntax and detailed operation of the inter-ALTO 175 communication as well as the rating/ranking procedure is out of scope 176 of this document. 178 2. Definitions 180 In the scope of this document we use all the definitions specified in 181 the Section 2 of ALTO problem statement [RFC5693]. Moreover, the 182 following terms have the special meaning. 184 Local Peer: A peer which belongs to the same Autonomous System to 185 which the ALTO client belongs. 187 Remote Peer: A peer which belongs to another Autonomous System than 188 the one to which the ALTO client belongs. 190 Local AS: The Autonomous System to which the ALTO client belongs. 192 Remote AS: An Autonomous System to which a remote peer belongs. 194 Local ALTO Server: The ALTO server serving the ALTO client and the 195 local peers. 197 Remote ALTO Server: An ALTO server serving remote peers. 199 3. The Problem and Motivation 201 ALTO server optimization capabilities are limited by the fact that 202 they use information available locally only. It can be shown that 203 more information on remote peers, a routing path, or remote ISP 204 preferences would be useful. The data from remote ASes obtained by 205 the external interface as shown in Figure 1 of the ALTO protocol 206 draft [I-D.ietf-alto-protocol] may have a substantial significance 207 for the management of overlay traffic (e.g. with respect to peer 208 rating, ranking, or the choice of the best peers). The suggested 209 approach to deliver these types of information is defined in the 210 inter-ALTO communication discussed in this document. 212 The ALTO service may also be used by the client-server applications, 213 supporting the best choice of the mirror servers. If some mirror 214 servers are in other ASes than the client's AS, some information 215 about the network conditions in the remote ASes may be delivered only 216 by the ALTO servers localized in these ASes. Both clients and mirror 217 servers may communicate with their local ALTO servers for delivering 218 traffic optimization parameters. As an ALTO client communicates only 219 with its local ALTO server, the information from remote ASes is 220 accessible only via inter-ALTO communication. 222 The ALTO-based traffic optimization may be also used in the context 223 of the Content Delivery Networks (CDNs) 224 [I-D.jenkins-alto-cdn-use-cases]. The draft by Niven-Jenkins et al. 225 shows how CDNs may benefit from the information provided by the ALTO 226 protocol. Local information, however, may be not sufficient to 227 optimize the request routing process. The information gathered from 228 ALTO servers in other domains may be needed. 230 The basic ALTO architecture presented in Figure 1 of the ALTO 231 protocol draft [I-D.ietf-alto-protocol] defines the external 232 interface used to communicate with other information sources like 233 remote ALTO servers. The ALTO Protocol draft, however, does not 234 define what information should be exchanged between ALTO servers to 235 optimize the traffic. The inter-ALTO communication proposed by the 236 current document implements the external interface as defined by the 237 ALTO protocol draft. 239 +------------------------+ +------------------------+ 240 | Local AS | | Remote AS | 241 | +-------------+ | | +-------------+ | 242 | | Local |+ | | | Remote |+ | 243 | | Information || | | | Information || | 244 | | Sources || | | | Sources || | 245 | +-------------+| | | +-------------+| | 246 | + ------------+ | | + ------------+ | 247 | \ | | / | 248 | \ | | / | 249 | +--------+ | Inter-ALTO | +--------+ | 250 | | Local | | Communication | | Remote | | 251 | | ALTO |-----------------------| ALTO | | 252 | | Server | | | | Server | | 253 | +--------+ | | +--------+ | 254 | / | | \ | 255 | / | | \ | 256 | +---------+ | | +---------+ | 257 | | Local |+ | | | Remote |+ | 258 | | ALTO || | | | ALTO || | 259 | | Clients || | | | Clients || | 260 | +---------+| | | +---------+| | 261 | +---------+ | | +---------+ | 262 | | | | 263 +------------------------+ +------------------------+ 265 Figure 1: Inter-ALTO communication architecture. 267 The architecture of the Inter-ALTO communication is shown in 268 Figure 1. Both ALTO servers gather the information from their 269 information sources like routing protocols, provisioning policies, or 270 dynamic network information sources. The local ALTO server needs to 271 communicate with a remote ALTO server to obtain information which is 272 available only at the entities in the remote AS. 274 In particular, the following key aspects motivate the proposal of the 275 inter-ALTO communication. 277 o Route asymmetry. 279 o Different types of business relations. 281 o Congestion avoidance. 283 o Proximity awareness (distance to the remote AS), e.g.: 285 * number of inter-AS hops; 286 * delay (RTT). 288 o Remote ISP's preference. 290 o Coordination of ISPs' policies. 292 o Outdated information. 294 3.1. Route Asymmetry 296 The communication between two ASes does not need to follow the same 297 path in the upstream and downstream direction. It was shown that 298 about 29% of paths between AS pairs in the Internet are fully 299 symmetric, i.e., upstream and downstream traffic follows exactly the 300 same path [ICC.optimal]. In 51% of cases the number of inter-AS hops 301 is different for the upstream and downstream direction. 302 Additionally, in 50.5% of all path pairs a neighbor AS for upstream 303 and downstream paths are different. 305 The ALTO server can obtain routing information locally (e.g. from BGP 306 routers) and can determine the upstream path. Information about the 307 downstream path is usually not easily available. Some additional 308 routing information can be obtained from Looking Glass Servers, but 309 not all ASes provide them. The inter-ALTO communication provides the 310 ability to exchange the relevant information between ALTO servers. 311 Especially, the downstream path can be reliably determined using the 312 information provided by remote ALTO server. In the light of route 313 asymmetry in the Internet such information appears to be necessary 314 for a better optimization of a peer rating/ranking algorithm, as 315 assumption that the inter-AS routes follow symmetrical paths can give 316 not only sub-optimal, but misleading and, in effect, harmful results. 318 3.2. Many ASes within One ISP 320 An ISP may possess a complex topology network composed of many 321 autonomous systems. Current ALTO specification allows for deployment 322 of independent ALTO servers in each AS. In such a case the overlay 323 traffic management performed by the ALTO server is restricted to a 324 single AS since cost maps have a local meaning. An ISP operating a 325 multi-AS network may be interested in managing the traffic in the 326 whole administrative domain in a consistent and coordinated manner. 327 The information possessed by a single ALTO server is insufficient. 328 To obtain a complete knowledge on the multi-AS network a 329 communication between ALTO servers is needed. As a result, local 330 cost maps originating from different autonomous systems may be 331 coordinated. A uniform cost map reflecting the whole network 332 structure may be created and distributed between ALTO servers. 334 3.3. Different Types of Business Relations 336 Two basic business relations between ISPs may be distinguished. 338 When two ISPs agree to exchange the traffic without any charge, such 339 a relation is called peering. The inter-domain link between the 340 respective ASes is also called a peering link. Usually, there is no 341 charge if the difference between traffic volumes passing such a link 342 in different directions does not exceed a previously agreed limit. 344 The other case occurs when one ISP serves as a network provider to 345 another ISP (e.g. relation between tier 2 and tier 3 ISPs). In such 346 a case one ISP (acting as a customer) has to pay the other ISP 347 (acting as provider) for the traffic sent over the inter-AS link 348 connecting them. The real monetary cost of the traffic volume 349 exchanged on such a link depends on agreements between ISPs. In 350 general, some links may be considered as cheaper or more expensive. 352 AS may be connected to many other ASes with various agreements. The 353 cost of the inter-AS traffic transfer may differ depending on which 354 neighbor AS the path passes. For this reason an ISP may prefer that 355 its own customers exchange data with remote peers located in such 356 ASes that the path directed to them passes cheaper links. The ALTO 357 server may sort peers taking into account these criteria. To receive 358 almost complete information on routing paths to and from different 359 remote domains the information provided by remote ALTO server using 360 inter-AS communication may be helpful. 362 3.4. Congestion Avoidance 364 A peer rating/ranking procedure may also take into account the 365 congestions on inter-AS links. An ISP is able to monitor queues on 366 its inter-domain links and assign metrics indicating the buffer 367 occupancy or bandwidth utilization. These metrics can express 368 percentage use of buffers or bandwidth on a particular inter-AS link. 369 If one inter-domain link is congested it is desirable to promote 370 peers reachable through lightly loaded links. Again, information 371 provided by the remote ALTO server would support such optimization. 372 The aim of the inter-ALTO communication is not to replace the 373 existing congestion avoidance mechanisms. The idea is to support the 374 present mechanism by the exchange of parameters describing the load 375 on the inter-AS links. 377 3.5. Proximity Awareness 379 For a set of reasons (e.g. the performance of an application) the 380 ALTO server may suggest its customers to connect to remote peers 381 located in its proximity. The simplest measure of proximity is the 382 number of inter-AS hops. As indicated above, due to the route 383 asymmetry, the number of hops may significantly differ between the 384 upstream and downstream paths. Such information for the downstream 385 path may be provided by the remote ALTO server. A more advanced 386 metric of proximity can be found in the delay that can be 387 approximated by exchanging messages between ALTO servers. The ALTO 388 servers can be equipped with an application-layer ping functionality 389 which only operates between ALTO servers. By exchanging special 390 packets prepared by the ALTO servers, these servers can estimate 391 delay and packet loss. 393 3.6. Remote ISP's Preference 395 If two ISPs agree on a cooperation, the remote ALTO server may 396 provide its preference parameters (remote preference parameters) 397 indicating which peers are better from the point of view of the 398 remote ISP. For instance, the AS in which the remote ALTO server is 399 located may possess two subnetworks connected to the operator's core 400 network by distinct links. It may happen that a connection to one of 401 the subnetworks is cheaper than the other. The remote operator may 402 prefer connections through cheaper link, so peers located in the 403 subnetwork transferring data via this cheaper link are preferred. 405 The remote preference parameter may be also used when a remote ISP 406 wants to suggest peers which are connected to the Internet through 407 access links of higher capacity. This way, the remote ALTO server, 408 without exposing the exact values of access link bandwidth, may 409 indicate peers with higher throughput. The remote preference 410 parameters have only local meaning, i.e., their values are comparable 411 for peers located in the same AS only. 413 If a remote ISP does not want to reveal numerical values of network 414 parameters related to its peers (such information might be considered 415 as confidential) the remote ALTO server may perform a rating/ranking 416 procedure and assign priority parameter to its peers. The rating/ 417 ranking criteria may remain hidden for the requesting local ALTO 418 server. 420 3.7. Coordination of ISPs' Policies 422 Operators may have an incentive to coordinate their efforts in order 423 to decrease transfer costs on inter-AS links or improve quality 424 experienced by peers, i.e., coordinate their peer rating/ranking 425 strategies. This way, operators may avoid contradictory strategies 426 resulting in inefficiency of rating/ranking algorithms. Operators 427 may agree to promote each other's peers. 429 For example, it may happen that operator A wanting to decrease 430 traffic on one of its links discourages its own peers from 431 communicating with peers located in operator B's domain. On the 432 other hand, operator B would consider peers located in a domain of 433 operator A as very attractive for its own peers. As a result, 434 rating/ranking procedures performed by respective ALTO servers give 435 contradictory results what may decrease the effectiveness of these 436 procedures. To avoid such a situation, the inter-ALTO communication 437 is needed. 439 Another example of a usefulness of coordination of policies is 440 clustering of ASes. Recent studies [IJNM.unfairness] have shown that 441 locality promotion might be ineffective or even harmful if used in AS 442 with small number of peers. A proposed solution is to create a 443 cluster of two or more ASes. Then ALTO servers serving different 444 ASes in the cluster treat all peers located in the cluster as if they 445 were in a single AS. In other words, from a point of view of 446 locality promotion algorithm all peers located in the cluster are 447 local, regardless of their home AS. 449 3.8. Sensitivity of Topology Information 451 The minimum information that the remote AS provides to the local ALTO 452 server via the inter-ALTO communication may be the number of inter-AS 453 hops and the number of the local AS's neighbor in the downstream path 454 (the full downstream AS_PATH may be not exchanged). Such information 455 does not reveal any sensitive information neither on the ISP internal 456 topology details nor remote AS connections with other ASes, but does 457 provide basic and very useful information for the local ALTO server. 459 3.9. Outdated Information 461 It is expected that some information (parameters) from routing 462 protocols that will be used in the rating/ranking procedures may 463 outdate. Also information related to the network performance is 464 constantly changing. Therefore, the information obtained from the 465 remote AS requires updates. This updates may be generated on request 466 (pull mechanism), on event base schema or periodically (push 467 mechanism). The inter-ALTO communication should be equipped with 468 mechanisms for updates. The need for the present information 469 describing network conditions and some routing parameters are 470 arguments for introducing specific protocol for the communication 471 between ALTO servers. 473 3.10. Mobile Networks 475 The inter-ALTO communication may be very useful for mobile network 476 operators and content providers serving mobile clients. An ALTO 477 server may recognize mobile clients and properly assign them to PIDs. 479 Some information about the mobile network resources gathered from 480 mobile network nodes located in different networks should be 481 exchanged between operators for better then random peer selection. 482 ALTO servers should posses information which allows to make proper 483 peer selection, taking into account, e.g., the mobile network load 484 (including the load in the radio access network and in the circuit- 485 and packet-switched domains). 487 After collecting the load information, the ALTO server may assign 488 priorities. These priorities may exemplify the load in some parts of 489 the radio access network. Via the inter-ALTO communication, the 490 priorities may be passed to the other operator's networks where other 491 clients are located. Relying on this information, the ALTO server 492 may optimize the connections between clients. 494 3.11. Route Aggregation 496 The BGP protocol allows the aggregation of specific routes into one 497 route. In such a case the aggregate route is advertised. The full 498 path is either lost completely or the AS set information is 499 available. In the latter case only the set of ASes behind the 500 aggregating router is known but the detailed information about the 501 routing path, including AS sequence and AS-hop count, is lost. From 502 the overlay traffic optimization point of view the knowledge on ASes 503 located behind aggregating router and the number as well as sequence 504 of inter-AS hops may be useful, e.g., because of route asymmetry 505 problem described earlier (Section 3.1). The solution for this 506 problem is information exchange between ALTO servers located in ASes 507 ahead and behind the router aggregating routes. 509 4. Usage of the Mechanisms Offered by the ALTO Protocol 511 The basic ALTO protocol architecture allows an ALTO server to 512 communicate with a third party through the external interface. The 513 inter-ALTO communication may use some functionalities offered by the 514 ALTO protocol [I-D.ietf-alto-protocol]. 516 Server Information Service: This service defined by the ALTO 517 protocol may be extended in order to provide information about 518 server's ability to cooperate with other ALTO servers. Thanks 519 to this service, the other ALTO servers may acquire the 520 information about available parameters and their definitions. 521 These parameters may be used by cooperating ALTO servers for 522 the peer rating/ranking procedures. The access for this 523 service may be restricted. Some information may be accessible 524 only by the privileged ALTO servers after the successful 525 authentication. 527 ALTO Information Services: These services has been defined to 528 provide the query information services for ALTO clients. All 529 the information delivered by these services has local meaning. 530 This information is related to the locally defined parameters 531 describing a particular ISP's network. Some part of this 532 information managed by a remote ALTO server may be useful for 533 the requesting local ALTO server. The requesting ALTO server 534 obtains this information via inter-ALTO communication. After 535 receiving the response, the local ALTO server has to perform 536 some calculations, scaling, merging, or adaptation of the 537 received parameters. In this way the local ALTO server may 538 conform to both its internal network topology and measurements, 539 and the external ones. However, it should be stressed that the 540 ALTO Information Services is designed for communication between 541 ALTO clients and servers, not for the inter-ALTO communication. 543 Network Map: This structure is defined by the ISP and reflects the 544 internal structure of the ISP network. This structure has only 545 a local meaning and, generally, it is not unique for all 546 entities within the Internet. 547 A particular network map can be used by different operators. 548 The requesting ALTO server usually has to perform some 549 prediction of the external topology on its own. The ALTO 550 server has to apply its own rules and definitions. The PIDs, 551 defined in the remote ALTO server, have to be mapped on the PID 552 structure defined in the local AS. 554 Cost Map: This structure also has the local meaning. The local ALTO 555 server may receive the network map and the cost map from a 556 remote ALTO server. These costs may require recalculation in 557 order to unify the cost measures in the local AS. After these 558 operations, if it is needed, the rating/ranking procedure can 559 be performed. 561 5. Security Considerations 563 The communication between ALTO servers requires authentication and 564 authorization procedures. In some cases it may require establishment 565 of the secured tunnels between the partner ALTO servers. The minimum 566 security requirements for the inter-ALTO communication is out of 567 scope of this document. 569 The inter-ALTO communication allows ALTO servers to exchange any 570 parameters which improve the performance of the overlay traffic, or, 571 generally, allows them to manage overlay traffic. In order to 572 achieve this results a group ISP may exchange sensitive data, the 573 exchanged parameters may be confidential. They should not be 574 accessible by a third party, e.g., some other ISPs or peers. 576 An ISP may have its own policy how organize the overlay traffic and 577 this policy may use a number of parameters during the evaluation 578 procedure. The policy result may be delivered to peers in many ways. 579 It can take the form of a sorted peer list without any parameters, a 580 sorted list with some parameters which are derived from the 581 parameters exchanged in the inter-ALTO communication, or raw 582 exchanged parameters. ISPs may have an incentive not to expose these 583 parameters in the raw form to peers. The mentioned sensitive 584 parameters require applying a higher level of the security 585 procedures. 587 In order to keep the exchanged parameters confidential it may be 588 reasonable to keep the communications between peers and ALTO server 589 from communication among ALTO servers by the protocol differentiation 590 separated. Different security procedures may be easier to manage if 591 these communication procedures take the form of two distinct 592 protocols. This protocol separation allows to define mechanisms 593 which are specific for the inter-ALTO communication only. The 594 protocol should not allow to use this mechanism by overlay peers. 595 The set of procedures for the inter-ALTO communication is expected to 596 be separated from the client ALTO communication and this can be 597 achieved by distinct protocols. 599 6. IANA Considerations 601 This document has no actions for IANA. 603 7. Acknowledgements 605 The authors would like to thank following people for the valuable 606 discussions (in alphabetical order): 608 o Piotr Cholda (AGH University of Science and Technology) 610 o Miroslaw Kantor (AGH University of Science and Technology) 612 o Jan Medved (Juniper) 614 o Stefano Previdi (Cisco) 616 o Robert Varga (Pantheon) 618 This work has been partially supported by the EU through the ICT FP7 619 Project SmoothIT (FP7-2007-ICT-216259). 621 8. References 623 8.1. Normative References 625 [I-D.ietf-alto-protocol] 626 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 627 draft-ietf-alto-protocol-09 (work in progress), June 2011. 629 [ICC.optimal] 630 Dulinski, Z., Kantor, M., Krzysztofek, W., Stankiewicz, 631 R., and P. Cholda, "Optimal Choice of Peers based on BGP 632 Information", Proceedings of 2010 IEEE International 633 Conference on Communications (ICC), May 2010. 635 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 636 Optimization (ALTO) Problem Statement", RFC 5693, 637 October 2009. 639 8.2. Informative References 641 [I-D.jenkins-alto-cdn-use-cases] 642 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 643 S. Previdi, "Use Cases for ALTO within CDNs", 644 draft-jenkins-alto-cdn-use-cases-01 (work in progress), 645 June 2011. 647 [IJNM.unfairness] 648 Lehrieder, F., Oechsner, S., Hossfeld, T., Staehle, D., 649 Despotovic, Z., Kellerer, W., and M. Michel, "Mitigating 650 unfairness in locality-aware peer-to-peer networks", 651 International Journal of Network Management, Volume 21, 652 Issue 1, pp. 3-20, January/February 2011. 654 Authors' Addresses 656 Zbigniew Dulinski 657 Jagiellonian University 658 ul. Reymonta 4 659 Krakow 30-059 660 Poland 662 Phone: +48 12 663 5571 663 Fax: +48 12 633 4079 664 Email: dulinski@th.if.uj.edu.pl 665 Piotr Wydrych 666 AGH University of Science and Technology 667 al. Mickiewicza 30 668 Krakow 30-059 669 Poland 671 Phone: +48 12 617 4817 672 Fax: +48 12 634 2372 673 Email: piotr.wydrych@agh.edu.pl 675 Rafal Stankiewicz 676 AGH University of Science and Technology 677 al. Mickiewicza 30 678 Krakow 30-059 679 Poland 681 Phone: +48 12 617 4036 682 Fax: +48 12 634 2372 683 Email: rstankie@agh.edu.pl