idnits 2.17.1
draft-ietf-p2psip-diagnostics-14.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 395 has weird spacing: '... opaque diagn...'
== Line 640 has weird spacing: '...ionType type;...'
== The document seems to contain a disclaimer for pre-RFC5378 work, but was
first submitted on or after 10 November 2008. The disclaimer is usually
necessary only for documents that revise or obsolete older RFCs, and that
take significant amounts of text from those RFCs. If you can contact all
authors of the source material and they are willing to grant the BCP78
rights to the IETF Trust, you can and should remove the disclaimer.
Otherwise, the disclaimer is needed and you can ignore this comment.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (February 14, 2014) is 3723 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: '0x00' is mentioned on line 538, but not defined
== Missing Reference: '0x0F' is mentioned on line 538, but not defined
== Unused Reference: 'RFC0792' is defined on line 1090, but no explicit
reference was found in the text
== Unused Reference: 'I-D.ietf-p2psip-self-tuning' is defined on line 1115,
but no explicit reference was found in the text
== Unused Reference: 'I-D.ietf-p2psip-concepts' is defined on line 1121,
but no explicit reference was found in the text
== Outdated reference: A later version (-15) exists of
draft-ietf-p2psip-self-tuning-10
== Outdated reference: A later version (-09) exists of
draft-ietf-p2psip-concepts-05
-- Obsolete informational reference (is this intentional?): RFC 5226
(Obsoleted by RFC 8126)
Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 P2PSIP Working Group H. Song
3 Internet-Draft X. Jiang
4 Intended status: Standards Track R. Even
5 Expires: August 18, 2014 Huawei
6 D. Bryan
7 Ethernot.org
8 Y. Sun
9 ICT-CAS
10 February 14, 2014
12 P2P Overlay Diagnostics
13 draft-ietf-p2psip-diagnostics-14
15 Abstract
17 This document describes mechanisms for P2P overlay diagnostics. It
18 defines extensions to the RELOAD P2PSIP base protocol to collect
19 diagnostic information, and details the protocol specifications for
20 these extensions. Useful diagnostic information for connection and
21 node status monitoring is also defined. The document also describes
22 the usage scenarios and provides examples of how these methods are
23 used to perform diagnostics in P2P overlay networks.
25 Status of This Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at http://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on August 18, 2014.
42 Copyright Notice
44 Copyright (c) 2014 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 This document may contain material from IETF Documents or IETF
58 Contributions published or made publicly available before November
59 10, 2008. The person(s) controlling the copyright in some of this
60 material may not have granted the IETF Trust the right to allow
61 modifications of such material outside the IETF Standards Process.
62 Without obtaining an adequate license from the person(s) controlling
63 the copyright in such materials, this document may not be modified
64 outside the IETF Standards Process, and derivative works of it may
65 not be created outside the IETF Standards Process, except to format
66 it for publication as an RFC or to translate it into languages other
67 than English.
69 Table of Contents
71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
73 3. Diagnostic Scenarios . . . . . . . . . . . . . . . . . . . . 4
74 4. Overview of operations . . . . . . . . . . . . . . . . . . . 5
75 4.1. "Ping-like" Behavior: Extending Ping . . . . . . . . . . 7
76 4.2. "Traceroute-like" Behavior: The Path_Track Method . . . . 7
77 5. RELOAD diagnostic extensions . . . . . . . . . . . . . . . . 8
78 5.1. Diagnostic Data Structures . . . . . . . . . . . . . . . 8
79 5.1.1. DiagnosticsRequest Data Structure . . . . . . . . . . 9
80 5.1.2. DiagnosticsResponse Data Structure . . . . . . . . . 10
81 5.1.3. dMFlags and Diagnostic Kind ID Types . . . . . . . . 11
82 5.1.4. Extending Diagnostic Information . . . . . . . . . . 14
83 5.2. Request Extension: Ping . . . . . . . . . . . . . . . . . 14
84 5.3. New Request: PathTrack . . . . . . . . . . . . . . . . . 14
85 5.3.1. PathTrack Request . . . . . . . . . . . . . . . . . . 15
86 5.3.2. PathTrack Response . . . . . . . . . . . . . . . . . 15
87 5.4. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 16
88 5.5. Message Processing . . . . . . . . . . . . . . . . . . . 16
89 5.5.1. Message Creation and Transmission . . . . . . . . . . 16
90 5.5.2. Message Processing: Intermediate Peers . . . . . . . 17
91 5.5.3. Message Response Creation . . . . . . . . . . . . . . 18
92 5.5.4. Interpreting Results . . . . . . . . . . . . . . . . 19
93 6. Authorization through Overlay Configuration . . . . . . . . . 19
94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
96 8.1. Diagnostic Kind ID Types . . . . . . . . . . . . . . . . 20
97 8.2. Message Codes . . . . . . . . . . . . . . . . . . . . . . 21
98 8.3. Error Code . . . . . . . . . . . . . . . . . . . . . . . 22
99 8.4. Message Extension . . . . . . . . . . . . . . . . . . . . 22
100 8.5. Diagnostics Flag . . . . . . . . . . . . . . . . . . . . 22
101 8.6. XML Name Space Registration . . . . . . . . . . . . . . . 23
102 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
104 10.1. Normative References . . . . . . . . . . . . . . . . . . 24
105 10.2. Informative References . . . . . . . . . . . . . . . . . 24
106 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 25
107 A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 25
108 A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 25
109 A.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 25
110 Appendix B. Problems with Generating Multiple Responses on Path 26
111 Appendix C. Changes to the Draft . . . . . . . . . . . . . . . . 26
112 C.1. Changes since -00 version . . . . . . . . . . . . . . . . 26
113 C.2. Changes since -01 version . . . . . . . . . . . . . . . . 26
114 C.3. Changes since -02 version . . . . . . . . . . . . . . . . 27
115 C.4. Changes since -03 version . . . . . . . . . . . . . . . . 27
116 C.5. Changes since -04 version . . . . . . . . . . . . . . . . 27
117 C.6. Changes since -05 version . . . . . . . . . . . . . . . . 27
118 C.7. Changes in version -10 . . . . . . . . . . . . . . . . . 27
119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
121 1. Introduction
123 In the last few years, overlay networks have rapidly evolved and
124 emerged as a promising platform for deployment of new applications
125 and services in the Internet. One of the reasons overlay networks
126 are seen as an excellent platform for large scale distributed systems
127 is their resilience in the presence of failures. This resilience has
128 three aspects: data replication, routing recovery, and static
129 resilience. Routing recovery algorithms are used to repopulate the
130 routing table with live nodes when failures are detected. Static
131 resilience measures the extent to which an overlay can route around
132 failures even before the recovery algorithm repairs the routing
133 table. Both routing recovery and static resilience rely on accurate
134 and timely detection of failures.
136 There are a number of situations in which some nodes in a P2P overlay
137 may malfunction or behave badly. For example, these nodes may be
138 disabled, congested, or may be misrouting messages. The impact of
139 these malfunctions on the overlay network may be a degradation of
140 quality of service provided collectively by the peers in the overlay
141 network or an interruption of the overlay services. It is desirable
142 to identify malfunctioning or badly behaving peers through diagnostic
143 tools, and exclude or reject them from the P2P system. Node failures
144 may be also caused by underlying failures, for example the recovery
145 from an incorrect overlay topology may be slow when the IP layer
146 routing failover speed after link failures is very slow. Moreover,
147 if a backbone link fails and the failover is slow, the network may be
148 partitioned, leading to partitions of overlay topologies and
149 inconsistent routing results between different partitioned
150 components.
152 Some keep-alive algorithms based on periodic probe and acknowledge
153 mechanisms enable accurate and timely detection of failures of one
154 node's neighbors [Overlay-Failure-Detection], but these algorithms by
155 themselves can only detect the disabled neighbors using the periodic
156 method. This may not be enough for service providers operating the
157 overlay network.
159 A single, general P2PSIP overlay diagnostic framework supporting
160 periodic and on-demand methods for detecting node failures and
161 network failures is desirable. This document describes a general
162 P2PSIP overlay diagnostic extension to the P2PSIP base protocol
163 RELOAD [I-D.ietf-p2psip-base] and is intended as a complement to
164 keep-alive algorithms in the P2PSIP overlay itself.
166 2. Terminology
168 This document uses the concepts defined in RELOAD
169 [I-D.ietf-p2psip-base].
171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
173 document are to be interpreted as described in [RFC2119].
175 3. Diagnostic Scenarios
177 P2P systems are self-organizing and ideally require no network
178 management in the traditional sense to set up and to configure
179 individual P2P nodes. However, users of an overlay, as well as P2P
180 service providers may contemplate usage scenarios where some
181 monitoring and diagnostics are required. We present a simple
182 connectivity test and some useful diagnostic information that may be
183 used in such diagnostics.
185 The common usage scenarios for P2P diagnostics can be broadly
186 categorized in three classes:
188 a. Automatic diagnostics built into the P2P overlay routing
189 protocol. Nodes perform periodic checks of known neighbors and
190 remove those nodes from the routing tables that fail to respond
191 to connectivity checks [Handling_Churn_in_a_DHT]. However, the
192 unresponsive nodes may only be temporarily disabled, for example
193 due to some local cryptographic processing overload, disk
194 processing overload or link overload. It is therefore useful to
195 repeat the connectivity checks to see if such nodes have
196 recovered and can be again placed in the routing tables. This
197 process is known as 'failed node recovery' and can be optimized
198 as described in the paper "Handling Churn in a DHT"
199 [Handling_Churn_in_a_DHT].
201 b. Diagnostics for a particular node to follow up an individual user
202 complaint or failure. For example, in this case a technical
203 support person may use a desktop sharing application with the
204 permission of the user to determine remotely the health and
205 possible problems with the malfunctioning node. Part of the
206 remote diagnostics may consist of simple connectivity tests with
207 other nodes in the P2PSIP overlay and retrieval statistics of
208 nodes from the overlay. The simple connectivity tests are not
209 dependent on the type of P2PSIP overlay. Note that other tests
210 may be required as well, such as checking the health and
211 performance of the user's computer or mobile device and also
212 checking the bandwidth of the link connecting the user to the
213 Internet.
215 c. P2P system diagnostics to check the overall health of the P2P
216 overlay network, the consumption of network bandwidth, for the
217 presence of problem links and also to check for abusive or
218 malicious nodes. This is not a trivial problem and has been
219 studied in detail for content and streaming P2P overlays
220 [Diagnostic_Framework] as well as in earlier P2PSIP documents
221 [Diagnostics_and_NAT_traversal_in_P2PP]. While this is a
222 difficult problem, a great deal of information can be obtained in
223 helping these diagnostics by sending messages to diagnose the
224 network. This document provides a framework for obtaining this
225 information.
227 4. Overview of operations
229 The diagnostic mechanisms described in this document are mainly
230 intended to detect and locate failures or monitor performance in
231 P2PSIP overlay networks. It provides mechanisms to detect and locate
232 malfunctioning or badly behaving nodes including disabled nodes,
233 congested nodes and misrouting peers. It provides a mechanism to
234 detect direct connectivity or connectivity to a specified node, a
235 mechanism to detect the availability of specified resource records
236 and a mechanism to discover P2PSIP overlay topology and the underlay
237 topology failures.
239 The P2PSIP diagnostics extensions define two mechanisms to collect
240 data. The first is an extension to the RELOAD Ping mechanism,
241 allowing diagnostic data to be queried from a node, as well as to
242 diagnose the path to that node. The second is a new method and
243 response, PathTrack, for collecting diagnostic information
244 iteratively. Payloads for these mechanisms allowing diagnostic data
245 to be collected and represented are presented, and additional error
246 codes are introduced. Essentially, this document reuses RELOAD
247 [I-D.ietf-p2psip-base]specification and extends them to introduce the
248 new diagnostics methods. The extensions strictly follow RELOAD
249 specification on the messages routing, transport, NAT traversal etc.
250 The diagnostic methods are however P2PSIP protocol independent.
252 This document primarily describes how to detect and locate failures
253 including disabled nodes, congested nodes, misrouting behaviors and
254 underlying network faults in P2PSIP overlay networks through a simple
255 and efficient mechanism. This mechanism is modeled after the ping/
256 traceroute paradigm: ping [RFC0792]is used for connectivity checks,
257 and traceroute is used for hop-by-hop fault localization as well as
258 path tracing. This document specifies a "ping-like" mode (by
259 extending the RELOAD Ping method to gather diagnostics) and a
260 "traceroute-like" mode (by defining the new PathTrack method) for
261 diagnosing P2PSIP overlay networks.
263 One way these tools can be used is to detect the connectivity to the
264 specified node or the availability of the specified resource-record
265 through the extended P2PSIP Ping operation. Once the overlay network
266 receives some alarms about overlay service degradation or
267 interruption, a Ping is sent. If the Ping fails, one can then send a
268 PathTrack to determine where the fault lies.
270 The diagnostic information can only be provided to authorized nodes.
271 Some diagnostic information can be provided to all the participants
272 in the P2PSIP overlay, and some other diagnostic information can only
273 be provided to the nodes authorized by the local or overlay policy.
274 The authorization depends on the type of the diagnostic information
275 and the administrative considerations, and is application specific.
277 This document considers the general administrative scenario based on
278 diagnostic kind type, where a whole overlay can authorize a certain
279 type of diagnostic information to a small list of particular nodes
280 (e.g. administrative nodes). That means, if a node gets the
281 authorization to access a diagnostic kind type, it can access that
282 information from all nodes in the overlay network. It leaves the
283 scenario where a particular node authorizes its diagnostic
284 information to a particular list of nodes out of scope. This could
285 be achieved by extension of this document if there is requirement in
286 the near future. The default policy or access rule for a type of
287 diagnostic information is "permit" unless specified in the
288 diagnostics extension document. As the RELOAD protocol already
289 requires that each messge carries the message signature of the
290 sender, the receiver of the diagnostics requests can use the
291 signature to identify the sender. It can then use the overlay
292 configuration file with this signature to determine which types of
293 diagnostic information that node is authorized for.
295 4.1. "Ping-like" Behavior: Extending Ping
297 To provide "ping-like" behavior, the RELOAD Ping method has been
298 extended to collect diagnostic data along the path. The request
299 message is forwarded by the intermediate peers along the path and
300 then terminated by the responsible peer. After optional local
301 diagnostics, the responsible peer returns a response message. If an
302 error is found when routing, an Error response is sent to the
303 initiator node by the intermediate peer.
305 The message flow of a Ping message (with diagnostic extensions) is as
306 follows:
308 Peer A Peer B Peer C Peer D
309 | | | |
310 |(1). PingReq | | |
311 |------------------->|(2). PingReq | |
312 | |------------------->|(3). PingReq |
313 | | |------------------->|
314 | | | |
315 | | |<-------------------|
316 | |<-------------------|(4). PingAns |
317 |<-------------------|(5). PingAns | |
318 |(6). PingAns | | |
319 | | | |
321 Figure 1: Ping Diagnostic Message Flow
323 4.2. "Traceroute-like" Behavior: The Path_Track Method
325 We define a simple PathTrack method for retrieving diagnostic
326 information iteratively. For example, in Figure 2, the initiator
327 node A asks its neighbor B which is the next hop peer to the
328 destination ID, and then retrieves the next hop peer C information,
329 along with optional diagnostic information of B, to the initiator
330 node. Then the initiator node A asks the next hop peer C (directly
331 or via symmetric routing) to get the further next hop peer D
332 information and diagnostic information of C. Unless a failure
333 prevents the message from being forwarded, this step can be
334 iteratively repeated until the request reaches responsible peer D for
335 the destination ID, and retrieves diagnostic information of peer D.
337 The message flow of a PathTrack message (with diagnostic extensions)
338 is as follows:
340 Peer-A Peer-B Peer-C Peer-D
341 | | | |
342 |(1).PathTrackReq | | |
343 |------------------->| | |
344 |(2).PathTrackAns | | |
345 |<-------------------| | |
346 | |(3).PathTrackReq | |
347 |--------------------|------------------->| |
348 | |(4).PathTrackAns | |
349 |<-------------------|--------------------| |
350 | | |(5).PathTrackReq |
351 |--------------------|--------------------|------------------->|
352 | | |(6).PathTrackAns |
353 |<-------------------|--------------------|--------------------|
354 | | | |
356 Figure 2: PathTrack Diagnostic Message Flow
358 There have been proposals that RouteQuery and a series of Fetch
359 requests can be used to replace the PathTrack mechanism, but in the
360 presence of churn such an operation would not, strictly speaking,
361 provide identical results, as the path may change between RouteQuery
362 and Fetch operations. (although obviously the path could change
363 between steps of PathTrack as well).
365 5. RELOAD diagnostic extensions
367 This document extends RELOAD to carry diagnostic information.
368 Considering the special usage of diagnostics, this document defines
369 extensions for a payload to Ping, as well as the new method PathTrack
370 and its response. Additionally, new Error codes, message bodies for
371 conveying diagnostics, and some suggested common diagnostic values
372 are defined. Processing of the PathTrack message and the diagnostic
373 bodies is discussed.
375 The mechanism defined in this document follows the RELOAD
376 specification, the new request and response message use the message
377 format specified in RELOAD messages. Please refer to the RELOAD
378 [I-D.ietf-p2psip-base] for details of the protocol.
380 5.1. Diagnostic Data Structures
382 The diagnostics use the following common diagnostics data structures.
383 Two common structures are defined, DiagnosticsRequest for requesting
384 data, and DiagnosticsResponse for returning information.
386 5.1.1. DiagnosticsRequest Data Structure
388 The DiagnosticsRequest data structure is sent to request diagnostic
389 information and has the following form:
391 enum{ (2^16-1) } DiagnosticKindId;
393 struct{
394 DiagnosticKindId kind;
395 opaque diagnostic_extension_contents<0..2^32-1>;
396 }DiagnosticExtension;
398 struct{
399 uint64 expiration;
400 uint64 timestamp_initiated;
401 uint64 dMFlags;
402 uint32 length;
403 DiagnosticExtension diagnostic_extensions[length];
404 }DiagnosticsRequest;
406 The fields in the DiagnosticsRequest are as follows:
408 expiration : The time when the request will expire represented as
409 the number of milliseconds elapsed since midnight Jan 1, 1970 UTC
410 not counting leap seconds. This will have the same values for
411 seconds as standard UNIX time or POSIX time. More information can
412 be found at UnixTime [UnixTime]
414 timestamp_initiated : The time when the P2PSIP diagnostics request
415 was initiated represented as the number of milliseconds elapsed
416 since midnight Jan 1, 1970 UTC not counting leap seconds. This
417 will have the same values for seconds as standard UNIX time or
418 POSIX time.
420 length : the length of the extended diagnostic request information
421 in bytes. If the value is greater than or equal to 1, then some
422 extended diagnostic information is requested. The value of length
423 MUST NOT be negative.
425 dMFlags : A mandatory field which is an unsigned 64-bit integer
426 indicating which base diagnostic information the request initiator
427 node is interested in. The initiator sets different bits to
428 retrieve different kinds of diagnostic information. If dMFlags is
429 set to zero, then no base diagnostic information is conveyed in
430 the PathTrack response. If dMFlag is set to all '1's, then all
431 base diagnostic information values are requested. A request may
432 set any number of the flags to request the corresponding
433 diagnostic information.
435 Note this memo specifies the initial set of flags, the flags can
436 be extended. The dMflags indicate general diagnostic information
437 The mapping between the bits in the dMFlags and the diagnostic
438 information kind presented is as described in Section 8.5.
440 diagnostic_extensions : consists of one or more
441 DiagnosticExtension structures (see below) documenting additional
442 diagnostic information being requested.
444 Each DiagnosticExtension has the following fields:
446 kind : a numerical code indicating the extension kind of
447 diagnostic information(see Section 8.1). Note that kind 0xFFFE is
448 reserved for overlay specific diagnostics and may be used without
449 IANA registration for local diagnostic information. And the kind
450 from 0x0000 to 0x003F MUST NOT be indicated in the
451 diagnostic_extensions in the message request becasue they can be
452 represented in the dMFlags in a much simpler way.
454 diagnostic_extension_contents : the opaque data containing the
455 request for this particular extension. This data is extension
456 dependent.
458 5.1.2. DiagnosticsResponse Data Structure
460 enum { (2^16-1) } DiagnosticKindId;
461 struct{
462 DiagnosticKindId kind;
463 opaque diagnostic_info_contents<0..2^16-1>;
464 }DiagnosticInfo;
466 struct{
467 uint64 expiration;
468 uint64 timestamp_received;
469 uint8 hop_counter;
470 DiagnosticInfo diagnostic_info_list<0..2^32-1>;
471 }DiagnosticsResponse;
473 The fields in the DiagnosticsResponse are as follows:
475 expiration : The time when the response will expire represented as
476 the number of milliseconds elapsed since midnight Jan 1, 1970 UTC
477 not counting leap seconds. This will have the same values for
478 seconds as standard UNIX time or POSIX time.
480 timestamp_received : The time when P2PSIP Overlay diagnostic
481 request was received represented as the number of milliseconds
482 elapsed since midnight Jan 1, 1970 UTC not counting leap seconds.
484 This will have the same values for seconds as standard UNIX time
485 or POSIX time.
487 hop_counter : This field only appears in diagnostic responses. It
488 MUST be exactly copied from the TTL field of the forwarding header
489 in the received request. This information is sent back to the
490 request initiator, allowing it to compute the hops that the
491 message traversed in the overlay.
493 diagnostic_info_list : consists of one or more DiagnosticInfo
494 values containing the requested diagnostic information.
496 The fields in the DiagnosticInfo structure are as follows:
498 kind : A numeric code indicating the type of information being
499 returned. For base data requested using the dMFlags, this code
500 corresponds to the dMFlag set, and is described in Section 5.1.1.
501 For diagnostic extensions, this code will be identical to the
502 value of the DiagnosticKindId set in the "kind" field of the
503 DiagnosticExtension of the request. See Section 8.1.
505 diagnostic_information : Data containing the value for the
506 diagnostic information being reported. Various kinds of
507 diagnostic information can be retrieved, Please refer to
508 Section 5.1.3 for details of the diagnostic kind ID for the base
509 diagnostic information that may be reported.
511 5.1.3. dMFlags and Diagnostic Kind ID Types
513 The dMFlags field described above is a 64 bit field that allows
514 initiator nodes to identify up to 62 items of base information to
515 request (the first and last flags being reserved) when sending a
516 request. When the requested base information is returned in the
517 response, the value of the diagnostic kind ID will correspond to the
518 numeric field marked in the dMFlags in the request. The values for
519 the dMFlags are defined in Section 8.5 and the diagnostic kind IDs
520 are defined in Section 8.1. The information contained for each value
521 is described in this section.
523 STATUS_INFO (8 bits): A single value element containing an
524 unsigned byte representing whether or not the node is in
525 congestion status. An example usage of STATUS_INFO is for
526 congestion-aware routing. In this scenario, each peer has to
527 update its congestion status periodically, an intermediate peer in
528 the distributed hash table (DHT) network will choose its next hop
529 according to both the DHT routing algorithm and the status
530 information, and then forward requests to the chosen next hop, so
531 as to avoid increasing load on congested peers. The rightmost 4
532 bits are used and other bits MUST be cleared to "0"s for future
533 use. There are 16 levels of congestion status, with "0x00"
534 represent zero load and "0x0F" represent congested. This document
535 is not going to provide a measurement method for congestion,
536 although a node can contemplate its CPU/memory/bandwidth usage
537 percentage in the past seconds and normalize the highest value to
538 the range [0x00, 0x0F]. This document reserves these bits and
539 leave it for this purpose. A future draft may define it.
541 ROUTING_TABLE_SIZE (32 bits): A single value element containing an
542 unsigned 32-bit integer representing the number of peers in the
543 peer's routing table. The administrator of the overlay may be
544 interested in statistics of this value for reasons such as routing
545 efficiency. Access to this kind of diagnostic information MUST
546 NOT be allowed unless compliant to the rules defined in Section 6.
548 PROCESS_POWER (32 bits): A single value element containing an
549 unsigned 32-bit integer specifying the processing power of the
550 node in unit of MIPS.
552 BANDWIDTH (32 bits): A single value element containing an unsigned
553 32-bit integer specifying the bandwidth of the node in unit of
554 Kbps.
556 SOFTWARE_VERSION: A single value element containing a US-ASCII
557 string that identifies the manufacture, model, operating system
558 information and the version of the software. The format is as
559 follows: ApplicationProductToken (Platform; OS-or-CPU) *
560 VendorProductToken (VendorComment). One example is: MyReloadApp/
561 1.0 (Unix; Linux x86_64) libreload-java/0.7.0 (Stonyfish Inc.).
562 Access to this kind of diagnostic information MUST NOT be allowed
563 unless compliant to the rules defined in Section 6.
565 MACHINE_UPTIME (64 bits): A single value element containing an
566 unsigned 64-bit integer specifying the time the node has been up
567 in seconds.
569 APP_UPTIME (64 bits): A single value element containing an
570 unsigned 64-bit integer specifying the time the P2P application
571 has been up in seconds.
573 MEMORY_FOOTPRINT (32 bits): A single value element containing an
574 unsigned 32-bit integer representing the memory footprint of the
575 peer program in kibibytes (1024 bytes). Access to this kind of
576 diagnostic information MUST NOT be allowed unless compliant to the
577 rules defined in Section 6.
579 DATASIZE_STORED (64 bits): An unsigned 64-bit integer representing
580 the number of bytes of data being stored by this node. Access to
581 this kind of diagnostic information MUST NOT be allowed unless
582 compliant to the rules defined in Section 6.
584 INSTANCES_STORED: An array element containing the number of
585 instances of each kind stored. The array is indexed by Kind-ID.
586 Each entry is an unsigned 64-bit integer. Access to this kind of
587 diagnostic information MUST NOT be allowed unless compliant to the
588 rules defined in Section 6.
590 MESSAGES_SENT_RCVD: An array element containing the number of
591 messages sent and received. The array is indexed by method code.
592 Each entry in the array is a pair of unsigned 64-bit integers
593 (packed end to end) representing sent and received. Access to
594 this kind of diagnostic information MUST NOT be allowed unless
595 compliant to the rules defined in Section 6.
597 EWMA_BYTES_SENT (32 bits): A single value element containing an
598 unsigned 32-bit integer representing an exponential weighted
599 average of bytes sent per second by this peer. sent = alpha x
600 sent_present + (1 - alpha) x sent where sent_present represents
601 the bytes sent per second since the last calculation and sent
602 represents the last calculation of bytes sent per second. A
603 suitable value for alpha is 0.8. This value is calculated every
604 five seconds. Access to this kind of diagnostic information MUST
605 NOT be allowed unless compliant to the rules defined in Section 6.
607 EWMA_BYTES_RCVD (32 bits): A single value element containing an
608 unsigned 32-bit integer representing an exponential weighted
609 average of bytes received per second by this peer. rcvd = alpha x
610 rcvd_present + (1 - alpha) x rcvd where rcvd_present represents
611 the bytes received per second since the last calculation and rcvd
612 represents the last calculation of bytes received per second. A
613 suitable value for alpha is 0.8. This value is calculated every
614 five seconds. Access to this kind of diagnostic information MUST
615 NOT be allowed unless compliant to the rules defined in Section 6.
617 UNDERLAY_HOP (8 bits): Indicates the IP layer hops from the
618 intermediate peer which receives the diagnostics message to the
619 next hop peer for this message. (Note: RELOAD does not require
620 the intermediate peers to look into the message body. So here we
621 use PathTrack to gather underlay hops for diagnostics purpose).
623 BATTERY_STATUS (8 bits): The left-most bit is used to indicate
624 whether this peer is using battery or not. If this bit is clear
625 as '0', then the peer is using a battery power. The other 7 bits
626 are to be determined by specific applications.
628 5.1.4. Extending Diagnostic Information
630 The DiagnosticsExtension structure may be used to extend the
631 diagnostic information collected.
633 5.2. Request Extension: Ping
635 To extend the ping request for use in diagnostics, a new extension of
636 RELOAD is defined. The structure for a MessageExtension in RELOAD is
637 defined as:
639 struct {
640 MessageExtensionType type;
641 Boolean critical;
642 opaque extension_contents<0..2^32-1>;
643 } MessageExtension;
645 For the Ping request extension, we define a new MessageExtensionType,
646 extension 0x0002 named Diagnostic_Ping, as specified in Table 4 and
647 specified in the RELOAD. The extension contents consists of a
648 DiagnosticsRequest structure as defined in Section 5.1.1. This
649 extension MAY be used for new requests of the the Ping method and
650 MUST NOT be included in requests using any other method.
652 This extension is not critical. If a peer does not support the
653 extension, they will simply ignore the diagnostic portion of the
654 message, and will treat the message if it was a normal ping. Senders
655 MUST accept a response that lacks diagnostic information and SHOULD
656 NOT resend the message expecting a reply. Receivers who receive a
657 method other than Ping including this extension MUST ignore the
658 extension.
660 5.3. New Request: PathTrack
662 This document defines a simple PathTrack method to retrieve the
663 diagnostic information from the intermediate peers along the routing
664 path. At each step of the PathTrack request, the responsible peer
665 responds to the initiator node with requested status information such
666 as congestion state, its processing power, its available bandwidth,
667 the number of entries in its neighbor table, its uptime, its identity
668 and network address information, and the next hop peer information.
670 A PathTrack request specifies which diagnostic information is
671 requested using a DiagnosticsRequest Data structure. Base
672 information is requested by setting the appropriate flags in the
673 dMFlags field of the DiagnosticsRequest. If the flag is clear (no
674 bits are set), then the PathTrack request is only used for requesting
675 the next hop information. In this case the iterative mode of
676 PathTrack is degraded to a RouteQuery method which is only used for
677 checking the liveness of the peers along the routing path. The
678 PathTrack request can be routed directly or through the overlay based
679 on the routing mode chosen by the initiator node.
681 A response to a successful PathTrackReq is a PathTrackAns message.
682 There is a general diagnostic information portion of the payload, the
683 contents of which are based on the flags in the request. Please
684 refer to Section 5.1.3 for the definitions of the base diagnostic
685 information, and Section 8.2 for the numeric message code for the new
686 request.
688 5.3.1. PathTrack Request
690 The structure of the PathTrack request is as follows:
692 struct{
693 Destination destination;
694 DiagnosticsRequest request;
695 }PathTrackReq;
697 The fields of the PathTrackReq are as follows:
699 destination : The destination which the initiator node is
700 interested in. This may be any valid destination object,
701 including a NodeID, opaque ids, or ResourceID.
703 request : A DiagnosticsRequest, as discussed in Section 5.1.
705 5.3.2. PathTrack Response
707 The structure of the PathTrack Response is as follows:
709 struct{
710 Destination next_hop;
711 DiagnosticsResponse response;
712 }PathTrackAns;
714 The fields of the PathTrackAns are as follows:
716 next_hop : The information of the next hop node from the
717 responding intermediate peer to the destination node. If the
718 responding peer is the responsible peer for the destination ID,
719 then the next_hop node ID equals the responding node ID, and after
720 that the initiator MUST stop the iterative process.
722 response : A DiagnosticsResponse, as discussed in Section 5.1.
724 5.4. Error Codes
726 This document extends the Error response method defined in the RELOAD
727 specification to describe the result of diagnostics. When an error
728 is encountered in RELOAD, the Message Code 0xFFFF is returned. The
729 ErrorResponse structure includes an error code, and we define new
730 error codes to report on possible error conditions detected while
731 performing diagnostics:
733 Code Value Error Code Name
734 101 Underlay Destination Unreachable
735 102 Underlay Time exceeded
736 103 Message Expired
737 104 Upstream Misrouting
738 105 Loop detected
739 106 TTL hops exceeded
741 The final error codes will be assigned by IANA as specified in RELOAD
742 protocol [I-D.ietf-p2psip-base].
744 This document introduces several types of error information in the
745 error_info field in the case of Code 101. These are represented as
746 an opaque UTF-8 text string. Here are some examples for the error
747 info.
749 error_info:
751 net unreachable
752 host unreachable
753 protocol unreachable
754 port unreachable
755 fragmentation needed
756 source route failed
758 The error_info field of the Code 102 to 106 are to be specified by
759 the specific overlay.
761 5.5. Message Processing
763 5.5.1. Message Creation and Transmission
765 When constructing either a Ping message with diagnostic extensions or
766 a PathTrack message, the sender MUST create a DiagnosticsRequest data
767 structure. The sender MUST set the expiration field of this
768 structure in Unix time timestamp format. The value MUST be at least
769 10 seconds in the future, and MUST NOT be more than 600 seconds in
770 the future. The timestamp_initiated field MUST be set to the current
771 time in Unix time timestamp format. The sender includes the dMFlags
772 field in the structure, and MAY send any number (or all) of the flags
773 to request the desired diagnostic information. The sender MAY leave
774 all the bits unset, requesting no diagnostic information. The sender
775 MAY also include diagnostic extensions for additional information.
776 If the sender includes any extensions, it MUST calculate the length
777 of these extensions and set the length field to the correct length.
778 If no extensions are included, the sender MUST set length to zero.
780 When constructing a diagnostic Ping message, the sender MUST create
781 an MessageExtension structure as defined in RELOAD. The value of
782 type MUST be 0x0002. The value of critical MUST be FALSE. The value
783 of extension_contents MUST be the DiagnosticsRequest structure
784 defined above. The sender MUST place the MessageExtension structure
785 in the extensions field of the MessageContents structure. The
786 message MAY be directed to a particular NodeId or ResourceID, but
787 SHOULD NOT be sent to the broadcast NodeID.
789 When constructing a PathTrack message, the sender MUST set the
790 message_code for the RELOAD MessageContents structure for PathTrack.
791 The request field of the PathTrackReq MUST be set to the
792 DiagnosticsRequest data structure defined above. The destination
793 field MUST be set to the desired destination, which MAY be either a
794 NodeId or ResourceID but SHOULD NOT be the broadcast NodeID.
796 5.5.2. Message Processing: Intermediate Peers
798 When a request arrives at a peer, if the peer's responsible ID space
799 does not cover the destination ID of the request, then the peer MUST
800 continue processing this request according to the overlay specified
801 routing mode from RELOAD protocol.
803 In P2PSIP overlay, the error response can be generated by the
804 intermediate peer or responsible peer, either to a diagnostic message
805 or other messages. When a request is received at a peer, the peer
806 may find some connectivity failures or malfunction peers through the
807 pre-defined rules of the overlay network, e.g. by analyzing via list
808 or underlay error messages. The peer SHOULD report the error
809 responses to the initiator node. The malfunction node information
810 SHOULD also be reported to the initiator node in the error message
811 payload. All error responses contain the Error code followed by
812 descriptions if they exist.
814 Each intermediate peer receiving a Ping message with extensions (and
815 which understands the extension) or receiving a PathTrack request/
816 response SHOULD check the expiration value (Unix time format) to
817 determine if the message is expired. If the message expired, the
818 intermediate peer SHOULD generate a message with Error Code 103
819 "Message Expired" and return it to the initiator node, and discard
820 the message.
822 The peer SHOULD return an Error response with the Error Code 101
823 "Underlay Destination Unreachable" when it receives an ICMP message
824 with "Destination Unreachable" information after forwarding the
825 received request to the destination peer.
827 The peer SHOULD return an Error response with the Error Code 102
828 "Underlay Time Exceeded" when it receives an ICMP message with "Time
829 Exceeded" information after forwarding the received request.
831 The peer SHOULD return an Error response with Error Code 104
832 "Upstream Misrouting" when it finds its upstream peer disobeys the
833 routing rules defined in the overlay. The immediate upstream peer
834 information SHOULD also be conveyed to the initiator node.
836 The peer SHOULD return an Error response with Error Code 105 "Loop
837 detected" when it finds a loop through the analysis of via list.
839 The peer SHOULD return an Error response with Error Code 106 "TTL
840 hops exceeded" when it finds that the TTL field value is no more than
841 0 when forwarding.
843 5.5.3. Message Response Creation
845 When a diagnostic request message arrives at a peer, it understands
846 the extension (in the case of Ping) or the new request type
847 PathTrack, and it is responsible for the destination ID specified in
848 the forwarding header, it MUST follow the specifications defined in
849 5.1.3 of RELOAD protocol to form the response header, and perform the
850 following operations:
852 The receiver MUST check the expiration value (Unix time format) in
853 the DiagnosticsRequest to determine if the message is expired. If
854 the message is expired, the peer MUST generate a message with the
855 Error Code 103 "Message Expired" and return it to the initiator node,
856 and discard the message.
858 If the message is not expired, the receiver MUST construct a
859 DiagnosticsResponse structure. The destination peer MUST copy the
860 TTL value from the forwarding header to the hop_counter field of the
861 DiagnosticsResponse structure. Note that the default value for TTL
862 at the beginning represents 100-hops unless overlay configuration has
863 overridden the value. The receiver MUST generate an Unix time format
864 timestamp for the current time of day and place it in the
865 timestamp_received field. The receiver MUST construct a new
866 expiration time and place it in the expiration field of the
867 DiagnosticsResponse. This expiration MUST be at least 10 seconds in
868 the future and MUST NOT be more than 600 seconds in the future.
870 The destination peer MUST check if the initiator node has the
871 authority to request that type of diagnostic information, and if
872 appropriate, appends the diagnostic information requested in the
873 dMFlags and diagnostic_extensions (if any) in the
874 diagnostic_info_list field of the DiagnosticsResponse structure. If
875 there is any information returned, the receiver MUST calculate the
876 length of the response and set length appropriately. If there is no
877 diagnostic information returned, length MUST be set to zero.
879 In the event of an error, an error response containing the error code
880 followed by the description (if they exist) MUST be created and sent
881 to the sender. If the initiator node asks for diagnostic information
882 that they are not authorized to query, the receiving peer MUST return
883 an Error response with the Error Code 2 "Error_Forbidden".
885 5.5.4. Interpreting Results
887 The initiator node, as well as the responding peer, MAY compute the
888 overlay One-Way-Delay time through the value in timestamp_received
889 and the timestamp_initiated field. However, for a single hop
890 measurement, the traditional measurement methods MUST be used instead
891 of the overlay layer diagnostics methods.
893 The P2P overlay network that uses the diagnostics methods specified
894 in this document MUST enforce time synchronization with a central
895 time server. Network Time Protocol [RFC5905] can usually maintain
896 time to within tens of milliseconds over the public Internet, and can
897 achieve better than one millisecond accuracy in local area networks
898 under ideal conditions. However, this document does not specify the
899 choice for time synchronization. It depends on the implementation.
901 The initiator node receiving the Ping response MAY check the
902 hop_counter field and compute the overlay hops to the destination
903 peer for the statistics of connectivity quality from the perspective
904 of overlay hops.
906 6. Authorization through Overlay Configuration
908 The overlay configuration file MUST contain the following XML
909 elements for authorizating a node to access the relative diagnostic
910 kinds.
912 diagnostic-kind: This has the attribute "kind" with the hexadecimal
913 number indicating the diagnostic Kind Type, this attribute has the
914 same value with Section 8.1, and at least one sub element "access-
915 node".
917 access-node: This element contains one hexadecimal number indicating
918 a NodeID, and the node with this NodeID is allowed to access the
919 diagnostic "kind" under the same diagnostic-kind element.
921 7. Security Considerations
923 The authorization for diagnostic information must be designed with
924 care to prevent it becoming a method to retrieve information for bot
925 attacks. It should also be noted that attackers can use diagnostics
926 to analyze overlay information to attack certain key peers. As this
927 document is a RELOAD extension, it follows RELOAD message header and
928 routing specifications, the common security considerations described
929 in the base document [I-D.ietf-p2psip-base] are also applicable to
930 this document. Overlays may define their own requirements on who can
931 collect/share diagnostic information.
933 8. IANA Considerations
935 8.1. Diagnostic Kind ID Types
937 IANA SHALL create a "RELOAD Diagnostic Kind ID Types" Registry.
938 Entries in this registry are 16-bit integers denoting diagnostics
939 extension data kind types carried in the diagnostic request and
940 response message, as described in Section 5.1.2. Code points from
941 0x0000 to 0x003F SHALL be assigned together with flags within "RELOAD
942 Diagnostics Flag" registry via RFC 5226 [RFC5226] standards action.
943 Code points in the range 0x0040 to 0xFFFD SHALL be registered via RFC
944 5226 standards action.
946 +----------------------+--------+---------------+
947 | Diagnostic Kind Type | Code | Specification |
948 +----------------------+--------+---------------+
949 | reserved | 0x0000 | RFC-XXXX |
950 | STATUS_INFO | 0x0001 | RFC-XXXX |
951 | ROUTING_TABLE_SIZE | 0x0002 | RFC-XXXX |
952 | PROCESS_POWER | 0x0003 | RFC-XXXX |
953 | BANDWIDTH | 0x0004 | RFC-XXXX |
954 | SOFTWARE_VERSION | 0x0005 | RFC-XXXX |
955 | MACHINE_UPTIME | 0x0006 | RFC-XXXX |
956 | APP_UPTIME | 0x0007 | RFC-XXXX |
957 | MEMORY_FOOTPRINT | 0x0008 | RFC-XXXX |
958 | DATASIZE_STORED | 0x0009 | RFC-XXXX |
959 | INSTANCES_STORED | 0x000A | RFC-XXXX |
960 | MESSAGES_SENT_RCVD | 0x000B | RFC-XXXX |
961 | EWMA_BYTES_SENT | 0x000C | RFC-XXXX |
962 | EWMA_BYTES_RCVD | 0x000D | RFC-XXXX |
963 | UNDERLAY_HOP | 0x000E | RFC-XXXX |
964 | BATTERY_STATUS | 0x000F | RFC-XXXX |
965 | reserved | 0x003F | RFC-XXXX |
966 | local use (reserved) | 0xFFFE | RFC-XXXX |
967 | reserved | 0xFFFF | RFC-XXXX |
968 +----------------------+--------+---------------+
970 Table 1: Diagnostic Kind Types
972 8.2. Message Codes
974 This document introduces two new types of messages and their
975 responses, requiring the following additions to the "RELOAD Message
976 Code" Registry defined in RELOAD [I-D.ietf-p2psip-base]. These
977 additions are:
979 +-------------------+------------+----------+
980 | Message Code Name | Code Value | RFC |
981 +-------------------+------------+----------+
982 | path_track_req | 101 | RFC-AAAA |
983 | path_track_ans | 102 | RFC-AAAA |
984 +-------------------+------------+----------+
986 Table 2: Extensions to RELOAD Message Codes
988 [To RFC editor: Values starting at 101 were used to prevent
989 collisions with RELOAD base values. Once RELOAD moves to RFC, these
990 values may start at the next higher value after the RELOAD base
991 values. The final message code will be assigned by IANA. And all
992 RFC-AAAA should be replaced with the RFC number of RELOAD when
993 publication.]
995 8.3. Error Code
997 This document introduces the following new error codes, extending the
998 "RELOAD Message Code" registry as described below:
1000 +----------------------------------------+------------+----------+
1001 | Message Code Name | Code Value | RFC |
1002 +----------------------------------------+------------+----------+
1003 | Error_Underlay_Destination_Unreachable | 101 | RFC-AAAA |
1004 | Error_Underlay_Time_Exceeded | 102 | RFC-AAAA |
1005 | Error_Message_Expired | 103 | RFC-AAAA |
1006 | Error_Upstream_Misrouting | 104 | RFC-AAAA |
1007 | Error_Loop_Detected | 105 | RFC-AAAA |
1008 | Error_TTL_Hops_Exceeded | 106 | RFC-AAAA |
1009 +----------------------------------------+------------+----------+
1011 Table 3: Extensions to RELOAD Error Codes
1013 8.4. Message Extension
1015 This document introduces the following new RELOAD extension code:
1017 +-----------------+------------+----------+
1018 | Extension Name | Code Value | RFC |
1019 +-----------------+------------+----------+
1020 | Diagnostic_Ping | 0x0002 | RFC-AAAA |
1021 +-----------------+------------+----------+
1023 Table 4: New RELOAD Extension Code
1025 8.5. Diagnostics Flag
1027 IANA SHALL create a "RELOAD Diagnostics Flag" Registry. Entries in
1028 this registry are 1-bit flags contained in a 64-bits long integer
1029 dMFlags denoting diagnostic information to be retrieved as described
1030 in Section 5.3. New entries SHALL be defined via [RFC5226] Standards
1031 Action. The initial contents of this registry are:
1033 +-------------------------+------------------------------+--------+
1034 | diagnostic information |diagnostic flag in dMFlags | RFC |
1035 |-------------------------+------------------------------+--------|
1036 |Reserved | 0x 0000 0000 0000 0000 |RFC-XXXX|
1037 |STATUS_INFO | 0x 0000 0000 0000 0001 |RFC-XXXX|
1038 |ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0002 |RFC-XXXX|
1039 |PROCESS_POWER | 0x 0000 0000 0000 0004 |RFC-XXXX|
1040 |BANDWIDTH | 0x 0000 0000 0000 0008 |RFC-XXXX|
1041 |SOFTWARE_VERSION | 0x 0000 0000 0000 0010 |RFC-XXXX|
1042 |MACHINE_UPTIME | 0x 0000 0000 0000 0020 |RFC-XXXX|
1043 |APP_UPTIME | 0x 0000 0000 0000 0040 |RFC-XXXX|
1044 |MEMORY_FOOTPRINT | 0x 0000 0000 0000 0080 |RFC-XXXX|
1045 |DATASIZE_STORED | 0x 0000 0000 0000 0100 |RFC-XXXX|
1046 |INSTANCES_STORED | 0x 0000 0000 0000 0200 |RFC-XXXX|
1047 |MESSAGES_SENT_RCVD | 0x 0000 0000 0000 0400 |RFC-XXXX|
1048 |EWMA_BYTES_SENT | 0x 0000 0000 0000 0800 |RFC-XXXX|
1049 |EWMA_BYTES_RCVD | 0x 0000 0000 0000 1000 |RFC-XXXX|
1050 |UNDERLAY_HOP | 0x 0000 0000 0000 2000 |RFC-XXXX|
1051 |BATTERY_STATUS | 0x 0000 0000 0000 4000 |RFC-XXXX|
1052 |Reserved | 0x FFFF FFFF FFFF FFFF |RFC-XXXX|
1053 +-------------------------+------------------------------+--------+
1055 [To RFC editor: Please replace all RFC-XXXX in this document with the
1056 RFC number of this document.]
1058 8.6. XML Name Space Registration
1060 This document registers a URI for the config-diagnostics XML
1061 namespaces in the IETF XML registry defined in [RFC3688]. All the
1062 elements defined in this document belong to this namespace.
1064 URI: urn:ietf:params:xml:ns:p2p:config-diagnostics
1065 Registrant Contact: The IESG.
1066 XML: N/A, the requested URIs are XML namespaces
1068 And the overlay configuration file MUST contain the following xml
1069 language declaring P2PSIP diagnostics as a mandatory extension to
1070 RELOAD.
1072
1073 urn:ietf:params:xml:ns:p2p:config-diagnostics
1074
1076 9. Acknowledgments
1078 We would like to thank Zheng Hewen for the contribution of the
1079 initial version of this document. We would also like to thank Bruce
1080 Lowekamp, Salman Baset, Henning Schulzrinne, Jiang Haifeng and Marc
1081 Petit-Huguenin for the email discussion and their valued comments,
1082 and special thanks to Henry Sinnreich for contributing to the usage
1083 scenarios text. We would like to thank the authors of the RELOAD
1084 protocol for transferring text about diagnostics to this document.
1086 10. References
1088 10.1. Normative References
1090 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
1091 RFC 792, September 1981.
1093 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1094 Requirement Levels", BCP 14, RFC 2119, March 1997.
1096 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1097 January 2004.
1099 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
1100 Time Protocol Version 4: Protocol and Algorithms
1101 Specification", RFC 5905, June 2010.
1103 [I-D.ietf-p2psip-base]
1104 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
1105 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
1106 Base Protocol", draft-ietf-p2psip-base-26 (work in
1107 progress), February 2013.
1109 10.2. Informative References
1111 [UnixTime]
1112 "UnixTime", .>.
1115 [I-D.ietf-p2psip-self-tuning]
1116 Maenpaa, J. and G. Camarillo, "Self-tuning Distributed
1117 Hash Table (DHT) for REsource LOcation And Discovery
1118 (RELOAD)", draft-ietf-p2psip-self-tuning-10 (work in
1119 progress), February 2014.
1121 [I-D.ietf-p2psip-concepts]
1122 Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
1123 Dawkins, "Concepts and Terminology for Peer to Peer SIP",
1124 draft-ietf-p2psip-concepts-05 (work in progress), July
1125 2013.
1127 [Overlay-Failure-Detection]
1128 Zhuang, S., "On failure detection algorithms in overlay
1129 networks", Proc. IEEE Infocomm, Mar 2005.
1131 [Handling_Churn_in_a_DHT]
1132 Rhea, S., "Handling Churn in a DHT", USENIX Annual
1133 Conference, June 2004.
1135 [Diagnostic_Framework]
1136 Jin, X., "A Diagnostic Framework for Peer-to-Peer
1137 Streaming", 2005.
1139 [Diagnostics_and_NAT_traversal_in_P2PP]
1140 Gupta, G., "Diagnostics and NAT Traversal in P2PP - Design
1141 and Implementation", Columbia University Report , June
1142 2008.
1144 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1145 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
1146 May 2008.
1148 Appendix A. Examples
1150 Below, we sketch how these metrics can be used.
1152 A.1. Example 1
1154 A peer may set EWMA_BYTES_SENT and EWMA_BYTES_RCVD flags in the
1155 PathTrackReq to its direct neighbors. A peer can use EWMA_BYTES_SENT
1156 and EWMA_BYTES_RCVD of another peer to infer whether it is acting as
1157 a media relay. It may then choose not to forward any requests for
1158 media relay to this peer. Similarly, among the various candidates
1159 for filling up routing table, a peer may prefer a peer with a large
1160 UPTIME value, small RTT, and small LAST_CONTACT value.
1162 A.2. Example 2
1164 A peer may set the STATUS_INFO Flag in the PathTrackReq to a remote
1165 destination peer. The overlay has its own threshold definition for
1166 congestion. The peer can obtain knowledge of all the status
1167 information of the intermediate peers along the path. Then it can
1168 choose other paths to that node for the subsequent requests.
1170 A.3. Example 3
1172 A peer may use Ping to evaluate the average overlay hops to other
1173 peers by sending PingReq to a set of random resource or node IDs in
1174 the overlay. A peer may adjust its timeout value according to the
1175 change of average overlay hops.
1177 Appendix B. Problems with Generating Multiple Responses on Path
1179 An earlier version of this document considered an approach where a
1180 response was generated by each intermediate peer as the message
1181 traversed the overlay. This approach was discarded. One reason this
1182 approach was discarded was that it could provide a DoS mechanism,
1183 whereby an attacker could send an arbitrary message claiming to be
1184 from a spoofed "sender" the real sender wished to attack. As a
1185 result of sending this one message, many messages would be generated
1186 and sent back to the spoofed "sender" - one from each intermediate
1187 peer on the message path. While authentication mechanisms could
1188 reduce some risk of this attack, it still resulted in a fundamental
1189 break from the request-response nature of the RELOAD protocol, as
1190 multiple responses are generated to a single request. Although one
1191 request with responses from all the peers in the route will be more
1192 efficient, it was determined to be too great a security risk and
1193 deviation from the RELOAD architecture.
1195 Appendix C. Changes to the Draft
1197 To RFC editor: This section is to track the changes. Please remove
1198 this section before publication.
1200 C.1. Changes since -00 version
1202 1. Changed title from "Diagnose P2PSIP Overlay Network" to "P2PSIP
1203 Overlay Diagnostics".
1205 2. Changed the table of contents. Add a section about message
1206 processing and a section of examples.
1208 3. Merge diagnostics text from the p2psip base draft -01.
1210 4. Removed ECHO method for security reasons.
1212 C.2. Changes since -01 version
1214 Added BATTERY_STATUS as diagnostic information.
1216 Removed UnderlayTTL test from the Ping method, instead adding an
1217 UNDERLAY_HOP diagnostic information for PathTrack method.
1219 Give some examples for diagnostic information, and give some
1220 editor's notes for further work.
1222 C.3. Changes since -02 version
1224 Provided further explanation as to why the base draft Ping in the
1225 current form cannot be used to replace Ping, and why some combination
1226 of methods cannot replace PathTrack.
1228 C.4. Changes since -03 version
1230 Modified structure used to share information collected. Both
1231 mechanisms now use a common data structure to convey information.
1233 C.5. Changes since -04 version
1235 Updated the authors' addresses and modified the last sentence in .
1236 (Section 5.3.2)
1238 C.6. Changes since -05 version
1240 Resolve Marc's comments from the mailing list. And define the
1241 details of STATUS_INO.
1243 C.7. Changes in version -10
1245 Resolve the authorization issue and other comments (e.g. define
1246 diagnostics as a mandatory extension) from WGLC. And check for the
1247 languages.
1249 Authors' Addresses
1251 Haibin Song
1252 Huawei
1254 Email: haibin.song@huawei.com
1256 Jiang Xingfeng
1257 Huawei
1259 Email: jiang.x.f@huawei.com
1261 Roni Even
1262 Huawei
1263 14 David Hamelech
1264 Tel Aviv 64953
1265 Israel
1267 Email: roni.even@mail01.huawei.com
1268 David A. Bryan
1269 Ethernot.org
1270 Williamsburg, Virginia
1271 United States of America
1273 Email: dbryan@ethernot.org
1275 Yi Sun
1276 ICT-CAS
1278 Email: sunyi@ict.ac.cn