RFC 7263
An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing
An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing 🦋
okay bestie, RFC 7263 is an Internet Standards Track document from the IETF 💅 It was published in June 2014 and has ISSN 2070-1721. The authors are N. Zong, X. Jiang, and R. Even from Huawei Technologies, plus Y. Zhang from CoolPad / China Mobile 👑 It's about giving RELOAD a faster route back for responses 🚀
Abstract 💖
this doc defines an optional extension to RELOAD (REsource LOcation And Discovery) that supports the direct response routing mode 🎀 RELOAD recommends symmetric recursive routing for routing messages. the new optional extension gives responses a shorter route, so there's less overhead on intermediate peers ✨ it also describes possible 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/rfc7263.
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.
Table of Contents 📚
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Overview ........................................................5
3.1. SRR and DRR ................................................5
3.1.1. Symmetric Recursive Routing (SRR) ...................6
3.1.2. Direct Response Routing (DRR) .......................6
3.2. Scenarios Where DRR Can Be Used ............................7
3.2.1. Managed or Closed P2P Systems .......................7
3.2.2. Wireless Scenarios ..................................8
4. Relationship between SRR and DRR ................................8
4.1. How DRR Works ..............................................8
4.2. How SRR and DRR Work Together ..............................8
5. DRR Extensions to RELOAD ........................................9
5.1. Basic Requirements .........................................9
5.2. Modification to RELOAD Message Structure ...................9
5.2.1. State-Keeping Flag ..................................9
5.2.2. Extensive Routing Mode .............................10
5.3. Creating a Request ........................................11
5.3.1. Creating a Request for DRR .........................11
5.4. Request and Response Processing ...........................11
5.4.1. Destination Peer: Receiving a Request and
Sending a Response .................................11
5.4.2. Sending Peer: Receiving a Response .................12
6. Overlay Configuration Extension ................................12
7. Security Considerations ........................................12
8. IANA Considerations ............................................13
8.1. A New RELOAD Forwarding Option ............................13
8.2. A New IETF XML Registry ...................................13
9. Acknowledgments ................................................13
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................14
Appendix A. Optional Methods to Investigate Peer Connectivity .....15
A.1. Getting Addresses to Be Used as Candidates for DRR .........15
A.2. Public Reachability Test ...................................16
Appendix B. Comparison of Cost of SRR and DRR .....................17
B.1. Closed or Managed Networks .................................17
B.2. Open Networks ..............................................191. Introduction ✨
the REsource LOcation And Discovery (RELOAD) protocol [RFC6940] recommends symmetric recursive routing (SRR) for routing messages, and it describes the extensions that would be required to support additional routing algorithms 💜 Besides 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, DRR beats SRR in some scenarios because DRR can reduce load (CPU and link bandwidth) on intermediate peers 🔥 For example, in a closed network where every peer is in the same address realm, DRR performs better than SRR 👑 In other scenarios, using DRR and SRR together is more likely to provide benefits than using SRR alone 🫶
Note that this document focuses on the DRR mode and its extensions to RELOAD, so it can stand on its own 🦋 For details on the RPR mode, check [RFC7264] 🎀
We first discuss the problem statement in Section 3. How to combine DRR and SRR is presented in Section 4. An extension to RELOAD that supports DRR is defined in Section 5. Some optional methods to check peer connectivity are introduced in Appendix A. In Appendix B, we compare the cost of SRR and DRR 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. 🌍
- Direct Response Routing (DRR): "DRR" refers to a routing mode in which responses to Peer-to-Peer SIP (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. 🦋
- 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. 🔁
- Relay Peer Routing (RPR): "RPR" refers to a routing mode in which responses to P2PSIP requests are sent by the destination peer to the transport address of a relay peer, and that relay peer forwards the responses toward the sending peer. For simplicity, the abbreviation "RPR" 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 gets deployed differ a lot. For instance, some deployments are global, like a Skype-like system meant to provide a public service, while others run in small-scale closed networks 🏠 SRR works in any situation, but DRR may work better in some specific scenarios ✨
3.1. SRR and DRR 💜
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'll cover the details of two routing modes: SRR and DRR 🎀
Some assumptions are made in the illustrations that follow:
- Peer A sends a request destined to a peer who is the responsible peer for a Resource-ID k.
- Peer X is the root peer responsible for Resource-ID k.
- The intermediate peers for the path from A to X are peers B, C, and D.
3.1.1. Symmetric Recursive Routing (SRR) 🦋
okay so for SRR, when peer A's request hits an intermediate peer (B, C, or D), each intermediate peer adds info about whoever sent them the request into the Via List, as described in RELOAD [RFC6940] 📋 Because of that, the destination peer X knows the exact path the request took 🗺️ Then X sends the response back the same way by building a Destination List from the Via List in the request. Figure 1 illustrates SRR 💅
A B C D X
| Request | | | |
|----------->| | | |
| | Request | | |
| |----------->| | |
| | | Request | |
| | |----------->| |
| | | | Request |
| | | |----------->|
| | | | |
| | | | Response |
| | | |<-----------|
| | | Response | |
| | |<-----------| |
| | Response | | |
| |<-----------| | |
| Response | | | |
|<-----------| | | |
| | | | |
Figure 1: SRR ModeSRR works in any situation, especially when there are NATs or firewalls 🛡️ The downside is that the message takes several hops to get back to the peer, which bumps up bandwidth usage and the CPU/battery load on multiple peers 🔋 ngl that's the part that makes DRR look so cute 🥹
3.1.2. Direct Response Routing (DRR) 🦋
okay so in DRR, peer X gets the request from peer A through B, C, and D, just like in SRR 🫶 but here's the twist: X sends the response straight back to A using A's local transport address 💅. The response skips the middle peers entirely. Figure 2 shows it. A shorter route means way less overhead on the intermediate peers, which is huge for wireless networks where CPU and uplink bandwidth are limited 🔋. For example, with no NATs, or if the NAT does endpoint-independent filtering, this is the optimal routing technique 👑. Also ngl, setting up a secure connection takes multiple round trips, so keep that in mind 💀. Check Appendix B for a cost comparison between SRR and DRR 🧚.
A B C D X
| Request | | | |
|----------->| | | |
| | Request | | |
| |----------->| | |
| | | Request | |
| | |----------->| |
| | | | Request |
| | | |----------->|
| | | | |
| | | | Response |
|<-----------+------------+------------+------------|
| | | | |
Figure 2: DRR Mode3.2. Scenarios Where DRR Can Be Used ✨
This section lists a few scenarios where DRR would work and shows when the extra efficiency is totally worth it 💖.
3.2.1. Managed or Closed P2P Systems 🌸
The stuff that makes P2P tech so attractive, like no need for centralized servers, self-organization, etc., is just as good for managed systems as it is for unmanaged ones 🙌. Lots of these systems run on private networks where peers are in the same address realm and/or can route straight to each other. In that case, the network admin can set a DRR preference in the peer's configuration file. Peers in that kind of system should always try DRR first, but peers MUST also support SRR in case DRR fails 🫠. While the responding peer is setting up a direct connection with the sending peer, if it gets a request with SRR as the preferred routing mode (or it fails to set up the direct connection), the responding peer SHOULD NOT use DRR and should switch to SRR instead. The simple policy is to try DRR and, if that fails, switch to SRR for all connections. A finer-grained policy is to keep a list of unreachable peers based on DRR attempts, then only use SRR for those peers. So why bother with DRR? Network stability 🦋! It puts less overhead on the intermediate peers, since they won't be routing the responses. They route fewer messages and save CPU and link bandwidth 💅.
3.2.2. Wireless Scenarios 📱
In some mobile deployments, DRR can help cut radio battery usage and the bandwidth used by intermediate peers 🔋. The service provider may recommend DRR based on their knowledge of the topology 🍓.
4. Relationship between SRR and DRR 💖
4.1. How DRR Works 🧚
DRR is super simple 💅. The only requirement is that source peers give their potential (publicly reachable) transport address to the destination peers, so the destination knows where to send the response. Responses go straight to the requesting peer.
4.2. How SRR and DRR Work Together 🫶
DRR isn't meant to replace SRR. It's better to use both together so each peer can adapt to its own situation. This section has some informative suggestions for switching between routing modes in RELOAD.
According to [RFC6940], SRR MUST be supported. An overlay MAY be configured to use alternative routing algorithms, and alternative routing algorithms MAY be selected on a per-message basis. That means a node in an overlay that supports SRR and some other routing algorithm -- for example, DRR -- might use SRR some of the time and DRR some of the time. A node joining the overlay should get its preferred routing mode from the configuration file. If an overlay runs within a private network and all peers in the system can reach each other directly, peers MAY send most of the transactions with DRR. However, DRR SHOULD NOT be used on the open Internet, or if the administrator doesn't feel they have enough information about the overlay network topology. A new overlay configuration element specifying the usage of DRR is defined in Section 6.
Alternatively, a peer can collect statistical data on the success of the different routing modes based on previous transactions and keep a list of non-reachable addresses. Based on this data, the peer will have a clearer view of the success rate of different routing modes. In addition to data on the success rate, the peer can also get data of finer granularity -- for example, the number of retransmissions the peer needs to achieve a desirable success rate.
A typical strategy for the peer is as follows. A peer chooses to start with DRR based on the configuration. Based on the success rate as indicated by statistics on lost messages or by responses that used DRR, the peer can either continue to offer DRR first or switch to SRR. Note that a peer should use the DRR success statistics to decide whether to continue using DRR or fall back to SRR. Making such a decision per specific connection is not recommended; this should be an application decision.
5. DRR Extensions to RELOAD 🎀
Adding support for DRR 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 DRR routing requests.
5.2. Modification to RELOAD Message Structure 🧩
RELOAD provides an extensible framework to accommodate future extensions. In this section, we define a ForwardingOption structure to support DRR mode. We also present a state-keeping flag to tell intermediate peers if they're allowed to not maintain state for a transaction.
5.2.1. State-Keeping Flag 🚩
RELOAD allows intermediate peers to maintain state in order to implement SRR -- for example, for implementing hop-by-hop retransmission. If DRR is used, the response will not follow the reverse path, and the state in the intermediate peers won't be cleared until that state expires. To deal with this, we define a new flag, the state-keeping flag, in the ForwardingOption structure to indicate whether state-keeping is required in the intermediate peers.
Flag: 0x08 IGNORE-STATE-KEEPING
If IGNORE-STATE-KEEPING is set, any peer receiving this message but who is not the destination of the message SHOULD forward the message with the full Via List and SHOULD NOT maintain any internal state.
5.2.2. Extensive Routing Mode 🌈
This document introduces a new forwarding option for an extensive routing mode. This option conforms to the description in Section 6.3.2.3 of [RFC6940].
We first define a new type for the new option, extensive_routing_mode:
The option value that defines the ExtensiveRoutingModeOption structure is illustrated below:
enum {(0),DRR(1),(255)} RouteMode;
struct {
RouteMode routemode;
OverlayLinkType transport;
IpAddressPort ipaddressport;
Destination destinations<1..2^8-1>;
} ExtensiveRoutingModeOption;The above structure reuses the OverlayLinkType, Destination, and IpAddressPort structures as defined in Sections 6.5.1.1, 6.3.2.2, and 6.3.1.1 of [RFC6940], respectively.
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 sending peer.
IpAddressPort: refers to the transport address that the destination peer will use for sending responses. This will be a sending peer address for DRR.
Destination: refers to the sending peer itself. If the routing mode is DRR, then the destination only contains the sending peer's Node-ID.
5.3. Creating a Request 📮
5.3.1. Creating a Request for DRR 💌
When using DRR for a transaction, the sending peer MUST set the IGNORE-STATE-KEEPING flag in the ForwardingHeader. The peer MUST also construct and include a ForwardingOption structure in the ForwardingHeader. When constructing the ForwardingOption structure, the fields MUST be set as follows:
- The type MUST be set to
extensive_routing_mode. - The
ExtensiveRoutingModeOptionstructure MUST be used for the option field within theForwardingOptionstructure. The fields MUST be defined as follows:- 2.1:
routemodeset to0x01(DRR). - 2.2:
transportset as appropriate for the sender. - 2.3:
ipaddressportset to the peer's associated transport address. - 2.4: The destination structure MUST contain one value, defined as type "node" and set with the sending peer's own values.
- 2.1:
5.4. Request and Response Processing 🎬
This section gives normative text for message processing after DRR is introduced. Here, we only describe the additional procedures for supporting DRR. 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.
If the routing mode is DRR, the destination peer MUST construct the Destination List for the response with only one entry, using the requesting peer's Node-ID from the Via List in the request as the value.
In the event that the routing mode is set to DRR and there is not exactly one destination, the destination peer MUST try to return 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 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 now trying to respond to, the responding peer SHOULD abort the DRR response and use SRR.
5.4.2. Sending Peer: Receiving a Response 📨
Upon receiving a response, the peer follows the rules in [RFC6940]. The peer SHOULD note if DRR worked, in order to decide whether to offer DRR again. If the peer does not receive a response until the timeout, it SHOULD resend the request using SRR.
6. Overlay Configuration Extension ✨
okay so this doc is basically adding ONE new thing to the RELOAD overlay config (see Section 11.1 of [RFC6940]) 🎀 and that thing is a route-mode element that goes inside every configuration element. it's giving tiny but mighty 💅
the RELAX NG (Compact Regular Language for XML Next Generation) grammar for it looks like this:
namespace route-mode = "urn:ietf:params:xml:ns:p2p:route-mode"
parameter &= element route-mode:mode { xsd:string }?bestie, this namespace gets added into the <mandatory-extension> element in the overlay configuration file 🧚 and the routing modes it defines are DRR and RPR 🦋
the mode can be DRR or RPR. if it's specified in the configuration, it should be the preferred routing mode the application uses ✨
7. Security Considerations 💀
okay the security part is SERIOUS, so pay attention 🙈 the normative security recommendations in Section 13 of [RFC6940] apply to this document too 🔒
DRR is an alternative routing option, and its security side conforms to Section 13.6 of [RFC6940], which is all about routing security 🛡️ for example, the DRR routing option gives you info about the route back to the source 👀
and according to Section 13.6 of [RFC6940], the entire DRR routing message MUST be digitally signed and sent over via a protected channel to protect the DRR routing information 🔐 no skipping this one, periodt 😭
the DRR routing message has to be signed and sent over a protected channel. that's not optional vibes, that's the rule 💀
8. IANA Considerations 🌸
8.1. A New RELOAD Forwarding Option 🦋
okay so a brand new RELOAD Forwarding Option type got added to the "RELOAD Forwarding Option" registry, which is defined in [RFC6940] 📋 here's the entry:
Code: 2
Forwarding Option: extensive_routing_mode8.2. A New IETF XML Registry 💜
IANA registered the following URN in the "XML Namespaces" class of the "IETF XML Registry", following [RFC3688] 🎀 the entry looks like this:
URI: urn:ietf:params:xml:ns:p2p:route-mode
Registrant Contact: The IESG
XML: This specification9. Acknowledgments 🫶
shoutout to David Bryan, who helped SO much with this doc and contributed some of the text, analysis, and ideas 👑 the authors also want to thank Ted Hardie, Narayanan Vidya, Dondeti Lakshminath, Bruce Lowekamp, Stephane Bryant, Marc Petit-Huguenin, and Carlos Jesus Bernardos Cano for their constructive comments 💖 the girlies gave real feedback and that's iconic ✨
10. References 📚
10.1. Normative References 🌈
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", RFC 6940, January 2014.10.2. Informative References 🧚
[Chord] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D.,
Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A
Scalable Peer-to-Peer Lookup Protocol for Internet
Applications", IEEE/ACM Transactions on Networking
Volume 11, Issue 1, 17-32, February 2003.
[DTLS] Modadugu, N. and E. Rescorla, "The Design and
Implementation of Datagram TLS", Proc. 11th Network and
Distributed System Security Symposium (NDSS),
February 2004.
[IGD2] UPnP Forum, "WANIPConnection:2 Service", September 2010,
<http://upnp.org/specs/gw/
UPnP-gw-WANIPConnection-v2-Service.pdf>.
[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.
[RFC6886] Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol
(NAT-PMP)", RFC 6886, April 2013.
[RFC7264] Zong, N., Jiang, X., Even, R., and Y. Zhang, "An Extension
to the REsource LOcation And Discovery (RELOAD) Protocol
to Support Relay Peer Routing", RFC 7264, June 2014.
[wikiChord]
Wikipedia, "Chord (peer-to-peer)", 2013,
<http://en.wikipedia.org/w/
index.php?title=Chord_%28peer-to-peer%29&oldid=549516287>.Appendix A. Optional Methods to Investigate Peer Connectivity 🔍
this part is purely informational, bestie 🌸 it covers some mechanisms you can use when the configuration info doesn't say whether DRR can be used. it sums up methods a peer can use to figure out its own network location compared with NAT 🧭 these methods may help a peer decide which routing mode it may wish to try.
heads up: there's no foolproof way to tell whether a peer is publicly reachable, other than out-of-band mechanisms 🙅♀️ this document deals with UNilateral Self-Address Fixing (UNSAF) [RFC3424] considerations by specifying a fallback plan to SRR [RFC6940]. SRR is not an UNSAF mechanism, and this document does not define any new UNSAF mechanisms 💅
for DRR to work correctly, a peer may try to figure out whether it's publicly reachable. if it's not, the peer should fall back to SRR. if the peer believes it IS publicly reachable, DRR may be attempted 🦋 NATs and firewalls are the two big troublemakers that stop DRR from working properly 😤 there are a bunch of techniques a peer can use to get its reflexive address on the public side of the NAT. after it has that reflexive address, the peer can run more tests to learn whether the address is publicly reachable. if it looks publicly reachable, the peer that owns the address can use DRR for responses ✨
some things that are unique to P2PSIP architecture could be leveraged to make these tests easier 🧚 in a P2P overlay, each peer only has a partial view of the whole network and knows a few peers in the overlay. P2P routing algorithms can easily deliver a request from a sending peer to a peer it has no direct connection with 💫 so it's easy for a peer to ask other peers to send unsolicited messages back to the requester 🫶
in the sections below, we first introduce a few ways for a peer to get the addresses it needs for further tests. then we propose a test for learning whether a peer may be publicly reachable 🎀
A.1. Getting Addresses to Be Used as Candidates for DRR 🌈
to test whether a peer may be publicly reachable, the peer should first get one or more addresses that other peers will use to send it messages directly. that address is either a local address of the peer or a translated address that a NAT assigned to the peer 🏠
Session Traversal Utilities for NAT (STUN) is used to get a reflexive address on the public side of a NAT, with help from STUN servers 🔭 NAT behavior discovery using STUN is specified in [RFC5780]. under the RELOAD architecture, a few infrastructure servers can be leveraged for discovering NAT behavior, like enrollment servers, diagnostic servers, bootstrap servers, etc. 🛠️
the peer can send a STUN Binding request to one of the STUN servers to trigger a STUN Binding response, which returns the reflexive address from the server's perspective 🪞 if the reflexive transport address is the same as the source address of the Binding request, the peer can determine that there is likely no NAT between it and the chosen infrastructure server. (yes, in some rare cases the allocated address happens to match the source address. further tests will catch that and rule it out in the end 🙈) usually these infrastructure servers are publicly reachable in the overlay, so the peer can be considered publicly reachable. on the other hand, using the techniques in [RFC5780], a peer can also decide whether it's behind a NAT with endpoint-independent mapping behavior. if it is, the reflexive address should also be a candidate for further tests 🦋
the Universal Plug and Play Internet Gateway Device (UPnP-IGD) [IGD2] is a mechanism a peer can use to get its assigned address from its residential gateway 🏡 once it has this address and shares it with other peers, the peer can receive unsolicited messages from outside, even though it's behind a NAT 🤩 so the address obtained through UPnP should also be used for further tests 💅
another way a peer behind a NAT can learn its assigned address is via the NAT Port Mapping Protocol (NAT-PMP) [RFC6886] 🌸 just like with UPnP-IGD, the address obtained this way should also be tested further.
these techniques are NOT exhaustive, periodt 💁♀️ they can be used to get candidate transport addresses for further tests.
A.2. Public Reachability Test 🔥
using the transport addresses from the techniques above, a peer can start a test to learn whether a candidate transport address is publicly reachable 🎯 the basic idea is that a peer sends a request and expects another peer in the overlay to send back a response. if the sending peer successfully receives that response, and the responding peer has no direct connection with the sending peer, the sending peer can determine that the address is probably publicly reachable. so the peer may be publicly reachable at the tested transport address 👑
in a P2P overlay, a request gets routed through the overlay, and eventually a destination peer terminates the request and gives the response 🧚 in a large system there's a high probability that the destination peer has no direct connection with the sending peer. every peer maintains a connection table, especially in the RELOAD architecture, so it's easier for a peer to check whether it has a direct connection with another peer 📋
if a peer wants to test whether its transport address is publicly reachable, it can send a request to the overlay. the routing for this test message is different from other requests, because it's not for storing or fetching anything in the overlay, and it's not for locating a specific peer. instead, it's to find a peer that can deliver an unsolicited response to the sending peer and has no direct connection with it 🦋 each intermediate peer that gets the request first checks whether it has a direct connection with the sending peer. if it does, the request gets routed to the next peer. if it doesn't, the intermediate peer terminates the request and sends the response straight back to the sending peer, using the transport address under test 💖
after running the test, if the peer decides it may be publicly reachable, it can try DRR in subsequent transactions 🌈✨
Appendix B. Comparison of Cost of SRR and DRR 💜
the big win of DRR is that it cuts down on the number of intermediate peers the response has to go through 🙌 that means less load on those peers' resources, like processing power and communication bandwidth 🧠⚡ it's giving efficiency, no cap 💅🎀
B.1. Closed or Managed Networks 🏰
okay so, as Section 3 explains, lots of P2P systems run in a closed or managed environment (think carrier networks) 🛰️, which means network admins would know they can safely use DRR 💅
SRR uses more routing hops than DRR, no cap 😭 Say there are N peers in the P2P system and Chord [Chord] [wikiChord] is used for routing. The hop and message counts for a response in SRR and DRR are in the table below. Setting up a secure connection between the sending peer and the responding peer with Transport Layer Security (TLS) or Datagram TLS (DTLS) takes multiple messages, and ngl, (D)TLS isn't always the move for a P2P overlay 🙈 DRR is one example, since (D)TLS is heavy for temporary connections. So the table shows two DRR cases: 1) no (D)TLS in DRR, and 2) still using DTLS in DRR, which is sub-optimal. The worst-cost case uses seven (7) messages during DTLS handshaking [DTLS]. (The TLS handshake is a negotiation protocol that needs two (2) round trips, and the DTLS handshake needs three (3) round trips 🔁)
Mode | Success | No. of Hops | No. of Msgs
------------------------------------------------
SRR | Yes | log(N) | log(N)
DRR | Yes | 1 | 1
DRR (DTLS) | Yes | 1 | 7+1
Table 1: Comparison of SRR and DRR in Closed NetworksFrom the above comparison, it is clear that:
- In most cases when the number of peers (N) >
2^1, DRR uses fewer hops than SRR. Using a shorter route means less overhead and resource usage on intermediate peers, which is a big deal when resources like CPU and bandwidth are limited, e.g., mobile, wireless networks 📱✨ - In the cases when N >
256(2^8), DRR also uses fewer messages than SRR. - In the cases when N <
256, DRR uses more messages than SRR (but still uses fewer hops than SRR), so whether to use DRR or SRR depends on other factors, like using fewer resources (bandwidth and processing) from the intermediate peers. Section 4 covers use cases where DRR has a better chance of working, or where intermediary resources really matter 🫶
B.2. Open Networks 🌐
In open networks (e.g., the Internet) where DRR is not guaranteed to work, DRR can fall back to SRR if it fails after trial, as described in Section 4 🔄 Using the same settings as Appendix B.1, the hops and messages for a response in SRR and DRR are in the table below:
Mode | Success | No. of Hops | No. of Msgs
----------------------------------------------------------------
SRR | Yes | log(N) | log(N)
DRR | Yes | 1 | 1
| Fail & fall back to SRR | 1+log(N) | 1+log(N)
DRR (DTLS) | Yes | 1 | 7+1
| Fail & fall back to SRR | 1+log(N) | 8+log(N)
Table 2: Comparison of SRR and DRR in Open NetworksFrom the above comparison, it can be observed that trying DRR first could still give an overall number of hops lower than going straight to SRR 👀 Suppose P peers are publicly reachable. The number of hops in DRR and SRR is P*1+(N-P)*(1+logN) and N*logN, respectively. The condition for fewer hops in DRR is P*1+(N-P)*(1+logN) < N*logN, which works out to P/N > 1/logN. So as N grows, the required ratio of publicly reachable peers (P/N) for fewer hops in DRR goes down 📉 Basically, the chance of trying DRR and getting fewer hops than SRR gets better as the network scales up 🚀🦋
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
📦 where this page comes from
- ietf: rfc7263 2014-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms