Subject: [P2PSIP] going forward with diagnostic draft

From: Roni Even <[email-masked]>
Date: Mon, 08 Mar 2010 12:41:17 +0200

Hi,

As the authors of the diagnostic draft got ready to iterate, we realized we
have to clear up a few issues with the group before we can come up with the
next version. There have been comments on list about doing this without
creation of new messages, but we also had comments at meetings and some
consensus saying that we shouldn't extend the messages that exist and use
new ones.

While the extensions are minor, it seems like we would need some extensions
to accomplish the collection of diagnostic information. We would like to
discuss on list which behavior is preferable -- document use of existing
messages, but this requires extensions that ideally should be in base, or
implement new messages. Simply using existing messages with no extensions
doesn't seem to result in being able to have the diagnostic collection
abilities we need, so doesn't appear to be a valid option. We'd like to nail
down some list discussion, and hopefully discuss this at IETF to get some
clear, specific hums on which direction the WG would like to take this work.

Essentially, for the "ping" behavior, we need to do we want to be able to do
two things -- send a message destined for a particular peer, and find out if
a particular resource lives there. How this differs somewhat from the
current behavior is in being able to obtain information from the destination
(diagnostic information) and being able to capture some on-path information
as well. If we reuse existing messages, we can query if a peer exists using
ping (and looking at who the response is from), and can query a resource
using fetch, but we need additional extensions, (for example in the current
draft, hop

counts) and need to specify how to request/obtain diagnostic information in
the message. The alternative is to use a new method, such as the INSPECT we
have proposed in the current draft.

Note that the ping message in the base draft is not extensible.

For the "traceroute" behavior, which is iterative to collect information,
keep the response from being enormous (and to allow for detecting failures
on-path), and for security reasons, we have two options. We can send a route
query, and then a message to each peer (again, assuming we specify/have
support for fetching diagnostic information), or we can use the path_track
as defined in the document.

They result in slightly different results (using existing messages gets a
"snap shot" of a route then checks each hop, so if the route changes, you
could be inspecting an invalid path, path_track has exactly the same
behavior, but the timing is a bit different as the next step in the route is
determined at each hop). It isn't clear to me one is any better than the
other. 

Having a specific diagnostic message will enable future extensions both
standard and enterprise specific.

The authors feel that it will be better to use specific messages for
diagnostics purposes and not to overload the base reload messages.

Roni Even

---

From: songhaibin 64081 <[email-masked]>
Date: Mon, 22 Mar 2010 02:55:25 +0800

> next version. There have been comments on list about doing this 
> withoutcreation of new messages, but we also had comments at 
> meetings and some
> While the extensions are minor, it seems like we would need some 
> extensionsto accomplish the collection of diagnostic information. 
> We would like to
> discuss on list which behavior is preferable -- document use of 
> existingmessages, but this requires extensions that ideally should 
> be in base, or
> implement new messages. Simply using existing messages with no 
> extensionsdoesn't seem to result in being able to have the 
> diagnostic collection
> current behavior is in being able to obtain information from the 
> destination(diagnostic information) and being able to capture some 
> on-path information
> ping (and looking at who the response is from), and can query a 
> resourceusing fetch, but we need additional extensions, (for 
> example in the current
> draft, hop
> 

That means if people want to reuse the existing ping message in the base draft, it has to be made extensible there(so that it can be used to collect some diagnostic info, such like hop counts). Or we use an alternative method (Inspect message in the diagnostic draft). Whatever, we need an explicit feedback from the WG about which way to go.

> 
> 
> For the "traceroute" behavior, which is iterative to collect 
> information,keep the response from being enormous (and to allow 
> for detecting failures
> query, and then a message to each peer (again, assuming we 
> specify/havesupport for fetching diagnostic information), or we 
> can use the path_track
> Having a specific diagnostic message will enable future extensions 
> bothstandard and enterprise specific.
> 
> 
> 

We would also like to talk about this question at this meeting. 

BR,
Haibin