draft-ietf-p2psip-rpr-06.txt   draft-ietf-p2psip-rpr-07.txt 
P2PSIP N. Zong P2PSIP N. Zong
Internet-Draft X. Jiang Internet-Draft X. Jiang
Intended status: Standards Track R. Even Intended status: Standards Track R. Even
Expires: November 08, 2013 Huawei Technologies Expires: December 11, 2013 Huawei Technologies
Y. Zhang Y. Zhang
May 07, 2013
June 09, 2013
An extension to RELOAD to support Relay Peer Routing An extension to RELOAD to support Relay Peer Routing
draft-ietf-p2psip-rpr-06 draft-ietf-p2psip-rpr-07
Abstract Abstract
This document proposes an optional extension to RELOAD to support This document proposes an optional extension to RELOAD to support
relay peer routing mode. RELOAD recommends symmetric recursive relay peer routing mode. RELOAD recommends symmetric recursive
routing for routing messages. The new optional extension provides a routing for routing messages. The new optional extension provides a
shorter route for responses reducing the overhead on intermediate shorter route for responses reducing the overhead on intermediate
peers and describes the potential use cases where this extension can peers and describes the potential use cases where this extension can
be used. be used.
skipping to change at page 1, line 37 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 08, 2013. This Internet-Draft will expire on December 11, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. RPR . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. RPR . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Relay Peer Routing (RPR) . . . . . . . . . . . . . . 4 3.1.1. Relay Peer Routing (RPR) . . . . . . . . . . . . . . 4
3.2. Scenarios where RPR can be beneficial . . . . . . . . . . 5 3.2. Scenarios where RPR can be beneficial . . . . . . . . . . 5
3.2.1. Managed or closed P2P systems . . . . . . . . . . . . 5 3.2.1. Managed or closed P2P systems . . . . . . . . . . . . 5
3.2.2. Using bootstrap nodes as relay peers . . . . . . . . 6 3.2.2. Using bootstrap nodes as relay peers . . . . . . . . 5
3.2.3. Wireless scenarios . . . . . . . . . . . . . . . . . 6 3.2.3. Wireless scenarios . . . . . . . . . . . . . . . . . 6
4. Relationship between SRR and RPR . . . . . . . . . . . . . . 6 4. Relationship between SRR and RPR . . . . . . . . . . . . . . 6
4.1. How RPR works . . . . . . . . . . . . . . . . . . . . . . 6 4.1. How RPR works . . . . . . . . . . . . . . . . . . . . . . 6
4.2. How SRR and RPR work together . . . . . . . . . . . . . . 6 4.2. How SRR and RPR work together . . . . . . . . . . . . . . 6
5. Comparison on cost of SRR and RPR . . . . . . . . . . . . . . 7 5. Comparison on cost of SRR and RPR . . . . . . . . . . . . . . 6
5.1. Closed or managed networks . . . . . . . . . . . . . . . 7 5.1. Closed or managed networks . . . . . . . . . . . . . . . 7
5.2. Open networks . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Open networks . . . . . . . . . . . . . . . . . . . . . . 7
6. RPR extensions to RELOAD . . . . . . . . . . . . . . . . . . 8 6. RPR extensions to RELOAD . . . . . . . . . . . . . . . . . . 8
6.1. Basic requirements . . . . . . . . . . . . . . . . . . . 8 6.1. Basic requirements . . . . . . . . . . . . . . . . . . . 8
6.2. Modification to RELOAD message structure . . . . . . . . 8 6.2. Modification to RELOAD message structure . . . . . . . . 8
6.2.1. State-keeping flag . . . . . . . . . . . . . . . . . 8 6.2.1. State-keeping flag . . . . . . . . . . . . . . . . . 8
6.2.2. Extensive routing mode . . . . . . . . . . . . . . . 9 6.2.2. Extensive routing mode . . . . . . . . . . . . . . . 9
6.3. Creating a request . . . . . . . . . . . . . . . . . . . 9 6.3. Creating a request . . . . . . . . . . . . . . . . . . . 9
6.3.1. Creating a request for RPR . . . . . . . . . . . . . 10 6.3.1. Creating a request for RPR . . . . . . . . . . . . . 9
6.4. Request and response processing . . . . . . . . . . . . . 10 6.4. Request and response processing . . . . . . . . . . . . . 10
6.4.1. Destination peer: receiving a request and sending a 6.4.1. Destination peer: receiving a request and sending a
response . . . . . . . . . . . . . . . . . . . . . . 10 response . . . . . . . . . . . . . . . . . . . . . . 10
6.4.2. Sending peer: receiving a response . . . . . . . . . 11 6.4.2. Sending peer: receiving a response . . . . . . . . . 11
6.4.3. Relay peer processing . . . . . . . . . . . . . . . . 11 6.4.3. Relay peer processing . . . . . . . . . . . . . . . . 11
7. Discovery of relay peers . . . . . . . . . . . . . . . . . . 11 7. Discovery of relay peers . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9.1. A new RELOAD Forwarding Option . . . . . . . . . . . . . 12 9.1. A new RELOAD Forwarding Option . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Optional methods to investigate peer connectivity . 13 Appendix A. Optional methods to investigate peer connectivity . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
RELOAD [I-D.ietf-p2psip-base] recommends symmetric recursive routing RELOAD [I-D.ietf-p2psip-base] recommends symmetric recursive routing
(SRR) for routing messages and describes the extensions that would be (SRR) for routing messages and describes the extensions that would be
required to support additional routing algorithms. Other than SRR, required to support additional routing algorithms. Other than SRR,
two other routing options: direct response routing (DRR) and relay two other routing options: direct response routing (DRR) and relay
peer routing (RPR) are also discussed in Appendix A of [I-D.ietf- peer routing (RPR) are also discussed in Appendix A of [I-D.ietf-
p2psip-base]. As we show in section 3, RPR is advantageous over SRR p2psip-base]. As we show in section 3, RPR is advantageous over SRR
in some scenarios reducing load (CPU and link bandwidth) on in some scenarios reducing load (CPU and link bandwidth) on
intermediate peers. RPR works better in a network where relay peers intermediate peers. RPR works better in a network where relay peers
are provisioned in advance so that relay peers are publicly reachable are provisioned in advance so that relay peers are publicly reachable
in the P2P system. In other scenarios, using a combination of RPR in the P2P system. In other scenarios, using a combination of RPR
skipping to change at page 4, line 51 skipping to change at page 4, line 40
the source peer. In this section, we will provide detailed the source peer. In this section, we will provide detailed
information on RPR. information on RPR.
Note that the same illustrative settings can be found in DRR document Note that the same illustrative settings can be found in DRR document
[I-D.ietf-p2psip-drr]. [I-D.ietf-p2psip-drr].
3.1.1. Relay Peer Routing (RPR) 3.1.1. Relay Peer Routing (RPR)
If peer A knows it is behind a NAT or NATs, and knows one or more If peer A knows it is behind a NAT or NATs, and knows one or more
relay peers with whom they have a prior connections, peer A can try relay peers with whom they have a prior connections, peer A can try
RPR. Assume A is associated with relay peer R. When sending the RPR. Assume A is associated with relay peer R. When sending the
request, peer A includes information describing peer R transport request, peer A includes information describing peer R transport
address in the request. When peer X receives the request, peer X address in the request. When peer X receives the request, peer X
sends the response to peer R, which forwards it directly to Peer A on sends the response to peer R, which forwards it directly to Peer A on
the existing connection. Figure 1 illustrates RPR. Note that RPR the existing connection. Figure 1 illustrates RPR. Note that RPR
also allows a shorter route for responses compared to SRR, which also allows a shorter route for responses compared to SRR, which
means less overhead on intermediate peers. Establishing a connection means less overhead on intermediate peers. Establishing a connection
to the relay with TLS requires multiple round trips. Please refer to to the relay with TLS requires multiple round trips. Please refer to
Section 5 for cost comparison between SRR and RPR. Section 5 for cost comparison between SRR and RPR.
A B C D X R A B C D X R
skipping to change at page 7, line 5 skipping to change at page 6, line 42
peers comply with the same procedure as an ordinary peer to forward peers comply with the same procedure as an ordinary peer to forward
messages. The only difference is that there may be a larger traffic messages. The only difference is that there may be a larger traffic
burden on relay peers. Relay peers can decide whether to accept a burden on relay peers. Relay peers can decide whether to accept a
new connection based on their current burden. new connection based on their current burden.
4.2. How SRR and RPR work together 4.2. How SRR and RPR work together
RPR is not intended to replace SRR. It is better to use these two RPR is not intended to replace SRR. It is better to use these two
modes together to adapt to each peer's specific situation. Note that modes together to adapt to each peer's specific situation. Note that
the informative suggestions on how to transition between SRR and RPR the informative suggestions on how to transition between SRR and RPR
(e.g. compute success rate of RPR, fall back to SRR, etc) are the (e.g. compute success rate of RPR, fall back to SRR, etc) are the
same with that of DRR. Please refer to DRR document [I-D.ietf- same with that of DRR. Please refer to DRR document [I-D.ietf-
p2psip-drr] for more details. Similarly, the peer can decide whether p2psip-drr] for more details. Similarly, the peer can decide whether
to try RPR based on other information such as configuration file to try RPR based on other information such as configuration file
information. If a relay peer is provided by the service provider, information. If a relay peer is provided by the service provider,
peers MAY prefer RPR over SRR. peers MAY prefer RPR over SRR.
5. Comparison on cost of SRR and RPR 5. Comparison on cost of SRR and RPR
The major advantage of the use of RPR is that it reduces the number The major advantage of the use of RPR is that it reduces the number
of intermediate peers traversed by the response. By doing that, it of intermediate peers traversed by the response. By doing that, it
reduces the load on those peers' resources like processing and reduces the load on those peers' resources like processing and
communication bandwidth. communication bandwidth.
5.1. Closed or managed networks 5.1. Closed or managed networks
As described in Section 3, many P2P systems run in a closed or As described in Section 3, many P2P systems run in a closed or
managed environment (e.g. carrier networks) so that network managed environment (e.g. carrier networks) so that network
administrators would know that they could safely use RPR. administrators would know that they could safely use RPR.
The number of hops for a response in SRR and RPR are listed in the The number of hops for a response in SRR and RPR are listed in the
following table. Note that the same illustrative settings can be following table. Note that the same illustrative settings can be
found in DRR document [I-D.ietf-p2psip-drr]. found in DRR document [I-D.ietf-p2psip-drr].
Mode | Success | No. of Hops | No. of Msgs Mode | Success | No. of Hops | No. of Msgs
---------------------------------------------------- ----------------------------------------------------
SRR | Yes | log(N) | log(N) SRR | Yes | log(N) | log(N)
RPR | Yes | 2 | 2 RPR | Yes | 2 | 2
RPR(DTLS) | Yes | 2 | 7+2 RPR(DTLS) | Yes | 2 | 7+2
Table 1. Comparison of SRR and RPR in closed networks Table 1. Comparison of SRR and RPR in closed networks
From the above comparison, it is clear that: From the above comparison, it is clear that:
1) In most cases when N > 4 (2^2), RPR uses fewer hops than SRR. 1) In most cases when N > 4 (2^2), RPR uses fewer hops than SRR.
Using a shorter route means less overhead and resource usage on Using a shorter route means less overhead and resource usage on
intermediate peers, which is an important consideration for adopting intermediate peers, which is an important consideration for adopting
RPR in the cases where the resources such as CPU and bandwidth are RPR in the cases where the resources such as CPU and bandwidth are
limited, e.g. the case of mobile, wireless networks. limited, e.g. the case of mobile, wireless networks.
2) In the cases when N > 512 (2^9), RPR also uses fewer messages than 2) In the cases when N > 512 (2^9), RPR also uses fewer messages than
SRR. SRR.
3) In the cases when N < 512, RPR uses more messages than SRR (but 3) In the cases when N < 512, RPR uses more messages than SRR (but
still uses fewer hops than SRR). So the consideration on whether still uses fewer hops than SRR). So the consideration on whether
using RPR or SRR depends on other factors like using less resources using RPR or SRR depends on other factors like using less resources
(bandwidth and processing) from the intermediate peers. Section 4 (bandwidth and processing) from the intermediate peers. Section 4
provides use cases where RPR has better chance to work or where the provides use cases where RPR has better chance to work or where the
intermediary resources considerations are important. intermediary resources considerations are important.
skipping to change at page 13, line 6 skipping to change at page 12, line 37
Carlos Jesus Bernardos Cano for their constructive comments. Carlos Jesus Bernardos Cano for their constructive comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E.,
Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery
(RELOAD) Base Protocol", draft-ietf-p2psip-base-26 (work in (RELOAD) Base Protocol", draft-ietf-p2psip-base-26 (work in
progress), February 2013. progress), February 2013.
11.2. Informative References 11.2. Informative References
[ChurnDHT] Rhea, S., "Handling Churn in a DHT", Proceedings of the [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
USENIX Annual Technical Conference. Handling Churn in a DHT, June
2004.
[DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation of
Datagram TLS", 11th Network and Distributed System Security Symposium
(NDSS), 2004.
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using STUN", RFC5780, May 2010. Using STUN", RFC5780, May 2010.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. [I-D.ietf-p2psip-drr] Zong, N., Jiang, X., Even, R. and Zhang, Y.,
Srisuresh, "NAT Behavioral Requirements for TCP", RFC5382, October
2008.
[I-D.lowekamp-mmusic-ice-tcp-framework] Lowekamp, B. and A. Roach,
"A Proposal to Define Interactive Connectivity Establishment for the
Transport Control Protocol (ICE-TCP) as an Extensible Framework",
draft-lowekamp-mmusic-ice-tcp-framework-00 (work in progress),
October 2008.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787,
January 2007.
[I-D.ietf-p2psip-drr] Zong, N., Jiang, X., Even, R. and Zhang, Y.,
"An extension to RELOAD to support Direct Response Routing", draft- "An extension to RELOAD to support Direct Response Routing", draft-
ietf-p2psip-drr-05, April 2013. ietf-p2psip-drr-07, June 2013.
[I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis, [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis,
D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP",
draft-ietf-p2psip-concepts-04 (work in progress), October 2011. draft-ietf-p2psip-concepts-04 (work in progress), October 2011.
12. References 12. References
Appendix A. Optional methods to investigate peer connectivity Appendix A. Optional methods to investigate peer connectivity
This section is for informational purposes only for providing some This section is for informational purposes only for providing some
mechanisms that can be used when the configuration information does mechanisms that can be used when the configuration information does
not specify if RPR can be used. It summarizes some methods which can not specify if RPR can be used. It summarizes some methods which can
be used for a peer to determine its own network location compared be used for a peer to determine its own network location compared
 End of changes. 24 change blocks. 
57 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/