ALTO WorkingGroup Yu Meng
Internet-Draft Jun Wang
Intended status: Informational ZTE Corporation
Expires: Feb 20, 2010 Tao Ma
Hui Wang
Miao Xiong
MINE lab,Beijing University of Posts and Telecommunication
Aug 20,2009
Relay Usage for ALTO in Real Time Communication
draft-meng-alto-relay-00
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 January 21, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Meng, et al. Expires Jan 21, 2010 [Page 1]
Internet-Draft ALTO relay usage July, 2009
Abstract
ALTO has been proposed to help peer-to-peer (P2P) applications make
better decisions with respect to peer selection. It provides the
underlying network view for P2P users to choose the optimal resource
instances. The usage of ALTO has covered nearly all the P2P
applications, such as file sharing, media streaming, real time
communications and etc. In real time communication where the source
and destination are fixed, it is used to choose relays.
This document defines the relay usage for ALTO in real time
communication. Beside the relay for NAT traversal mentioned before,
this document introduce a relay called Qos relay to improve the
performance. After analyzing the necessity of this type of relay and
the benefits of combining ALTO with relay, two models of combination
are described according to the coupling tightness between ALTO and
relay service. One is called "integrating relay service into alto
service" and the other is "cooperation between P2P application
provider and ISP". In all, the usage of ALTO in real time
communication has been developed in this document.
Meng, et al. Expires Feb 20, 2010 [Page 2]
Internet-Draft ALTO relay usage July, 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The necessity of relay in the P2P real time communication. . . 5
2.1. Connectivity relay . . . . . . . . . . . . . . . . . . . . 5
2.2. Qos relay. . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. The phenomenon of anti-triangular . . . . . . . . . . 5
2.2.2. The benefits of combining
ALTO service with relay service . . . . . . . . . . . 7
3. The model of combining ALTO service with relay service . . . . 7
3.1. Integrating relay service into alto service . . . . . . . 8
3.1.1. Server functions . . . . . . . . . . . . . . . . . . 8
3.1.2. Server database . . . . . . . . . . . . . . . . . . . 9
3.1.3. Protocol . . . . . . . . . . . . . . . . . . . . . . 9
3.1.4. Measurements. . . . . . . . . . . . . . . . . . . . . 10
3.2. Cooperation between P2P application provider and ISP . . . 10
4. Security and privacy . . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Meng, et al. Expires Feb 20, 2010 [Page 3]
Internet-Draft ALTO relay usage July, 2009
1. Introduction
Network traffic generated by Peer-to-Peer (P2P) applications
determines a large portion of the overall traffic in the Internet.
Because P2P applications have limited information about the
underlying network topology, they usually select direct P2P
connections in a suboptimal way. As a result, P2P traffic often
crosses several ISPs, causes high load and congestion on particular
network links, reduces application performance, and generates high
costs for ISPs. This problem is discussed and described in detail in
the ALTO problem statement[draft-ietf-alto-problem-statement].
The goal of ALTO is to solve the ALTO problems by providing
information which can help peer-to-peer (P2P) applications to make
better decisions with respect to peer selection. The ALTO solution
provides a logical entity called ALTO server which provides the
information and guides the peer selection. The ALTO service provided
by ALTO server is most likely deployed by ISP which has the accurate
topology information. The ALTO clients are possibly the P2P
application users who try to receive good experiences by locating
suitable peers or resource providers.
ALTO service can be applied in many scenarios. The ALTO problem
statement[draft-ietf-alto-problem-statement] has listed five usecases
of ALTO service: file sharing, live media streaming, real time
communication, DHTs and cache/mirror selection. In the five cases,
ALTO service is mainly used to sort multiple destinations in the P2P
communication. For example, a user would locate the proximatepeer
with the help of ALTO according to underlying network topology among
a group of resource instances. But in real time communication, the
source and destination are fixed. Under this circumstance, ALTO
service would only help peers to choose relay, which acts as a bridge
in the application layer between the source and destination.
The relay mentioned in the ALTO problem statement [draft-ietf- alto-
problem-statement] is applied to connect users with limited access to
the Internet (e.g. users behind NATs, firewalls or HTTP proxies).
ALTO would help them find the best relays to relay the media flows.
We call this type of relay as "connectivity relay", which is used to
guarantee the connectivity of real time communication. This document
proposes another type of relay, which can be used to improve
performance of real time communication, called "Qos relay" here. This
document would describe the background of Qos relay and design the
mechanism of combining ALTO service with relay. On the basis of the
tightness of coupling between ALTO and relay service, we put forward
two methods to apply ALTO solution for relay to improve performance
of real time communication.
Meng, et al. Expires Feb 20, 2010 [Page 4]
Internet-Draft ALTO relay usage July, 2009
2. The necessity of relay in the P2P real time communication
We argue that two types of relay are needed in P2P real time
communication, which include the connectivity relay and Qos relay.
Here the necessity of relay would be formulated to show that relay is
generally useful. Additionally, the benefits of combining ALTO
service with relay service is generalized, which expands the range of
application of ALTO.
2.1. Connectivity relay
P2P real time communication allows users to establish direct media
flows, usually to place audio and video calls, or to have text chats.
In the basic case, media would flow directly between the two
endpoints; however, in the general case, a significant portion of
communications between users with limited access to the Internet
(e.g. users behind NATs, firewalls or HTTP proxies) need to be
relayed by other elements. Such media relays are distributed over the
Internet -- in some cases co-located with applications with a public
address; the goal of an ALTO solution would be to help peers find the
best relays[draft-alto-problem-statement]. We call this type of relay
as connectivity relay which aims to guarantee the connectivity of the
endpoints of real time communication. This type of relay is widely
used, but not the focus of our document.
2.2. Qos relay
This document stresses upon another type of relay, which can be used
to improve performance of real time communication, called Qos relay
here. Its existence comes from the phenomenon of anti-triangular in
Internet. Because of the quality requirements of real time
communication and this widely existing phenomenon, Qos relay is of
great significance and impact.
2.2.1. The phenomenon of anti-triangular
Among all of the sessions on the internet, there are always some
sessions with direct IP routing RTTs which exceed the RTT threshold
for quality VoIP communication. For these sessions, it is likely to
find one-hop overlay relay paths to reduce the RTTs. The RTTs of
these relay paths are less than those of the direct IP routing paths.
This is called as the phenomenon of anti-triangular.
Meng, et al. Expires Feb 20, 2010 [Page 5]
Internet-Draft ALTO relay usage July, 2009
IP routing on the Internet is dependent on the provider-customer and
peer-peer commercial contractual relationships between neighboring
Autonomous Systems (AS) or Internet Service Providers (ISPs). Usually
a provider AS transits traffic for a customer AS, while a customer AS
does not transit traffic for its provider AS. Constrained by this
rule, an Internet AS-level routing path usually has the valley-free
property. Because each AS can enforce its own routing policy, the
direct IP routing path between two end hosts is not necessarily the
optimal one among all possible routing paths between them, including
overlay routing paths. Under the following two conditions, overlay
routing paths can be faster than the direct IP routing paths[SL06].
(1) An AS in a direct routing path is congested or failed.
Consider a session between two end hosts in AS A and AS B. The direct
IP routing path between them contains AS C which is congested. If
there is a one-hop relay overlay routing path between AS A and AS B
through AS D which does not contain the congested AS C on the IP
routing path, this relay path will be faster than the direct IP
routing path. Even worsely, the direct routing path may contain
failed ASes, while needs to be bypassed by overlay routing path. In
these cases, overlay routing latency can be shorter than the direct
IP routing path.
(2) Multi-homed customer ASes can further improve overlay routing.
A multi-homed customer AS connecting to multiple upstream provider
ISPs can act as the intermediary relay to transit traffic for its
provider ISPs, and this one-hop relay path can have shorter AS hops
than the direct IP routing path. Considering the AS graph in
Figure 1, an AS B has multi-homed connections to two providers AS D
and AS E. For the two end hosts in AS A and AS C, the direct IP
routing path between them is A-D-F-H-I-G-E-C, which has 7 AS hops,
while the overlay routing path through AS B is A-D-B-E-C, which has
only 4 AS hops, 3 hops shorter. As the path latency is correlated to
the AS hops on this path, the RTT of overlay routing is highly likely
to be shorter than that of direct IP routing despite of the relay
delay at AS B.
Meng, et al. Expires Feb 20, 2010 [Page 6]
Internet-Draft ALTO relay usage July, 2009
AS H****AS I
/ \
/ \
AS F AS G
/ \
/ \
AS D AS E
/ \ / \
/ \ / \
/ \ / \
AS A AS B AS C
/ provider-to-customer edge
* peer-to-peer edge
Figure 1 Multihome AS-overlay routing is faster than direct IP routing
2.2.2 The benefits of combining ALTO service with relay service
In P2P applications, the underlay topology is very limited known,
which results in the suboptimal choice of peers and unnecessary waste
of network resources. For relay service, P2P application needs to do
a lot of measurements to choose the suitable relays. If ALTO service
is combined with relay service, we can get reliable and accurate
information from the ISPs, including accurate AS topology, link cost
and QoS parameters. Both ISPs and P2P applications can benefit from
the combination. The introduction of ALTO service makes the relay
selection process and the overlay routing under the control of ISPs,
which avoids the traffic congestion and confusion of selection of
nodes in P2P network which is lack of management. It also reduces the
costs of measurements for P2P applications because many parameters
can be obtained from the ALTO server.
3. The model of combining ALTO service with relay service
The idea of combining ALTO service with relay service can be
implemented in two models. Here two models are illustrated. The two
models are different in the tightness of coupling between ALTO and
relay. For the first model, ALTO server accounts for both the
management and ranking of relay candidate lists. Relay service is
tightly coupled with alto service. We call this model as "integrating
relay service into alto service". For the second model, ALTO server
is unaware of relay peer. The P2P application provides relay
candidate lists and ALTO server only sorts it considering topological
proximity. The coupling relationship between ALTO and relay is
relatively loose. It reflects the cooperation between ISP and P2P
application providers. ALTO server provides the P2P application
provider the necessary underlying network information to help choose
the suitable relay candidates. We call this model as "cooperation
between P2P application provider and ISP".
Meng, et al. Expires Feb 20, 2010 [Page 7]
Internet-Draft ALTO relay usage July, 2009
3.1 Integrating relay service into alto service
As the anti-triangular phenomenon widely exists in Internet, relay
service can be deemed as an important tool for application layer
traffic optimization, which means ALTO server would take the relay
service into its functional components. In this model, the relay
candidate lists are maintained in ALTO servers. An ALTO server is a
logical entity that provides interfaces to query the alto service.
The ALTO server may integrate relay service into alto service to
improve client's performance or quality of service. ALTO clients can
query the ALTO server for the list of available relay peers or
servers.
An illustration of the architecture is presented in the following
figure.
+-------------------------------------------------------------------+
| AS1 or cluster1 |
| +-----------+ +---------+ +--------+ |
| |Relay | | ALTO | ALTO Query/Response | ALTO | |
| |Information|........| Server | ------------------- | Client | |
| +-----------+ +---------+ +--------+ |
| | | |
+----------------------------|------------------------------|-------+
+----------------------------|------------------------------|-------+
| AS2 or cluster2 | | |
| | | |
| +-----------+ +---------+ +--------+ |
| |Relay | | ALTO | ALTO Query/Response | ALTO | |
| |Information|........| Server | ------------------- | Client | |
| +-----------+ +---------+ +--------+ |
+-------------------------------------------------------------------+
Figure 2 The architecture of combining ALTO service with relay
service
Four key points are highlighted in this model: server functions;
server database; protocol; measurements.
3.1.1. Server functions
Functions of ALTO server include:
1.Maintain and update AS topology;
2.Peer registration ;
3.Gathering relay list;
4.Update adjacent AS information
Meng, et al. Expires Feb 20, 2010 [Page 8]
Internet-Draft ALTO relay usage July, 2009
3.1.2. Server database
ALTO server requires these data below:
AS topology information;
AS number(ASN);
Mapping information between ASN and IP address(es);
Peer registration information;
Relay list;
Hops to the adjacent AS.
3.1.3. Protocol
Communication protocol in the system comprises protocol between ALTO
servers, protocol between ALTO server and peers, protocol between
peers.
An illustration of the flowchart is presented in the following
figure.
p1 ALTO server1 ALTO server2 p2
| | | |
|------1------>| | |
|--------------|-------------2-----------|------------>|
| | |<-----3------|
| |<------------4-----------| |
|<-----5-------| | |
| |-------------6---------->| |
| | |------7----->|
|<-------------|-------------8-----------|-------------|
| |
Figure 3 Example of integration model
Meng, et al. Expires Feb 20, 2010 [Page 9]
Internet-Draft ALTO relay usage July, 2009
Figure 3 shows an example of integration model. Peer 1 have
established a session to peer2 and it measures the direct path QoS
value.
1> If Peer 1 needs relay(direct Qos value are not satisfactory),
peer1 sends a relay request to ALTO server1.After receiving the
request ,server1 searches relay peer/server information among
adjacent AS through communication with other ALTO servers.
2> Peer 1 sends a relay notification to peer 2 via direct path.
3> After receiving from peer 1,peer 2 sends a relay request to ALTO
server 2. Server 2 does the same as in step1.
4> ALTO server 2 sends the relay information to ALTO server 1,
server 1 will do an intersection operation between its own relay
information and the received relay information, and then obtain the
relay candidate list.
5> ALTO server 1 returns the relay list to peer 1. Peer 1 measures
the QoS value to those candidates in the list.
6> ALTO server 1 returns the relay candidate list to ALTO server2.
7> ALTO server 2 returns the relay candidate list to peer 2, and
peer 2 measures the QoS value to those candidates in the list.
8> peer 2 returns the measuring results to peer 1.
Based on the measuring results, peer 1 will determine the best relay
peer.
3.1.4. Measurements
Measurements in the system mainly consist of AS topology measurements
and QoS value measurements. AS topology measurements contain adjacent
AS hops and other connection relationship information.
QoS value includes delay, jitter, loss rate etc from peers to relays.
Source and destination should both measure the Qos values to relays.
The destination gives the results to the source which will deal with
them and filter the suitable relays.
3.2. Cooperation between P2P application provider and ISP
We define another model which is compatible with the current ALTO
architecture. The relay service is not integrated but considered as
the ordinary peer selection process. The peer would provide the ALTO
server with the relay candidate list, and the ALTO server would rank
the list. Here the relay candidate list is provided and maintained by
P2P application providers. P2P software users might configure or
cache this list before querying ALTO server. The relay candidate
discovery mechanism might be designed by P2P application providers.
After receiving the ranked list, the end users negotiate with each
other and choose the most suitable relay according to the ALTO server
response.
Meng, et al. Expires Feb 20, 2010 [Page 10]
Internet-Draft ALTO relay usage July, 2009
The ALTO goal here is not only for traffic localization but also for
improving the Qos. ALTO server might use BGP routing information to
calculate the preference of relay candidates that P2P application
provides. The rating method can be seen in [draft-racz-bgp-based-
alto-service]. In P2P real time communication, P2P application
providers has deployed relay candidate peers or servers, then ALTO
server assists the users to select relay to reduce inter-domain
traffic and achieve a more efficient inter-domain traffic pattern
between ISPs. It is meaningful to both P2P application and ISPs.
The flow chart of P2P real time communication with the cooperation
between ISP and P2P application providers can be seen as follows:
p1 ALTO server1 ALTO server2 p2
| | | |
|------1------>| | |
|<------2------| | |
|--------------|-------------3-----------|------------>|
| | |<-----4------|
| | |-------5---->|
|<-------------|-------------6-----------|-------------|
| | | |
Figure 4 Example of cooperation model
Figure 4 shows an example of cooperation model. Peer 1 have
established a session to peer2 and it measures the direct path QoS
value.
1> If peer 1 needs relay(direct Qos value are not satisfactory),
peer 1 sends the relay candidate lists to ALTO server1.After
receiving, ALTO server1 ranks the lists according to its policy or
topological proximity information.
2>ALTO server 1 returns the ranked list to peer 1, and peer 1
measures the QoS value to those candidates in the relay list.
3> Peer1 sends a relay notification to peer2 via direct path.
4> After Peer2 receives the notification from peer 1, it sends the
relay candidate list to ALTO server2. Server2 does the same as in
step1.
5> ALTO server 2 returns the ranked list to peer 2, and peer 2
measures the QoS value to those candidates in the relay list.
6>Peer 2 returns the measuring results to peer 1.
Based on the measuring results, peer 1 will determine the best relay
peer. A possible measure is to intersect the received peer 2's relay
list and peer 1's own relay list to choose the best relay.
Meng, et al. Expires Feb 20, 2010 [Page 11]
Internet-Draft ALTO relay usage July, 2009
This model needs the cooperation between P2P application providers
and ISPs. P2P application providers would provide the relay lists
they maintain and asks ISPs to help the selection. The ISPs would
sort the candidates according to both the policy and topological
proximity. The results would be sent back to end users, who would
decide whether or which to choose. The cooperation between the two
parties would result in better relay selection and further improve
the Qos of P2P real time communication.
4. Security considerations
High-level security considerations can be found in the ALTO problem
statement [draft-ietf-alto-problem-statement] and they apply for this
document as well.
5. IANA Considerations
None.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[draft-ietf-alto-problem-statement] Seedorf, J., Burger, E.,
"Application-Layer Traffic Optimization (ALTO) Problem Statement",
Internet-Draft, May, 2009.
[SL06] S. Ren, L. Guo, and X. Zhang, "ASAP: an AS-Aware Peer-Relay
Protocol for High Quality VoIP with Low Overhead", in Proceedings of
26th International Conference on Distributed Computing Systems
(ICDCS'06), Lisbon, Portugal, July 4 - 7, 2006
Meng, et al. Expires Feb 20, 2010 [Page 12]
Internet-Draft ALTO relay usage July, 2009
Authors' Addresses
Yu Meng
ZTE Corpoporation
No68, Zijinghua Road
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86 025 52877648
Email: meng.yu@zte.com.cn
Jun Wang
ZTE Corpoporation
4F,RD Building 2,Zijinghua Road
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86 025 52877648
Email: wang.jun17@zte.com.cn
Tao Ma
Mobile lIfe and New mEdia Lab, BUPT.
P.O. Box 92, No.10,
Xitucheng Road BeiJing, Haidian District 100876
P.R.China
Email: abcdmatao@gmail.com
Hui Wang
Mobile lIfe and New mEdia Lab, BUPT.
P.O. Box 92, No.10,
Xitucheng Road BeiJing, Haidian District 100876
P.R.China
Email: whui.bupt@gmail.com
Miao Xiong
Mobile lIfe and New mEdia Lab, BUPT.
P.O. Box 92, No.10,
Xitucheng Road BeiJing, Haidian District 100876
P.R.China
Email: xiongbearie@gmail.com
Meng, et al. Expires Feb 20, 2010 [Page 13]