Internet DRAFT - draft-alto-deployment
draft-alto-deployment
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]
