One document matched: draft-ietf-p2psip-diagnostics-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3261 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC0792 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0792.xml">
<!ENTITY RFC4330 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4330.xml">
<!ENTITY RFC4981 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4981.xml">
<!ENTITY RFC5226 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY I-D.ietf-p2psip-sip PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-p2psip-sip.xml">
<!ENTITY I-D.ietf-p2psip-base PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-p2psip-base.xml">
<!ENTITY I-D.song-p2psip-security-eval PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.song-p2psip-security-eval.xml">
<!ENTITY I-D.bryan-p2psip-app-scenarios PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bryan-p2psip-app-scenarios.xml">
<!ENTITY I-D.bryan-p2psip-requirements PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bryan-p2psip-requirements.xml">
<!ENTITY I-D.zheng-p2psip-diagnose PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zheng-p2psip-diagnose.xml">
<!ENTITY I-D.matuszewski-p2psip-security-requirements PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.matuszewski-p2psip-security-requirements.xml">
<!ENTITY I-D.baset-p2psip-p2pp PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.baset-p2psip-p2pp.xml">
<!ENTITY I-D.ietf-mmusic-ice PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-ice.xml">
<!ENTITY I-D.ietf-behave-rfc3489bis PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-rfc3489bis.xml">
<!ENTITY I-D.ietf-p2psip-concepts PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-p2psip-concepts.xml">
<!ENTITY I-D.ietf-p2psip-self-tuning PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-p2psip-self-tuning.xml">
]>
<rfc category="std" docName="draft-ietf-p2psip-diagnostics-04"
ipr="pre5378Trust200902" submissionType="IETF" updates="" xml:lang="">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="yes" ?>
<?rfc strict="no" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<front>
<title abbrev="P2PSIP Overlay Diagnostics">P2PSIP Overlay
Diagnostics</title>
<author fullname="Song Haibin" initials="H." surname="Song">
<organization>Huawei</organization>
<address>
<postal>
<street>Baixia Road No. 91</street>
<city>Nanjing</city>
<region>Jiangsu Province</region>
<code>210001</code>
<country>P.R.China</country>
</postal>
<phone>+86-25-84565867</phone>
<facsimile>+86-25-84565888</facsimile>
<email>melodysong@huawei.com</email>
</address>
</author>
<author fullname="Jiang Xingfeng" initials="X." surname="Jiang">
<organization>Huawei</organization>
<address>
<postal>
<street>Baixia Road No. 91</street>
<city>Nanjing</city>
<region>Jiangsu Province</region>
<code>210001</code>
<country>P.R.China</country>
</postal>
<phone>+86-25-84565868</phone>
<facsimile>+86-25-84565888</facsimile>
<email>jiang.x.f@huawei.com</email>
</address>
</author>
<author fullname="Roni Even" initials="R" surname="Even">
<organization>Huawei</organization>
<address>
<postal>
<street>14 David Hamelech</street>
<city>Tel Aviv 64953</city>
<country>Israel</country>
</postal>
<email>even.roni@huawei.com</email>
</address>
</author>
<author fullname="David A. Bryan" initials="D" surname="Bryan">
<organization>Cogent Force, LLC / Huawei</organization>
<address>
<postal>
<street>Williamsburg, Virginia</street>
<country>United States of America</country>
</postal>
<email>dbryan@ethernot.org</email>
</address>
</author>
<date day="12" month="July" year="2010" />
<area>Real-time Applications and Infrastructure</area>
<workgroup>P2PSIP Working Group</workgroup>
<keyword>Diagnostics</keyword>
<keyword>P2PSIP</keyword>
<abstract>
<t>This document describes mechanisms for P2PSIP diagnostics. It
defines extensions to the RELOAD P2PSIP base protocol <xref
target="I-D.ietf-p2psip-base">RELOAD</xref> to collect
diagnostic information, and details the protocol specifications
for these extensions. Useful diagnostic information for
connection and node status monitoring is also defined. The
document also describes the usage scenarios and provides
examples of how these methods are used to perform diagnostics in
a P2PSIP overlay networks.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In the last few years, overlay networks have rapidly evolved
and emerged as a promising platform for deployment of new
applications and services in the Internet. One of the reasons
overlay networks are seen as an excellent platform for large
scale distributed systems is their resilience in the presence of
failures. This resilience has three aspects: data replication,
routing recovery, and static resilience. Routing recovery
algorithms are used to repopulate the routing table with live
nodes when failures are detected. Static resilience measures the
extent to which an overlay can route around failures even before
the recovery algorithm repairs the routing table. Both routing
recovery and static resilience relies on accurate and timely
detection of failures.</t>
<t>There are a number of situations in which some peers in a
P2PSIP overlay may malfunction or behave badly. For example,
these peers may be disabled, congested, or may be misrouting
messages. The impact of these malfunctions on the overlay
network may be a degradation of quality of service provided
collectively by the peers in the overlay network or an
interruption of the overlay services. It is desirable to
identify malfunctioning or badly behaving peers through
diagnostic tools, and exclude or reject them from the P2PSIP
system. Node failures may be also caused by underlying failures,
for example the recovery from an incorrect overlay topology may
be slow when the IP layer routing failover speed after link
failures is very slow. Moreover, if a backbone link fails and
the failover is slow, the network may be partitioned, leading to
partitions of overlay topologies and inconsistent routing
results between different partitioned components.</t>
<t>Some keep-alive algorithms based on periodic probe and
acknowledge mechanisms enable accurate and timely detection of
failures of one peer's neighbors <xref
target="Overlay-Failure-Detection"></xref>, but these algorithms
by themselves can only detect the disabled neighbors using the
periodic method, it may not be enough for service providers
operating the overlay network.</t>
<t>A single, general P2PSIP overlay diagnostic framework
supporting periodic and on-demand methods for detecting node
failures and network failures is desirable. This document
describes a general P2PSIP overlay diagnostic extension to the
P2PSIP base protocol RELOAD and is intended as a compliment to
keep-alive algorithms in the P2PSIP overlay itself.</t>
</section>
<section title="Terminology" toc="default">
<t>The concepts used in this document are compatible with <xref
target="I-D.ietf-p2psip-concepts">"Concepts and Terminology for Peer to
Peer SIP"</xref> and the <xref target="I-D.ietf-p2psip-base">P2PSIP base
protocol RELOAD</xref>.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Diagnostic Scenarios">
<t>P2P systems are self-organizing and ideally require no
network management in the traditional sense to set up and to
configure individual P2P nodes. However, users of an overlay, as
well as P2P service providers may contemplate usage scenarios
where some monitoring and diagnostics are required. We present a
simple connectivity test and some useful diagnostic information
that may be used in such diagnostics.</t>
<t>The common usage scenarios for P2P diagnostics can be broadly
categorized in three classes:</t>
<list style='letters'>
<t>Automatic diagnostics built into the P2P overlay routing
protocol. Nodes perform periodic checks of known neighbors and
remove those nodes from the routing tables that fail to
respond to connectivity checks <xref
target="Handling_Churn_in_a_DHT"></xref>. However, the
unresponsive nodes may only be temporarily disabled, for
example due to some local cryptographic processing overload,
disk processing overload or link overload. It is therefore
useful to repeat the connectivity checks to see if such nodes
have recovered and can be again placed in the routing tables.
This process is known as 'failed node recovery' and can be
optimized as described in the paper <xref
target="Handling_Churn_in_a_DHT">"Handling Churn in a
DHT"</xref>.</t>
<t>Diagnostics for a particular node to follow up an
individual user complaint or failure. For example, in this
case a technical support person may use a desktop sharing
application with the permission of the user to determine
remotely the health and possible problems with the
malfunctioning node. Part of the remote diagnostics may
consist of simple connectivity tests with other nodes in the
P2PSIP overlay and retrieval statistics of nodes from the
overlay . The simple connectivity tests are not dependent on
the type of P2PSIP overlay. Note that other tests may be
required as well, such as checking the health and performance
of the user's computer or mobile device and also checking the
bandwidth of the link connecting the user to the Internet.</t>
<t>P2P system diagnostics to check the overall health of the
P2P overlay network, the consumption of network bandwidth, for
the presence of problem links and also to check for abusive or
malicious nodes. This is not a trivial problem and has been
studied in detail for content and streaming P2P overlays <xref
target="Diagnostic_Framework"></xref> as well as in earlier
P2PSIP documents <xref
target="Diagnostics_and_NAT_traversal_in_P2PP"></xref>. While
this is a difficult problem, a great deal of information can
be obtained in helping these diagnostics by sending messages
to diagnose the network. This document provides a framework
for obtaining this information.</t>
</list>
</section>
<section title="Overview of operations" toc="default">
<t>The diagnostic mechanisms described in this document are
mainly intended to detect and localize failures or monitor
performance in P2PSIP overlay networks. It provides mechanisms
to detect and localize malfunctioning or badly behaving peers
including disabled peers, congested peers and misrouting peers.
It provides a mechanism to detect direct connectivity or
connectivity to a specified peer, a mechanism to detect the
availability of specified resource records and a mechanism to
discover P2PSIP overlay topology and the underlay topology
failures.</t>
<t>The P2PSIP diagnostics extensions define two mechanisms to
collect data. The first is an extension to the RELOAD ping
mechanism, allowing diagnostic data to be queried from a peer,
as well as to diagnose the path to that peer. The second is a
new method and response, Path_Track, for collecting diagnostic
information iteratively. Payloads for these mechanisms allowing
diagnostic data to be collected and represented are presented,
and additional error codes are introduced. Essentially, this
draft reuses P2PSIP base protocol specification and extends them
to introduce the new diagnostics methods. The extensions
strictly follow the P2PSIP base protocol specification on the
messages routing, transport, NAT traversal etc. The diagnostic
methods are however P2PSIP protocol independent.</t>
<t>This document primarily describes how to detect and localize
failures including disabled peers, congested peers, misrouting
behaviors and underlying network faults in P2PSIP overlay
networks through a simple and efficient mechanism. This
mechanism is modeled after the ping/traceroute paradigm: ping
(RFC792 <xref target="RFC0792">ICMP echo request </xref>) is
used for connectivity checks, and traceroute is used for
hop-by-hop fault localization as well as path tracing. This
document specifies a "ping-like" mode (by extending the RELOAD
ping method to gather diagnostics) and a "traceroute-like" mode
(by defining the new Path_Track method) for diagnosing P2PSIP
overlay networks.</t>
<t>One approach these tools can be used is to detect the
connectivity to the specified peer or the availability of the
specified resource-record through the extended P2PSIP Ping
operation once the overlay network receives some alarms about
overlay service degradation or interruption, if the Ping fails,
one can then send a Path_Track to determine where the fault
lies.</t>
<t>The diagnostic information must be only provided to
authorized peers. Some diagnostic information can be authorized
to all the participants in the P2PSIP overlay, and some other
diagnostic information can only be provided to the authorization
peer list of each diagnostic information according to the local
or overlay policy. The authorization depends on the kinds
of the diagnostic information and the administrative
considerations, and is application specific.</t>
<section title="“Ping-like” Behavior: Extending Ping">
<t>To provide “ping-like” behavior, the RELOAD
ping method has been extended to collect diagnostic data along
the path. The request message is forwarded by the intermediate
peers along the path and then terminated by the responsible
peer, and after optional local diagnostics, the responsible
peer returns a response message. If an error is found when
routing, an Error response is sent to the initiator node by
the intermediate peer.</t>
<t>The message flow of a Ping message (with diagnostic
extensions) is as follows:</t>
<figure title="Ping Diagnostic Message Flow">
<artwork>
Peer A Peer B Peer C Peer D
| | | |
|(1). Ping | | |
|------------------->|(2). Ping | |
| |------------------->|(3). Ping |
| | |------------------->|
| | | |
| | |<-------------------|
| |<-------------------|(4). Ping |
|<-------------------|(5). Ping | |
|(6). Ping | | |
| | | |
</artwork>
</figure>
</section>
<section title=" “Traceroute-like” Behavior: The
Path_Track Method">
<t>We define a simple Path_Track method for retrieving
diagnostics information iteratively. First, the initiating
peer asks its neighbor A which is the next hop peer to the
destination ID, and then retrieve the next hop peer B
information, along with optional diagnostic information of A,
to the initiator peer. Then the initiator peer asks the next
hop peer B (directly or symmetric routing) to get the further
next hop peer C information and diagnostic information of B.
Unless a failure prevents the message from being forwarded,
this step can be iteratively repeated until the request reaches
responsible peer D for the destination ID, and retrieves
diagnostic information of peer D.</t>
<t>The message flow of a Path_Track message (with diagnostic
extensions) is as follows:</t>
<figure title="Path_Track Diagnostic Message Flow">
<artwork>
Peer-A Peer-B Peer-C Peer-D
| | | |
|(1).Path_TrackReq | | |
|------------------->| | |
|(2).Path_TrackAns | | |
|<-------------------| | |
| |(3).Path_TrackReq | |
|--------------------|------------------->| |
| |(4).Path_TrackAns | |
|<-------------------|--------------------| |
| | |(5).Path_TrackReq |
|--------------------|--------------------|------------------->|
| | |(6).Path_TrackAns |
|<-------------------|--------------------|--------------------|
| | | |
</artwork>
</figure>
<t>There have been proposals made on list that RouteQuery and
a series of Fetch requests can be used to replace the
Path_Track mechanism, but in the presence of churn such an
operation would not, strictly speaking, provide identical
results, as the path may change between RouteQuery and Fetch
operations. (although obviously the path could change between
steps of Path_Track as well) The WG should discuss which
technique they prefer for obtaining this information. If Fetch
is used, a similar list of enhancements to Fetch may be
required.</t>
</section>
<section title="Problems with Generating Multiple Responses on Path">
<t>An earlier version of this document considered an approach
where a response was generated by each intermediate peer as
the message traversed the overlay. This approach was
discarded as a result of working group discussion. One reason
this approach was discarded was that it could provide a DoS
mechanism, whereby an attacker could send an arbitrary message
claiming to be from a spoofed “sender” the real
sender wished to attack. As a result of sending this one
message, many messages would be generated and sent back to the
spoofed “sender” -- one from each intermediate
peer on the message path. While authentication mechanisms
could reduce some of the risk of this attack, it still
resulted in a fundamental break from the request-response
nature of the RELOAD protocol, as multiple responses are
generated to a single request. Although one request with
responses from all the peers in the route will be more
efficient, it was determined to be too great a security risk
and deviation from the RELOAD architecture. This summary is
provided here to document the WG decision on this issue.</t>
</section>
</section>
<section title="RELOAD diagnostic extensions">
<t>This document extends RELOAD to carry diagnostics
information. Considering the special usage of diagnostics, this
document defines extensions for a payload to Ping, as well as
the new method Path_Track and its response. Additionally, new
Error codes, message bodies for conveying diagnostics, and some
suggested common diagnostic values are defined. Processing of
the Path_Track message and the diagnostic bodies is
discussed.</t>
<t>The mechanism defined in this document follows the RELOAD
specification, the new request and response message use the
message format specified in P2PSIP base protocol messages.
Please refer to the <xref
target="I-D.ietf-p2psip-base">RELOAD</xref> for details of the
protocol.</t>
<section title="Diagnostic Data Structures" anchor="DiagDataStruc">
<t>The diagnostics use the following common diagnostics data
structures. Two common structures are defined.
DiagnosticRequest for requesting data, and DiagnosticResponse
for returning information.</t>
<section title="DiagnosticRequest Data Structure" anchor="DiagReqDataStruc">
<t>The DiagnosticRequest data structure is sent to request
diagnostic information and has the following form:</t>
<figure>
<artwork>
enum { (2^16-1) } DiagnosticExtensionRequestType;
struct {
DiagnosticExtensionRequestType type;
opaque diagnostic_extension_contents<0..2^32-1>;
} DiagnosticExtension
struct {
uint64 expiration;
uint64 timestampInitiated;
uint32 length;
select (length){
case 0:
uint64 dMFlags;
case > 0:
uint64 dMFlags;
DiagnosticExtension diagnostic_extensions<0..2^32-1>;
}
} DiagnosticsRequest;
</artwork>
</figure>
<t>The fields in the DiagnosticRequest are as follows:</t>
<list style="hanging">
<t>expiration : The time-of-day (in seconds and
microseconds, according to the receiver's clock) in NTP
timestamp format <xref target="RFC4330"></xref> when the
request expires. This field can be used to mitigate the
replay attack to the destination peer and overlay
network.</t>
<t>timestampInitiated : The time-of-day (in seconds and
microseconds, according to the sender's clock) in NTP
timestamp format <xref target="RFC4330"></xref> when the
P2PSIP Overlay diagnostic request is sent.</t>
<t>length : the length of the extended diagnostic request
information in bytes. If the value is greater than or
equal to 1, then some extended diagnostics information is
requested. The value of length must not be negative. </t>
<t>dMFlags : A mandatory field which is an unsigned 64-bit
integer indicating which base diagnostic information the
initiator is interested in. The initiator sets different
bits to retrieve different kinds of diagnostic
information. If dMFlags is clear, then no base diagnostic
information is conveyed in the Path_Track response. If
dMFlag is set to all '1's, then all base diagnostic
information values are requested. A request may set any
number of the flags to request the corresponding
diagnostic information.</t>
<t>FIX (Note: This memo specifies the initial set of
flags, the flags can be extended by standard action. We
will add a section about extending the flags both standard
and application specific in a future version) The dMflags
indicate general diagnostic information The mapping
between the bits in the dMFlags and the diagnostic
information kind presented is as below.</t>
<t>diagnostic_extensions : consists of one or more
DiagnosticExtension structures (see below) documenting
additional diagnostic information being requested.</t>
</list>
<t>Each DiagnosticExtension has the following fields:</t>
<list>
<t>type : the extension type (see <xref target="IANADER" />) Note that type 0xFFFE
is reserved for overlay specific diagnostics and may be
used without IANA registration for local diagnostic
information.</t>
<!-- <t>length : the length of the opaque data describing the
request for this particular extension.</t> -->
<t>diagnostic_extension_contents : the opaque data
containing the request for this particular extension. This
data is extension dependent.</t>
</list>
</section>
<section title="DiagnosticResponse Data Structure">
<figure>
<artwork>
enum { (2^16-1) } DiagnosticKindId;
struct {
DiagnosticKindId kind;
opaque diagnostic_info_contents<0..2^16-1>;
} DiagnosticInfo;
struct {
uint64 expiration;
uint64 timestampReceived;
uint8 hopCounter;
DiagnosticInfo diagnostic_info_list<0..2^32-1>;
} DiagnosticsResponse;
</artwork>
</figure>
<t>The fields in the Diagnostic Response are as follows:</t>
<list style="hanging">
<t>expiration : The time-of-day (in seconds and
microseconds, according to the receiver's clock) in NTP
timestamp format <xref target="RFC4330"></xref> when the
Inspect request expires. This field can be used to
mitigate the replay attack to the destination peer and
overlay network.</t>
<t>timestampReceived : The time-of-day (in seconds and
microseconds, according to the receiver's clock) in NTP
timestamp format <xref target="RFC4330"></xref> when the
P2PSIP Overlay diagnostic request was received.</t>
<t>hopCounter : This field only appears in diagnostic
responses. It must be exactly copied from the TTL field of
the forwarding header in the received request. This
information is sent back to the request initiator,
allowing it to compute the hops that the message traversed
in the overlay.</t>
<!-- <t>length : the length of the extended diagnostic response
information in bytes. If no information was requested in
the request, this field may be zero.</t> -->
<t>diagnostic_info_list : consists of one or more
DiagnosticInfo values containing the requested diagnostic
information.</t>
</list>
<t>The fields in the DiagnosticInfo structure are as
follows:</t>
<list style="hanging">
<t>kind : A numeric code indicating the type of
information being returned. For base data requested using
the dMFlags, this code corresponds to the dMFlag set, and
is listed in section FIX. For diagnostic extensions, this
code will be identical to the value of the
DiagnosticExtensionRequestType set in the type field of
the DiagnosticExtension of the request, and these two
values will be assigned together. See <xref
target="IANADKT" />.</t>
<!-- <t>length : the length in bytes of the opaque data
containing the information being returned.</t> -->
<t>diagnostic_information : Data containing the value for
the diagnostic information being reported. Various kinds
of diagnostic information can be retrieved, Please refer
to <xref target="diag_information" /> for details of the
types and Diagnostic Kind-ID for the base diagnostic
information that may be reported.</t>
</list>
</section>
<section title="dMFlags and Diagnostic Kind ID Types" anchor="diag_information">
<t>The dMFlags field described above is a 64 bit field that
allows requesters to identify up to 62 items of base
information to request (the first and last flags being
reserved) when sending a request. When the requested base
information is returned in the response, the value of the
diagnostic kind ID will correspond to the numeric field
marked in the dMFlags in the request. The values for the
dMFlags are defined in <xref target="IANADFLG" /> and the
diagnostic Kind-IDs are defined in <xref target="IANADKT" />.
The information contained for each value is described in
this section.</t>
<t>Editor's note: For the diagnostic information of
processing power, bandwidth and etc., we should look at what
has been useful for PlanetLab and in commercial deployments
in this context, and further discussion is needed on what
mature diagnostics information for p2p overlays can be
brought here. </t>
<list>
<t>STATUS_INFO (8 bits): A single value element containing
an unsigned byte representing whether or not the node is
in congestion status. An example usage of STATUS_INFO is
for congestion-aware routing. In this scenario, each peer
has to update its congestion status periodically, an
intermediate peer in the DHT network will choose its next
hop according to both the DHT routing algorithm and the
status information, and then forward requests to the
chosen next hop, so as to avoid increasing load on
congested peers.</t>
<t>ROUTING_TABLE_SIZE (32 bits): A single value element
containing an unsigned 32-bit integer representing the number of
peers in the peer's routing table. The administrator of the
overlay may be interested in statistics of this value for the
consideration such as routing efficiency.</t>
<t>PROCESS_POWER (32 bits): A single value element containing an
unsigned 32-bit integer specifying the processing power of the
node in unit of MIPS.</t>
<t>BANDWIDTH (32 bits): A single value element containing
an unsigned 32-bit integer specifying the bandwidth of the
node in unit of Kbps.</t>
<t>SOFTWARE_VERSION: A single value element containing a
US-ASCII string that identifies the manufacture, model, and
version of the software.</t>
<t>MACHINE_UPTIME (64 bits): A single value element containing
an unsigned 64-bit integer specifying the time the nodes has
been up in seconds.</t>
<t>APP_UPTIME (64 bits): A single value element containing an
unsigned 64-bit integer specifying the time the p2p application
has been up in seconds.</t>
<t>MEMORY_FOOTPRINT (32 bits): A single value element containing
an unsigned 32- bit integer representing the memory footprint of
the peer program in kilo bytes. (Note: A kilo byte in this document represents 1024
bytes.)</t>
<t>DATASIZE_STORED (64 bits): An unsigned 64-bit integer
representing the number of bytes of data being stored by this
node.</t>
<t>INSTANCES_STORED: An array element containing the number of
instances of each kind stored. The array is index by Kind-ID.
Each entry is an unsigned 64-bit integer.</t>
<t>MESSAGES_SENT_RCVD: An array element containing the
number of messages sent and received. The array is indexed
by method code. Each entry in the array is a pair of
unsigned 64-bit integers (packed end to end) representing
sent and received.</t>
<t>EWMA_BYTES_SENT (32 bits): A single value element
containing an unsigned 32-bit integer representing an
exponential weighted average of bytes sent per second by
this peer. sent = alpha x sent_present + (1 - alpha) x
sent where sent_present represents the bytes sent per
second since the last calculation and sent represents the
last calculation of bytes sent per second. A suitable
value for alpha is 0.8. This value is calculated every
five seconds.</t>
<t>EWMA_BYTES_RCVD (32 bits): A single value element
containing an unsigned 32-bit integer representing an
exponential weighted average of bytes received per second
by this peer. Same calculation as above.</t>
<t>UNDERLAY_HOP (8 bits): It indicates the IP layer hops
from the intermediate peer which receives the diagnostics
message to its next hop peer for this message. (Note: this
is from the underlayTTL in the previous version. However,
RELOAD does not require the intermediate peers to look
into the message body. So here we use Path_Track to gather
underlay hops for diagnostics purpose.</t>
<t>BATTERY_STATUS (8 bits): The left-most bit is used to
indicate whether this peer is using battery or not. If
this bit is clear ('0'), then the peer is using battery
power. The other 7 bits are to be determined by specific
applications.</t>
</list>
</section>
<section title="Extending Diagnostic Information">
<t>The DiagnosticsExtension structure may be used to extend
the diagnostic information collected.</t>
<t>Editor's Note: <xref
target="I-D.ietf-p2psip-self-tuning">The self-tuning
draft</xref> could extend the diagnostics information here
to collect related information for calculating self-tuning
parameters.</t>
</section>
</section>
<section title="Request Extension: Ping" anchor="ping_ext">
<t>To extend the ping request for use in diagnostics, a new
extension as defined in Section 5.3.3 of RELOAD is defined.
The structure for a MessageExtension in RELOAD is defined
as:</t>
<figure align="left">
<artwork>
struct {
MessageExtensionType type;
Boolean critical;
opaque extension_contents<0..2^32-1>;
} MessageExtension;
</artwork>
</figure>
<t>For the ping request extension, we define a new
MessageExtensionType, extension 0x0001 named Diagnostic_Ping, as
specified in <xref target="table_extcodes"/> and specified in
the RELOAD draft section 13.12. The extension contents consists of a
DiagnosticRequest structure as defined in <xref
target="DiagReqDataStruc" />. This extension MAY be used for
new requests of the the ping method and MUST NOT be included
in requests using any other method.</t>
<t>This extension is NOT critical. If a peer does not extend
the extension, they will simply ignore the diagnostic portion
of the message, and will treat the message if it was a normal
ping. Senders MUST accept a response that lacks diagnostic
information and SHOULD NOT resend the message expecting a
reply. Receivers who receive a method other than ping
including this extension MUST ignore the extension.</t>
</section>
<section title="New Reqeust: Path_Track" anchor="Path_Track">
<t>This document defines a simple Path_Track method to
retrieve the diagnostic information from the intermediate
peers along the routing path. At each step of the Path_Track
request, the responsible peer responds to the initiator node
with requested status information such as congestion state,
its processing power, its available bandwidth, the number of
entries in its neighbor table, its uptime, its identity and
network address information, and the next hop peer
information.</t>
<t>A Path_Track request specifies which diagnostic information
is requested using a DiagnosticRequest Data structure. Base
information is requested by setting the appropriate flags in
the dMFlags field of the DiagnosticRequest. If the flag is
clear (no bits are set), then the Path_Track request is only
used for requesting the next hop information. In this case the
iterative mode of Path_Track is degraded to a Route_Query
method which is only used for checking the liveness of the
peers along the routing path. The Path_Track request can be
routed directly or through the overlay based on the routing
mode chosen by the initiator node.</t>
<t>A response to a successful PathTrackReq is a PathTrackAns
message. There is a general diagnostic information portion of
the payload, the contents of which are based on the flags in
the request. Please refer to <xref
target="diag_information"></xref> for the definitions of the
base diagnostic information, and <xref target="IANARMC" /> for
the numeric message code for the new request.</t>
<section title="Path_track Request">
<t>The structure of the Path_track request is as follows:</t>
<figure>
<artwork>
struct {
Destination destination;
DiagnosticRequest request;
} PathTrackReq;
</artwork>
</figure>
<t>The fields of the PathTrackReq are as follows:</t>
<list style="hanging">
<t>destination : The destination which the requester is
interested in. This may be any valid destination object,
including a Node-ID, compressed ids, or Resource-ID.</t>
<t>request : A DiagnosticsRequest, as discussed in
<xref target="DiagDataStruc" />.</t>
</list>
</section>
<section title="Path_track Response">
<t>The structure of the Path_Track Response is as follows:</t>
<figure>
<artwork>
struct {
Destination next_hop;
DiagnosticResponse response;
} PathTrackAns;
</artwork>
</figure>
<t>The fields of the PathTrackAns are as follows:</t>
<list style="hanging">
<t>next_hop : The information of the next hop node from the
responding intermediate peer to the destination node. If the
responding peer is the responsible peer for the destination
ID, then the next_hop node ID equals the responding node ID,
and after that the initiator must stop the iterative
process.</t>
<t>response : A DiagnosticsResponse, as discussed in
<xref="DiagDataStruct" />.</t>
</list>
</section>
</section>
<section anchor="sec_err_codes" title="Error Codes">
<t>This document extends the Error response method defined in
the P2PSIP base protocol specification to describe the result
of diagnostics. When an error is encountered in RELOAD, the
Message Code 0xFFFF is returned. The ErrorResponse structure
includes an error code, and we define new error codes to
report on possible error conditions detected while performing
diagnostics:</t>
<figure align="left">
<artwork>
Code Value Error Code Name
101 Underlay Destination Unreachable
102 Underlay Time exceeded
103 Message Expired
104 Upstream Misrouting
105 Loop detected
106 TTL hops exceeded
</artwork>
</figure>
<t>The final error codes will be assigned by IANA. as
specified in section 13.7 of the <xref
target="I-D.ietf-p2psip-base">p2psip base protocol
</xref>.</t>
<t>This document introduces several types of error information
in the error_info field in the case of Code 101. These are
represented as a text string of length 32, with the end padded
with null characters.</t>
<figure align="left">
<artwork>
error_info:
net unreachable
host unreachable
protocol unreachable
port unreachable
fragmentation needed
source route failed
</artwork>
</figure>
<t>Editors note: We may need more discussion here to see if we
need to define an additional sub-code field for the error
information. Sub-codes are easier for the machine to process
while various text is more human readable.</t>
</section>
<section title="Message Processing">
<section title="Message Creation and Transmission">
<t>When constructing either a Ping message or with
diagnostic extensions or a Path_Track message, the sender
MUST create a DiagnosticRequest data structure. The sender
MUST set the expiration field of this structure in NTP
timestamp format. The value MUST be at least 10 seconds in
the future, and MUST NOT be more than 600 seconds in the
future. The timestampInitiated field MUST be set to the
current time in NTP timestamp format. The sender MUST
include the dMFlags field in the structure, and MAY send any
number (or all) of the flags to request the desired
diagnostic information. The sender MAY leave all the bits
unset, requesting no diagnostic information, but MUST
include the field. The sender MAY also include diagnostic
extensions for additional information. If the sender
includes any extensions, they MUST calculate the length of
these extensions and set the length field to the correct
length. If no extensions are included, the sender MUST set
length to zero.</t>
<t>When constructing a diagnostic ping message, the sender
MUST create an MessageExtension structure as defined in
RELOAD 5.3.3. The value of type MUST be 0x0001. The value of
critical must be FALSE. The value of extension_contents MUST
be the DiagnosticRequest structure defined above. The sender
MUST place the MessageExtension structure in the extensions
field of the MessageContents structure. The message MAY be
directed to a particular NodeId or ResourceID, but SHOULD
NOT be sent to the broadcast NodeID.</t>
<!-- <t>Editors note: RELOAD appears to be broken right now. To allow
for multiple extensions and allow peers that don't understand the
extension to process it properly, there needs to be a length in
the MessageContents structure. Right now, the message appears
like it couldn't be parsed without knowing the extension.</t> -->
<t>When constructing a Path_Track message, the sender MUST
set the message_code for the RELOAD MessageContents
structure for Path_track. The request field of the
PathTrackReq must be set to the DiagnosticRequest data
structure defined above. The destination field MUST be set
to the desired destination, which MAY be either a NodeId or
ResourceID but SHOULD NOT be the broadcast NodeID.</t>
</section>
<section anchor="Message_Processing_Intermediate_Peers"
title="Message Processing: Intermediate Peers">
<t>When a request arrives at a peer, if the peer's responsible ID
space does not cover the destination ID of the request, then the
peer MUST continue process this request according to the overlay
specified routing mode from the base draft.</t>
<t>In p2psip overlay, the error response can be generated by the
intermediate peer or responsible peer, to a diagnostic message or
other messages. When a request is received at a peer, the peer may
find some connectivity failures or malfunction peers through the
pre-defined rules of the overlay network, e.g. by analyzing via list
or underlay error messages. The peer SHOULD report the error
responses to the initiator node. The malfunction node information
should also be reported to the initiator node in the error message
payload. All error responses contain the Error code followed by the
subcode and descriptions if existed.</t>
<t>Each intermediate peer receiving a Ping message with
extensions (and which understands the extension) or
receiving a Path_Track request/response SHOULD check the
expiration value (NTP format) to determine if the message
expired. If the message expired, the intermediate peer
SHOULD generate a message with Error Code 103 "Message
Expired" and return it to the initiator node, and discard
the message.</t>
<t>The peer should return an Error response with the Error Code 101
"Underlay Destination Unreachable" when it receives an ICMP message
with "Destination Unreachable" information after forwarding the
received request to the destination peer.</t>
<t>The peer should return an Error response with the Error Code 102
"Underlay Time Exceeded" when it receives an ICMP message with "Time
Exceeded" information after forwarding the received request.</t>
<t>The peer should return an Error response with Error Code 104
"Upstream Misrouting" when it finds its upstream peer disobeys the
routing rules defined in the overlay. The immediate upstream peer
information should also be conveyed to the initiator node.</t>
<t>The peer should return an Error response with Error Code 105
"Loop detected" when it finds a loop through the analysis of via
list.</t>
<t>The peer should return an Error response with Error Code 106 "TTL
hops exceeded" when it finds that the TTL field value is no more
than 0 when forwarding.</t>
<!--
<t>With Path_Track, if a former Path_Track message does not arrive
at the destination, then the following Path_Track request must copy
the next_hop field in the former response into the forwarding header
and keep the destination_ID unchanged.</t>
<t>Inspect is also used to detect possible failures in the specified
path of P2PSIP overlay network. If disabled peers, misrouting
behavior and underlying network faults are detected during the
routing process, the Error responses with Error codes and
descriptions, must be sent to the initiator node immediately.</t>
-->
</section>
<section anchor="Message_response" title="Message Response Creation">
<t>When a diagnostic request message arrives at a peer, it
understands the extension (in the case of ping) or the new
request type path_track, and it is responsible for the
destination ID specified in the forwarding header, it MUST
follow the specifications defined in 5.1.3 of the base draft
to form the response header, and perform the following operations:</t>
<t>The receiver MUST check the expiration value (NTP format)
in the DiagnosticsRequest to determine if the message
expired. If the message expired, the peer MUST generate a
message with the Error Code 103 "Message Expired" and return
it to the initiator node, and discard the message.</t>
<t>If the message is not expired, the receiver MUST
construct a DiagnosticsResponse structure. The destination peer MUST copy the
TTL value from the forwarding header to the hopCounter field of the DiagnosticsResponse
structure. Note that this value will represent 100-hops
unless overlay configuration has overridden the value. The receiver MUST generate an NTP
format timestamp for the current time of day and place it in the
timestampReceived field. The receiver MUST construct a new
expiration time and place it in the expiration field of the
DiagnosticResponse. This expiration MUST be at least 10
seconds in the future and MUST NOT be more than 600 seconds
in the future.</t>
<t>The destination peer MUST check if the initiator node has
the authority to get certain kinds of diagnostic
information, and if appropriate, appends the diagnostic
information requested in the dMFlags and
diagnostic_extensions (if any) in the diagnostic_info_list
field of the DiagnosticsResponse structure. If there is any
information returned, the receiver MUST calculate the length
of the response and set length appropriately. If there is no
diagnostic information returned, length MUST be set to zero.</t>
<t>In the event of an error, an error response containing the error
code followed by the subcode and description (if they exist) MUST be
created and sent to the sender. If the requester asks for
diagnostic information that they are not authorized to
query, the receiving peer MUST return an Error response
with the Error Code 1 "Error_Unauthorized".</t>
</section>
<section title="Interpreting Results">
<t>The initiator node, as well as the responding peer, MAY compute
the overlay One-Way-Delay time through the value in
timestampReceived and the timestampInitiated field. However, for a
single hop measurement, the traditional measurement methods MUST be
used instead of the overlay layer diagnostics methods.</t>
<t>Editor note: We need more discussion and careful consideration on
how to use the timestamp here because time synchronization is a
barrier in open Internet environment, while in the operator's
network, it may be less of a problem.</t>
<t>The initiator node receiving the Inspect response MAY check the
hopCounter field and compute the overlay hops to the destination
peer for the statistics of connectivity quality from the perspective
of overlay hops.</t>
</section>
</section>
</section>
<section title="Examples">
<t>Below, we sketch how these metrics can be used.</t>
<section title="Example 1">
<t>A peer may set EWMA_BYTES_SENT and WEMA_BYTES_RCVD flags in the
PathTrackReq to its direct neighbors. A peer can use EWMA_BYTES_SENT
and EWMA_BYTES_RCVD of another peer to infer whether it is acting as a
media relay. It may then choose not to forward any requests for media
relay to this peer. Similarly, among the various candidates for
filling up routing table, a peer may prefer a peer with a large UPTIME
value, small RTT, and small LAST_CONTACT value.</t>
</section>
<section title="Example 2">
<t>A peer may set the StatusInfo Flag in the PathTrackReq to a remote
destination peer. The overlay has its own threshold definition for
congestion. The peer can get knowledge of all the status information
of the intermediate peers along the path. Then it can choose other
paths to that node for the later requests.</t>
</section>
<section title="Example 3">
<t>A peer may use Inspect to evaluate the average overlay hops to
other peers by sending InspectReq to a set of random resource or node
IDs in the overlay. A peer may adjust its timeout value according to
the change of average overlay hops.</t>
</section>
</section>
<section title="Security Considerations">
<t>The authorization for diagnostics information must be designed with
care to prevent it becoming a resort to retrieve information for bot
attacks. It should also be careful that attackers can use diagnostics to
analyze overlay information to attack certain key peers if there are. As
this draft is a RELOAD extension, it follows RELOAD message header and
routing specifications, the common security considerations described in
the base draft <xref target="I-D.ietf-p2psip-base"></xref> are also
applicable to this draft. Overlays may define their own
requirements on who can collect/share diagnostic information.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<section title="Diagnostic Extension Types" anchor="IANADER">
<texttable anchor="table_diagextcodes"
title="Diagnostic Extension Request Types">
<ttcol align="center">Diagnostic Extension Name</ttcol>
<ttcol align="center">Code</ttcol>
<ttcol align="center">Specification</ttcol>
<c>reserved (identifiers used for built in types)</c>
<c>0 - 0x003F</c>
<c>RFC-BBBB</c>
<c>local use (reserved)</c>
<c>0xFFFE</c>
<c>RFC-BBBB</c>
<c>reserved</c>
<c>0xFFFF</c>
<c>RFC-BBBB</c>
</texttable>
</section>
<section title="Diagnostic Kind ID Types" anchor="IANADKT">
<texttable anchor="table_diagkindcodes"
title="Diagnostic Kind Types">
<ttcol align="center">Diagnostic Kind Type</ttcol>
<ttcol align="center">Code</ttcol>
<ttcol align="center">Specification</ttcol>
<c>reserved</c>
<c>0x0000</c>
<c>RFC-BBBB</c>
<c>STATUS_INFO</c>
<c>0x0001</c>
<c>RFC-BBBB</c>
<c>ROUTING_TABLE_SIZE</c>
<c>0x0002</c>
<c>RFC-BBBB</c>
<c>PROCESS_POWER</c>
<c>0x0003</c>
<c>RFC-BBBB</c>
<c>BANDWIDTH</c>
<c>0x0004</c>
<c>RFC-BBBB</c>
<c>SOFTWARE_VERSION</c>
<c>0x0005</c>
<c>RFC-BBBB</c>
<c>MACHINE_UPTIME</c>
<c>0x0006</c>
<c>RFC-BBBB</c>
<c>APP_UPTIME</c>
<c>0x0007</c>
<c>RFC-BBBB</c>
<c>MEMORY_FOOTPRINT</c>
<c>0x0008</c>
<c>RFC-BBBB</c>
<c>DATASIZE_STORED</c>
<c>0x0009</c>
<c>RFC-BBBB</c>
<c>INSTANCES_STORED</c>
<c>0x000A</c>
<c>RFC-BBBB</c>
<c>MESSAGES_SENT_RCVD</c>
<c>0x000B</c>
<c>RFC-BBBB</c>
<c>EWMA_BYTES_SENT</c>
<c>0x000C</c>
<c>RFC-BBBB</c>
<c>EWMA_BYTES_RCVD</c>
<c>0x000D</c>
<c>RFC-BBBB</c>
<c>UNDERLAY_HOP</c>
<c>0x000E</c>
<c>RFC-BBBB</c>
<c>BATTERY_STATUS</c>
<c>0x000F</c>
<c>RFC-BBBB</c>
<c>reserved</c>
<c>0x003F</c>
<c>RFC-BBBB</c>
<c>local use (reserved)</c>
<c>0xFFFE</c>
<c>RFC-BBBB</c>
<c>reserved</c>
<c>0xFFFF</c>
<c>RFC-BBBB</c>
</texttable>
</section>
<section title="Message Codes" anchor="IANARMC">
<t>This document introduces two new types of messages and
their responses, requiring the following additions to the
"RELOAD Message Code" Registry defined in <xref
target="I-D.ietf-p2psip-base">RELOAD</xref>. These additions
are:</t>
<texttable anchor="table_msgcodes"
title="Extensions to RELOAD Message Codes">
<ttcol align="center">Message Code Name</ttcol>
<ttcol align="center">Code Value</ttcol>
<ttcol align="center">RFC</ttcol>
<c>path_track_req</c>
<c>101</c>
<c>RFC-AAAA</c>
<c>path_track_ans</c>
<c>102</c>
<c>RFC-AAAA</c>
</texttable>
<t>Note: Values starting at 101 were used to prevent
collisions with RELOAD base values. Once RELOAD moves to
RFC, these values may start at the next higher value after
the RELOAD base values. The final message code will be
assigned by IANA.</t>
</section>
<section title="Error Code">
<t>This document introduces the following new error codes, extending the "RELOAD
Message Code" registry as described below:</t>
<texttable anchor="table_errcodes"
title="Extensions to RELOAD Error Codes">
<ttcol align="center">Message Code Name</ttcol>
<ttcol align="center">Code Value</ttcol>
<ttcol align="center">RFC</ttcol>
<c>Error_Underlay_Destination_Unreachable</c>
<c>101</c>
<c>RFC-AAAA</c>
<c>Error_Underlay_Time_Exceeded</c>
<c>102</c>
<c>RFC-AAAA</c>
<c>Error_Message_Expired</c>
<c>103</c>
<c>RFC-AAAA</c>
<c>Error_Upstream_Misrouting</c>
<c>104</c>
<c>RFC-AAAA</c>
<c>Error_Loop_Detected</c>
<c>105</c>
<c>RFC-AAAA</c>
<c>Error_TTL_Hops_Exceeded</c>
<c>106</c>
<c>RFC-AAAA</c>
</texttable>
</section>
<section title="Message Extension">
<t>This document introduces the following new RELOAD extension
code:</t>
<texttable anchor="table_extcodes"
title="New RELOAD Extension Code">
<ttcol align="center">Extension Name</ttcol>
<ttcol align="center">Code Value</ttcol>
<ttcol align="center">RFC</ttcol>
<c>Diagnostic_Ping</c>
<c>0x0001</c>
<c>RFC-AAAA</c>
</texttable>
</section>
<section title="Diagnostics Flag" anchor="IANADFLG">
<t>IANA SHALL create a "RELOAD Diagnostics Flag" Registry. Entries in
this registry are 1-bit flag contained in a 64-bits long integer
dMFlags denoting diagnostic information to be retrieved as described
in <xref target="Path_Track"></xref>. New entries SHALL be defined via
<xref target="RFC5226"></xref> Standards Action. The initial contents
of this registry are:<figure>
<artwork>
+-------------------------+------------------------------+--------+
| diagnostic information |diagnostic flag in dMFlags | RFC |
|-------------------------+------------------------------+--------|
|Reserved | 0x 0000 0000 0000 0000 |RFC-BBBB|
|STATUS_INFO | 0x 0000 0000 0000 0001 |RFC-BBBB|
|ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0002 |RFC-BBBB|
|PROCESS_POWER | 0x 0000 0000 0000 0004 |RFC-BBBB|
|BANDWIDTH | 0x 0000 0000 0000 0008 |RFC-BBBB|
|SOFTWARE_VERSION | 0x 0000 0000 0000 0010 |RFC-BBBB|
|MACHINE_UPTIME | 0x 0000 0000 0000 0020 |RFC-BBBB|
|APP_UPTIME | 0x 0000 0000 0000 0040 |RFC-BBBB|
|MEMORY_FOOTPRINT | 0x 0000 0000 0000 0080 |RFC-BBBB|
|DATASIZE_STORED | 0x 0000 0000 0000 0100 |RFC-BBBB|
|INSTANCES_STORED | 0x 0000 0000 0000 0200 |RFC-BBBB|
|MESSAGES_SENT_RCVD | 0x 0000 0000 0000 0400 |RFC-BBBB|
|EWMA_BYTES_SENT | 0x 0000 0000 0000 0800 |RFC-BBBB|
|EWMA_BYTES_RCVD | 0x 0000 0000 0000 1000 |RFC-BBBB|
|UNDERLAY_HOP | 0x 0000 0000 0000 2000 |RFC-BBBB|
|BATTERY_STATUS | 0x 0000 0000 0000 4000 |RFC-BBBB|
|Reserved | 0x FFFF FFFF FFFF FFFF |RFC-BBBB|
+-------------------------+------------------------------+--------+
</artwork>
</figure></t>
</section>
</section>
<section title="Open Questions">
The term "underlay" here is used in conformance with current
P2P literature to represent (generically) the physical network
over which the P2P overlay operates. While there have been
comments to use "overlay link" as terminology for this term,
that term is not used in the broader P2P literature (underlay
is used in its place). To conform to the broader P2P work
outside the P2PSIP WG, we have used this term. Open Question:
Should the base draft/terminology draft be updated to reflect
the literature?
</section>
<section title="Acknowledgments">
<t>We would like to thank Zheng Hewen for the contribution of the
initial version of this draft. We would also like to thank Bruce
Lowekamp, Salman Baset, Henning Schulzrinne and Jiang Haifeng for the
email discussion and their valued comments, and special thanks to Henry
Sinnreich for contributing to the usage scenarios text. We would like to
thank the authors of the p2psip base draft for transferring text about
diagnostics to this document.</t>
<t>The authors would also like to thank the many people of the IETF
P2PSIP WG that have contributed to discussions and provided input
invaluable in assembling this document.</t>
</section>
<section title="Appendix: Changes to the Draft">
<section title="Changes since -00 version">
<list style="numbers">
<t>Changed title from "Diagnose P2PSIP Overlay Network"
to "P2PSIP Overlay Diagnostics".</t>
<t>Changed the table of contents. Add a section about message
processing and a section of examples.</t>
<t>Merge diagnostics text from the p2psip base draft -01.</t>
<t>Removed ECHO method for security reasons.</t>
</list>
</section>
<section title="Changes since -01 version">
<list>
<t>Added BATTERY_STATUS as diagnostic information.</t>
<t>Removed UnderlayTTL test from the Inspect method, instead
adding an UNDERLAY_HOP diagnostic information for PathTrack
method.</t>
<t>Give some examples for diagnostic information, and give
some editor's notes for further work.</t>
</list>
</section>
<section title="Changes since -02 version">
<list>
<t>Provided further explanation as to why the base draft Ping
in the current form cannot be used to replace Inspect, and
why some combination of methods cannot replace
Path_track.</t>
</list>
</section>
<section title="Changes since -03 version">
<list>
<t>Modified structure used to share information collected.
Both mechanisms now use a common data structure to convey information.</t>
</list>
</section>
</section>
<!--
<section title="Appendix: Changes Required to use Ping instead of Inspect">
<t><list>
<t>1. Addition of a hopCounter mechanism to replicate the behavior
of the current Inspect.</t>
</list></t>
</section> -->
</middle>
<back>
<references title="Normative References">
&RFC0792;
&RFC2119;
&RFC3261;
&RFC5226;
&I-D.ietf-p2psip-sip;
&I-D.ietf-p2psip-base;
&I-D.zheng-p2psip-diagnose;
<reference anchor="Overlay-Failure-Detection">
<front>
<title>On failure detection algorithms in overlay networks</title>
<author initials="S" surname="Zhuang">
<organization></organization>
</author>
<date day="13-17" month="Mar" year="2005" />
</front>
<seriesInfo name="" value="Proc. IEEE Infocomm" />
</reference>
<reference anchor="Handling_Churn_in_a_DHT">
<front>
<title>Handling Churn in a DHT</title>
<author initials="S" surname="Rhea">
<organization></organization>
</author>
<date day="" month="June" year="2004" />
</front>
<seriesInfo name="USENIX" value="Annual Conference" />
</reference>
<reference anchor="Diagnostic_Framework">
<front>
<title>A Diagnostic Framework for Peer-to-Peer Streaming</title>
<author initials="X" surname="Jin">
<organization>Hong Kong University and Microsoft</organization>
</author>
<date year="2005" />
</front>
</reference>
<reference anchor="Diagnostics_and_NAT_traversal_in_P2PP" target="">
<front>
<title>Diagnostics and NAT Traversal in P2PP - Design and
Implementation</title>
<author initials="G" surname="Gupta">
<organization></organization>
</author>
<date month="June" year="2008" />
</front>
<seriesInfo name="Columbia University Report" value="" />
</reference>
</references>
<references title="Informative References ">
&RFC4330;
&RFC4981;
&I-D.ietf-behave-rfc3489bis;
&I-D.matuszewski-p2psip-security-requirements;
&I-D.song-p2psip-security-eval;
&I-D.baset-p2psip-p2pp;
&I-D.ietf-mmusic-ice;
&I-D.bryan-p2psip-app-scenarios;
&I-D.bryan-p2psip-requirements;
&I-D.ietf-p2psip-self-tuning;
&I-D.ietf-p2psip-concepts;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 15:29:28 |