ALTO WG Xianghui. Sun Internet-Draft China Telecom Intended status: Standards Track October 18, 2010 Expires: April 21, 2011 ALTO Deployment Considerations: Configuration and Monitoring by ISPs draft-alto-deployment-00.txt Abstract As ALTO specification continues in the ALTO Working Group and some applications start to conduct integration with ALTO, more ISPs start to evaluate key issues in the deployment of ALTO in their networks. In this document, we discuss key issues that an ISP needs to consider when deploying ALTO. In particular, we disucss issues on how to configure ALTO information as well as how to monitor the effectiveness of ALTO. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 15, 2011. Sun Expires April 15, 2011 [Page 1]
Internet-Draft ISP ALTO Configuration and Monitoring October 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. ALTO Server Placement and Configuration . . . . . . . . . . . 3 2.1. Server Placement . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Optimization Area . . . . . . . . . . . . . . . . . . 4 2.1.2. Server Load Balancing and Fault Tolerance . . . . . . 4 2.2. Network and Cost Map Configuration . . . . . . . . . . . . 4 2.2.1. Network Map and PID . . . . . . . . . . . . . . . . . 4 2.2.2. Cost Map . . . . . . . . . . . . . . . . . . . . . . . 5 3. ALTO Deployment Monitoring . . . . . . . . . . . . . . . . . . 5 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5 3.2. Requrements . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Monitoring Metrics . . . . . . . . . . . . . . . . . . . . 6 3.4. Monitoring Data Sources . . . . . . . . . . . . . . . . . 7 3.4.1. Log Server . . . . . . . . . . . . . . . . . . . . . . 7 3.4.2. P2P Clients . . . . . . . . . . . . . . . . . . . . . 8 3.4.3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4.4. DPI . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. New Entities . . . . . . . . . . . . . . . . . . . . . . . 8 3.6. Monitoring Example . . . . . . . . . . . . . . . . . . . . 9 3.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 9 3.6.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Sun Expires April 15, 2011 [Page 2]
Internet-Draft ISP ALTO Configuration and Monitoring October 2010 1. Introduction A basic service of ALTO is to provide information from network service providers to applications, in order to improve network efficiency and application performance. Some applications start to or have shown interests to conduct integration with ALTO. Some major ISPs (e.g., China Telecom) are in the process of deploying production ALTO services in some of their production networks. As a result, more ISPs start to evaluate key issues in the deployment of ALTO in their networks. Thus, a document highlighting some key issues that an ISP should consider in the deployment process can be a highly valuable reference. The objective of this document is to provide such a reference. The document draws on many valuable discussions in the ALTO mailing list as well as the predecessor p2pi mailing list. In addition, it draws on the trial experiences of multiple ISPs (e.g., [CTTrial,ComcastTrial]. The deployment of ALTO involves both ISPs and network applications. We can identify four major issues in ALTO deployment: 1. How does an ISP deploy and configure its ALTO servers? Specifically, an ALTO Server provides the Network Map and the Cost Map. How does an ISP configure these maps? Where does an ISP deploy ALTO servers? 2. Which application entities fetch ALTO information? 3. How does an application integrate ALTO information into its decision process? 4. How does an ISP (potentially with collaboration from applications) monitor the deployment of ALTO, so that the ISP can better understand the status as well as the policy impacts of its ALTO deployment? This document focuses more on the ISP perspective. Therefore, it focuses more on the first and fourth issues. There are additional deployment documents in the ALTO working group. For example, [] focuses more on the second issue; [] focuses more on the third issue. Our document is complementary to these other documents. 2. ALTO Server Placement and Configuration Sun Expires April 15, 2011 [Page 3]
Internet-Draft ISP ALTO Configuration and Monitoring October 2010 2.1. Server Placement 2.1.1. Optimization Area An ISP deploys ALTO service to optimize traffic for a given network area. We define a network area for which traffic need be optimized using the ALTO service as an optimization area. A typical optimization objective of an ISP is to reduce the inbound and outbound traffic across the optimization area, due to the higher cost of such traffic. An optimization area can be an access network, a MAN, or a larger network consisting of both access works and MANs. An ISP with a relatively small network can define a single optimization area and deploy an ALTO server for the area. An ISP with a larger network may partition its network into multiple optimization areas. Each optimization area may include one or more MANs. Alternatively, the ISP may choose to use a large optimization area and distribute a group of ALTO servers. 2.1.2. Server Load Balancing and Fault Tolerance 2.2. Network and Cost Map Configuration The key components for an ISP to configure when it deploys its ALTO service are the Network Map and Cost Map. They have impacts on both the load and the effectiveness of the service. 2.2.1. Network Map and PID To define network map in real deployment, the tradeoff network scale is very important. In the research and study point of view, the small grain of network map is beneficial to improve the optimization result of ALTO service. But too small grain will lead to the complexity of ALTO service running and management. There may be many tables and costs maintained in the ALTO server. However, too large grain can reduce the optimization result of ALTO service, make ALTO service nonsense. In real network, the Internet is one combination network of multiple ISPs around world. Every ISP operator has its own infrastructure and technology to build its ISP network. Some ISPs only have access network, such as school network, enterprise network and so on. Some ISPs have access networks, MAN or Core network, such as telecom operator, like China Telecom. So, the real network infrastructure can make some natural boundaries. Sun Expires April 15, 2011 [Page 4]
Internet-Draft ISP ALTO Configuration and Monitoring October 2010 We can give some examples as below. 1. Usually, the school, enterprise or organization have their own network. This kind of network is simple infrastructure, constituted with several switches and routers. These networks always are connected to Internet through one telecom operator. One enterprise network can be identified by one PID. 2. The access network, using ADSL technology or Ethernet technology, which is very popular in current telecom operator's network or some small ISPs, has BAS server to provide access service for its subscribers. Because all its subscribers' traffic must be transmitted through its BAS server, this kind of access network can be identified by one PID. There is not necessary to divide smaller groups in this kind of access network. 3. The MAN usually is constituted with several access networks. In big telecom network, all MANs are connected to Core network, and the Core network bandwidth resource is high-cost. Deploying ALTO service in one or several MANs, the traffic can be limited in the local MAN, and the Core network resource can be saved. In this scenario, one or several MANs can be identified by one PID. 2.2.2. Cost Map 3. ALTO Deployment Monitoring 3.1. Problem Statement In current ALTO architecture, we have no method to understand the ALTO service running conditions. For example, we know ALTO service can reduce network resource consumption and accelerate download rate, but we cannot know how much traffic can be reduced. Also in ALTO service deployment, many policies can be tried to let ALTO service select the most effective policy in different network environment. To do this, we have to know the deployment result of different policies. 3.2. Requrements To deal with problem above, some requirements are proposed, as below. 1. We should analyze which data or information are needed 2. Available data source should be studied, including using system already deployed or new monitoring system Sun Expires April 15, 2011 [Page 5]
Internet-Draft ISP ALTO Configuration and Monitoring October 2010 3. Agile transport mechanism from multiple types of source to ALTO service 3.3. Monitoring Metrics Currently ALTO service can be applied in multiple applications, including P2P, CDN and so on. But only the scenario integrated with P2P application has been deployed in Comcast and CT. So in this document, we mainly consider the P2P application. To understand ALTO service running condition or evaluate policies result, some data should be defined, which are named as Metric in this document. We think through these metrics, the ALTO service deployment can be understood more exactly or even improved. First, we define domain as one or many groups of Endpoints. That is, one domain includes one PID or some PIDs. Endpoints and PID are defined in "draft-ietf-alto-protocol-05". From ISP's point of view, we can define some metrics as below: o Metric 1 (Inter-domain IP traffic): To evaluate how ALTO service can reduce network resource consumption, the total traffic information has to known. For example, before we deploy ALTO service in one domain of network, we should know the inbound and outbound traffic condition of this domain. This traffic includes total traffic information, in current Internet, usually is IP traffic. o Metric 2 (Inter-domain application traffic): The optimizing traffic in ALTO service is application layer traffic. So this metric is very important in ALTO service. ALTO service mainly reduces the inter-traffic between domains, so the inter-domain application traffic change condition before and after ALTO service deploying can give the result of ALTO service. This metric is always used with Metric 1 and 3. o Metric 3 (Inner-domain application traffic): One of the ALTO service primary functions is application traffic localization. This metric can provide the efficacy result of ALTO service and different policies. This metric is always used with Metric 1 and 2. From application service provider's point of view, we can define some metrics as below: o Metric 4 (Peer user distribution in domain): This metric is only for P2P application. In P2P overlay, peer distribution Sun Expires April 15, 2011 [Page 6]
Internet-Draft ISP ALTO Configuration and Monitoring October 2010 information can provide some hints to understand this overlay architecture. This information can be helpful to understand the P2P overlay. o Metric 5 (Peer list condition): This metric is only for P2P application. In P2P application, every p2p client need connect with other p2p clients. The list of these p2p clients is named as peer list for one request peer client. The ALTO service let peer list more localization. So this metric can be helpful to give the efficacy result of ALTO service and different policies. o Metric 6 (Global average download rate): This metric provides the application performance directly. Download means inbound traffic to one user. Global average means the average value of all users download rate in one or more domains. We can compare this metric before and after deployment ALTO service in one domain to understand the ALTO service. o Metric 7 (Global average connection hop): This metric provides the application performance indirectly. One of ALTO protocol's aims is to reduce the network path hops of one data connection. This metric gives the average hops of all connections in one or more domains. We can compare this metric before and after deployment ALTO service in one domain to understand the ALTO service. o Metric 8 (Global average cache time): This metric is for streaming application. This metric means the time between the clients starting to download streaming packets and the streaming content starting to play in the player. Global average means the average value of all cache time in one or more domains. We can compare this metric before and after deployment ALTO service in one domain to understand the ALTO service. o Metric 9 (jitter time) 3.4. Monitoring Data Sources The metrics can be obtained come from multiple locations. There are already some monitor and measurement methods deployed in current network, such as netflow, DPI and so on. Also, we need add some new methods for monitor application performance. We identify four data sources are defined as below. 3.4.1. Log Server Log Server of service providers' network architecture is used to monitor all running conditions of service operation. Commonly, Sun Expires April 15, 2011 [Page 7]
Internet-Draft ISP ALTO Configuration and Monitoring October 2010 service providers deploy Log Server to collect data of their operation condition by themselves, usually using private protocol. In our scenario, Log Server can provide more information about service operation, service using condition and more exact information. For example, to one P2P service system, Log Server can provide some data, such as peer distribution information, peer list selection information and so on. 3.4.2. P2P Clients In some P2P overlays, there is no central Log Server. Also we can obtain some information from P2P client directly. The information is same as Log Server. 3.4.3. OAM OAM systems have been deployed in all networks, and mainly are used to monitor IP layer traffic condition. OAM can provide the traffic information of every network device in its management area, including link physical bandwidth, traffic and so on. In our scenario, some monitor points can be configured in OAM system to monitor IP layer traffic information, such as inter-domain IP layer traffic. 3.4.4. DPI DPI systems have been deployed in large scale in may ISPs' network. ISPs use DPI system to understand their application layer traffic. Differ from OAM system, DPI system can provide application layer information of network traffic. In our scenario, using DPI system, we can know P2P traffic condition exactly in the network, such as the P2P traffic proportion of overall IP traffic, or the traffic proportion information of different P2P service providers. 3.5. New Entities Some new entities and transport protocol are added to current ALTO architecture. Monitor Service usually is deployed in the ALTO service Provider, commonly in ISP network. It is in charge of collecting data from all data resources. Monitor Client usually is deployed in Service Provider, such as in P2P operator or CDN operator. It can obtain raw data from Log Server or P2P clients locally, and transmits the data needed according to the protocol and format defined in this document. Sun Expires April 15, 2011 [Page 8]
Internet-Draft ISP ALTO Configuration and Monitoring October 2010 +------------------------------------------------+ | | | New Entities +--------------------------------------+ | | Service Provider | | | (P2P/CDN Operator etc)| | +-----------+ | +-----------+ | | | |ALTO Server|-------------|ALTO Client| | | | +-----------+ | +-----------+ | | | | | +----------+ | | | | |Log Server| | | | | +----------+ | | +--------------+ | +--------------+ | +----------+ | | |Monitor Server|----------|Monitor Client| | |P2P Client| | | +--------------+ | +--------------+ | +----------+ | | | | | | | | +-----|-----|-----+ +--------------------------------------+ +-|-----|-----|-----|----------------------------+ | | | | | | | | | +---+ +---+ | | |DPI| |OAM| | | +---+ +---+ | | | | ISP | ----------------- Figure 1 3.6. Monitoring Example 3.6.1. Overview From analysis above, we can know there are multiple type sources. To these sources, some have standard protocol and interface, such as OAM; some have private protocol; or even some have no transport protocol currently. To deal with this condition, one agile transport protocol suite is needed. It can use standard protocol in some data sources. Also it can use new transport protocol in some data sources. Some new modules and transport protocol are added to current ALTO architecture. Monitor Service usually is deployed in the ALTO service Provider, commonly in ISP network. It is in charge of collecting data from all data resources. Monitor Client usually is deployed in Service Provider, such as in P2P operator or CDN operator. It can obtain raw data from Log Server or P2P clients locally, and transmits the data needed according to the protocol and format defined in this document. We can give one example as below. Sun Expires April 15, 2011 [Page 9]
Internet-Draft ISP ALTO Configuration and Monitoring October 2010 3.6.2. Protocol Some data sources already have standard protocol and interface, and then we can also use this protocol. To some data sources, which have no public transport protocols, the new protocol can be defined as below. Monitor Client sends message to Monitor Server to report defined information periodically. The period time can be configured in the system. In the message body field of Data Report message, we can use the definition in draft "draft-ietf-alto-protocol-05". HTTP/1.1 200 OK Content-Length: [TODO] Content-Type: application/alto { "meta" : { "version" : 1, "status" : { "code" : 1 } }, "metric1 name" : "value", "metric2 name" : "value", } Sample Table Schema. Figure 2 The body of Reply message can be "OK" or "ERROR". 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations . Sun Expires April 15, 2011 [Page 10]
Internet-Draft ISP ALTO Configuration and Monitoring October 2010 6. References 6.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [2] H. Xie, Y.R. Yang, A. Krishnamurthy, Y. Liu, and A. Silberschatz., "P4P:", In SIGCOMM 2008. Appendix A. Acknowledgments We thank ... Author's Address XianghuiSun China Telecom Email: sunxh@ctbri.com.cn Sun Expires April 15, 2011 [Page 11]