Subject: [P2PSIP] Ping

From: Cullen Jennings <[email-masked]>
Date: Wed, 16 Jul 2008 12:05:46 -0700

The ping method now does three things as described in 6.4.2.2 and  
perhaps the name should be changed to something other than ping.  
Options are so the options are here are roughly
1) leave it as is
2) change name to something new (say probe)
3) split into two methods one that determines which resource another  
node is responsible (PROBE)  for and one that does the other parts  
(PING)
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "David A. Bryan" <[email-masked]>
Date: Thu, 17 Jul 2008 12:43:04 -0400

I'm pretty solidly in the camp of splitting it (3). Technically
speaking, you can do two things with the same message, so the present
approach would work, but from a protocol design perspective, I prefer
splitting it for a few reasons:

1) The draft is a little hard to read this way. I can see a good bit
of confusion being caused by the fact that in many cases PING will be
used for the DHT, but it is only described in 6.4.2, on connection
management, and not in 6.3.2. You could list it both places, but that
seems ugly too.

2) Splitting it in two gives the DHT section not only a push-based
mechanism for information, but a poll-based one as well (other than
abuse of a connection method). Many DHTs will be far easier to
implement this way (Chord is, for that matter -- PING is used as a
poll-based for DHT maintenance, not connection management in 12.6.3 of
the current draft).

3) While I can see being able to do it either way, if they are split,
from an implementation perspective I can see modular DHTs being
easier. Connection management can be implemented once, DHTs for each
message, and a lower layer doesn't have to determine which context
PING is being used in. (I know there are other ways to do this, but I
just think it will make implementations simpler)

So again, I say split 'em. PROBE is a good name for the new method.
POLL would work too.

David (as individual)

On Wed, Jul 16, 2008 at 3:05 PM, Cullen Jennings <[email-masked]> wrote:
>
> The ping method now does three things as described in 6.4.2.2 and perhaps
> the name should be changed to something other than ping. Options are so the
> options are here are roughly
> 1) leave it as is
> 3) split into two methods one that determines which resource another node is
> responsible (PROBE)  for and one that does the other parts (PING)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: Dan York <[email-masked]>
Date: Mon, 28 Jul 2008 20:06:37 -0400

I would also agree that Ping be split up for the very simple reason  
that most *users* out there are accustomed to a "ping" command being a  
VERY simple connectivity test.  Users are used to using ping to just  
test if they can reach another node on the network.  That's it.

Sure, functionality *could* be added to a "ping" command to have it  
retrieve various bits of resource information, but I would expect that  
this is not necessarily what users (and implementers) may be  
expecting.  I would agree that it would be best to split it so that  
PING was just the truly low-level connectivity test - simple, easy and  
fast - and then something else like "PROBE" would be used to test for  
and receive the resource information.

My 2 cents,
Dan

On Jul 17, 2008, at 12:43 PM, David A. Bryan wrote:

>> perhaps

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: songhaibin 64081 <[email-masked]>
Date: Tue, 29 Jul 2008 14:08:31 +0800

If that makes sense, perhaps the traceroute mode of the Echo message in the diagnostic draft, which is used to diagnose where the problem happens for the failed routing, and gather other useful information on the path, should also be splitted into two messages:
(1) a message to track where the problem happens for failed routing, 
(2) a new message to gather other information of intermediate peers

-Song Haibin

 Dan York <[email-masked]> wrote

> > speaking, you can do two things with the same message, so the 
> present> approach would work, but from a protocol design 
> perspective, I prefer
> > management, and not in 6.3.2. You could list it both places, but 
> that> seems ugly too.
> >
> > 3) While I can see being able to do it either way, if they are 
> split,> from an implementation perspective I can see modular DHTs 
> being> easier. Connection management can be implemented once, DHTs 
> for each
> > On Wed, Jul 16, 2008 at 3:05 PM, Cullen Jennings 
> <[email-masked]>  
> > wrote:
> >>
> >> the name should be changed to something other than ping. 
> Options  
> >> are so the

---

From: songhaibin 64081 <[email-masked]>
Date: Tue, 29 Jul 2008 21:22:21 +0800

Bruce Lowekamp <[email-masked]> wrote:

> songhaibin 64081 wrote:
> > If that makes sense, perhaps the traceroute mode of the Echo 
> message in the diagnostic draft, which is used to diagnose where 
> the problem happens for the failed routing, and gather other 
> useful information on the path, should also be splitted into two 
> messages:> (1) a message to track where the problem happens for 
> failed routing, 
> For (2), does reload's route log (6.2.2.2) meet your requirements, 
> or do 
> you think different functionality is needed.
> 
> Bruce

Route-log is an attribute must be involved with other requests. I prefer a separate message to do this work(2). You can just gather the ovelay information, without accompany with any other PUT, GET or other requests.

-Song Haibin

> >> Sure, functionality *could* be added to a "ping" command to 
> have 
> >> it  
> >> retrieve various bits of resource information, but I would 
> expect 
> >> that  
> >> PING was just the truly low-level connectivity test - simple, 
> easy 
> >> and  
> >> fast - and then something else like "PROBE" would be used to 
> test 
> >> for  
> >>> mechanism for information, but a poll-based one as well (other 
> than>>> abuse of a connection method). Many DHTs will be far 
> easier to
> >>> PING is being used in. (I know there are other ways to do 
> this, 
> >> but I
> >>> So again, I say split 'em. PROBE is a good name for the new 
> method.>>> POLL would work too.
> >>>
> >>> David (as individual)
> >>>