Network Working Group Yunfei.Zhang
Internet Draft China Mobile
Intended status: Informational Hongluan.liao
Expires: April 23, 2009 China Mobile
Naibao.ZHOU
China Mobile
October 23, 2008
P2P Traffic Localization by Alias Tracker for Tracker-based P2P
applications (ATTP)
draft-zhang-alto-attp-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
This document may not be modified, and derivative works of it may not
be created.
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 February 1, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
zhang & liao Expires April 23, 2009 [Page 1]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
Currently P2P applications have accounts for large cross-ISP traffic.
This document proposes a method to reduce cross-ISP traffic by
setting cooperative ISP-friendly trackers in the ISP's network.
Through improving the random node selection mechanism in P2P
tracker-based application, we can effectively reduce cross-ISP
traffic as well as the cost of network equipments and network
operation.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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].
Table of Contents
1. Introduction................................................2
1.1. Terminology............................................3
2. Overview....................................................4
3. ISP's Considerations on ISP-P2P application provider align....5
4. ATTP: One mechanism for Tracker-based P2P applications........6
4.1. Architecture...........................................6
4.2. Procedure of ATTP.......................................8
4.3. The strategies of alias Tracker choosing seed nodes.....10
4.3.1. According to the state of the network.............10
4.3.2. According to the seed node service capabilities....13
4.3.3. The connection strategy and economy of the AS......13
4.4. The process order of Alias Tracker selecting seed nodes.13
4.5. Advantages of ATTP.....................................14
5. Security Considerations.....................................14
6. IANA Considerations........................................15
7. Conclusions................................................15
8. Acknowledgments............................................15
8.1. Normative References...................................16
8.2. Informative References.................................16
Author's Addresses............................................16
Intellectual Property Statement................................17
Disclaimer of Validity........................................17
1. Introduction
Currently P2P applications take a large share in total network
traffic. According to the recent record of China Telecom, one of the
zhang & liao Expires April 23, 2009 [Page 2]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
biggest ISP in China, P2P applications account for more than 50% of
the Internet traffic in the daytime and 90% at night. Meanwhile the
ISP international outport is jammed seriously by P2P applications
almost all the time. The problem of cross-ISP traffic is serious
which will bring out great cross-ISP traffic billing as well as
network management and operation cost for ISPs.
The purpose of this document is to specify a cooperative tracker
building mechanism aligned with tracker-based P2P application
providers to improve the seed selection mechanism for Tracker-based
P2P applications. This mechanism doesn't change current P2P software
and can make node selection consistent with physical topology, so
cross-ISP traffic can be effectively reduced and the cost of network
equipment and network operation is largely cut off.
1.1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described RFC 2119 [RFC2119].
This section defines some key concepts using in this document.
Tracker: A server which assists in the communication between live
peers. It is a major critical point. Clients communicate with
the tracker to get peer list. After initiate downloads clients
communicate with the tracker periodically to negotiate with newer
peers.
Tracker-based application: We denote P2P file sharing applications
like Bittorent and P2P streaming (both live and VOD) applications
like PPlive as tracker-based applications. In a P2P tracker-based
system, each end node requests seed/leecher list from the tracker.
Seed Node/Leecher node: P2P clients that can provide data to other
clients, allowing other clients to download p2p data. They register
themselves at the tracker and refresh information periodically. The
difference in seed Node and leecher node is just how much it holds
the shared files. A seed holds the whole parts of the specific
files.
DNS Redirection: A technique on the Internet for making a domain
name available under many IP address. Through this technique user
request to a domain name can be redirected to a new address.
zhang & liao Expires April 23, 2009 [Page 3]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
2. Overview
Currently P2P applications accounts for significant traffic on the
Internet, For example, in China some P2P applications including
Bittorent[4] PPlive[5] have take 75% share of total P2P traffic.
Such applications are all tracker-based. The tracker selects nodes
without any knowledge about the physical topology. That causes a
serious mismatch between physical topology and application topology
and it contributes to most P2P cross-ISP traffic, which will bring
great network operation cost for ISPs.
These P2P applications are tracker-based and we mainly focus on this
type of P2P applications because its traffic dominance in the
Internet. In this document we will take Bittorent as an example to
describe the problem and the related solutions. Obviously it can be
used in other tracker-based P2P applications.
As showed in Figure 1 there are three components in Bittorent:
tracker, websites and end nodes. The website provides resource
information published by end nodes about which files others can
download. Other end nodes visit the website to search the target
files and then download related torrent files; the trackers is an
index server which maintains seed nodes/leecher nodes list that can
provide files data and it returns nodes list to end nodes after they
request. After receiving the corresponding nodes list, the requesting
end node then connects the seed nodes/leecher nodes to request the
file blocks and download file blocks from these nodes when these
nodes allow its request.
In current mechanism the cross-ISP traffic will be great. The most
important reason is that trackers select some seed nodes/leecher
nodes and return them to end nodes without knowledge of physical
topology. End nodes will contact these seed nodes/leecher nodes to
download P2P data. If two nodes don't belong to the same ISP, cross-
network traffic will be unavoidable.
zhang & liao Expires April 23, 2009 [Page 4]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
/------------------------\
| Trackers |
\------------------------/
/--------------\ ^ ^
| websites | | |(4) |
\--------------/ |(3) |return |
^ | |Parsing |node list |
| |(2) |.torrent | |periodically
| | |file and | |communication
| | download |request | |and heart beat
(1) | | .torrent |node list| |
visit| | file | | |
| | | V |
|--------------------------------| |
| end nodes | |
|--------------------------------| |
| ^ |
(5)request | | (6) |
status and data| | return |
| | status and data|
V | |
|--------------------------------|
| end nodes |
|--------------------------------|
Figure 1 Bittorent
3. ISP's Considerations on ISP-P2P application provider align
In a word, node clustering and localization is very important for
reducing cross-ISP traffic. The basic idea is to let operators/ISPs
and service providers of P2P application cooperate with node
clustering and localization. On one hand, operators totally know
their own network topology. They can effectively manage and classify
inner nodes of operator's network. On the other hand if service
providers of P2P application want to make node localized they have to
have some knowledge of the network topology and other information.
There are several choices in the use of network topologys. One choice
is that the operator provides topology and/or bandwidth information
to P2P applications. The other choice is that P2P applications
provides live nodes information to the operator and the operator
makes the decision of node clustering and localization based on its
network knowledge.
zhang & liao Expires April 23, 2009 [Page 5]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
Because the topology and/or bandwidth information is are important
and private for the operator,it's difficult to make it public for
security consideration becuse:
1) Malicious nodes/parties may use such information to launch network
attack;
2) It may affect the fairness of network to applications if P2P
application is the basic users of such services; So it's a good
choice for operators to provide node localization decision themselves
with the help of P2P application providers. In this document we
propose one mechanism to reduce cross-ISP traffic for Tracker-based
P2P applications.
It has some advantages:
1) It can keep operator independence and privacy;
2) It can make full use of operator's knowledge to reduce cross-ISP
traffic;
3) it don't add more burdens for the P2P application providers to
make node and request localization decision and it make increase the
application performance(esp. decreasing latency and increasing
throughput by localization). So it's a double-will game.
4. ATTP: One mechanism for Tracker-based P2P applications
4.1. Architecture
ATTP (Alias Tracker for Tracker-based P2P applications)is proposed in
this document to reduce the cross-ISP traffic. Three kinds of new
components/mechanisms are introduced in ATTP. We create a mirror-P2P
environment in home network by the cooperation with original P2P
application. The first new component is called Alias tracker. It is
controlled by the operators and is a cooperative component with
original tracker in P2P applications.
The second new component is inner resource website. The Resource
websites is similar to the websites in Bittorent. The most popular
resource information and the related torrent files will be issued
here. The inner nodes will be redirected to resource websites when
they try to visit Bittorent websites residing in foreign networks.
zhang & liao Expires April 23, 2009 [Page 6]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
The third part is a redirection mechanism in inner DNS server. When
inner nodes visit the original Bittorent website, ip address of this
website should be gotten from inner DNS server. When inner DNS server
receives the request, it will return the IP address of the mirror
resource website. So inner nodes will be automatically redirected to
resource website.
Alias Tracker is designed to provide peer index service for inner
nodes. It monitors live seed/leecher information in the Internet
scale and when inner nodes request peer list, it will first return
the inner nodes. One special case is that all the nodes return by
alias tracker are local nodes of operator's network.
Alias Tracker can reduce the cross-ISP traffic effectively between
different operator networks through returning inner nodes as more as
it can. If we just depend on the original BT websites and BT trackers
we can not achieve the goals because operators can not control the BT
trackers that may not in operator's network.
Alias Tracker is deployed in operator's network. In order to make
users automatically visit Alias tracker, some resource description
information (such as .torrent in Bittorent) should be changed to
amend the original tracker address to be Alias tracker address.
Through ATTP local nodes will be first recommended in the node list
to download file blocks thus the network traffic could be reduced
greatly for P2P application.
We take Bittorent as an example to describe the architecture as
Figure 2.
zhang & liao Expires April 23, 2009 [Page 7]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
network of | operator's home network
other operators |
|
/------------\ |
| Trackers | <--- |------- \
\------------/ | /----------------\
| | Alias Trackers |
/-----------\ | \----------------/
| websites | <---------|---------/
\-----------/ | /------------------\
| | | Resource websites |
| | \------------------/
| | |
| | |
|---------------| | |---------------|
| Foreign nodes | | | Inner nodes |
|---------------| | |---------------|
|
Figure 2 ATTP
4.2. Procedure of ATTP
According to the requirements, one or more Alias trackers could be
deployed as the mirror tracker for inner nodes of the ISP's network.
As showed in Figure 3 the Procedure of ATTP is as follows
zhang & liao Expires April 23, 2009 [Page 8]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
Original Original Alias Resource inner
BT websites BT trackers tracker websites nodes
| | | | |
| get files | | | |
|<--------------|--------------| issue | |
|---------------|------------->| files | |
| | |--------->| |
| | get peer list| | |
| |<-------------| | |
| |<-------------| | |
| | | | visit |
| | | |<----------|
| | | |---------->|
| | | | |
| | | | get peer |
| | | | list |
| | |<---------|-----------|
| | |----------|---------->|
| | | | |
| | | | |
| | | | |
Figure 3 Procedure
Firstly alias tracker obtains a list of N files which are downloaded
most often at the most popular Bittorent websites. The parameter N
can be adjusted according to the service ability of Alias tracker
(Another way is to get the files information that are downloaded most
often from the Web Cache servers which are deployed widely .Then
Alias tracker obtains the resource description files of above files
from Bittorent websites (such as .torrent files for BT).It may
cooperate with the original BT websites or simply act as normal
Bittorent client to get the description files. We change the original
tracker address in the .torrent files to the address of the alias
tracker (it is easy to be changed because it is plain text). Then the
new resource description files are issued to the resource website in
inner operator's network. The operator use DNS redirection [RFC2234]
or other application layer redirection to change the user request
from Bittorent website to the resource website in operator's network.
When users want to visit the original BT website, actually they will
visit the resource website in inner operator network. Users will
contact alias tracker through analyzing the .torrent file form the
resource website in operator's network.
zhang & liao Expires April 23, 2009 [Page 9]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
Obviously by this means inner nodes will request the Alias tracker
for file downloading. Alias tracker functions similar to BT Tracker
server It maintains the seed/leecher nodes lists that can provide
files data which are listed in the resource website in the home
network. And it will return related nodes list when end users request.
To further improve the downloading performance, an enhanced tracker
communication procedure between original tracker and alias tracker is
defined in ATTP to increase the amount of available seed/leechers.
Alias tracker gets the outside seed/leecher node list of the files
from BT tracker. Again this can be achieved by the proactive report
from the original tracker or reactive request as a normal P2P client.
When Alias tracker return seed/leecher nodes list, it will follow the
following policies:
a) If the amount of inner nodes of the ISP's network is enough, all
of the nodes that are returned by alias tracker are inner nodes.
b) If the amount of inner nodes is not enough it should return all
the inner nodes and some foreign nodes.
At last the end nodes will download the files from the seed nodes
returned by alias tracker.
4.3. The strategies of alias Tracker choosing seed nodes
4.3.1. According to the state of the network
Alias Tracker will monitor and record the operation state of current
network including network loads, network topology. When Alias Tracker
selects seed nodes, it will make the best choice according to all
above information.
zhang & liao Expires April 23, 2009 [Page 10]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
+-------------------------------------------+
| |
| ISP +---------+ |
| | Alias | |
| | Tracker | |
| | | |
| +---------+ |
| ^ ^ |
| /| |\ |
| / | | \ |
| / | | \ |
| +--------+ / | | \ +--------+ |
| | +----+ | / | | \ | +----+ | |
| | | DP | |/ | | \| | DP | | |
| | +----+ | | | | +----+ | |
| | +----+ | | | | +----+ | |
| | | U1 | | | | | | U2 | | |
| | +----+ | | | | +----+ | |
| +--------+ | | +--------+ |
| | | |
| | | |
| | | |
| +--------+ | | +--------+ |
| | +----+ | | | | +----+ | |
| | | DP | | | | | DP | | |
| | +----+ |------+ +------| +----+ | |
| | +----+ | | +----+ | |
| | | U4 | | | | U3 | | |
| | +----+ | | +----+ | |
| +--------+ +--------+ |
| |
+-------------------------------------------+
Figure 4 Sub-domain clustering network monitoring the traffic
According to the Figure 4, in a network such as an ISP network, Alias
Tracker will firstly select seed nodes which belong to its own network.
A network can be divided into several sub-domain networks which load
maybe different. So we provide a sub-domain clustering traffic
monitoring method. The details of the method are as follows: a network
is divided into various small sub-domain clustering networks which have
one or more DP (Detection Point) nodes. In the sub-domain networks, DPI
equipments can be used as DP nodes and responsible for monitoring the
sub-domain network traffic load, and calculate the sub-domain network's
traffic density:
Formula: Traffic density=Total of traffic for a period/Number of users
zhang & liao Expires April 23, 2009 [Page 11]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
For example, in an access network, DPI can monitor and calculate all of
the network traffic. We also can get the total number of the users
accessing to the network. As a result, the traffic density of the
network can be computed through the formula.
DP nodes will send information about the traffic density to the Alias
Tracker periodically. When Alias Tracker chooses seed nodes, it will
priority select nodes which belong to traffic density lower sub-domain
network. But in the lower traffic density sub-domain network, the
upstream bandwidth of the seed node maybe has been very small, and the
loads of the seed node are very heavy. As a result, Alias Tracker not
only concerns the traffic density, but also need to consider the seed
nodes' service capabilities.
+------------------------------------------------+
| |
| |
| | +-----+ |
| | | | |
| |------| DPI | |
| | +-----+ |
| | |
| | |
| +-------------------|--------------------+ |
| | | | |
| | +--------+ | |
| | | | | |
| | --->| BRAS |<--- | |
| | / +--------+ \ | |
| | / | | \ | |
| | / | | \ | |
| | / | | \ | |
| | / | | \ | |
| | +----+ +----+ | | +----+ +----+ | |
| | | U1 | | U2 |--+ +--| U3 | | U4 | | |
| | +----+ +----+ +----+ +----+ | |
| | | |
| +----------------------------------------+ |
+------------------------------------------------+
Figure 5 Accessing network works as a sub-domain network
For example, in Figure 4 sub-domain networks' traffic density: sub-
domain A < sub-domain B < sub-domain C < sub-domain D. Assuming that
seed nodes U1 and U2 are optional, but the seed node U1's available
zhang & liao Expires April 23, 2009 [Page 12]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
capabilities (such as upstream bandwidth, etc) are less than
U2's.Preference will be given to seed node U2 by Alias Tracker, despite
the density of sub-domain B is greater than sub-domain A's.
4.3.2. According to the seed node service capabilities
Each seed node has different capabilities. In addition to general
information, each seed node will report performance data to the Alias
Tracker periodically. The data may include, but are not limited to
these: the CPU's average utilization rate, the average memory usage
rate, available network bandwidth, and other information.
4.3.3. The connection strategy and economy of the AS
The AS business relationship of different network operators decide
the price of transferring a bit of data. Choosing a different network,
the inter-working billing rate is not the same. In this method, when
Alias Tracker selects seed nodes, the selection order is:
1) Selecting the seed nodes inside the AS;
2) Selecting the seed nodes in other AS which belong to the same
network operators;
3) Selecting the seed nodes in other network operators whose inter-
working billing rate is lower;
The business relationship of AS can obtained by operators or by
detection methods [CAIDA have done a lot of work in this area], which
is not within the scope of this invention.
Selection order is showed as the following:
1) AS;
2) Node capabilities;
3) The state of network congestion.
4.4. The process order of Alias Tracker selecting seed nodes
Alias Tracker implements all functions of the origin Tracker:
monitoring the current end users downloading resources; allocating
the other end users which are currently downloading the resources and
returning the peer list to the client, the specific selection process
are as follows:
zhang & liao Expires April 23, 2009 [Page 13]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
1) A network such as an ISP network, will be divided into several
sub-domain clustering networks. For example, an access network can
act as a sub-domain clustering network;
2) A DPI equipment will be deployed in the network export link
interface to monitor the sub-domain network traffic;
3) According to the total numbers of traffic and network users
obtained from DP(Detection Point) and BRAS, the network traffic
density can be calculated through the formula, further more the
network congestion situation can be got;
4) DP will send all the sub-domain traffic density values to the
Alias Tracker periodically;
5) At the same time, each node will send the node service
capabilities information to Alias Tracker, which include the average
CPU utilization rate, the average utilization rate of memory,
available network bandwidth, and some other information;
6) Pre-set the configure file on the Alias Tracker, which indicate
the connection strategy and economic billing rate of AS;
7) When a node sends a request for seed nodes list to Alias Tracker,
it will integrate traffic density, nodes service capabilities, and AS
information, comprehensive judgment to choose the low traffic density,
strong capacity nodes as seed nodes;
8) Alias Tracker returns the peer list to the requesting node;
4.5. Advantages of ATTP
ATTP just needs some alias trackers and website built up by the
operator and only need configure DNS re-direction mechanism to
achieve above goals. The cost is low and the deployment is simple. It
can make operators keep independence and privacy when making full use
of operator's advantages. And it don't add more burdens for the P2P
application providers to make node and request localization decision
and it make increase the application performance(esp. decreasing
latency and increasing throughput by localization). So it's a
double-will game.
5. Security Considerations
This document does not currently introduce security considerations.
zhang & liao Expires April 23, 2009 [Page 14]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
6. IANA Considerations
This document does not specify IANA considerations.
7. Conclusions
This document describes a novel method to reduce cross-ISP traffic in
P2P tracker-based applications such as Bittorrent and PPlive.
Through cooperating ISP with P2P application providers, ATTP acts as
a mirror P2P application provider in its home network to lower
cross-network traffic.
8. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
zhang & liao Expires April 23, 2009 [Page 15]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997.
[3] [RFC2234]M. Crawford, "Non-Terminal DNS Name Redirection",
August 1999.
8.2. Informative References
[4] J.A. Pouwelse, P. Garbacki, D.H.J. Epema, H.J. Sips,THE
BITTORRENT P2P FILE-SHARING SYSTEM: MEASUREMENTS AND
ANALYSIS,IPTPS 2005.
[5] www.pplive.com.
Author's Addresses
Yunfei Zhang
China Mobile Communications Corporation
Phone: +86 10 66006688
Email: zhangyunfei@chinamobile.com
Hongluan liao
China Mobile Communications Corporation
Phone: +86 10 66006688
Email: liaohongluan@chinamobile.com
Naibao ZHOU
China Mobile Communications Corporation
Phone: +86 10 66006688
Email: zhounaibao@gmail.com
zhang & liao Expires April 23, 2009 [Page 16]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
zhang & liao Expires April 23, 2009 [Page 17]
Internet-Draft P2P Traffic Localization by Alias Tracker October 2008
zhang & liao Expires April 23, 2009 [Page 18]