RFC 7851
Peer-to-Peer (P2P) Overlay Diagnostics
RFC 7851: Peer-to-Peer (P2P) Overlay Diagnostics 🦋
Okay bestie, this one is by H. Song, X. Jiang, R. Even, D. Bryan, and Y. Sun, from Huawei, ethernot.org, and ICT. It's a Standards Track document, so it's an actual official spec and not just vibes 💅. It came out in May 2016 and has ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC 🌸.
Abstract ✨
This doc is about diagnostics for Peer-to-Peer (P2P) overlays 🔍. It adds extensions to the REsource LOcation And Discovery (RELOAD) base protocol so you can collect diagnostic info, and it spells out the protocol details for those extensions. It also defines useful diagnostic data for monitoring connection and node status 📊. Plus, it covers the usage scenarios and gives examples of how these methods get used to run diagnostics. Iconic, honestly 👑.
Status of This Memo 📜
This is an Internet Standards Track document, so it's official 💖.
It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 📚.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7851 🎀.
Copyright Notice 🌈
Copyright (c) 2016 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, which you can find at http://trustee.ietf.org/license-info as they were in effect when this was published. Please actually read those, because they explain your rights and restrictions for this doc 🙈. If you pull Code Components out of this document, they must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They also come with no warranty, as described in the Simplified BSD License 🔥.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Diagnostic Scenarios . . . . . . . . . . . . . . . . . . . . 5
4. Data Collection Mechanisms . . . . . . . . . . . . . . . . . 6
4.1. Overview of Operations . . . . . . . . . . . . . . . . . 6
4.2. "Ping-like" Behavior: Extending Ping . . . . . . . . . . 8
4.2.1. RELOAD Request Extension: Ping . . . . . . . . . . . 9
4.3. "Traceroute-like" Behavior: The PathTrack Method . . . . 9
4.3.1. New RELOAD Request: PathTrack . . . . . . . . . . . . 10
4.4. Error Code Extensions . . . . . . . . . . . . . . . . . . 12
5. Diagnostic Data Structures . . . . . . . . . . . . . . . . . 13
5.1. DiagnosticsRequest Data Structure . . . . . . . . . . . . 13
5.2. DiagnosticsResponse Data Structure . . . . . . . . . . . 15
5.3. dMFlags and Diagnostic Kind ID Types . . . . . . . . . . 16
6. Message Processing . . . . . . . . . . . . . . . . . . . . . 19
6.1. Message Creation and Transmission . . . . . . . . . . . . 19
6.2. Message Processing: Intermediate Peers . . . . . . . . . 20
6.3. Message Response Creation . . . . . . . . . . . . . . . . 21
6.4. Interpreting Results . . . . . . . . . . . . . . . . . . 22
7. Authorization through Overlay Configuration . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.1. Diagnostics Flag . . . . . . . . . . . . . . . . . . . . 24
9.2. Diagnostic Kind ID . . . . . . . . . . . . . . . . . . . 25
9.3. Message Codes . . . . . . . . . . . . . . . . . . . . . . 26
9.4. Error Code . . . . . . . . . . . . . . . . . . . . . . . 26
9.5. Message Extension . . . . . . . . . . . . . . . . . . . . 26
9.6. XML Name Space Registration . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 29
A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 29
A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 29
A.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix B. Problems with Generating Multiple Responses on Path 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 301. Introduction 🌸
Overlay networks have been glowing up fast over the last few years 📈. They're now a promising base for new apps and services on the Internet 🚀. A big reason they're seen as a great platform for large-scale distributed systems is that they're resilient when things break 💪. That resilience has three parts: data replication, routing recovery, and static resilience 🧩. Routing recovery algorithms refill the routing table with live nodes once failures are detected 🔄. Static resilience is how well an overlay can route around failures before the recovery algorithm has fixed the routing table 🛡️. Both routing recovery and static resilience depend on detecting failures accurately and on time ⏰.
Okay, so some nodes in a Peer-to-Peer (P2P) overlay can malfunction or behave badly 😭. They might be disabled, congested, or misrouting messages 🙃. The fallout can be lower quality of service from the peers working together, or the overlay services just stopping ❌. It's really useful to spot malfunctioning or badly behaving peers with diagnostic tools, and then exclude or reject them from the P2P system 🚫. Node failures can also come from problems in underlying layers 🧱. For example, recovering from an incorrect overlay topology can be slow when IP routing is super slow to recover after link failures 🐢. And if a backbone link fails and failover is slow, the network can get partitioned 💔. That can split overlay topologies and cause inconsistent routing results between the partitioned pieces 🙈.
Some keep-alive algorithms use periodic probe and acknowledge mechanisms to detect failures of one node's neighbors accurately and on time [Overlay-Failure-Detection] ✅. But on their own, these algorithms can only find disabled neighbors using the periodic method 🔁. That might not be enough for the service provider running the overlay 🤷♀️.
So a P2P overlay diagnostic framework that supports both periodic and on-demand methods for detecting node and network failures is what we need 🎯. This document describes a general P2P overlay diagnostic extension to the base protocol RELOAD [RFC6940]. It's meant to complement the keep-alive algorithms inside the P2P overlay itself 🫶. If you want more background on the problem space, go read [P2PSIP-CONCEPTS] 📖.
2. Terminology 📚
This document uses the concepts defined in RELOAD [RFC6940]. It also uses these extra terms:
overlay hop: One overlay hop is one piece of the path between the initiator node and the destination peer in a RELOAD overlay 🧚. Every time packets get passed to the next node in the RELOAD overlay, that's one overlay hop 🦋.
underlay hop: An underlay hop is one piece of the path between source and destination at the IP layer 🌐. Every time packets get passed to the next IP-layer device, that's one underlay hop 💜.
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 [RFC2119] 🎀.
3. Diagnostic Scenarios 🔍
P2P systems organize themselves 🫧. Ideally, setting up and configuring individual P2P nodes needs no network management in the traditional sense 😌. But users of an overlay, and the P2P service providers, might still want some monitoring and diagnostics in certain scenarios 👀. This document shows a simple connectivity test and some handy diagnostic info you can use for that 💅.
The common usage scenarios for P2P diagnostics fall into three main classes 🌈:
a. Automatic diagnostics built into the P2P overlay routing protocol. Nodes run periodic checks on known neighbors, and they remove any neighbors that don't respond to connectivity checks from their routing tables [Handling_Churn_in_a_DHT] 🗑️. Unresponsive nodes might only be temporarily disabled, for example because of a local cryptographic processing overload, a disk processing overload, or a link overload ⚡. So it's smart to keep repeating the connectivity checks to see whether nodes have recovered, so they can go back into the routing tables 🔙. This process is called 'failed node recovery' and it can be optimized as described in the paper "Handling Churn in a DHT" [Handling_Churn_in_a_DHT] 🧠.
b. Diagnostics used by a particular node to follow up on an individual user complaint or failure. For example, a technical support staff member might use a desktop sharing app (with the user's permission) to remotely figure out the health of the malfunctioning node, and what might be wrong with it 🖥️. Part of the remote diagnostics could be simple connectivity tests with other nodes in the P2P overlay, plus pulling statistics from overlay nodes 📈. The simple connectivity tests don't depend on the type of P2P overlay, which is honestly great 🙌. Other tests might be needed too, like checking the health and performance of the user's computer or mobile device, and checking the bandwidth of the link that connects the user to the Internet 📶.
c. P2P system-wide diagnostics used to check the overall health of the P2P overlay network. These cover checking network bandwidth consumption, finding problem links, and spotting abusive or malicious nodes 🚨. This is a seriously tricky problem 😤. It has been studied in detail for content and streaming P2P overlays [Diagnostic_Framework], but earlier documents haven't tackled it 📝. Even so, a lot of the info needed to diagnose these problems can come from basic diagnostic info about peers and the network 🔎. This document provides a framework for collecting that info 🫶✨.
4. Data Collection Mechanisms 💅
4.1. Overview of Operations ✨
okay bestie, this section is the big picture 🦋 The diagnostic mechanisms here are mainly for detecting and locating failures or monitoring performance in P2P overlay networks 💅 They help you catch malfunctioning or badly behaving nodes, like disabled nodes, congested nodes, and misrouting peers 🙈 They also give you a way to detect direct connectivity or connectivity to a specified node, a way to detect whether specified resource records are available, and a way to discover the P2P overlay topology and underlay topology failures 🧚
The RELOAD diagnostics extensions define two ways to collect data 💖 The first is an extension to the RELOAD Ping mechanism, so you can query diagnostic data from a node and also diagnose the path to that node. The second is a brand new method called PathTrack, which collects diagnostic information iteratively 🔥 The payloads for collecting and representing this data are included, and some new error codes get added too ✨ Basically, this doc reuses the RELOAD spec [RFC6940] and extends it with the new diagnostics methods 🎀 The extensions strictly follow how RELOAD handles message routing, transport, NAT traversal, and everything else, no cap 🫶
This document is all about detecting and locating failures, like disabled nodes, congested nodes, misrouting behaviors, and underlying network faults, in P2P overlay networks, and it does it with a simple and efficient mechanism 💅 It's modeled after the ping/traceroute paradigm. ping [RFC792] is used for connectivity checks, and traceroute is used for hop-by-hop fault localization as well as path tracing 🦋 This document specifies a "ping-like" mode, made by extending the RELOAD Ping method to gather diagnostics, and a "traceroute-like" mode, made by defining the new PathTrack method, for diagnosing P2P overlay networks 😭
One way to use these tools is to check the connectivity to a specified node, or the availability of a specified resource record, with the extended Ping operation 🧚 Once the overlay network gets alarms about service degradation or interruption, a Ping gets sent. If the Ping fails, you can then send a PathTrack to figure out where the fault lies 🔍
Diagnostic information can only be provided to authorized nodes 🔒 Some of it can be provided to all the participants in the P2P overlay, and some of it can only be provided to nodes authorized by the local or overlay policy 💜 Authorization depends on the type of diagnostic information and the administrative considerations, and it's application specific ✨
This document considers the general administrative scenario based on diagnostic Kind. In this scenario, a whole overlay can authorize a certain kind of diagnostic information for a small list of particular nodes (for example, administrative nodes) 👑 That means that if a node gets authorization to access a diagnostic Kind, it can access that information from all nodes in the overlay network. The scenario where a particular node authorizes its own diagnostic information for a particular list of nodes is out of scope here. It could be added through an extension of this document if there's a requirement for it in the near future 🌈 The default policy or access rule for a type of diagnostic information is "deny", unless the diagnostics extension document specifies otherwise 🙅♀️ Since RELOAD already requires each message to carry the message signature of the sender, the receiver of diagnostics requests can use that signature to identify the sender. It can then use the overlay configuration file with this signature to determine which types of diagnostic information that node is authorized for 🧠
In the rest of this section, we define mechanisms for collecting data and the specific protocol extensions (message extensions, new methods, and error codes) needed to collect this information 🎀 In Section 5 we discuss the format of the collected data, and in Section 6 we discuss detailed message processing 📝
It's important to note that the mechanisms in this document do not guarantee that the collected information is actually related to the previous failures 😬 However, by using the information from previously traversed nodes, the user (or management system) may be able to infer the problem 🕵️♀️ Symmetric routing can be achieved by using the Via List [RFC6940] (or an alternate DHT routing algorithm), but the response path is not guaranteed to be the same 🌸
4.2. "Ping-like" Behavior: Extending Ping 🏓
To get "ping-like" behavior, the RELOAD Ping method gets extended to collect diagnostic data along the path 💖 The request message is forwarded by the intermediate peers along the path, and then the responsible peer terminates it. After optional local diagnostics, the responsible peer returns a response message 🫶 If an error is found while routing, the intermediate peer sends an error response to the initiator node 🚨
Here's the message flow of a Ping message with diagnostic extensions 🦋
Peer A Peer B Peer C Peer D
| | | |
|(1). PingReq | | |
|------------------->|(2). PingReq | |
| |------------------->|(3). PingReq |
| | |------------------->|
| | | |
| | |<-------------------|
| |<-------------------|(4). PingAns |
|<-------------------|(5). PingAns | |
|(6). PingAns | | |
| | | |
Figure 1: Ping Diagnostic Message Flow4.2.1. RELOAD Request Extension: Ping 💅
To extend the Ping request for diagnostics, a new RELOAD extension gets defined 🎀 The structure for a MessageExtension in RELOAD is defined like this:
struct {
MessageExtensionType type;
Boolean critical;
opaque extension_contents<0..2^32-1>;
} MessageExtension;For the Ping request extension, we define a new MessageExtensionType, extension 0x2 named Diagnostic_Ping, as specified in Table 4 🧚 The extension contents are a DiagnosticsRequest structure, defined in Section 5.1. This extension MAY be used for new requests of the Ping method, and it MUST NOT be included in requests using any other method 🙅♀️
This extension is not critical 💖 If a peer doesn't support the extension, it will just ignore the diagnostic part of the message and treat the message as a normal ping 🙈 Senders MUST accept a response that lacks diagnostic information, and they SHOULD NOT resend the message expecting a reply 🫶 Receivers who get a method other than Ping that includes this extension MUST ignore the extension 🚫
4.3. "Traceroute-like" Behavior: The PathTrack Method 🦋
We define a simple PathTrack method for retrieving diagnostic information iteratively 🧚
Here's how this request works, shown in Figure 2 below 🔥 The initiator node A asks its neighbor B which peer is the next hop to the destination ID. B returns a message with the next hop peer C's information, along with optional diagnostic information for B, back to the initiator node. Then initiator node A asks the next hop peer C (using direct response routing [RFC7263] or symmetric routing) to return the next hop peer D's information and C's diagnostic information 💅 Unless a failure stops the message from being forwarded, this step can be repeated until the request reaches the responsible peer D for the destination ID and retrieves D's diagnostic information ✨
Here's the message flow of a PathTrack message with diagnostic extensions 🌈
Peer-A Peer-B Peer-C Peer-D
| | | |
|(1).PathTrackReq | | |
|------------------->| | |
|(2).PathTrackAns | | |
|<-------------------| | |
| |(3).PathTrackReq | |
|--------------------|------------------->| |
| |(4).PathTrackAns | |
|<-------------------|--------------------| |
| | |(5).PathTrackReq |
|--------------------|--------------------|------------------->|
| | |(6).PathTrackAns |
|<-------------------|--------------------|--------------------|
| | | |
Figure 2: PathTrack Diagnostic Message FlowThere have been proposals that RouteQuery and a series of Fetch requests could replace the PathTrack mechanism 🤔 But with high rates of churn, that operation wouldn't strictly provide identical results, because the path may change between the RouteQuery and Fetch operations. The path could also change between steps of PathTrack, obviously, but with a single message instead of two messages for query and fetch, less inconsistency is likely, so a single message is preferred 💜
Since a peer sending a PathTrack request usually wants information about the current path to the destination, if successive calls to PathTrack return different paths, the results should be discarded and the request resent 🔁 That way, the second request goes through the appropriate path ✨
4.3.1. New RELOAD Request: PathTrack ✨
okay so this is the big one 🦋 This document defines a brand new RELOAD method called PathTrack, and it lets you pull diagnostic info from every intermediate peer along a routing path 🧚 Each time a PathTrack request hops along, the peer that's responsible for that step sends back status info straight to the initiator node 💌 And the info can be sooo much: congestion state, processing power, available bandwidth, how many entries are in its neighbor table, uptime, identity, network address info, and next hop peer info. literally a whole peer profile 💅
A PathTrack request tells everyone exactly which diagnostic info it wants using a DiagnosticsRequest data structure, which we get into properly in Section 5.1 🎀 You ask for base info by setting the right flags in that structure. And here's the lowkey genius part: if all the flags are clear (no bits set), the PathTrack request is only asking for next hop info 👀 In that case, iterative PathTrack just becomes a RouteQuery method, which is basically a liveness check on all the peers along the routing path 🔥 And the PathTrack request can be routed using direct response routing, or any other routing method the initiator picks ✨
A successful PathTrackReq gets a PathTrackAns back 💜 The answer carries general diagnostic info in its payload, wrapped in a DiagnosticResponse data structure (Section 5.2, obsessed) 🌸 Whatever comes back depends on what the flags in the original request asked for, so it's always matched up 🫶
4.3.1.1. PathTrack Request
The PathTrack request is shaped like this 🍓
struct{
Destination destination;
DiagnosticsRequest request;
}PathTrackReq;Here's what the fields of the PathTrackReq are:
destination: The destination the initiator node is curious about 🧚 This can be any valid destination object, so a NodeID, opaque ids, or a ResourceID all work 💖 One thing to note: for debugging purposes, the initiator uses the destination ID exactly as it was used when the failure happened 🙈request: A DiagnosticsRequest, as discussed in Section 5.1 ✨
4.3.1.2. PathTrack Response
And the PathTrack response looks like this 💅
struct{
Destination next_hop;
DiagnosticsResponse response;
}PathTrackAns;Fields of the PathTrackAns:
next_hop: The info about the next hop node, from the responding intermediate peer toward the destination 🦋 If the responding peer is the responsible peer for the destination ID, then the next_hop node ID equals the responding node ID. And once the initiator gets a PathTrackAns where next_hop node ID equals the responding node ID, the initiator MUST stop the iterative process 🛑 That's the finish line, bestie 🏁response: A DiagnosticsResponse, as discussed in Section 5.2 💜
4.4. Error Code Extensions 🚨
This document extends the error response method from the RELOAD specification so it can cover error cases that come up during diagnostic queries 🎀 When something goes wrong in RELOAD, the Message Code 0xffff comes back, and the ErrorResponse structure includes an error code. We're adding new error codes for problems found while running diagnostics:
Code Value Error Code Name
0x15 Error_Underlay_Destination_Unreachable
0x16 Error_Underlay_Time_Exceeded
0x17 Error_Message_Expired
0x18 Error_Upstream_Misrouting
0x19 Error_Loop_Detected
0x1a Error_TTL_Hops_ExceededSo the error code gets returned by the upstream node sitting right before the failure node 👀 That upstream node uses the normal ping to figure out the failure type and sends it back to the initiator node, which helps the user understand where the failure happened and what kind of error it was 🔍 This matters because the failure can happen in the same place and for the same reason whether you're sending a normal message or a diagnostics message, so the two line up 💅
Like RELOAD says, extra info can be stored in the optional error_info byte string, in an implementation-specific way 🌈 The details are totally up to the implementation, but as an example, for 0x15, the error_field could hold extra info about why the underlay destination is unreachable (net unreachable, host unreachable, fragmentation needed, etc.) 🧚
5. Diagnostic Data Structures 💖
Both the extended Ping method and the PathTrack method use the same common diagnostics data structures to collect data 🦋 There are two common structures: DiagnosticsRequest for asking for data, and DiagnosticsResponse for sending the info back 💌
5.1. DiagnosticsRequest Data Structure 🎀
The DiagnosticsRequest data structure is how diagnostic info gets requested, and it looks like this ✨
enum{ (2^16-1) } DiagnosticKindId;
struct{
DiagnosticKindId kind;
opaque diagnostic_extension_contents<0..2^32-1>;
}DiagnosticExtension;
struct{
uint64 expiration;
uint64 timestamp_initiated;
uint64 dMFlags;
uint32 ext_length;
DiagnosticExtension diagnostic_extensions_list<0..2^32-1>;
}DiagnosticsRequest;Here are the fields in the DiagnosticsRequest 🍓
expiration: The time the request expires, shown as the number of milliseconds elapsed since midnight Jan 1, 1970 UTC (not counting leap seconds) 🕛 It has the same values for seconds as standard UNIX time or POSIX time. You can read more under "Unix time" on Wikipedia [UnixTime]. This value MUST have a value between 1 and 600 seconds in the future 🚫 This value is used to prevent replay attacks 🛡️ we love a safe bestie 🫶timestamp_initiated: The time the diagnostics request was started, shown as the number of milliseconds elapsed since midnight Jan 1, 1970 UTC (not counting leap seconds) ⏰ Same deal: the seconds match standard UNIX time or POSIX time.dMFlags: A mandatory field, an unsigned 64-bit integer that tells you which base diagnostic info the request initiator node is interested in 🎯 The initiator sets different bits to grab different kinds of diagnostic info. If dMFlags is set to zero, no base diagnostic info goes in the PathTrack response 🙅 If dMFlags is set to all "1"s, then every base diagnostic info value is requested 🤩 A request can set any number of the flags 💅
Note this memo specifies the initial set of flags, but the flags can be extended 🌱 The dMflags indicate general diagnostic info. How the bits in dMFlags map to the diagnostic Kind ID is described in Section 9.1 📖
ext_length: The length of the extended diagnostic request info, in bytes 📏 If the value is greater than or equal to 1, then some extended diagnostic info is being requested, on the assumption that it'll be included in the response if the recipient understands the extended request and is willing to provide it 🤞 The specific diagnostic info requested is defined in the diagnostic_extensions_list below. A value of zero means no extended diagnostic info is being requested 😌 The value of ext_length MUST NOT be negative 🚫 And note that it's not the length of the entire DiagnosticsRequest data structure, just the data making up the diagnostic_extensions_list 🧠diagnostic_extensions_list: Holds one or more DiagnosticExtension structures (see below) describing the extra diagnostic info being requested 🌈 Each DiagnosticExtension has these fields:kind: A numerical code for the type of extension diagnostic info (see Section 9.2) 🔢 Heads up: kinds 0xf000 - 0xfffe are reserved for overlay specific diagnostics, and they can be used without IANA registration for local diagnostic info 🧚 And kinds from 0x0000 to 0x003f MUST NOT be indicated in the diagnostic_extensions_list in the message request, because the dMFlags can represent them in a much simpler (and more space efficient) way 💀 use the flags, not the list, bestiediagnostic_extension_contents: The opaque data holding the request for this particular extension 📦 What's in it depends on the extension itself 💜
5.2. DiagnosticsResponse Data Structure ✨
okay so this is the DiagnosticsResponse data structure, and it's the one that brings all the juicy diagnostic info back to the initiator 💌 It's set up like this:
enum { (2^16-1) } DiagnosticKindId;
struct{
DiagnosticKindId kind;
opaque diagnostic_info_contents<0..2^16-1>;
}DiagnosticInfo;
struct{
uint64 expiration;
uint64 timestamp_initiated;
uint64 timestamp_received;
uint8 hop_counter;
uint32 ext_length;
DiagnosticInfo diagnostic_info_list<0..2^32-1>;
}DiagnosticsResponse;Here's what each field is giving 🎀
expiration: this is when the response expires, written as the number of milliseconds since midnight Jan 1, 1970 UTC (leap seconds not counted). The seconds match standard UNIX time or POSIX time ⏰ This value MUST have a value between 1 and 600 seconds in the future.timestamp_initiated: copied straight from the diagnostics request 🦋 The perk is that the initiator node doesn't have to keep any state around.timestamp_received: when the diagnostic request was received, in milliseconds since midnight Jan 1, 1970 UTC (leap seconds not counted). Same seconds as standard UNIX or POSIX time, so no weird math needed 🧠hop_counter: this one only shows up in responses, and it's a whole mood 🌈 It MUST be exactly copied from the TTL field of the forwarding header in the received request. The info goes back to the initiator so it can work out how many hops the message traveled through the overlay.ext_length: the length of the returnedDiagnosticInfoinfo, in bytes. If it's greater than or equal to 1, some extended diagnostic info (the stuff asked for in the DiagnosticsRequest) was available and is being sent back, and this number tells you how big it is 📏 A value of zero means no extended info is included, either because nothing was requested or because the request couldn't be accommodated. The value ofext_lengthMUST NOT be negative. Also, it's NOT the length of the whole DiagnosticsRequest structure. It's only the length of the data making up thediagnostic_info_list💅diagnostic_info_list: one or moreDiagnosticInfostructures, each holding the requesteddiagnostic_info_contents. The fields inDiagnosticInfogo like this:kind: a numeric code for what type of info is being returned 🔥 For base data requested using the dMFlags, this code matches the dMFlag that was set, and it's described in Section 5.1. For diagnostic extensions, this code is identical to the DiagnosticKindId that was set in the "kind" field of the DiagnosticExtension in the request. See Section 9.2.diagnostic_info_contents: the data holding the value of the diagnostic info being reported. Lots of different kinds of info can be retrieved here. For details on the diagnostic Kind ID of the base diagnostic info that might get reported, check out Section 5.3 📚
5.3. dMFlags and Diagnostic Kind ID Types 🧚
okay the dMFlags field is a 64-bit field that lets initiators ask for up to 62 items of base info in a request message 🎀 The first and last flags are reserved, so they don't count. dMFlags also has two special vibes: all "0"s means nothing is requested, and all "1"s means everything is requested 🌸 BUT the first and last bits can't be used for anything else, and they MUST be set to 0 when other particular diagnostic Kind IDs are requested. When the requested base info comes back in the response, the diagnostic Kind ID matches the numeric field marked in the dMFlags of the request 💖 The dMFlags values are defined in Section 9.1, the diagnostic Kind IDs are defined in Section 9.2, and the info for each one is described right here. Access to each kind of diagnostic info MUST NOT be allowed unless it's compliant with the rules in Section 7 🔒 no cap, this part matters.
STATUS_INFO(8 bits): a single-value element holding an unsigned byte that shows whether or not the node is in congestion status 🚦 An example is congestion-aware routing. Each peer has to update its congestion status periodically. An intermediate peer in the Distributed Hash Table (DHT) network picks its next hop based on both the DHT routing algorithm and the status info, so it can avoid piling more load onto congested peers 🫶 The rightmost 4 bits are used, and the other bits MUST be cleared to "0"s for future use.
There are 16 levels of congestion status: 0x00 means zero load and 0x0f means congestion. This document doesn't give a specific method for figuring out congestion and leaves that choice to each overlay implementation 🤷♀️ One possible option would be to take the node's CPU/memory/bandwidth usage percentage over the past 600 seconds and normalize the highest value into the range from 0x00 to 0x0f. An overlay implementation can also decide not to use all 16 values from 0x00 to 0x0f. A future document may define an objective measure or a specific algorithm for this.
ROUTING_TABLE_SIZE(32 bits): a single-value element holding an unsigned 32-bit integer for the number of peers in the peer's routing table 🗺️ Overlay admins may be super interested in stats on this for things like routing efficiency.PROCESS_POWER(64 bits): a single-value element holding an unsigned 64-bit integer for the node's processing power, measured in MIPS. Fractional values get rounded up ⬆️UPSTREAM_BANDWIDTH(64 bits): a single-value element holding an unsigned 64-bit integer for the node's upstream network bandwidth (provisioned or maximum, not available), in kbit/s. Fractional values get rounded up. For multihomed hosts, this should be the link used to send the response 🌐DOWNSTREAM_BANDWIDTH(64 bits): a single-value element holding an unsigned 64-bit integer for the node's downstream network bandwidth (provisioned or maximum, not available), using kbit/s as the unit. Fractional values get rounded up. For multihomed hosts, this should be the link the request was received from 📶SOFTWARE_VERSION: a single-value element holding a US-ASCII string that identifies the manufacturer, model, operating system info, and software version 💻 Some networks have a ton of peers, and no peer is likely to know everyone else's software. So this info can be super useful for figuring out whether a group of misbehaving peers is tied to specific software versions 🕵️♀️ The format is up to each peer, but a suggested format is:
"ApplicationProductToken (Platform; OS-or-CPU) VendorProductToken (VendorComment)"
For example:
"MyReloadApp/1.0 (Unix; Linux x86_64) libreload-java/0.7.0 (Stonyfish Inc.)"
This is a C-style string, so it MUST be terminated by "\0". The "\0" MUST NOT be included in the string itself, so it doesn't get confused with the delimiter 🙈
MACHINE_UPTIME(64 bits): a single-value element holding an unsigned 64-bit integer for how long the node's underlying system has been up, in seconds ⏳APP_UPTIME(64 bits): a single-value element holding an unsigned 64-bit integer for how long the P2P application has been up, in seconds 🧃MEMORY_FOOTPRINT(64 bits): a single-value element holding an unsigned 64-bit integer for the memory footprint of the peer program, in kilobytes (1024 bytes). Fractional values get rounded up 🧠DATASIZE_STORED(64 bits): an unsigned 64-bit integer for the number of bytes of data this node is storing 💾INSTANCES_STORED: an array element holding the number of instances of each kind stored. The array is indexed by Kind-ID, and each entry is an unsigned 64-bit integer 📦MESSAGES_SENT_RCVD: an array element holding the number of messages sent and received. The array is indexed by method code. Each entry is a pair of unsigned 64-bit integers (packed end to end) representing sent and received 💌EWMA_BYTES_SENT(32 bits): a single-value element holding an unsigned 32-bit integer for an exponential weighted average of bytes sent per second by this peer 📈
sent = alpha x sent_present + (1 - alpha) x sent_lastHere sent_present is the bytes sent per second since the last calculation, and sent_last is the last calculation of bytes sent per second. A suitable value for alpha is 0.8 (or another value the implementation picks). This value is calculated every five seconds (or another time period the implementation picks). For the very first time period, the value should simply be the average of bytes sent in that period 🌸
EWMA_BYTES_RCVD(32 bits): a single-value element holding an unsigned 32-bit integer for an exponential weighted average of bytes received per second by this peer 📉
rcvd = alpha x rcvd_present + (1 - alpha) x rcvd_lastHere rcvd_present is the bytes received per second since the last calculation, and rcvd_last is the last calculation of bytes received per second. A suitable value for alpha is 0.8 (or another value the implementation picks). This value is calculated every five seconds (or another time period the implementation picks). For the very first time period, the value should simply be the average of bytes received in that period ✨
UNDERLAY_HOP(8 bits): shows the IP-layer hops from the intermediate peer that receives the diagnostics message to the next-hop peer for this message 🛣️ (Note: RELOAD does not require the intermediate peers to look into the message body. So, here we use PathTrack to gather underlay hops for diagnostics purposes 🕵️♀️)BATTERY_STATUS(8 bits): the leftmost bit shows whether this peer is using a battery or not. If that bit is clear (set to "0"), the peer is using a battery for power 🔋 The other 7 bits are to be determined by specific applications 🌈
6. Message Processing 💅
6.1. Message Creation and Transmission
okay bestie, when you're putting together either a Ping message with diagnostic extensions or a PathTrack message 🦋, the sender starts by making a DiagnosticsRequest data structure ✨. The timestamp_initiated field gets set to the current time, and the expiration field is built off of that time ⏰. The sender also fills in the dMFlags field and flips on any number of the flags (even all of them 👑) to ask for particular diagnostic info. The sender MAY leave all the bits unset, though, which just means "I'm not asking for anything in particular" 🙈.
The sender MAY also tack diagnostic extensions onto the DiagnosticsRequest data structure to ask for extra info 🌸.
If the sender includes any extensions, it MUST work out the length of those extensions and put that number in the ext_length field 🧮. If there are no extensions, the sender MUST set ext_length to zero 💖.
The format of the DiagnosticRequest data structure and its fields MUST follow the restrictions in Section 5.1 🎀.
When building a Ping message with diagnostic extensions, the sender MUST create a MessageExtension structure as defined in RELOAD [RFC6940], with the value of type set to 0x2 and the value of critical set to FALSE 💅. The value of extension_contents MUST be a DiagnosticsRequest structure as defined above. The message MAY be directed to a particular NodeID or ResourceID, but it MUST NOT be sent to the broadcast NodeID 🚫📣.
When building a PathTrack message, the sender MUST set the message_code for the RELOAD MessageContents structure to path_track_req 0x27 🛤️. The request field of the PathTrackReq MUST be set to the DiagnosticsRequest data structure defined above. The destination field MUST be set to the desired destination, which MAY be either a NodeID or ResourceID but SHOULD NOT be the broadcast NodeID 🎯.
6.2. Message Processing: Intermediate Peers
okay so when a request shows up at a peer, and that peer's responsible ID space does NOT cover the destination ID of the request 🙅♀️, the peer MUST keep processing the request according to the overlay's routing mode from the RELOAD protocol 🧭.
In a P2P overlay, error responses can come from either an intermediate peer or the responsible peer 🫶. When a request lands on a peer, that peer might spot connectivity failures or malfunctioning peers using the overlay's predefined rules, like checking the Via List or underlay error messages 🕵️♀️. In that case, the intermediate peer sends an error response back to the initiator node, reporting any malfunctioning node info it has in the error message payload 💌. All error responses generated MUST contain the appropriate error code 🏷️.
Every intermediate peer that gets a Ping message with extensions (and that understands the extension), or gets a PathTrack request or response, MUST check the expiration value (Unix time format) to see if the message has expired ⌛. If it has, the intermediate peer MUST generate a response with error code 0x17 "Error_Message_Expired", return that response to the initiator node, and discard the message 🗑️. Not me watching a message expire 💀.
The intermediate peer MUST return an error response with the error code 0x15 "Error_Underlay_Destination_Unreachable" when it gets an ICMP message with "Destination Unreachable" information after forwarding the request to the destination peer 🚧.
The intermediate peer MUST return an error response with the error code 0x16 "Error_Underlay_Time_Exceeded" when it gets an ICMP message with "Time Exceeded" information after forwarding the received request ⏳.
The peer MUST return an error response with error code 0x18 "Error_Upstream_Misrouting" when it finds that its upstream peer is disobeying the overlay's routing rules 🙅. The immediate upstream peer information MUST also be conveyed to the initiator node 📮.
The peer MUST return an error response with error code 0x19 "Error_Loop_Detected" when it finds a loop by analysing the Via List 🔁.
The peer MUST return an error response with error code 0x1a "Error_TTL_Hops_Exceeded" when it finds that the TTL field value is no more than 0 while forwarding 🪫.
6.3. Message Response Creation
when a diagnostic request message arrives at a peer, that peer is responsible for the destination ID in the forwarding header 📬. As long as it understands the extension (for Ping) or the new PathTrack request type, it MUST follow the RELOAD specifications to form the response header, and then do the following 👇:
- When constructing a PathTrack response, the sender MUST set the
message_codefor the RELOADMessageContentsstructure topath_track_ans 0x28🌷. - The receiver MUST check the expiration value (Unix time format) in the
DiagnosticsRequestto see if the message has expired. If it has, the peer MUST generate a response with the error code0x17 "Error_Message_Expired", return the response to the initiator node, and discard the message 🙈. - If the message has NOT expired, the receiver MUST build a
DiagnosticsResponsestructure like this: 1) the TTL value from the forwarding header gets copied into thehop_counterfield of theDiagnosticsResponsestructure (the default TTL at the start is 100 hops, unless the overlay configuration has overridden it 🧠), and 2) the receiver generates a Unix time format timestamp for the current time of day and puts it in thetimestamp_receivedfield, then builds a new expiration time and puts it in theexpirationfield of theDiagnosticsResponse⏱️. - The destination peer MUST check whether the initiator node is authorized to request specific types of diagnostic information. If that checks out, it appends the diagnostic information requested in the
dMFlagsanddiagnostic_extensions(if any) to theDiagnosticsResponsestructure, using thediagnostic_info_listfield 📋. If any information gets returned, the receiver MUST calculate the length of the response and setext_lengthappropriately. If no diagnostic information gets returned,ext_lengthMUST be set to zero 🧾. - The format of the
DiagnosticResponsedata structure and its fields MUST follow the restrictions in Section 5.2 🎀. - If there's an error, an error response containing the error code, followed by the description (if there is one), MUST be created and sent to the sender 🚨. If the initiator node asks for diagnostic information it is not authorized to query, the receiving peer MUST return an error response with the error code
2 "Error_Forbidden"🔒.
6.4. Interpreting Results
the initiator node, and also the responding peer, may compute the overlay One-Way-Delay time using the value in timestamp_received and the timestamp_initiated field 🧮✨. However, for a single hop measurement, the traditional measurement methods (IP-layer ping) MUST be used instead of the overlay layer diagnostics methods 🏓.
A P2P overlay network using the diagnostics methods in this document MUST enforce time synchronization with a central time server ⏰🫂. The Network Time Protocol [RFC5905] can usually keep time within tens of milliseconds over the public Internet, and it can reach better than one millisecond accuracy on local area networks under ideal conditions 🌈. However, this document does not specify the choice of time resolution and synchronization, and leaves that up to the implementation 🤷♀️.
The initiator node that receives the Ping response may check the hop_counter field and compute the overlay hops to the destination peer, which gives statistics on connectivity quality from the perspective of overlay hops 📊💜.
7. Authorization through Overlay Configuration
okay so different users and nodes can get different levels of access control 👑. For example, diagnostic information A can be accessed by nodes 1 and 2, but diagnostic information B can only be accessed by node 2 🔐.
The overlay configuration file MUST contain the following XML elements to authorize a node to access the relevant diagnostic Kinds 🧾:
diagnostic-kind: This has the attributekind, which holds the hexadecimal number indicating the diagnostic Kind ID. This attribute has the same value as in Section 9.2, and at least one subelementaccess-node🏷️.access-node: This element contains one hexadecimal number indicating a NodeID, and the node with this NodeID is allowed to access the diagnostickindunder the samediagnostic-kindelement 🫶.
8. Security Considerations
okay, this part is SERIOUS bestie 😭🚨. The authorization for diagnostic information must be designed with care so it doesn't become a way for attackers to retrieve information for both attacks. It should also be noted that attackers can use diagnostics to analyze overlay information and go after certain key peers 🕵️♀️. For example, diagnostic information might be used to fingerprint a peer, and then that peer loses its anonymity characteristics. Anonymity might be very important for some P2P overlay networks, and defenses against that kind of fingerprinting are probably very hard 💀. So networks where anonymity matters a LOT may find implementing diagnostics problematic, or even undesirable, even though it has many advantages 🙈.
As this document is a RELOAD extension, it follows the RELOAD message header and routing specifications 📜. The common security considerations described in the base document [RFC6940] also apply to this document 🛡️. Overlays may define their own requirements on who can collect and share diagnostic information 🔐✨.
9. IANA Considerations 🎀
9.1. Diagnostics Flag ✨
okay so IANA made a "RELOAD Diagnostics Flag" registry under protocol RELOAD 💅 Each entry is a 1-bit flag inside the 64-bit integer dMFlags, and each one says which diagnostic info you want back (the stuff from Section 4.3.1). New entries SHALL be defined via Standards Action as per [RFC5226]. Here's the initial lineup, and it's giving full menu 🔥
+-------------------------+----------------------------+----------+
| Diagnostic Information |Diagnostic Flag in dMFlags | Reference|
|-------------------------+----------------------------+----------|
|Reserved All 0s value | 0x 0000 0000 0000 0000 | RFC 7851 |
|Reserved First Bit | 0x 0000 0000 0000 0001 | RFC 7851 |
|STATUS_INFO | 0x 0000 0000 0000 0002 | RFC 7851 |
|ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0004 | RFC 7851 |
|PROCESS_POWER | 0x 0000 0000 0000 0008 | RFC 7851 |
|UPSTREAM_BANDWIDTH | 0x 0000 0000 0000 0010 | RFC 7851 |
|DOWNSTREAM_ BANDWIDTH | 0x 0000 0000 0000 0020 | RFC 7851 |
|SOFTWARE_VERSION | 0x 0000 0000 0000 0040 | RFC 7851 |
|MACHINE_UPTIME | 0x 0000 0000 0000 0080 | RFC 7851 |
|APP_UPTIME | 0x 0000 0000 0000 0100 | RFC 7851 |
|MEMORY_FOOTPRINT | 0x 0000 0000 0000 0200 | RFC 7851 |
|DATASIZE_STORED | 0x 0000 0000 0000 0400 | RFC 7851 |
|INSTANCES_STORED | 0x 0000 0000 0000 0800 | RFC 7851 |
|MESSAGES_SENT_RCVD | 0x 0000 0000 0000 1000 | RFC 7851 |
|EWMA_BYTES_SENT | 0x 0000 0000 0000 2000 | RFC 7851 |
|EWMA_BYTES_RCVD | 0x 0000 0000 0000 4000 | RFC 7851 |
|UNDERLAY_HOP | 0x 0000 0000 0000 8000 | RFC 7851 |
|BATTERY_STATUS | 0x 0000 0000 0001 0000 | RFC 7851 |
|Reserved Last Bit | 0x 8000 0000 0000 0000 | RFC 7851 |
|Reserved All 1s value | 0x ffff ffff ffff ffff | RFC 7851 |
+-------------------------+----------------------------+----------+9.2. Diagnostic Kind ID 🌸
this one is the registry for the 16-bit Diagnostic Kind IDs. These are the diagnostics extension data kinds that ride along in the diagnostic request and response messages, as described in Sections and 5.1 and 5.2. Code points from 0x0001 to 0x003e are asked to be assigned together with flags within the "RELOAD Diagnostics Flag" registry. The registration procedure for the "RELOAD Diagnostic Kind ID" registry is Standards Action as defined in RFC 5226. so organized, I'm obsessed 🫶
+----------------------+---------------+---------------+
| Diagnostic Kind | Code | Specification |
+----------------------+---------------+---------------+
| Reserved | 0x0000 | RFC 7851 |
| STATUS_INFO | 0x0001 | RFC 7851 |
| ROUTING_TABLE_SIZE | 0x0002 | RFC 7851 |
| PROCESS_POWER | 0x0003 | RFC 7851 |
| UPSTREAM_BANDWIDTH | 0x0004 | RFC 7851 |
| DOWNSTREAM_BANDWIDTH | 0x0005 | RFC 7851 |
| SOFTWARE_VERSION | 0x0006 | RFC 7851 |
| MACHINE_UPTIME | 0x0007 | RFC 7851 |
| APP_UPTIME | 0x0008 | RFC 7851 |
| MEMORY_FOOTPRINT | 0x0009 | RFC 7851 |
| DATASIZE_STORED | 0x000a | RFC 7851 |
| INSTANCES_STORED | 0x000b | RFC 7851 |
| MESSAGES_SENT_RCVD | 0x000c | RFC 7851 |
| EWMA_BYTES_SENT | 0x000d | RFC 7851 |
| EWMA_BYTES_RCVD | 0x000e | RFC 7851 |
| UNDERLAY_HOP | 0x000f | RFC 7851 |
| BATTERY_STATUS | 0x0010 | RFC 7851 |
| Unassigned | 0x0011-0x003e | RFC 7851 |
| local use (Reserved) | 0xf000-0xfffe | RFC 7851 |
| Reserved | 0xffff | RFC 7851 |
+----------------------+---------------+---------------+
Table 1: Diagnostic Kind9.3. Message Codes 💜
this doc introduces two brand new message types and their responses, so the "RELOAD Message Codes" registry (defined in RELOAD [RFC6940]) gets some fresh additions 🧚
+-------------------+------------+----------+
| Message Code Name | Code Value | RFC |
+-------------------+------------+----------+
| path_track_req | 0x27 | RFC 7851 |
| path_track_ans | 0x28 | RFC 7851 |
+-------------------+------------+----------+
Table 2: Extensions to RELOAD Message Codes9.4. Error Code 🚨
the following new error codes are added to the "RELOAD Error Codes" registry. Sorry, the underlay ones are giving a lot of drama 💀
+----------------------------------------+------------+-----------+
| Error Code Name | Code Value | Reference |
+----------------------------------------+------------+-----------+
| Error_Underlay_Destination_Unreachable | 0x15 | RFC 7851 |
| Error_Underlay_Time_Exceeded | 0x16 | RFC 7851 |
| Error_Message_Expired | 0x17 | RFC 7851 |
| Error_Upstream_Misrouting | 0x18 | RFC 7851 |
| Error_Loop_Detected | 0x19 | RFC 7851 |
| Error_TTL_Hops_Exceeded | 0x1A | RFC 7851 |
+----------------------------------------+------------+-----------+
Table 3: RELOAD Error Codes9.5. Message Extension 🦋
this doc adds one new RELOAD extension code, and it's the diagnostic ping one ✨
+-----------------+------+-----------+
| Extension Name | Code | Reference |
+-----------------+------+-----------+
| Diagnostic_Ping | 0x2 | RFC 7851 |
+-----------------+------+-----------+
Table 4: New RELOAD Extension Code9.6. XML Name Space Registration 🎀
this doc registers a URI for the config-diagnostics XML namespace in the IETF XML registry defined in [RFC3688]. Every element defined in this document lives in this namespace. The details are:
- URI:
urn:ietf:params:xml:ns:p2p:config-diagnostics - Registrant Contact: The IESG.
- XML: N/A; the requested URIs are XML namespaces
the overlay configuration file MUST contain the following XML declaring P2P diagnostics as a mandatory extension to RELOAD. this is a must-do, bestie 😤
<mandatory-extension>
urn:ietf:params:xml:ns:p2p:config-diagnostics
</mandatory-extension>10. References 📚
10.1. Normative References
- [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981,
http://www.rfc-editor.org/info/rfc792. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
http://www.rfc-editor.org/info/rfc2119. - [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004,
http://www.rfc-editor.org/info/rfc3688. - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008,
http://www.rfc-editor.org/info/rfc5226. - [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
http://www.rfc-editor.org/info/rfc5905. - [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, January 2014,
http://www.rfc-editor.org/info/rfc6940. - [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, DOI 10.17487/RFC7263, June 2014,
http://www.rfc-editor.org/info/rfc7263.
10.2. Informative References
- [UnixTime] Wikipedia, "Unix time", April 2016,
https://en.wikipedia.org/w/index.php?title=Unix_time&oldid=715503178. - [P2PSIP-CONCEPTS] Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", Work in Progress, draft-ietf-p2psip-concepts-09, April 2016.
- [Overlay-Failure-Detection] Zhuang, S., Geels, D., Stoica, I., and R. Katz, "On failure detection algorithms in overlay networks", In Proceedings of the IEEE INFOCOM 2005, pp. 2112-2123, DOI 10.1109/INFCOM.2005.1498487, March 2005.
- [Handling_Churn_in_a_DHT] Rhea, S., Geels, D., Roscoe, T., and J. Kubiatowicz, "Handling Churn in a DHT", In Proceedings of the USENIX Annual Technical Conference, June 2004.
- [Diagnostic_Framework] Jin, X., Xiong, Y., Zhang, Q., and S. Chan, "A Diagnostic Framework for Peer-to-peer Streaming", IEEE ICME 2006, July 2006.
Appendix A. Examples 🎀
okay, time for the fun part! Below, we sketch how these metrics can be used 🧠
A.1. Example 1
a peer may set EWMA_BYTES_SENT and EWMA_BYTES_RCVD flags in the PathTrackReq to its direct neighbors 👀 A peer can use EWMA_BYTES_SENT and EWMA_BYTES_RCVD of another peer to infer whether it is acting as a media relay. It may then choose not to forward any requests for media relay to this peer. Similarly, among the various candidates for filling up a routing table, a peer may prefer a peer with a large UPTIME value, small RTT, and small LAST_CONTACT value. main character energy 💅
A.2. Example 2
a peer may set the STATUS_INFO Flag in the PathTrackReq to a remote destination peer. The overlay has its own threshold definition for congestion. The peer can obtain knowledge of all the status information of the intermediate peers along the path, then it can choose other paths to that node for the subsequent requests. so smart, it's giving strategy 🧚♀️
A.3. Example 3
a peer may use Ping to evaluate the average overlay hops to other peers by sending PingReq to a set of random resource or node IDs in the overlay. A peer may adjust its timeout value according to the change of average overlay hops. literally the cutest little adjustment loop ever 🌈💖
Appendix B. Problems with Generating Multiple Responses on Path 🦋
okay so this appendix is literally a "why we said no" moment and I'm obsessed with it 💅 An earlier draft of this document looked at letting every intermediate peer generate its own response as the message passed through the overlay. The team ended up ditching that idea. 🙈
One reason it got tossed: it could be used as a DoS trick. An attacker sends one message pretending to be from a spoofed "sender," which is the real sender they want to hurt. Then every intermediate peer on the path fires back a response to that poor spoofed sender, so one message turns into a bunch of messages landing on the victim. 😭 Authentication could cut down on some of that risk, but it still breaks the whole request-response vibe of RELOAD, because one request would be getting multiple responses. Yes, getting one request answered by every peer on the route would be more efficient, but it was judged to be too big a security risk and not very RELOAD-y. 🔥
Acknowledgments 🫶
Huge thanks to Zheng Hewen for the initial draft version of this document! 💖 Also a big shoutout to Bruce Lowekamp, Salman Baset, Henning Schulzrinne, Jiang Haifeng, and Marc Petit-Huguenin for the email discussion and their valued comments 🎀 And special thanks to Henry Sinnreich for helping with the usage scenarios text ✨ Finally, thank you to the authors of the RELOAD protocol for handing over the diagnostics text to this document 🧚
Authors' Addresses 🌸
Haibin Song Huawei
Email: haibin.song@huawei.com
Jiang Xingfeng Huawei
Email: jiangxingfeng@huawei.com
Roni Even Huawei 14 David Hamelech Tel Aviv 64953 Israel
Email: ron.even.tlv@gmail.com
David A. Bryan ethernot.org Cedar Park, Texas United States
Email: dbryan@ethernot.org
Yi Sun ICT
Email: sunyi@ict.ac.cn
📦 where this page comes from
- ietf: rfc7851 2016-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms