idnits 2.17.1 draft-ietf-p2psip-diagnostics-11.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-p2psip-base]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 394 has weird spacing: '... opaque diagn...' == Line 638 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 (March 25, 2013) is 4050 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-15) exists of draft-ietf-p2psip-self-tuning-08 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-04 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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: September 26, 2013 Huawei 6 D. Bryan 7 Ethernot.org 8 March 25, 2013 10 P2P Overlay Diagnostics 11 draft-ietf-p2psip-diagnostics-11 13 Abstract 15 This document describes mechanisms for P2P overlay diagnostics. It 16 defines extensions to the RELOAD P2PSIP base protocol RELOAD 17 [I-D.ietf-p2psip-base] to collect diagnostic information, and details 18 the protocol specifications for these extensions. Useful diagnostic 19 information for connection and node status monitoring is also 20 defined. The document also describes the usage scenarios and 21 provides examples of how these methods are used to perform 22 diagnostics in a P2PSIP overlay networks. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 26, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. Diagnostic Scenarios . . . . . . . . . . . . . . . . . . . . . 6 73 4. Overview of operations . . . . . . . . . . . . . . . . . . . . 7 74 4.1. "Ping-like" Behavior: Extending Ping . . . . . . . . . . . 8 75 4.2. "Traceroute-like" Behavior: The Path_Track Method . . . . 9 76 5. RELOAD diagnostic extensions . . . . . . . . . . . . . . . . . 10 77 5.1. Diagnostic Data Structures . . . . . . . . . . . . . . . . 10 78 5.1.1. DiagnosticsRequest Data Structure . . . . . . . . . . 10 79 5.1.2. DiagnosticsResponse Data Structure . . . . . . . . . . 12 80 5.1.3. dMFlags and Diagnostic Kind ID Types . . . . . . . . . 13 81 5.1.4. Extending Diagnostic Information . . . . . . . . . . . 15 82 5.2. Request Extension: Ping . . . . . . . . . . . . . . . . . 16 83 5.3. New Request: PathTrack . . . . . . . . . . . . . . . . . . 16 84 5.3.1. PathTrack Request . . . . . . . . . . . . . . . . . . 17 85 5.3.2. PathTrack Response . . . . . . . . . . . . . . . . . . 17 86 5.4. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 17 87 5.5. Message Processing . . . . . . . . . . . . . . . . . . . . 18 88 5.5.1. Message Creation and Transmission . . . . . . . . . . 18 89 5.5.2. Message Processing: Intermediate Peers . . . . . . . . 19 90 5.5.3. Message Response Creation . . . . . . . . . . . . . . 20 91 5.5.4. Interpreting Results . . . . . . . . . . . . . . . . . 21 92 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 21 94 6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 22 95 6.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 22 96 7. Mandatory Extension . . . . . . . . . . . . . . . . . . . . . 22 97 8. Authorization through Overlay Configuration . . . . . . . . . 22 98 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 99 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 100 10.1. Diagnostic Kind ID Types . . . . . . . . . . . . . . . . . 23 101 10.2. Message Codes . . . . . . . . . . . . . . . . . . . . . . 24 102 10.3. Error Code . . . . . . . . . . . . . . . . . . . . . . . . 25 103 10.4. Message Extension . . . . . . . . . . . . . . . . . . . . 25 104 10.5. Diagnostics Flag . . . . . . . . . . . . . . . . . . . . . 25 105 10.6. XML Name Space Registration . . . . . . . . . . . . . . . 26 106 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 107 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 108 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 109 12.2. Informative References . . . . . . . . . . . . . . . . . . 27 110 Appendix A. Problems with Generating Multiple Responses on 111 Path . . . . . . . . . . . . . . . . . . . . . . . . 28 112 Appendix B. Changes to the Draft . . . . . . . . . . . . . . . . 28 113 B.1. Changes since -00 version . . . . . . . . . . . . . . . . 28 114 B.2. Changes since -01 version . . . . . . . . . . . . . . . . 29 115 B.3. Changes since -02 version . . . . . . . . . . . . . . . . 29 116 B.4. Changes since -03 version . . . . . . . . . . . . . . . . 29 117 B.5. Changes since -04 version . . . . . . . . . . . . . . . . 29 118 B.6. Changes since -05 version . . . . . . . . . . . . . . . . 29 119 B.7. Changes in version -10 . . . . . . . . . . . . . . . . . . 29 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 122 1. Introduction 124 In the last few years, overlay networks have rapidly evolved and 125 emerged as a promising platform for deployment of new applications 126 and services in the Internet. One of the reasons overlay networks 127 are seen as an excellent platform for large scale distributed systems 128 is their resilience in the presence of failures. This resilience has 129 three aspects: data replication, routing recovery, and static 130 resilience. Routing recovery algorithms are used to repopulate the 131 routing table with live nodes when failures are detected. Static 132 resilience measures the extent to which an overlay can route around 133 failures even before the recovery algorithm repairs the routing 134 table. Both routing recovery and static resilience rely on accurate 135 and timely detection of failures. 137 There are a number of situations in which some nodes in a P2P overlay 138 may malfunction or behave badly. For example, these nodes may be 139 disabled, congested, or may be misrouting messages. The impact of 140 these malfunctions on the overlay network may be a degradation of 141 quality of service provided collectively by the peers in the overlay 142 network or an interruption of the overlay services. It is desirable 143 to identify malfunctioning or badly behaving peers through diagnostic 144 tools, and exclude or reject them from the P2P system. Node failures 145 may be also caused by underlying failures, for example the recovery 146 from an incorrect overlay topology may be slow when the IP layer 147 routing failover speed after link failures is very slow. Moreover, 148 if a backbone link fails and the failover is slow, the network may be 149 partitioned, leading to partitions of overlay topologies and 150 inconsistent routing results between different partitioned 151 components. 153 Some keep-alive algorithms based on periodic probe and acknowledge 154 mechanisms enable accurate and timely detection of failures of one 155 node's neighbors [Overlay-Failure-Detection], but these algorithms by 156 themselves can only detect the disabled neighbors using the periodic 157 method, it may not be enough for service providers operating the 158 overlay network. 160 A single, general P2PSIP overlay diagnostic framework supporting 161 periodic and on-demand methods for detecting node failures and 162 network failures is desirable. This document describes a general 163 P2PSIP overlay diagnostic extension to the P2PSIP base protocol 164 RELOAD and is intended as a complement to keep-alive algorithms in 165 the P2PSIP overlay itself. 167 2. Terminology 169 The concepts used in this document are compatible with "Concepts and 170 Terminology for Peer to Peer SIP" [I-D.ietf-p2psip-concepts] and the 171 P2PSIP base protocol RELOAD [I-D.ietf-p2psip-base]. 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 3. Diagnostic Scenarios 179 P2P systems are self-organizing and ideally require no network 180 management in the traditional sense to set up and to configure 181 individual P2P nodes. However, users of an overlay, as well as P2P 182 service providers may contemplate usage scenarios where some 183 monitoring and diagnostics are required. We present a simple 184 connectivity test and some useful diagnostic information that may be 185 used in such diagnostics. 187 The common usage scenarios for P2P diagnostics can be broadly 188 categorized in three classes: 190 a. Automatic diagnostics built into the P2P overlay routing 191 protocol. Nodes perform periodic checks of known neighbors and 192 remove those nodes from the routing tables that fail to respond 193 to connectivity checks [Handling_Churn_in_a_DHT]. However, the 194 unresponsive nodes may only be temporarily disabled, for example 195 due to some local cryptographic processing overload, disk 196 processing overload or link overload. It is therefore useful to 197 repeat the connectivity checks to see if such nodes have 198 recovered and can be again placed in the routing tables. This 199 process is known as 'failed node recovery' and can be optimized 200 as described in the paper "Handling Churn in a DHT" 201 [Handling_Churn_in_a_DHT]. 203 b. Diagnostics for a particular node to follow up an individual user 204 complaint or failure. For example, in this case a technical 205 support person may use a desktop sharing application with the 206 permission of the user to determine remotely the health and 207 possible problems with the malfunctioning node. Part of the 208 remote diagnostics may consist of simple connectivity tests with 209 other nodes in the P2PSIP overlay and retrieval statistics of 210 nodes from the overlay. The simple connectivity tests are not 211 dependent on the type of P2PSIP overlay. Note that other tests 212 may be required as well, such as checking the health and 213 performance of the user's computer or mobile device and also 214 checking the bandwidth of the link connecting the user to the 215 Internet. 217 c. P2P system diagnostics to check the overall health of the P2P 218 overlay network, the consumption of network bandwidth, for the 219 presence of problem links and also to check for abusive or 220 malicious nodes. This is not a trivial problem and has been 221 studied in detail for content and streaming P2P overlays 222 [Diagnostic_Framework] as well as in earlier P2PSIP documents 223 [Diagnostics_and_NAT_traversal_in_P2PP]. While this is a 224 difficult problem, a great deal of information can be obtained in 225 helping these diagnostics by sending messages to diagnose the 226 network. This document provides a framework for obtaining this 227 information. 229 4. Overview of operations 231 The diagnostic mechanisms described in this document are mainly 232 intended to detect and locate failures or monitor performance in 233 P2PSIP overlay networks. It provides mechanisms to detect and locate 234 malfunctioning or badly behaving nodes including disabled nodes, 235 congested nodes and misrouting peers. It provides a mechanism to 236 detect direct connectivity or connectivity to a specified node, a 237 mechanism to detect the availability of specified resource records 238 and a mechanism to discover P2PSIP overlay topology and the underlay 239 topology failures. 241 The P2PSIP diagnostics extensions define two mechanisms to collect 242 data. The first is an extension to the RELOAD Ping mechanism, 243 allowing diagnostic data to be queried from a node, as well as to 244 diagnose the path to that node. The second is a new method and 245 response, PathTrack, for collecting diagnostic information 246 iteratively. Payloads for these mechanisms allowing diagnostic data 247 to be collected and represented are presented, and additional error 248 codes are introduced. Essentially, this draft reuses P2PSIP base 249 protocol specification and extends them to introduce the new 250 diagnostics methods. The extensions strictly follow the P2PSIP base 251 protocol specification on the messages routing, transport, NAT 252 traversal etc. The diagnostic methods are however P2PSIP protocol 253 independent. 255 This document primarily describes how to detect and locate failures 256 including disabled nodes, congested nodes, misrouting behaviors and 257 underlying network faults in P2PSIP overlay networks through a simple 258 and efficient mechanism. This mechanism is modeled after the ping/ 259 traceroute paradigm: ping (RFC792 ICMP echo request [RFC0792]) is 260 used for connectivity checks, and traceroute is used for hop-by-hop 261 fault localization as well as path tracing. This document specifies 262 a "ping-like" mode (by extending the RELOAD Ping method to gather 263 diagnostics) and a "traceroute-like" mode (by defining the new 264 PathTrack method) for diagnosing P2PSIP overlay networks. 266 One way these tools can be used is to detect the connectivity to the 267 specified node or the availability of the specified resource-record 268 through the extended P2PSIP Ping operation. Once the overlay network 269 receives some alarms about overlay service degradation or 270 interruption, a Ping is sent. If the Ping fails, one can then send a 271 PathTrack to determine where the fault lies. 273 The diagnostic information MUST only be provided to authorized nodes. 274 Some diagnostic information can be provided to all the participants 275 in the P2PSIP overlay, and some other diagnostic information can only 276 be provided to the nodes authorized by the local or overlay policy. 277 The authorization depends on the type of the diagnostic information 278 and the administrative considerations, and is application specific. 280 This document considers the general administrative scenario based on 281 diagnostic kind type, where a whole overlay can authorize a certain 282 type of diagnostic information to a small list of particular nodes 283 (e.g. administrative nodes). It leaves the scenario where a 284 particular node authorizes its diagnostic information to a particular 285 list of nodes out of scope. This could be be achieved by extension 286 of this document if there is requirement in the near future. The 287 default policy or access rule for a type of diagnostic information is 288 "permit" unless specified in the diagnostics extension document. As 289 the RELOAD protocol already requires that each messge carries message 290 signature of the sender, the receiver of the diagnostics requests can 291 use the signature to identify the sender. It can then use the 292 overlay configuration file with this signature to determine which 293 types of 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 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. First, the initiating node asks its 327 neighbor A which is the next hop peer to the destination ID, and then 328 retrieves the next hop peer B information, along with optional 329 diagnostic information of A, to the initiator node. Then the 330 initiator node asks the next hop peer B (directly or via symmetric 331 routing) to get the further next hop peer C information and 332 diagnostic information of B. Unless a failure prevents the message 333 from being forwarded, this step can be iteratively repeated until the 334 request reaches responsible peer D for the destination ID, and 335 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 | | | | 355 PathTrack Diagnostic Message Flow 357 There have been proposals that RouteQuery and a series of Fetch 358 requests can be used to replace the PathTrack mechanism, but in the 359 presence of churn such an operation would not, strictly speaking, 360 provide identical results, as the path may change between RouteQuery 361 and Fetch operations. (although obviously the path could change 362 between steps of PathTrack as well). 364 5. RELOAD diagnostic extensions 366 This document extends RELOAD to carry diagnostic information. 367 Considering the special usage of diagnostics, this document defines 368 extensions for a payload to Ping, as well as the new method PathTrack 369 and its response. Additionally, new Error codes, message bodies for 370 conveying diagnostics, and some suggested common diagnostic values 371 are defined. Processing of the PathTrack message and the diagnostic 372 bodies is discussed. 374 The mechanism defined in this document follows the RELOAD 375 specification, the new request and response message use the message 376 format specified in P2PSIP base protocol messages. Please refer to 377 the RELOAD [I-D.ietf-p2psip-base] for details of the protocol. 379 5.1. Diagnostic Data Structures 381 The diagnostics use the following common diagnostics data structures. 382 Two common structures are defined, DiagnosticsRequest for requesting 383 data, and DiagnosticsResponse for returning information. 385 5.1.1. DiagnosticsRequest Data Structure 387 The DiagnosticsRequest data structure is sent to request diagnostic 388 information and has the following form: 390 enum{ (2^16-1) } DiagnosticKindId; 392 struct{ 393 DiagnosticKindId kind; 394 opaque diagnostic_extension_contents<0..2^32-1>; 395 }DiagnosticExtension; 397 struct{ 398 uint64 expiration; 399 uint64 timestamp_initiated; 400 uint64 dMFlags; 401 uint32 length; 402 DiagnosticExtension diagnostic_extensions[length]; 403 }DiagnosticsRequest; 405 The fields in the DiagnosticsRequest are as follows: 407 expiration : The time when the request will expire represented as 408 the number of milliseconds elapsed since midnight Jan 1, 1970 UTC 409 not counting leap seconds. This will have the same values for 410 seconds as standard UNIX time or POSIX time. More information can 411 be found at UnixTime [UnixTime] 413 timestamp_initiated : The time when the P2PSIP diagnostics request 414 was initiated represented as the number of milliseconds elapsed 415 since midnight Jan 1, 1970 UTC not counting leap seconds. This 416 will have the same values for seconds as standard UNIX time or 417 POSIX time. 419 length : the length of the extended diagnostic request information 420 in bytes. If the value is greater than or equal to 1, then some 421 extended diagnostic information is requested. The value of length 422 MUST NOT be negative. 424 dMFlags : A mandatory field which is an unsigned 64-bit integer 425 indicating which base diagnostic information the request initiator 426 node is interested in. The initiator sets different bits to 427 retrieve different kinds of diagnostic information. If dMFlags is 428 clear, then no base diagnostic information is conveyed in the 429 PathTrack response. If dMFlag is set to all '1's, then all base 430 diagnostic information values are requested. A request may set 431 any number of the flags to request the corresponding diagnostic 432 information. 434 Note this memo specifies the initial set of flags, the flags can 435 be extended. The dMflags indicate general diagnostic information 436 The mapping between the bits in the dMFlags and the diagnostic 437 information kind presented is as described in Section 10.5. 439 diagnostic_extensions : consists of one or more 440 DiagnosticExtension structures (see below) documenting additional 441 diagnostic information being requested. 443 Each DiagnosticExtension has the following fields: 445 kind : a numerical code indicating the extension kind of 446 diagnostic information(see Section 10.1). Note that kind 0xFFFE 447 is reserved for overlay specific diagnostics and may be used 448 without IANA registration for local diagnostic information. And 449 the kind from 0x0000 to 0x003F MUST NOT be indicated in the 450 diagnostic_extensions in the message request becasue they can be 451 represented in the dMFlags in a much simpler way. 453 diagnostic_extension_contents : the opaque data containing the 454 request for this particular extension. This data is extension 455 dependent. 457 5.1.2. DiagnosticsResponse Data Structure 459 enum { (2^16-1) } DiagnosticKindId; 460 struct{ 461 DiagnosticKindId kind; 462 opaque diagnostic_info_contents<0..2^16-1>; 463 }DiagnosticInfo; 465 struct{ 466 uint64 expiration; 467 uint64 timestamp_received; 468 uint8 hop_counter; 469 DiagnosticInfo diagnostic_info_list<0..2^32-1>; 470 }DiagnosticsResponse; 472 The fields in the DiagnosticsResponse are as follows: 474 expiration : The time when the response will expire represented as 475 the number of milliseconds elapsed since midnight Jan 1, 1970 UTC 476 not counting leap seconds. This will have the same values for 477 seconds as standard UNIX time or POSIX time. 479 timestamp_received : The time when P2PSIP Overlay diagnostic 480 request was received represented as the number of milliseconds 481 elapsed since midnight Jan 1, 1970 UTC not counting leap seconds. 482 This will have the same values for seconds as standard UNIX time 483 or POSIX time. 485 hop_counter : This field only appears in diagnostic responses. It 486 MUST be exactly copied from the TTL field of the forwarding header 487 in the received request. This information is sent back to the 488 request initiator, allowing it to compute the hops that the 489 message traversed in the overlay. 491 diagnostic_info_list : consists of one or more DiagnosticInfo 492 values containing the requested diagnostic information. 494 The fields in the DiagnosticInfo structure are as follows: 496 kind : A numeric code indicating the type of information being 497 returned. For base data requested using the dMFlags, this code 498 corresponds to the dMFlag set, and is described in Section 5.1.1. 499 For diagnostic extensions, this code will be identical to the 500 value of the DiagnosticKindId set in the "kind" field of the 501 DiagnosticExtension of the request. See Section 10.1. 503 diagnostic_information : Data containing the value for the 504 diagnostic information being reported. Various kinds of 505 diagnostic information can be retrieved, Please refer to 506 Section 5.1.3 for details of the diagnostic kind ID for the base 507 diagnostic information that may be reported. 509 5.1.3. dMFlags and Diagnostic Kind ID Types 511 The dMFlags field described above is a 64 bit field that allows 512 initiator nodes to identify up to 62 items of base information to 513 request (the first and last flags being reserved) when sending a 514 request. When the requested base information is returned in the 515 response, the value of the diagnostic kind ID will correspond to the 516 numeric field marked in the dMFlags in the request. The values for 517 the dMFlags are defined in Section 10.5 and the diagnostic kind IDs 518 are defined in Section 10.1. The information contained for each 519 value is described in this section. 521 STATUS_INFO (8 bits): A single value element containing an 522 unsigned byte representing whether or not the node is in 523 congestion status. An example usage of STATUS_INFO is for 524 congestion-aware routing. In this scenario, each peer has to 525 update its congestion status periodically, an intermediate peer in 526 the DHT network will choose its next hop according to both the DHT 527 routing algorithm and the status information, and then forward 528 requests to the chosen next hop, so as to avoid increasing load on 529 congested peers. The rightmost 4 bits are used and other bits 530 MUST be cleared to "0"s for future use. There are 16 levels of 531 congestion status, with "0x00" represent zero load and "0x0F" 532 represent congested. 534 ROUTING_TABLE_SIZE (32 bits): A single value element containing an 535 unsigned 32-bit integer representing the number of peers in the 536 peer's routing table. The administrator of the overlay may be 537 interested in statistics of this value for reasons such as routing 538 efficiency. Access to this kind of diagnostic information MUST 539 NOT be allowed unless compliant to the rules defined in Section 8. 541 PROCESS_POWER (32 bits): A single value element containing an 542 unsigned 32-bit integer specifying the processing power of the 543 node in unit of MIPS. 545 BANDWIDTH (32 bits): A single value element containing an unsigned 546 32-bit integer specifying the bandwidth of the node in unit of 547 Kbps. 549 SOFTWARE_VERSION: A single value element containing a US-ASCII 550 string that identifies the manufacture, model, operating system 551 information and the version of the software. The format is as 552 follows: ApplicationProductToken (Platform; OS-or-CPU) * 553 VendorProductToken (VendorComment). One example is: 554 MyReloadApp/1.0 (Unix; Linux x86_64) libreload-java/0.7.0 555 (Stonyfish Inc.). Access to this kind of diagnostic information 556 MUST NOT be allowed unless compliant to the rules defined in 557 Section 8. 559 MACHINE_UPTIME (64 bits): A single value element containing an 560 unsigned 64-bit integer specifying the time the node has been up 561 in seconds. 563 APP_UPTIME (64 bits): A single value element containing an 564 unsigned 64-bit integer specifying the time the p2p application 565 has been up in seconds. 567 MEMORY_FOOTPRINT (32 bits): A single value element containing an 568 unsigned 32-bit integer representing the memory footprint of the 569 peer program in kibibytes(1024 bytes). Access to this kind of 570 diagnostic information MUST NOT be allowed unless compliant to the 571 rules defined in Section 8. 573 DATASIZE_STORED (64 bits): An unsigned 64-bit integer representing 574 the number of bytes of data being stored by this node. Access to 575 this kind of diagnostic information MUST NOT be allowed unless 576 compliant to the rules defined in Section 8. 578 INSTANCES_STORED: An array element containing the number of 579 instances of each kind stored. The array is indexed by Kind-ID. 580 Each entry is an unsigned 64-bit integer. Access to this kind of 581 diagnostic information MUST NOT be allowed unless compliant to the 582 rules defined in Section 8. 584 MESSAGES_SENT_RCVD: An array element containing the number of 585 messages sent and received. The array is indexed by method code. 586 Each entry in the array is a pair of unsigned 64-bit integers 587 (packed end to end) representing sent and received. Access to 588 this kind of diagnostic information MUST NOT be allowed unless 589 compliant to the rules defined in Section 8. 591 EWMA_BYTES_SENT (32 bits): A single value element containing an 592 unsigned 32-bit integer representing an exponential weighted 593 average of bytes sent per second by this peer. sent = alpha x 594 sent_present + (1 - alpha) x sent where sent_present represents 595 the bytes sent per second since the last calculation and sent 596 represents the last calculation of bytes sent per second. A 597 suitable value for alpha is 0.8. This value is calculated every 598 five seconds. Access to this kind of diagnostic information MUST 599 NOT be allowed unless compliant to the rules defined in Section 8. 601 EWMA_BYTES_RCVD (32 bits): A single value element containing an 602 unsigned 32-bit integer representing an exponential weighted 603 average of bytes received per second by this peer. rcvd = alpha x 604 rcvd_present + (1 - alpha) x rcvd where rcvd_present represents 605 the bytes received per second since the last calculation and rcvd 606 represents the last calculation of bytes received per second. A 607 suitable value for alpha is 0.8. This value is calculated every 608 five seconds. Access to this kind of diagnostic information MUST 609 NOT be allowed unless compliant to the rules defined in Section 8. 611 UNDERLAY_HOP (8 bits): Indicates the IP layer hops from the 612 intermediate peer which receives the diagnostics message to the 613 next hop peer for this message. (Note: RELOAD does not require 614 the intermediate peers to look into the message body. So here we 615 use PathTrack to gather underlay hops for diagnostics purpose). 617 BATTERY_STATUS (8 bits): The left-most bit is used to indicate 618 whether this peer is using battery or not. If this bit is clear 619 as '0', then the peer is using a battery power. The other 7 bits 620 are to be determined by specific applications. 622 5.1.4. Extending Diagnostic Information 624 The DiagnosticsExtension structure may be used to extend the 625 diagnostic information collected. 627 Editor's Note: The self-tuning draft [I-D.ietf-p2psip-self-tuning] 628 could extend the diagnostic information here to collect related 629 information for calculating self-tuning parameters. 631 5.2. Request Extension: Ping 633 To extend the ping request for use in diagnostics, a new extension of 634 RELOAD is defined. The structure for a MessageExtension in RELOAD is 635 defined as: 637 struct { 638 MessageExtensionType type; 639 Boolean critical; 640 opaque extension_contents<0..2^32-1>; 641 } MessageExtension; 643 For the Ping request extension, we define a new MessageExtensionType, 644 extension 0x0002 named Diagnostic_Ping, as specified in Table 4 and 645 specified in the RELOAD. The extension contents consists of a 646 DiagnosticsRequest structure as defined in Section 5.1.1. This 647 extension MAY be used for new requests of the the Ping method and 648 MUST NOT be included in requests using any other method. 650 This extension is NOT critical. If a peer does not support the 651 extension, they will simply ignore the diagnostic portion of the 652 message, and will treat the message if it was a normal ping. Senders 653 MUST accept a response that lacks diagnostic information and SHOULD 654 NOT resend the message expecting a reply. Receivers who receive a 655 method other than Ping including this extension MUST ignore the 656 extension. 658 5.3. New Request: PathTrack 660 This document defines a simple PathTrack method to retrieve the 661 diagnostic information from the intermediate peers along the routing 662 path. At each step of the PathTrack request, the responsible peer 663 responds to the initiator node with requested status information such 664 as congestion state, its processing power, its available bandwidth, 665 the number of entries in its neighbor table, its uptime, its identity 666 and network address information, and the next hop peer information. 668 A PathTrack request specifies which diagnostic information is 669 requested using a DiagnosticsRequest Data structure. Base 670 information is requested by setting the appropriate flags in the 671 dMFlags field of the DiagnosticsRequest. If the flag is clear (no 672 bits are set), then the PathTrack request is only used for requesting 673 the next hop information. In this case the iterative mode of 674 PathTrack is degraded to a RouteQuery method which is only used for 675 checking the liveness of the peers along the routing path. The 676 PathTrack request can be routed directly or through the overlay based 677 on the routing mode chosen by the initiator node. 679 A response to a successful PathTrackReq is a PathTrackAns message. 680 There is a general diagnostic information portion of the payload, the 681 contents of which are based on the flags in the request. Please 682 refer to Section 5.1.3 for the definitions of the base diagnostic 683 information, and Section 10.2 for the numeric message code for the 684 new request. 686 5.3.1. PathTrack Request 688 The structure of the PathTrack request is as follows: 690 struct{ 691 Destination destination; 692 DiagnosticsRequest request; 693 }PathTrackReq; 695 The fields of the PathTrackReq are as follows: 697 destination : The destination which the initiator node is 698 interested in. This may be any valid destination object, 699 including a NodeID, opaque ids, or ResourceID. 701 request : A DiagnosticsRequest, as discussed in Section 5.1. 703 5.3.2. PathTrack Response 705 The structure of the PathTrack Response is as follows: 707 struct{ 708 Destination next_hop; 709 DiagnosticsResponse response; 710 }PathTrackAns; 712 The fields of the PathTrackAns are as follows: 714 next_hop : The information of the next hop node from the 715 responding intermediate peer to the destination node. If the 716 responding peer is the responsible peer for the destination ID, 717 then the next_hop node ID equals the responding node ID, and after 718 that the initiator MUST stop the iterative process. 720 response : A DiagnosticsResponse, as discussed in Section 5.1. 722 5.4. Error Codes 724 This document extends the Error response method defined in the P2PSIP 725 base protocol specification to describe the result of diagnostics. 726 When an error is encountered in RELOAD, the Message Code 0xFFFF is 727 returned. The ErrorResponse structure includes an error code, and we 728 define new error codes to report on possible error conditions 729 detected while performing diagnostics: 731 Code Value Error Code Name 732 101 Underlay Destination Unreachable 733 102 Underlay Time exceeded 734 103 Message Expired 735 104 Upstream Misrouting 736 105 Loop detected 737 106 TTL hops exceeded 739 The final error codes will be assigned by IANA. as specified in the 740 p2psip base protocol [I-D.ietf-p2psip-base]. 742 This document introduces several types of error information in the 743 error_info field in the case of Code 101. These are represented as 744 an opaque UTF-8 text string. Here are some examples for the error 745 info. 747 error_info: 749 net unreachable 750 host unreachable 751 protocol unreachable 752 port unreachable 753 fragmentation needed 754 source route failed 756 The error_info field of the Code 102 to 106 are to be specified by 757 the specific overlay. 759 5.5. Message Processing 761 5.5.1. Message Creation and Transmission 763 When constructing either a Ping message with diagnostic extensions or 764 a PathTrack message, the sender MUST create a DiagnosticsRequest data 765 structure. The sender MUST set the expiration field of this 766 structure in Unix time timestamp format. The value MUST be at least 767 10 seconds in the future, and MUST NOT be more than 600 seconds in 768 the future. The timestamp_initiated field MUST be set to the current 769 time in Unix time timestamp format. The sender includes the dMFlags 770 field in the structure, and MAY send any number (or all) of the flags 771 to request the desired diagnostic information. The sender MAY leave 772 all the bits unset, requesting no diagnostic information. The sender 773 MAY also include diagnostic extensions for additional information. 774 If the sender includes any extensions, they MUST calculate the length 775 of these extensions and set the length field to the correct length. 776 If no extensions are included, the sender MUST set length to zero. 778 When constructing a diagnostic Ping message, the sender MUST create 779 an MessageExtension structure as defined in RELOAD. The value of 780 type MUST be 0x0002. The value of critical MUST be FALSE. The value 781 of extension_contents MUST be the DiagnosticsRequest structure 782 defined above. The sender MUST place the MessageExtension structure 783 in the extensions field of the MessageContents structure. The 784 message MAY be directed to a particular NodeId or ResourceID, but 785 SHOULD NOT be sent to the broadcast NodeID. 787 When constructing a PathTrack message, the sender MUST set the 788 message_code for the RELOAD MessageContents structure for PathTrack. 789 The request field of the PathTrackReq MUST be set to the 790 DiagnosticsRequest data structure defined above. The destination 791 field MUST be set to the desired destination, which MAY be either a 792 NodeId or ResourceID but SHOULD NOT be the broadcast NodeID. 794 5.5.2. Message Processing: Intermediate Peers 796 When a request arrives at a peer, if the peer's responsible ID space 797 does not cover the destination ID of the request, then the peer MUST 798 continue processing this request according to the overlay specified 799 routing mode from the base draft. 801 In p2psip overlay, the error response can be generated by the 802 intermediate peer or responsible peer, either to a diagnostic message 803 or other messages. When a request is received at a peer, the peer 804 may find some connectivity failures or malfunction peers through the 805 pre-defined rules of the overlay network, e.g. by analyzing via list 806 or underlay error messages. The peer SHOULD report the error 807 responses to the initiator node. The malfunction node information 808 SHOULD also be reported to the initiator node in the error message 809 payload. All error responses contain the Error code followed by 810 descriptions if they exist. 812 Each intermediate peer receiving a Ping message with extensions (and 813 which understands the extension) or receiving a PathTrack request/ 814 response SHOULD check the expiration value (Unix time format) to 815 determine if the message is expired. If the message expired, the 816 intermediate peer SHOULD generate a message with Error Code 103 817 "Message Expired" and return it to the initiator node, and discard 818 the message. 820 The peer SHOULD return an Error response with the Error Code 101 821 "Underlay Destination Unreachable" when it receives an ICMP message 822 with "Destination Unreachable" information after forwarding the 823 received request to the destination peer. 825 The peer SHOULD return an Error response with the Error Code 102 826 "Underlay Time Exceeded" when it receives an ICMP message with "Time 827 Exceeded" information after forwarding the received request. 829 The peer SHOULD return an Error response with Error Code 104 830 "Upstream Misrouting" when it finds its upstream peer disobeys the 831 routing rules defined in the overlay. The immediate upstream peer 832 information SHOULD also be conveyed to the initiator node. 834 The peer SHOULD return an Error response with Error Code 105 "Loop 835 detected" when it finds a loop through the analysis of via list. 837 The peer SHOULD return an Error response with Error Code 106 "TTL 838 hops exceeded" when it finds that the TTL field value is no more than 839 0 when forwarding. 841 5.5.3. Message Response Creation 843 When a diagnostic request message arrives at a peer, it understands 844 the extension (in the case of ping) or the new request type 845 PathTrack, and it is responsible for the destination ID specified in 846 the forwarding header, it MUST follow the specifications defined in 847 5.1.3 of the base draft to form the response header, and perform the 848 following operations: 850 The receiver MUST check the expiration value (Unix time format) in 851 the DiagnosticsRequest to determine if the message is expired. If 852 the message is expired, the peer MUST generate a message with the 853 Error Code 103 "Message Expired" and return it to the initiator node, 854 and discard the message. 856 If the message is not expired, the receiver MUST construct a 857 DiagnosticsResponse structure. The destination peer MUST copy the 858 TTL value from the forwarding header to the hop_counter field of the 859 DiagnosticsResponse structure. Note that the default value for TTL 860 at the beginning represents 100-hops unless overlay configuration has 861 overridden the value. The receiver MUST generate an Unix time format 862 timestamp for the current time of day and place it in the 863 timestamp_received field. The receiver MUST construct a new 864 expiration time and place it in the expiration field of the 865 DiagnosticsResponse. This expiration MUST be at least 10 seconds in 866 the future and MUST NOT be more than 600 seconds in the future. 868 The destination peer MUST check if the initiator node has the 869 authority to request that type of diagnostic information, and if 870 appropriate, appends the diagnostic information requested in the 871 dMFlags and diagnostic_extensions (if any) in the 872 diagnostic_info_list field of the DiagnosticsResponse structure. If 873 there is any information returned, the receiver MUST calculate the 874 length of the response and set length appropriately. If there is no 875 diagnostic information returned, length MUST be set to zero. 877 In the event of an error, an error response containing the error code 878 followed by the description (if they exist) MUST be created and sent 879 to the sender. If the initiator node asks for diagnostic information 880 that they are not authorized to query, the receiving peer MUST return 881 an Error response with the Error Code 2 "Error_Forbidden". 883 5.5.4. Interpreting Results 885 The initiator node, as well as the responding peer, MAY compute the 886 overlay One-Way-Delay time through the value in timestamp_received 887 and the timestamp_initiated field. However, for a single hop 888 measurement, the traditional measurement methods MUST be used instead 889 of the overlay layer diagnostics methods. 891 Editor note: We need more discussion and careful consideration on how 892 to use the timestamp here because time synchronization is a barrier 893 in open Internet environment, while in a managed environment, it may 894 be less of a problem. 896 The initiator node receiving the Ping response MAY check the 897 hop_counter field and compute the overlay hops to the destination 898 peer for the statistics of connectivity quality from the perspective 899 of overlay hops. 901 6. Examples 903 Below, we sketch how these metrics can be used. 905 6.1. Example 1 907 A peer may set EWMA_BYTES_SENT and EWMA_BYTES_RCVD flags in the 908 PathTrackReq to its direct neighbors. A peer can use EWMA_BYTES_SENT 909 and EWMA_BYTES_RCVD of another peer to infer whether it is acting as 910 a media relay. It may then choose not to forward any requests for 911 media relay to this peer. Similarly, among the various candidates 912 for filling up routing table, a peer may prefer a peer with a large 913 UPTIME value, small RTT, and small LAST_CONTACT value. 915 6.2. Example 2 917 A peer may set the STATUS_INFO Flag in the PathTrackReq to a remote 918 destination peer. The overlay has its own threshold definition for 919 congestion. The peer can obtain knowledge of all the status 920 information of the intermediate peers along the path. Then it can 921 choose other paths to that node for the subsequent requests. 923 6.3. Example 3 925 A peer may use Ping to evaluate the average overlay hops to other 926 peers by sending PingReq to a set of random resource or node IDs in 927 the overlay. A peer may adjust its timeout value according to the 928 change of average overlay hops. 930 7. Mandatory Extension 932 This document registers a URI for the config-diagnostics XML 933 namespaces in the IETF XML registry defined in [RFC3688]. All the 934 elements defined in this document belong to this namespace. 936 URI: urn:ietf:params:xml:ns:p2p:config-diagnostics 937 Registrant Contact: The IESG. 938 XML: N/A, the requested URIs are XML namespaces 940 And the overlay configuration file MUST contain the following xml 941 language declaring p2psip diagnostics as a mandatory extension to 942 RELOAD. 944 945 urn:ietf:params:xml:ns:p2p:config-diagnostics 946 948 8. Authorization through Overlay Configuration 950 The overlay configuration file MUST contain the following XML 951 elements for authorization a node to access the relative diagnostic 952 kinds. 954 diagnostic-kind: This has the attribute "kind" with the hexadecimal 955 number indicating the diagnostic Kind Type, this attribute has the 956 same value with Section 10.1, and at least one sub element "access- 957 node". 959 access-node: This element contains one hexadecimal number indicating 960 the node with this NodeID is allowed to access the diagnostic "kind" 961 under the same diagnostic-kind emlement. 963 9. Security Considerations 965 The authorization for diagnostic information must be designed with 966 care to prevent it becoming a method to retrieve information for bot 967 attacks. It SHOULD also be noted that attackers can use diagnostics 968 to analyze overlay information to attack certain key peers. As this 969 draft is a RELOAD extension, it follows RELOAD message header and 970 routing specifications, the common security considerations described 971 in the base draft [I-D.ietf-p2psip-base] are also applicable to this 972 draft. Overlays may define their own requirements on who can 973 collect/share diagnostic information. 975 10. IANA Considerations 977 10.1. Diagnostic Kind ID Types 979 IANA SHALL create a "RELOAD Diagnostic Kind ID Types" Registry. 980 Entries in this registry are 16-bit integers denoting diagnostics 981 extension data kind types carried in the diagnostic request and 982 response message, as described in Section 5.1.2. Code points from 983 0x0000 to 0x003F SHALL be assigned together with flags within "RELOAD 984 Diagnostics Flag" registry via RFC 5226 [RFC5226] standards action. 985 Code points in the range 0x0040 to 0xFFFD SHALL be registered via RFC 986 5226 standards action. 988 +----------------------+--------+---------------+ 989 | Diagnostic Kind Type | Code | Specification | 990 +----------------------+--------+---------------+ 991 | reserved | 0x0000 | RFC-XXXX | 992 | STATUS_INFO | 0x0001 | RFC-XXXX | 993 | ROUTING_TABLE_SIZE | 0x0002 | RFC-XXXX | 994 | PROCESS_POWER | 0x0003 | RFC-XXXX | 995 | BANDWIDTH | 0x0004 | RFC-XXXX | 996 | SOFTWARE_VERSION | 0x0005 | RFC-XXXX | 997 | MACHINE_UPTIME | 0x0006 | RFC-XXXX | 998 | APP_UPTIME | 0x0007 | RFC-XXXX | 999 | MEMORY_FOOTPRINT | 0x0008 | RFC-XXXX | 1000 | DATASIZE_STORED | 0x0009 | RFC-XXXX | 1001 | INSTANCES_STORED | 0x000A | RFC-XXXX | 1002 | MESSAGES_SENT_RCVD | 0x000B | RFC-XXXX | 1003 | EWMA_BYTES_SENT | 0x000C | RFC-XXXX | 1004 | EWMA_BYTES_RCVD | 0x000D | RFC-XXXX | 1005 | UNDERLAY_HOP | 0x000E | RFC-XXXX | 1006 | BATTERY_STATUS | 0x000F | RFC-XXXX | 1007 | reserved | 0x003F | RFC-XXXX | 1008 | local use (reserved) | 0xFFFE | RFC-XXXX | 1009 | reserved | 0xFFFF | RFC-XXXX | 1010 +----------------------+--------+---------------+ 1012 Table 1: Diagnostic Kind Types 1014 10.2. Message Codes 1016 This document introduces two new types of messages and their 1017 responses, requiring the following additions to the "RELOAD Message 1018 Code" Registry defined in RELOAD [I-D.ietf-p2psip-base]. These 1019 additions are: 1021 +-------------------+------------+----------+ 1022 | Message Code Name | Code Value | RFC | 1023 +-------------------+------------+----------+ 1024 | path_track_req | 101 | RFC-AAAA | 1025 | path_track_ans | 102 | RFC-AAAA | 1026 +-------------------+------------+----------+ 1028 Table 2: Extensions to RELOAD Message Codes 1030 [To RFC editor: Values starting at 101 were used to prevent 1031 collisions with RELOAD base values. Once RELOAD moves to RFC, these 1032 values may start at the next higher value after the RELOAD base 1033 values. The final message code will be assigned by IANA. And all 1034 RFC-AAAA should be replaced with the RFC number of RELOAD when 1035 publication.] 1037 10.3. Error Code 1039 This document introduces the following new error codes, extending the 1040 "RELOAD Message Code" registry as described below: 1042 +----------------------------------------+------------+----------+ 1043 | Message Code Name | Code Value | RFC | 1044 +----------------------------------------+------------+----------+ 1045 | Error_Underlay_Destination_Unreachable | 101 | RFC-AAAA | 1046 | Error_Underlay_Time_Exceeded | 102 | RFC-AAAA | 1047 | Error_Message_Expired | 103 | RFC-AAAA | 1048 | Error_Upstream_Misrouting | 104 | RFC-AAAA | 1049 | Error_Loop_Detected | 105 | RFC-AAAA | 1050 | Error_TTL_Hops_Exceeded | 106 | RFC-AAAA | 1051 +----------------------------------------+------------+----------+ 1053 Table 3: Extensions to RELOAD Error Codes 1055 10.4. Message Extension 1057 This document introduces the following new RELOAD extension code: 1059 +-----------------+------------+----------+ 1060 | Extension Name | Code Value | RFC | 1061 +-----------------+------------+----------+ 1062 | Diagnostic_Ping | 0x0002 | RFC-AAAA | 1063 +-----------------+------------+----------+ 1065 Table 4: New RELOAD Extension Code 1067 10.5. Diagnostics Flag 1069 IANA SHALL create a "RELOAD Diagnostics Flag" Registry. Entries in 1070 this registry are 1-bit flags contained in a 64-bits long integer 1071 dMFlags denoting diagnostic information to be retrieved as described 1072 in Section 5.3. New entries SHALL be defined via [RFC5226] Standards 1073 Action. The initial contents of this registry are: 1075 +-------------------------+------------------------------+--------+ 1076 | diagnostic information |diagnostic flag in dMFlags | RFC | 1077 |-------------------------+------------------------------+--------| 1078 |Reserved | 0x 0000 0000 0000 0000 |RFC-XXXX| 1079 |STATUS_INFO | 0x 0000 0000 0000 0001 |RFC-XXXX| 1080 |ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0002 |RFC-XXXX| 1081 |PROCESS_POWER | 0x 0000 0000 0000 0004 |RFC-XXXX| 1082 |BANDWIDTH | 0x 0000 0000 0000 0008 |RFC-XXXX| 1083 |SOFTWARE_VERSION | 0x 0000 0000 0000 0010 |RFC-XXXX| 1084 |MACHINE_UPTIME | 0x 0000 0000 0000 0020 |RFC-XXXX| 1085 |APP_UPTIME | 0x 0000 0000 0000 0040 |RFC-XXXX| 1086 |MEMORY_FOOTPRINT | 0x 0000 0000 0000 0080 |RFC-XXXX| 1087 |DATASIZE_STORED | 0x 0000 0000 0000 0100 |RFC-XXXX| 1088 |INSTANCES_STORED | 0x 0000 0000 0000 0200 |RFC-XXXX| 1089 |MESSAGES_SENT_RCVD | 0x 0000 0000 0000 0400 |RFC-XXXX| 1090 |EWMA_BYTES_SENT | 0x 0000 0000 0000 0800 |RFC-XXXX| 1091 |EWMA_BYTES_RCVD | 0x 0000 0000 0000 1000 |RFC-XXXX| 1092 |UNDERLAY_HOP | 0x 0000 0000 0000 2000 |RFC-XXXX| 1093 |BATTERY_STATUS | 0x 0000 0000 0000 4000 |RFC-XXXX| 1094 |Reserved | 0x FFFF FFFF FFFF FFFF |RFC-XXXX| 1095 +-------------------------+------------------------------+--------+ 1097 [To RFC editor: Please replace all RFC-XXXX in this document with the 1098 RFC number of this document.] 1100 10.6. XML Name Space Registration 1102 This document registers a URI for the config-diagnostics XML 1103 namespaces in the IETF XML registry defined in [RFC3688]. All the 1104 elements defined in this document belong to this namespace. 1106 URI: urn:ietf:params:xml:ns:p2p:config-diagnostics 1107 Registrant Contact: The IESG. 1108 XML: N/A, the requested URIs are XML namespaces 1110 And the overlay configuration file MUST contain the following xml 1111 language declaring p2psip diagnostics as a mandatory extension to 1112 RELOAD. 1114 1115 urn:ietf:params:xml:ns:p2p:config-diagnostics 1116 1118 11. Acknowledgments 1120 We would like to thank Zheng Hewen for the contribution of the 1121 initial version of this draft. We would also like to thank Bruce 1122 Lowekamp, Salman Baset, Henning Schulzrinne, Jiang Haifeng and Marc 1123 Petit-Huguenin for the email discussion and their valued comments, 1124 and special thanks to Henry Sinnreich for contributing to the usage 1125 scenarios text. We would like to thank the authors of the p2psip 1126 base draft for transferring text about diagnostics to this document. 1128 12. References 1130 12.1. Normative References 1132 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1133 RFC 792, September 1981. 1135 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1136 Requirement Levels", BCP 14, RFC 2119, March 1997. 1138 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1139 January 2004. 1141 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1142 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1143 May 2008. 1145 [I-D.ietf-p2psip-base] 1146 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 1147 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 1148 Base Protocol", draft-ietf-p2psip-base-26 (work in 1149 progress), February 2013. 1151 12.2. Informative References 1153 [UnixTime] 1154 "UnixTime", .>. 1157 [I-D.ietf-p2psip-self-tuning] 1158 Maenpaa, J. and G. Camarillo, "A Self-tuning Distributed 1159 Hash Table (DHT) for REsource LOcation And Discovery 1160 (RELOAD)", draft-ietf-p2psip-self-tuning-08 (work in 1161 progress), February 2013. 1163 [I-D.ietf-p2psip-concepts] 1164 Bryan, D., Willis, D., Shim, E., Matthews, P., and S. 1165 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 1166 draft-ietf-p2psip-concepts-04 (work in progress), 1167 October 2011. 1169 [Overlay-Failure-Detection] 1170 Zhuang, S., "On failure detection algorithms in overlay 1171 networks", Proc. IEEE Infocomm, Mar 2005. 1173 [Handling_Churn_in_a_DHT] 1174 Rhea, S., "Handling Churn in a DHT", USENIX Annual 1175 Conference, June 2004. 1177 [Diagnostic_Framework] 1178 Jin, X., "A Diagnostic Framework for Peer-to-Peer 1179 Streaming", 2005. 1181 [Diagnostics_and_NAT_traversal_in_P2PP] 1182 Gupta, G., "Diagnostics and NAT Traversal in P2PP - Design 1183 and Implementation", Columbia University Report , 1184 June 2008. 1186 Appendix A. Problems with Generating Multiple Responses on Path 1188 An earlier version of this document considered an approach where a 1189 response was generated by each intermediate peer as the message 1190 traversed the overlay. This approach was discarded. One reason this 1191 approach was discarded was that it could provide a DoS mechanism, 1192 whereby an attacker could send an arbitrary message claiming to be 1193 from a spoofed "sender" the real sender wished to attack. As a 1194 result of sending this one message, many messages would be generated 1195 and sent back to the spoofed "sender" - one from each intermediate 1196 peer on the message path. While authentication mechanisms could 1197 reduce some risk of this attack, it still resulted in a fundamental 1198 break from the request-response nature of the RELOAD protocol, as 1199 multiple responses are generated to a single request. Although one 1200 request with responses from all the peers in the route will be more 1201 efficient, it was determined to be too great a security risk and 1202 deviation from the RELOAD architecture. 1204 Appendix B. Changes to the Draft 1206 To RFC editor: This section is to track the changes. Please remove 1207 this section before publication. 1209 B.1. Changes since -00 version 1211 1. Changed title from "Diagnose P2PSIP Overlay Network" to "P2PSIP 1212 Overlay Diagnostics". 1214 2. Changed the table of contents. Add a section about message 1215 processing and a section of examples. 1217 3. Merge diagnostics text from the p2psip base draft -01. 1219 4. Removed ECHO method for security reasons. 1221 B.2. Changes since -01 version 1223 Added BATTERY_STATUS as diagnostic information. 1225 Removed UnderlayTTL test from the Ping method, instead adding an 1226 UNDERLAY_HOP diagnostic information for PathTrack method. 1228 Give some examples for diagnostic information, and give some 1229 editor's notes for further work. 1231 B.3. Changes since -02 version 1233 Provided further explanation as to why the base draft Ping in the 1234 current form cannot be used to replace Ping, and why some 1235 combination of methods cannot replace PathTrack. 1237 B.4. Changes since -03 version 1239 Modified structure used to share information collected. Both 1240 mechanisms now use a common data structure to convey information. 1242 B.5. Changes since -04 version 1244 Updated the authors' addresses and modified the last sentence in . 1245 (Section 5.3.2) 1247 B.6. Changes since -05 version 1249 Resolve Marc's comments from the mailing list. And define the 1250 details of STATUS_INO. 1252 B.7. Changes in version -10 1254 Resolve the authorization issue and other comments (e.g. define 1255 diagnostics as a mandatory extension) from WGLC. And check for the 1256 languages. 1258 Authors' Addresses 1260 Haibin Song 1261 Huawei 1263 Email: haibin.song@huawei.com 1265 Jiang Xingfeng 1266 Huawei 1268 Email: jiang.x.f@huawei.com 1270 Roni Even 1271 Huawei 1272 14 David Hamelech 1273 Tel Aviv 64953 1274 Israel 1276 Email: roni.even@mail101.huawei.com 1278 David A. Bryan 1279 Ethernot.org 1280 Williamsburg, Virginia 1281 United States of America 1283 Email: dbryan@ethernot.org