summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7264.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7264.txt')
-rw-r--r--doc/rfc/rfc7264.txt843
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc7264.txt b/doc/rfc/rfc7264.txt
new file mode 100644
index 0000000..d55e3f4
--- /dev/null
+++ b/doc/rfc/rfc7264.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) N. Zong
+Request for Comments: 7264 X. Jiang
+Category: Standards Track R. Even
+ISSN: 2070-1721 Huawei Technologies
+ Y. Zhang
+ CoolPad / China Mobile
+ June 2014
+
+
+ An Extension to the REsource LOcation And Discovery (RELOAD) Protocol
+ to Support Relay Peer Routing
+
+Abstract
+
+ This document defines an optional extension to the REsource LOcation
+ And Discovery (RELOAD) protocol to support the relay peer routing
+ mode. RELOAD recommends symmetric recursive routing for routing
+ messages. The new optional extension provides a shorter route for
+ responses, thereby reducing overhead on intermediate peers. This
+ document also describes potential cases where this extension can be
+ used.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7264.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zong, et al. Standards Track [Page 1]
+
+RFC 7264 P2PSIP RPR June 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 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 Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zong, et al. Standards Track [Page 2]
+
+RFC 7264 P2PSIP RPR June 2014
+
+
+Table of Contents
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................4
+ 3. Overview ........................................................5
+ 3.1. RPR ........................................................5
+ 3.2. Scenarios Where RPR Can Be Used ............................6
+ 3.2.1. Managed or Closed P2P Systems .......................6
+ 3.2.2. Using Bootstrap Nodes as Relay Peers ................7
+ 3.2.3. Wireless Scenarios ..................................7
+ 4. Relationship between SRR and RPR ................................7
+ 4.1. How RPR Works ..............................................7
+ 4.2. How SRR and RPR Work Together ..............................7
+ 5. RPR Extensions to RELOAD ........................................8
+ 5.1. Basic Requirements .........................................8
+ 5.2. Modification to RELOAD Message Structure ...................8
+ 5.2.1. Extensive Routing Mode ..............................8
+ 5.3. Creating a Request .........................................9
+ 5.3.1. Creating a Request for RPR ..........................9
+ 5.4. Request and Response Processing ............................9
+ 5.4.1. Destination Peer: Receiving a Request and
+ Sending a Response ..................................9
+ 5.4.2. Sending Peer: Receiving a Response .................10
+ 5.4.3. Relay Peer Processing ..............................10
+ 6. Overlay Configuration Extension ................................10
+ 7. Discovery of Relay Peers .......................................11
+ 8. Security Considerations ........................................11
+ 9. IANA Considerations ............................................11
+ 9.1. A New RELOAD Forwarding Option ............................11
+ 10. Acknowledgments ...............................................11
+ 11. References ....................................................12
+ 11.1. Normative References .....................................12
+ 11.2. Informative References ...................................12
+ Appendix A. Optional Methods to Investigate Peer Connectivity .....13
+ Appendix B. Comparison of Cost of SRR and RPR .....................14
+ B.1. Closed or Managed Networks .................................14
+ B.2. Open Networks ..............................................15
+
+1. Introduction
+
+ The REsource LOcation And Discovery (RELOAD) protocol [RFC6940]
+ recommends symmetric recursive routing (SRR) for routing messages and
+ describes the extensions that would be required to support additional
+ routing algorithms. In addition to SRR, two other routing options --
+ direct response routing (DRR) and relay peer routing (RPR) -- are
+ also discussed in Appendix A of [RFC6940]. As we show in Section 3,
+ RPR is advantageous over SRR in some scenarios in that RPR can reduce
+ load (CPU and link bandwidth) on intermediate peers. RPR works
+ better in a network where relay peers are provisioned in advance so
+
+
+
+Zong, et al. Standards Track [Page 3]
+
+RFC 7264 P2PSIP RPR June 2014
+
+
+ that relay peers are publicly reachable in the P2P system. In other
+ scenarios, using a combination of RPR and SRR together is more likely
+ to provide benefits than if SRR is used alone.
+
+ Note that in this document we focus on the RPR mode and its
+ extensions to RELOAD to produce a standalone solution. Please refer
+ to [RFC7263] for details on the DRR mode.
+
+ We first discuss the problem statement in Section 3. How to combine
+ RPR and SRR is presented in Section 4. An extension to RELOAD to
+ support RPR is defined in Section 5. Discovery of relay peers is
+ introduced in Section 7. Some optional methods to check peer
+ connectivity are introduced in Appendix A. In Appendix B, we give a
+ comparison of the cost of SRR and RPR in both managed and open
+ networks.
+
+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 [RFC2119].
+
+ We use terminology and definitions from the base RELOAD specification
+ [RFC6940] extensively in this document. We also use terms defined in
+ the NAT behavior discovery document [RFC5780]. Other terms used in
+ this document are defined inline when used and are also defined below
+ for reference.
+
+ Publicly Reachable: A peer is publicly reachable if it can receive
+ unsolicited messages from any other peer in the same overlay.
+ Note: "Publicly" does not mean that the peers must be on the
+ public Internet, because the RELOAD protocol may be used in a
+ closed network.
+
+ Relay Peer: A relay peer is a type of publicly reachable peer that
+ can receive unsolicited messages from all other peers in the
+ overlay and forward the responses from destination peers towards
+ the sender of the request.
+
+ Relay Peer Routing (RPR): "RPR" refers to a routing mode in which
+ responses to Peer-to-Peer SIP (P2PSIP) requests are sent by the
+ destination peer to a relay peer transport address that will
+ forward the responses towards the sending peer. For simplicity,
+ the abbreviation "RPR" is used in the rest of this document.
+
+
+
+
+
+
+
+Zong, et al. Standards Track [Page 4]
+
+RFC 7264 P2PSIP RPR June 2014
+
+
+ Symmetric Recursive Routing (SRR): "SRR" refers to a routing mode
+ in which responses follow the reverse path of the request to get
+ to the sending peer. For simplicity, the abbreviation "SRR" is
+ used in the rest of this document.
+
+ Direct Response Routing (DRR): "DRR" refers to a routing mode in
+ which responses to P2PSIP requests are returned to the sending
+ peer directly from the destination peer based on the sending
+ peer's own local transport address(es). For simplicity, the
+ abbreviation "DRR" is used in the rest of this document.
+
+3. Overview
+
+ RELOAD is expected to work under a great number of application
+ scenarios. The situations where RELOAD is to be deployed differ
+ greatly. For instance, some deployments are global, such as a
+ Skype-like system intended to provide public service, while others
+ run in small-scale closed networks. SRR works in any situation, but
+ RPR may work better in some specific scenarios.
+
+3.1. RPR
+
+ RELOAD is a simple request-response protocol. After sending a
+ request, a peer waits for a response from a destination peer. There
+ are several ways for the destination peer to send a response back to
+ the source peer. In this section, we will provide detailed
+ information on RPR. Note that the same types of illustrative
+ settings can be found in Appendix B.1 of [RFC7263].
+
+ If peer A knows it is behind a NAT or NATs and knows one or more
+ relay peers with whom they have had prior connections, peer A can try
+ RPR. Assume that peer A is associated with relay peer R. When
+ sending the request, peer A includes information describing peer R's
+ transport 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 the existing connection. Figure 1 illustrates RPR. Note
+ that RPR also allows a shorter route for responses compared to SRR;
+ this means less overhead on intermediate peers. Establishing a
+ connection to the relay with Transport Layer Security (TLS) requires
+ multiple round trips. Please refer to Appendix B for a cost
+ comparison between SRR and RPR.
+
+
+
+
+
+
+
+
+
+
+Zong, et al. Standards Track [Page 5]
+
+RFC 7264 P2PSIP RPR June 2014
+
+
+ A B C D X R
+ | Request | | | | |
+ |----------->| | | | |
+ | | Request | | | |
+ | |----------->| | | |
+ | | | Request | | |
+ | | |----------->| | |
+ | | | | Request | |
+ | | | |----------->| |
+ | | | | | Response |
+ | | | | |---------->|
+ | | | | Response | |
+ |<-----------+------------+------------+------------+-----------|
+ | | | | | |
+
+ Figure 1: RPR Mode
+
+ This technique relies on the relative population of peers such as
+ peer A that require relay peers, and peers such as peer R that are
+ capable of serving as relay peers. It also requires a mechanism to
+ enable peers to know which peers can be used as their relays. This
+ mechanism may be based on configuration -- for example, as part of
+ the overlay configuration, an initial list of relay peers can be
+ supplied. Another option is a response message in which the
+ responding peer can announce that it can serve as a relay peer.
+
+3.2. Scenarios Where RPR Can Be Used
+
+ In this section, we will list several scenarios where using RPR would
+ improve performance.
+
+3.2.1. Managed or Closed P2P Systems
+
+ As described in Section 3.2.1 of [RFC7263], many P2P systems run in a
+ closed or managed environment so that network administrators can
+ better manage their system. For example, the network administrator
+ can deploy several relay peers that are publicly reachable in the
+ system and indicate their presence in the configuration file. After
+ learning where these relay peers are, peers behind NATs can use RPR
+ with help from these relay peers. Peers MUST also support SRR in
+ case RPR fails.
+
+ Another usage is to install relay peers on the managed network
+ boundary, allowing external peers to send responses to peers inside
+ the managed network.
+
+
+
+
+
+
+Zong, et al. Standards Track [Page 6]
+
+RFC 7264 P2PSIP RPR June 2014
+
+
+3.2.2. Using Bootstrap Nodes as Relay Peers
+
+ Bootstrap nodes are typically publicly reachable in a RELOAD
+ architecture. As a result, one possible scenario would be to use the
+ bootstrap nodes as relay peers for use with RPR. A relay peer SHOULD
+ be publicly accessible and maintain a direct connection with its
+ client. As such, bootstrap nodes are well suited to play the role of
+ relay peers.
+
+3.2.3. Wireless Scenarios
+
+ In some mobile deployments, using RPR may help reduce radio battery
+ usage and bandwidth by the intermediate peers. The service provider
+ may recommend using RPR based on his knowledge of the topology.
+
+4. Relationship between SRR and RPR
+
+4.1. How RPR Works
+
+ Peers using RPR MUST maintain a connection with their relay peer(s).
+ This can be done in the same way as establishing a neighbor
+ connection between peers using the Attach method [RFC6940].
+
+ A requirement for RPR is that the source peer convey its relay peer's
+ (or peers') transport address(es) in the request so the destination
+ peer knows where the relay peers are and will send the response to a
+ relay peer first. The request MUST also include the requesting
+ peer's Node-ID or IP address, which enables the relay peer to route
+ the response back to the right peer.
+
+ Note that being a relay peer does not require that the relay peer
+ have more functionality than an ordinary peer. Relay peers comply
+ with the same procedure as an ordinary peer to forward messages. The
+ only difference is that there may be a larger traffic burden on relay
+ peers. Relay peers can decide whether to accept a new connection
+ based on their current burden.
+
+4.2. How SRR and RPR Work Together
+
+ 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
+ the informative suggestions for how to transition between SRR and RPR
+ are the same as those for DRR. Please refer to Section 4.2 of
+ [RFC7263] for more details. If a relay peer is provided by the
+ service provider, peers SHOULD prefer RPR over SRR. However, RPR
+ SHOULD NOT be used in the open Internet or if the administrator does
+
+
+
+
+
+Zong, et al. Standards Track [Page 7]
+
+RFC 7264 P2PSIP RPR June 2014
+
+
+ not feel he has enough information about the overlay network
+ topology. A new overlay configuration element specifying the usage
+ of RPR is defined in Section 6.
+
+5. RPR Extensions to RELOAD
+
+ Adding support for RPR requires extensions to the current RELOAD
+ protocol. In this section, we define the required extensions,
+ including extensions to message structure and message processing.
+
+5.1. Basic Requirements
+
+ All peers MUST be able to process requests for routing in SRR and MAY
+ support RPR routing requests.
+
+5.2. Modification to RELOAD Message Structure
+
+ RELOAD provides an extensible framework to accommodate future
+ extensions. In this section, we define an RPR routing option for the
+ extensive routing mode specified in [RFC7263]. The state-keeping
+ flag [RFC7263] is needed to support the RPR mode.
+
+5.2.1. Extensive Routing Mode
+
+ The new RouteMode value for RPR is defined below for the
+ ExtensiveRoutingModeOption structure:
+
+ enum {(0),DRR(1),RPR(2),(255)} RouteMode;
+ struct {
+ RouteMode routemode;
+ OverlayLinkType transport;
+ IpAddressPort ipaddressport;
+ Destination destinations<1..2^8-1>;
+ } ExtensiveRoutingModeOption;
+
+ Note that the DRR value in RouteMode is defined in [RFC7263].
+
+ RouteMode: refers to which type of routing mode is indicated to the
+ destination peer.
+
+ OverlayLinkType: refers to the transport type that is used to deliver
+ responses from the destination peer to the relay peer.
+
+ IpAddressPort: refers to the transport address that the destination
+ peer should use for sending responses. This will be a relay peer
+ address for RPR.
+
+
+
+
+
+Zong, et al. Standards Track [Page 8]
+
+RFC 7264 P2PSIP RPR June 2014
+
+
+ Destination: refers to the relay peer itself. If the routing mode is
+ RPR, then the destination contains two items: the relay peer's
+ Node-ID and the sending peer's Node-ID.
+
+5.3. Creating a Request
+
+5.3.1. Creating a Request for RPR
+
+ When using RPR for a transaction, the sending peer MUST set the
+ IGNORE-STATE-KEEPING flag in the ForwardingHeader. Additionally, the
+ peer MUST construct and include a ForwardingOption structure in the
+ ForwardingHeader. When constructing the ForwardingOption structure,
+ the fields MUST be set as follows:
+
+ 1) The type MUST be set to extensive_routing_mode.
+
+ 2) The ExtensiveRoutingModeOption structure MUST be used for the
+ option field within the ForwardingOption structure. The fields
+ MUST be defined as follows:
+
+ 2.1) routemode set to 0x02 (RPR).
+
+ 2.2) transport set as appropriate for the relay peer.
+
+ 2.3) ipaddressport set to the transport address of the relay
+ peer through which the sender wishes the message relayed.
+
+ 2.4) The destination structure MUST contain two values. The
+ first MUST be defined as type "node" and set with the
+ values for the relay peer. The second MUST be defined as
+ type "node" and set with the sending peer's own values.
+
+5.4. Request and Response Processing
+
+ This section gives normative text for message processing after RPR is
+ introduced. Here, we only describe the additional procedures for
+ supporting RPR. Please refer to [RFC6940] for RELOAD base
+ procedures.
+
+5.4.1. Destination Peer: Receiving a Request and Sending a Response
+
+ When the destination peer receives a request, it will check the
+ options in the forwarding header. If the destination peer cannot
+ understand the extensive_routing_mode option in the request, it MUST
+ attempt to use SRR to return an "Error_Unknown_Extension" response
+ (defined in Sections 6.3.3.1 and 14.9 of [RFC6940]) to the sending
+ peer.
+
+
+
+
+Zong, et al. Standards Track [Page 9]
+
+RFC 7264 P2PSIP RPR June 2014
+
+
+ If the routing mode is RPR, the destination peer MUST construct a
+ destination_list for the response with two entries as defined in
+ [RFC6940]. The first entry MUST be set to the relay peer's Node-ID
+ from the option in the request, and the second entry MUST be the
+ sending peer's Node-ID from the option in the request.
+
+ In the event that the routing mode is set to RPR and there are not
+ exactly two destinations, the destination peer MUST try to send an
+ "Error_Unknown_Extension" response (defined in Sections 6.3.3.1 and
+ 14.9 of [RFC6940]) to the sending peer using SRR.
+
+ After the peer constructs the destination_list for the response, it
+ sends the response to the transport address, which is indicated in
+ the ipaddressport field in the option using the specific transport
+ mode in the ForwardingOption. If the destination peer receives a
+ retransmit with SRR preference on the message it is trying to respond
+ to now, the responding peer SHOULD abort the RPR response and
+ use SRR.
+
+5.4.2. Sending Peer: Receiving a Response
+
+ Upon receiving a response, the peer follows the rules in [RFC6940].
+ If the sender used RPR and did not get a response until the timeout,
+ it MAY resend the message using either RPR (but with a different
+ relay peer, if available) or SRR.
+
+5.4.3. Relay Peer Processing
+
+ Relay peers are designed to forward responses to peers who are not
+ publicly reachable. For the routing of the response, this document
+ still uses the destination_list. The only difference from SRR is
+ that the destination_list is not the reverse of the via_list.
+ Instead, it is constructed from the forwarding option as described
+ below.
+
+ When a relay peer receives a response, it MUST follow the rules in
+ [RFC6940]. It receives the response, validates the message,
+ readjusts the destination_list, and forwards the response to the next
+ hop in the destination_list based on the connection table. There is
+ no added requirement for the relay peer.
+
+6. Overlay Configuration Extension
+
+ This document uses the new RELOAD overlay configuration element,
+ "route-mode", inside each "configuration" element, as defined in
+ Section 6 of [RFC7263]. The route mode MUST be "RPR".
+
+
+
+
+
+Zong, et al. Standards Track [Page 10]
+
+RFC 7264 P2PSIP RPR June 2014
+
+
+7. Discovery of Relay Peers
+
+ There are several ways to distribute information about relay peers
+ throughout the overlay. P2P network providers can deploy some relay
+ peers and advertise them in the configuration file. With the
+ configuration file at hand, peers can get relay peers to try RPR.
+ Another way is to consider the relay peer as a service; some service
+ advertisement and discovery mechanism can then also be used for
+ discovering relay peers -- for example, using the same mechanism as
+ that used in Traversal Using Relays around NAT (TURN) server
+ discovery as discussed in [RFC6940]. Another option is to let a peer
+ advertise its capability to be a relay in the response to an Attach
+ or Join [RFC6940].
+
+8. Security Considerations
+
+ The normative security recommendations of Section 13 of [RFC6940] are
+ applicable to this document. As a routing alternative, the security
+ part of RPR conforms to Section 13.6 of [RFC6940], which describes
+ routing security. RPR behaves like a DRR requesting node towards the
+ destination node. The RPR relay peer is not necessarily an arbitrary
+ node -- for example, a managed network, a bootstrap node, or a
+ configured relay peer; it should be a trusted node, because a trusted
+ node will be less of a risk, as outlined in Section 13 of [RFC6940].
+
+ In order to address possible DoS attacks, the relay peer SHOULD also
+ limit the number of maximum connections; this is required in order to
+ also reduce load on the relay peer, as explained in Section 4.1.
+
+9. IANA Considerations
+
+9.1. A New RELOAD Forwarding Option
+
+ A new RELOAD Forwarding Option type has been added to the "RELOAD
+ Forwarding Option Registry" defined in [RFC6940].
+
+ Code: 2
+ Forwarding Option: extensive_routing_mode
+
+10. Acknowledgments
+
+ David Bryan helped extensively with this document and helped provide
+ some of the text, analysis, and ideas contained here. The authors
+ would like to thank Ted Hardie, Narayanan Vidya, Dondeti Lakshminath,
+ Bruce Lowekamp, Stephane Bryant, Marc Petit-Huguenin, and Carlos
+ Jesus Bernardos Cano for their constructive comments.
+
+
+
+
+
+Zong, et al. Standards Track [Page 11]
+
+RFC 7264 P2PSIP RPR June 2014
+
+
+11. References
+
+11.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
+ H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
+ Base Protocol", RFC 6940, January 2014.
+
+ [RFC7263] Zong, N., Jiang, X., Even, R., and Y. Zhang, "An Extension
+ to the REsource LOcation And Discovery (RELOAD) Protocol
+ to Support Direct Response Routing", RFC 7263, June 2014.
+
+11.2. Informative References
+
+ [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
+ Self-Address Fixing (UNSAF) Across Network Address
+ Translation", RFC 3424, November 2002.
+
+ [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
+ Using Session Traversal Utilities for NAT (STUN)",
+ RFC 5780, May 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zong, et al. Standards Track [Page 12]
+
+RFC 7264 P2PSIP RPR June 2014
+
+
+Appendix A. Optional Methods to Investigate Peer Connectivity
+
+ This section is for informational purposes only and provides some
+ mechanisms that can be used when the configuration information does
+ not specify if RPR can be used. It summarizes some methods that can
+ be used by a peer to determine its own network location compared with
+ NAT. These methods may help a peer to decide which routing mode it
+ may wish to try. Note that there is no foolproof way to determine
+ whether a peer is publicly reachable, other than via out-of-band
+ mechanisms. This document addresses UNilateral Self-Address Fixing
+ (UNSAF) [RFC3424] considerations by specifying a fallback plan to SRR
+ [RFC6940]. SRR is not an UNSAF mechanism. This document does not
+ define any new UNSAF mechanisms.
+
+ For RPR to function correctly, a peer may attempt to determine
+ whether it is publicly reachable. If it is not, RPR may be chosen to
+ route the response with help from relay peers, or the peers should
+ fall back to SRR. NATs and firewalls are two major contributors to
+ preventing RPR from functioning properly. There are a number of
+ techniques by which a peer can get its reflexive address on the
+ public side of the NAT. After obtaining the reflexive address, a
+ peer can perform further tests to learn whether the reflexive address
+ is publicly reachable. If the address appears to be publicly
+ reachable, the peer to which the address belongs can be a candidate
+ to serve as a relay peer. Peers that are not publicly reachable may
+ still use RPR to shorten the response path, with help from relay
+ peers.
+
+ Some conditions that are unique in P2PSIP architecture could be
+ leveraged to facilitate the tests. In a P2P overlay network, each
+ peer has only a partial view of the whole network and knows of a few
+ peers in the overlay. P2P routing algorithms can easily deliver a
+ request from a sending peer to a peer with whom the sending peer has
+ no direct connection. This makes it easy for a peer to ask other
+ peers to send unsolicited messages back to the requester.
+
+ The approaches for a peer to get the addresses needed for further
+ tests, as well as the test for learning whether a peer may be
+ publicly reachable, are the same as those for DRR. Please refer to
+ Appendix A of [RFC7263] for more details.
+
+
+
+
+
+
+
+
+
+
+
+Zong, et al. Standards Track [Page 13]
+
+RFC 7264 P2PSIP RPR June 2014
+
+
+Appendix B. Comparison of Cost of SRR and RPR
+
+ The major advantage of using RPR is that it reduces the number of
+ intermediate peers traversed by the response. This reduces the load,
+ such as processing and communication bandwidth, on those peers'
+ resources.
+
+B.1. Closed or Managed Networks
+
+ As described in Section 3, many P2P systems run in a closed or
+ managed environment (e.g., carrier networks), so network
+ administrators would know that they could safely use RPR.
+
+ The number of hops for a response in SRR and in RPR are listed in the
+ following table. Note that the same types of illustrative settings
+ can be found in Appendix B.1 of [RFC7263].
+
+ Mode | Success | No. of Hops | No. of Msgs
+ ------------------------------------------------
+ SRR | Yes | log(N) | log(N)
+ RPR | Yes | 2 | 2
+ RPR (DTLS) | Yes | 2 | 7+2
+
+ Table 1: Comparison of SRR and RPR in Closed Networks
+
+ From the above comparison, it is clear that:
+
+ 1) In most cases when the number of peers (N) > 4 (2^2), RPR uses
+ fewer hops than SRR. Using a shorter route means less overhead
+ and resource usage on intermediate peers, which is an important
+ consideration for adopting RPR in the cases where such resources
+ as CPU and bandwidth are limited, e.g., the case of mobile,
+ wireless networks.
+
+ 2) In the cases when N > 512 (2^9), RPR also uses fewer messages
+ than SRR.
+
+ 3) In the cases when N < 512, RPR uses more messages than SRR (but
+ still uses fewer hops than SRR), so the consideration of whether
+ to use RPR or SRR depends on other factors such as using less
+ resources (bandwidth and processing) from the intermediate peers.
+ Section 4 provides use cases where RPR has a better chance of
+ working or where the considerations of intermediary resources are
+ important.
+
+
+
+
+
+
+
+Zong, et al. Standards Track [Page 14]
+
+RFC 7264 P2PSIP RPR June 2014
+
+
+B.2. Open Networks
+
+ In open networks (e.g., the Internet) where RPR is not guaranteed to
+ work, RPR can fall back to SRR if it fails after trial, as described
+ in Section 4.2. Based on the same settings as those listed in
+ Appendix B.1, the number of hops, as well as the number of messages
+ for a response in SRR and RPR, are listed in the following table:
+
+ Mode | Success | No. of Hops | No. of Msgs
+ ----------------------------------------------------------------
+ SRR | Yes | log(N) | log(N)
+ RPR | Yes | 2 | 2
+ | Fail & fall back to SRR | 2+log(N) | 2+log(N)
+ RPR (DTLS) | Yes | 2 | 7+2
+ | Fail & fall back to SRR | 2+log(N) | 9+log(N)
+
+ Table 2: Comparison of SRR and RPR in Open Networks
+
+ From the above comparison, it can be observed that trying to first
+ use RPR could still provide an overall number of hops lower than
+ directly using SRR. The detailed analysis is the same as that for
+ DRR and can be found in [RFC7263].
+
+Authors' Addresses
+
+ Ning Zong
+ Huawei Technologies
+
+ EMail: zongning@huawei.com
+
+
+ Xingfeng Jiang
+ Huawei Technologies
+
+ EMail: jiang.x.f@huawei.com
+
+
+ Roni Even
+ Huawei Technologies
+
+ EMail: roni.even@mail01.huawei.com
+
+
+ Yunfei Zhang
+ CoolPad / China Mobile
+
+ EMail: hishigh@gmail.com
+
+
+
+
+Zong, et al. Standards Track [Page 15]
+