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