P2PSIP G. Li Internet Draft L. Le Intended status: Standards Track N. Zhou Expires: January 6, 2009 China Mobile July 6, 2009 Traffic localization for RELOAD draft-li-p2psip-localization-00.txt 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 6, 2009. 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. Abstract This document describes the traffic problems due to randomly distributed data storage in P2PSIP overlay, identifies the traffic Li Expires January 6, 2009 [Page 1] Internet-Draft Traffic localization for RELOAD July 2009 localization requirements, and then proposes an overlay construction and data storage mechanism to implement traffic localization for REsource LOcation And Discovery (RELOAD). Specifically, it's proposed to add location indicator to the Peer node ID, for example, the beginning 5 bit hash ID stands for the peer location, and user data with the location indication shall be possible to be stored in local peer, thus to achieve traffic localization, reduce backbone network traffic, and improve the efficiency and QoS of the whole network. Table of Contents 1. Introduction................................................2 2. Terminology.................................................2 3. Requirements................................................3 3.1. Problem statement.......................................3 3.2. Requirements...........................................3 3.3. Proposal...............................................4 4. Acknowledgement.............................................5 5. Security Considerations......................................5 6. IANA Considerations.........................................5 7. References..................................................5 7.1. Normative References....................................5 7.2. Informative References..................................6 1. Introduction In the RELOAD mechanism, user data are stored in pees in a randomly distributed manner. It doesn't take into account the geographical location information in data storage, which is not conducive to achieve traffic localization. Our approach is to add the geographical location information in the Node ID, when user data is stored, the appropriate local peer will be selected to store the data with the consideration of the location indication of user data. When a client initiates a query for user data, the client can retrieve data from the local peer, so that traffic could be reduced in the backbone network, and thus to achieve traffic localization. 2. Terminology 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]. We use the terminology and definitions from Concepts and Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base Protocol [I-D.ietf-p2psip-base] extensively in this document. Li Expires January 6, 2009 [Page 2] Internet-Draft Traffic localization for RELOAD July 2009 3. Requirements 3.1. Problem statement As we can see in the RELOAD Base protocol [I-D.ietf-p2psip-base], A RELOAD Overlay Instance consists of a set of nodes arranged in a partly connected graph. Each node in the overlay is assigned a numeric Node-ID which, together with the specific overlay algorithm in use, determines its position in the graph and the set of nodes it connects to. The RELOAD network is not only a messaging network, but also a storage network. Records are stored under numeric addresses which occupy the same space as node identifiers. Nodes are responsible for storing the data associated with some set of addresses as determined by their Node-ID. However, the mechanism of data storage and retrieval may be not good enough. Though each node in the overlay is assigned a numeric Node-ID, the Node-ID does not include geographical location information. When users' data are stored in the overlay, the peer storing user's data may be far away from the location of the users. For a peer-to-peer telephony service (see "A SIP Usage for RELOAD draft-ietf-p2psip-sip- 01"), It's estimated that the ratio between local calls and long distance/roaming calls is about 7:3, in which inter-provincial long- distance calls almost account for half of the long distance/roaming calls. However, inter-provincial bandwidth is much narrower than inner-provincial bandwidth. If users' data were randomly stored in P2PSIP overlay, most of users' data retrieval and updates would go through inter-provincial backbone network, which may overload backbone and cause traffic congestion. For example, for the user Bob in Beijing, his related subscription data might be stored in a peer in other location, e.g., Shanghai. However, other users in Beijing have more probabilities to access Bob's data, because according to telephony service characteristics most of calls towards or from Bob are initiated in Beijing. Therefore, if Bob's data is stored and retrieved from a remote peer/client, it's obvious that the traffic over the backbone network might be increased. For example, for China Mobile the traffic over backbone network is estimated to reach 3~10 Gbps. 3.2. Requirements The data storage in the RELOAD overlay might be randomly distributed. The location of data storage is based on the overlay algorithm. According to the hash algorithm, data will be stored in the Li Expires January 6, 2009 [Page 3] Internet-Draft Traffic localization for RELOAD July 2009 responsible peer which node ID is closest to the hash ID. From the above analysis, this approach might increase backbone traffic and easily overload the backbone network. To reduce backbone traffic burden, it's essential to introduce the mechanism to implement traffic localization. Specifically, it's worthwhile to take into account peers and users' location information when the P2PSIP overlay is constructed. Thus, when a user wants to store his/her data in the P2PSIP overlay, a local peer node will be selected to store user data according to a predefined policy. As a result, user client can retrieve data directly from local peer to achieve traffic localization. 3.3. Proposal Upon constructing P2PSIP overlay, part of peers' NodeID stands for where it comes from (e.g. the first 5 digits of NodeID). The location information of peers could be pre-configured by peer itself or assigned by the bootstrap server according to some static information (e.g. IP Address of Peers). And the rest of digits of NodeID are still constituted by the specific hash algorithm. When users' data is stored in P2PSIP overlay, it is required to constitute its key taking into account its location information (e.g. the first 5 digits of key stands for where the data comes from). Therefore, a geographically close peer will be selected to store the users' data. An example is showed in the following figure: Node 10001+Hash(IP) +-------+ +------| ND |------+ | +-------+ | Node 10004+Hash(IP)| |Node 10002+Hash(IP) +------+ +------+ +---| CA | | NY |---+ | +------+ +------+ | | | | | +-------+ | +-------+ | +--------+ |Client1| +------| TX |------+ |Client2 | +-------+ +-------+ +--------+ Node 10003+Hash(IP) Li Expires January 6, 2009 [Page 4] Internet-Draft Traffic localization for RELOAD July 2009 Figure 1 Example of traffic localization implementation. The P2PSIP overlay is constituted by four peers, i.e. ND(Located in North Dakota) / NY(Located in New York) / TX(Located in Texas) / CA(Located in California) node. The beginning 5 bit of NodeID stands for geographical location, for example, the numeric 10001 indicates North Dakota state. It's assumed that Client 1 is located in California and Client 2 is located in New York. When Client 1 or Client 2 tends to store user data, it will take into account its geographical location respectively. For example, when Client 1 in California stores his data in the overlay, its key will be assigned to 10004 in the first 5 digits of its NodeID. As a result, the will be stored to the local peer (i.e. CA). When any client initiates a query for Client 1's data, the data will be retrieved from peer CA. According to the previous analysis, the number of queries in California is much larger than that in other regions, so that backbone traffic between those regions could be reduced to some extent. 4. Acknowledgement The authors thank the review and valuable comments from Yunfei Zhang. This draft is generated as an output of DSN project, which is core network evolution of china mobile. 5. Security Considerations Security consideration please reference that in the draft of Sip usage of RELOAD [I-D.draft-ietf-p2psip-base]. We have no more consideration on security issues. 6. IANA Considerations None 7. References 7.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. Li Expires January 6, 2009 [Page 5] Internet-Draft Traffic localization for RELOAD July 2009 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base- 02 (work in progress), March 2009.1997. [I-D.draft-ietf-p2psip-sip] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, ''A SIP Usage for RELOAD'' draft-ietf-p2psip-sip-01,(work in progress), March 2009. 7.2. Informative References [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,June 1999. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", draft-ietf-p2psip-concepts-02 (work in progress), July 2008. Li Expires January 6, 2009 [Page 6] Internet-Draft Traffic localization for RELOAD July 2009 Authors' Addresses Gang Li China Mobile Phone: +86 13501279120 Email: ligangyf@chinamobile.com Lifeng Le China Mobile Phone: +86 13910019925 Email: lelifeng@chinamobile.com Naibao Zhou China Mobile Phone: +86 13811604066 Email: zhounaibao@gmail.com Li Expires January 6, 2009 [Page 7]