Re: [P2PSIP] 回复 :Re: Random resource probe

Discussing <draft-jiang-p2psip-sep-01> is a welcome opportunity to freshen up on DHT and application layer (SIP) techniques such as:

1. Routing around congested or invisible nodes. This happens in the DHT layer and is amply documented. Please remember we want to keep the SIP and DHT layers neatly separated.

2. Advertising and retrieval of classes of data such as resources/services: SIP proxies, NAT traversal helpers that can do STUN and maybe some flavors of ICE, NICE, D-ICE :-), plus some relaying or (perish the thought) tunneling. There may be other such as buddy lists and voice mail. 
We would do well in the WG to define data types and classes to facilitate faster retrieval (how?; range searches for coded data types?).

These topics have also been treated fairly well in: <draft-baset-p2psip-p2pp-01> and earlier in <draft-singh-p2p-sip-01>.

Questions: 

- Is storage and retrieval of data classes relevant to SIP _generic and independent of the various P2PSIP proposals_?

- What are the common concepts in the three I-Ds that can be adopted by the WG, irrespective of the P2PSIP protocol choice?

I am not sure if there is time to discuss this on Friday, but we can discuss on the list.
Last, but not least, we need some step by step examples and message flows for such cases as discovering nearby SIP proxies and say nearby STUN and relay capable peers.

What do you think?

Henry

-----Original Message-----
From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of jiangxingfeng 36340
Sent: Monday, March 10, 2008 2:43 PM
To: Bruce Lowekamp
Cc: Victor Pascual ?vila; p2psip@ietf.org
Subject: [P2PSIP] 回复 :Re: Random resource probe

Compared with other methods, the method proposed in SEP exploiting routing state to find service provider has the following advantages, IMHO,:

1. Less maintenance cost: the advertisement of the service capability is through the overlay maintenance mechanism which all P2P algorithm has;

2. Reflect the state change as soon as possible. Because the service capability is only distributed on hop further to its neighobr, so the peers could use keepalive message to update its status of the service capabilities what it supports timely.

3. It could be used in both structured P2P system and unstructure P2P system.

more comments in line.
Regards!

JiangXingFeng

> 
> On Mar 10, 2008, at 1:44 PM, Victor Pascual ?vila wrote:
> 
> > Hi Bruce,
> >
> > On Mon, Mar 10, 2008 at 6:28 PM, Bruce Lowekamp  
> > <lowekamp@sipeerior.com> wrote:
> >>  Fortunately, I think service discovery is something
> >>  that can be built on top of the basic mechanism.
> >
> > Please, could you elaborate this?
> >
> > In SEP, three different service discovery mechanisms can be 
> found in
> > Section 4.1. We plan to put more effort on this issue.
> >
> 
> So I think the key question here (that we need to answer soon) is  
> whether service discovery needs a new method like SEP's  
> LookUpServicePeer method or whether it can simple use FETCH for a  
> particular data type defined by a usage (as reload proposes).
> 
> I do think that SEP's proposal is an intriguing possibility, but 
> I'm  
> personally not too enthusiastic about a method type that requires  
> every intermediate peer to do processing---I really would like to 
> see  
> message routing being as low-overhead an operations as possible.
Yes, you are right. So we define a new method so that only this message will be handled by intermediate peers. For other messages, such as PUT,GET, etc, they are routed in the same way as before.

> 
> Anyway, back to my original comment.  Most of the service 
> discovery  
> algorithms just rely on FETCH, so there are no changes to the 
> basic  
> peer protocol at all.  SEP has a custom method in the peer 
> protocol.   
> I'm not convinced that if you really want to have per-hop 
> additions  
> to a query, that you need a particular method for it or that 
> service  
> discovery is the only possible example of that behavior.

>But the  
> next question is that if a custom method is needed for service  
> discovery, can we at least build new service discovery algorithms 
> on  
> top of that beyond what are envisioned for the base draft?
How do you define 'base' draft? Do you think service discovery is included in the base draft? For me, I think, requirements used to form the overlay  should be included in the base draft. 

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip