Subject: [P2PSIP] Random resource probe

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 10 Mar 2008 12:58:30 -0400

In reading the various drafts, I notice that several of them propose 
that to find something that you need, but that is not directly 
registered in the DHT (a "service", ala TURN or something else) the 
requester randomly probes the DHT to see if they can find what they need.

This make sense if you assume that most nodes are providing the service 
in question.  But if service providing nodes are sparse, that seems to 
be a very bad idea.
And none of the drafts talk about the assumed density of service 
availability.
Don't we at least need that information?

Yours, possibly very confused,
Joel
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 10 Mar 2008 13:28:52 -0400

The concept in section 11.3 of reload-03 is explicitly based on the  
assumption that the server density is something that can be estimated  
in advance (as explained in the Note on page 91).  ReDiR from OpenDHT  
is mentioned in the p2pp draft, and is a bit more complicated, but it  
attempts to dynamically adjust to the density of the service in the  
overlay.

I think it's clearly an open issue what type of service discovery is  
required.  In particular, what level of service discovery should be  
considered for part of the base draft and what should be regarded as  
an extension?   Fortunately, I think service discovery is something  
that can be built on top of the basic mechanism.

Bruce

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Mon, 10 Mar 2008 12:36:49 -0500

Hi, Joel:

It depends on the distribution of service provider. It may need some experiental data to see how much percentage of the service provider is enough for a relative efficient service discovery method. 

SEP proposal tries to check the routing states in the peer to find the service provider. One method to improve the search success rate is to send a LookupServicePeer message out and make the message traverse the overlay hop-by-hop until matched entry is found. It also set the max-hops for the message to avoid the message goes forever. 

Regards!
JiangXingFeng

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Mon, 10 Mar 2008 18:44:13 +0100

Hi Bruce,

On Mon, Mar 10, 2008 at 6:28 PM, Bruce Lowekamp <[email-masked]> wrote:
>  Fortunately, I think service discovery is something

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.

Thank you,
-- 
Victor Pascual Ávila
Research Engineer
Tel.  +34 93 542 2906
Fax. +34 93 542 2517

Research Group on Network Technologies and Strategies (NeTS)
Universitat Pompeu Fabra (UPF)
Pg. de Circumval·lació, 8
Office 358
08003 Barcelona (Spain)
http://nets.upf.edu/
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 10 Mar 2008 13:55:57 -0400

Thank you for the pointer to page 91, and the TURN usage description.
It seems to me that this sort of function is generic, so I was looking 
for a generic statement about these sorts of usages.  (For now, that can 
be abstracted as "any usage using random location should use the same 
multiple-entry registration approach as TURN, and is highly sensitive to 
accurate estimation of the usage density.")

It does seem quite difficult to accurately estimate the likely TURN 
server density.

Yours,
Joel M. Halpern

Bruce Lowekamp wrote:
> assumption that the server density is something that can be estimated in 
> advance (as explained in the Note on page 91).  ReDiR from OpenDHT is 
> mentioned in the p2pp draft, and is a bit more complicated, but it 
> considered for part of the base draft and what should be regarded as an 
> extension?   Fortunately, I think service discovery is something that 
> can be built on top of the basic mechanism.
> 
> Bruce
> 
>

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 10 Mar 2008 14:26:42 -0400

> 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.

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?

Bruce

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Mon, 10 Mar 2008 13:43:08 -0500

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,
> >
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.

> discovery is the only possible example of that behavior.

>But the  
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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 10 Mar 2008 17:54:47 -0400

Let me try parsing this another way.
If the Service location is just a normal lookup, returning normal 
responses, then it clearly needs no support from the P2P layer we are 
defining.
If pure random probes suffice, then that's enough.

However, if we want any pervasively supported mechanisms in order to 
increase the robustness of the search, then we need a base mechanism 
rather than just a usage.

(Correspondingly, I would like to see some discussion of whether TURN is 
really the only service or this is a general issue.  I have not been 
able to discern the answer to that.)

Yours,
Joel

Bruce Lowekamp wrote:
> 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.
> 
> 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?
> 
> Bruce
> 
>

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 10 Mar 2008 18:09:05 -0400

I think ReDiR is a good general-purpose service discovery algorithm.   
It auto-tunes based on server population, although I'm not entirely  
convinced it doesn't have bad behavior in avalanche restart, but  
there may be studies on that I'm not aware of.  In steady state, I  
believe ReDiR to be robust.

The mechanism currently in reload should work well in deployments  
where server population is well known.  I suspect that for wide-area  
overlays, for example, this is likely to be possible to measure in  
advance.  It has the virtue of simplicity.

I'm not sure what you mean by "pervasively supported mechanisms."   
Both of these techniques require no support beyond base STORE/FETCH.

TURN is certainly not the only example.  Conference bridges would be  
another.

Bruce

On Mar 10, 2008, at 5:54 PM, Joel M. Halpern wrote:

>> every

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 10 Mar 2008 18:25:49 -0400

An example of a "pervasively supported mechanism" is the SEP technique 
of having the receiver respond not just with whether it has the 
resource, but whether it knows where to find the resource (from 
exchanges with its neighbors.)  Since that would seem to be independent 
of any particular usage, it is a mechanism which, if you want it at all, 
you want supported by every node (i.e. pervasive.)
I can imagine other techniques.

If the ReDiR mechanism, and / or the Reload mechanism, are sufficiently 
robust to work across the range of real world deployments, then thats 
fine.  The fact that my limited intuition on random distributions makes 
me nervous doesn't mean anything.  (Heck, if I hadn't done the analysis 
years ago I wouldn't believe the numbers about how little overspeed 
switch cores need to work well.)  We are trying to cover a wide range of 
cases.

Yours,
Joel

PS: The reason I was asking about whether it is a single service (TURN) 
or multiple is that if we are going to end up with multiple "usages" 
which are essentially identical, it would be nice not to need to 
redefine things for each service.  As written Reload requires that the 
usage be redefined each time just to discover another underlying service.

Bruce Lowekamp wrote:
> I think ReDiR is a good general-purpose service discovery algorithm.  It 
> auto-tunes based on server population, although I'm not entirely 
> convinced it doesn't have bad behavior in avalanche restart, but there 
> may be studies on that I'm not aware of.  In steady state, I believe 
> ReDiR to be robust.
> 
> The mechanism currently in reload should work well in deployments where 
> server population is well known.  I suspect that for wide-area overlays, 
> for example, this is likely to be possible to measure in advance.  It 
> has the virtue of simplicity.
> 
> I'm not sure what you mean by "pervasively supported mechanisms."  Both 
> of these techniques require no support beyond base STORE/FETCH.
>

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Mon, 10 Mar 2008 17:39:59 -0500

> I can imagine other techniques.

That's right. The method proposed by SEP could work in both structured and unstructured overlay. What it requires node to do is to check its routing state whether there are peers providing the desired service while processing service searching message, in SEP, it is LookupServicePeer message. 

> usage be redefined each time just to discover another underlying 

SEP tries to propose a general method to search service.

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Mon, 10 Mar 2008 17:48:06 -0500

> responses, then it clearly needs no support from the P2P layer we 
Right. If the standard service name method works in all cases, there is no need to develop new methods. But in some cases, this method has some shortcomings:
1. if too much peers providing the same service, and also publish the information to the responsible peer fo the service-id gotten by hashing the standard service name. So the responsible peer has to store so much <key, value> pair;

2. the other shortcoming is if the service is a popular service, all query will go to the responsible peer. It may overload the responsible peer. 

> If pure random probes suffice, then that's enough.
Maybe we need collect some experiemental data to see whethere random probes could work in most cases. I mean, if the service providers could be got within two or three transactions, IMHO, it is a reasonable latency.

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 10 Mar 2008 18:57:49 -0400

On Mar 10, 2008, at 6:48 PM, jiangxingfeng 36340 wrote:

> Right. If the standard service name method works in all cases,  
> there is no need to develop new methods. But in some cases, this  
> method has some shortcomings:
> 1. if too much peers providing the same service, and also publish  
> the information to the responsible peer fo the service-id gotten by  
> hashing the standard service name. So the responsible peer has to  
> store so much <key, value> pair;
>
> 2. the other shortcoming is if the service is a popular service,  
> all query will go to the responsible peer. It may overload the  
> responsible peer.

This isn't how the service discovery algorithms work (either reload,  
redir, or any of the others I can think of).  ReDiR, in particular,  
is adaptive.  In ReDiR, the service providers and the queriers gauge  
the population density of the service and use that to select where to  
search for the service.  There isn't overload on a single responsible  
peer.

In the technique in reload, the data is stored at random locations  
and random queries are used to search, so again, there is no overload  
on a single peer.

> Maybe we need collect some experiemental data to see whethere  
> random probes could work in most cases. I mean, if the service  
> providers could be got within two or three transactions, IMHO, it  
> is a reasonable latency.
>

The technique in reload works fine if you can reasonably accurately  
predict the server population.  If you can't, it won't work very well.

Bruce

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 10 Mar 2008 19:01:33 -0400

How does the method in SEP work as service provider population grows  
or shrinks?  I like some of the properties it has, but it seems like  
as server population drops, it's relying on random chance that a  
particular path will happen to traverse a neighbor of a service  
provider.  As population drops, that probability goes down.

ReDiR handles this through its adaptation.  Reload (assuming the  
population is predicted in advance), works, but if a peer being able  
to provide the service is very rare, may require the service  
providers to do a lot of STOREs to achieve the desired density of  
registrations.

Bruce

On Mar 10, 2008, at 2:43 PM, jiangxingfeng 36340 wrote:

> 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.
>
> 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.
>
>>
> 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.
>

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Tue, 11 Mar 2008 00:12:11 +0100

>  2. the other shortcoming is if the service is a popular service, all query will go to the responsible peer. It may overload the responsible peer.

IMHO this is up to the DHT algorithm (e.g. CAN vs Chord) and the
number of replicas we have.
-- 
Victor Pascual Ávila
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Mon, 10 Mar 2008 18:35:57 -0500

Yes, You are right. These methods are trying to avoid the shortcomings which is in the method, just simply put the information under the service-id got by hashing the standard service name.

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Mon, 10 Mar 2008 18:46:36 -0500

> provider.  As population drops, that probability goes down.
If the key-id of the message is chosen at random, it may take more transactions to get the service provider. That needs some experimental data to see to which extent of the population of the service provider, the searching will succeed within reasonable time period. We will do some work after this IETF meeting. 

Another method to improve the success rate if the population is low, is to make the message traverse the overlay hop-by-hop until it finds matched entry. It may take longer time and may not stop. So maximum hops may be needed to prevent this happen.  
 
> providers to do a lot of STOREs to achieve the desired density of  

IMO, it is not easiy to predict the population. For TURN service, we could predict from some statistical data on the percentage of different types of NATs. But for other service, it may be hard to achieve the percentage. In another way, if the population changes over time, the service providers should do additional work accordingly. On the other hand, the service provider also should maintain 1/percentage <key,value> pair. It should periodi
cally update the state. 

JiangXingFeng

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 11 Mar 2008 07:15:32 -0700

The missing elements in Reload are well known in the DHT "industry":

1. Defining neighbor proximity by 

*         Delay

*         Number of routing hops

*         Bandwidth

2. Algorithms for fair disk usage, etc.

3. Recovery of temporarily "failed" neighbors that may have been
overloaded due to congestion in the access link or high CPU usage due to
cryptography.

The above are key ingredients and another reason to decouple the DHT
layer form the application layer; SIP in our case. 

This decoupling is one of the reasons why I believe P2PP should be the
common starting base for P2PSIP and not Reload for sure. 

In Reload (1) routing is duplicated in the DHT and the SIP layers and
(2) coupled for too strong from benefiting of advanced DHT development.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bruce Lowekamp
Sent: Monday, March 10, 2008 6:58 PM
To: jiangxingfeng 36340
Cc: [email-masked]
Subject: Re: [P2PSIP] Random resource probe

>> responses, then it clearly needs no support from the P2P layer we

>> are

peer.

on a single peer.

Bruce

P2PSIP mailing list

[email-masked]

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Tue, 11 Mar 2008 15:25:53 +0100

> common starting base for P2PSIP and not Reload for sure.

Excuse me for my ignorance, is there any implementation (and
measurements) of the "merged protocol"? AFAIK there are some
implementations (and measurements) of P2PP.

Thank you,

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 11 Mar 2008 07:36:25 -0700

I don't know about "merged code" but could not find any text or content from P2PP in Reload-03.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor Pascual Ávila
Sent: Tuesday, March 11, 2008 10:26 AM
To: Henry Sinnreich
Cc: Bruce Lowekamp; jiangxingfeng 36340; [email-masked]
Subject: Re: [P2PSIP] Random resource probe

Thank you,

---

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 11 Mar 2008 16:50:09 -0400

Hi Henry.  Responses inline...

On Mar 11, 2008, at 10:15 AM, Henry Sinnreich wrote:

> ·         Delay
> ·         Number of routing hops
> ·         Bandwidth
> 3. Recovery of temporarily ”failed” neighbors that may have been  
> overloaded due to congestion in the access link or high CPU usage  
> due to cryptography.
>

I think this is getting to an important open issue that we need to  
decide how we will handle (at least in whatever base overlay we agree  
on).  Basically, there is a spectrum of possibilities that range from

simple to explain and implement, but not ideal in all deployments
to
multi-featured, configurable, and complex. maybe(?) scales to  
different size/types of deployments

The DHT in reload-03 (and earlier) leans toward the simpler end of  
things, largely on the grounds of reducing complexity for ease of  
implementation.  But I think it certainly is an open topic (and  
likely to be the subject of much debate for some time) where the wg's  
base overlay should land on this scale.

> The above are key ingredients and another reason to decouple the  
> DHT layer form the application layer; SIP in our case.

Hear, hear!

>
> This decoupling is one of the reasons why I believe P2PP should be  
> the common starting base for P2PSIP and not Reload for sure.
> In Reload (1) routing is duplicated in the DHT and the SIP layers  
> and (2) coupled for too strong from benefiting of advanced DHT  
> development.
>

I'm not quite sure what you're referring to here.  11.2.2 and 11.2.3  
describe the two methods of establishing a SIP dialog proposed by  
reload-03.  The first is to use CONNECT (essentially ICE) to initiate  
a direct connection between the peers.  The second is a use of  
reload's generic TUNNEL mechanism to route the SIP dialog over the  
overlay as application-level traffic.   I believe that both these  
approaches separate the roles and responsibilities of the various  
layers appropriately, but am interested in any comments on how this  
could be improved.

Bruce

> From: [email-masked] [mailto:[email-masked]] On  
> Behalf Of Bruce Lowekamp

---

From: <[email-masked]>
Date: Wed, 12 Mar 2008 01:21:30 +0200

Hi Bruce,

>The first is to use CONNECT 
>(essentially ICE) to initiate a direct connection between the 
>peers.

Could you please explain why you want to use P2P layer methods on the
SIP layer (application layer)? Do you expect all SIP UAs to implement
P2PSIP?

Marcin  

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Bruce Lowekamp
>Sent: Tuesday, March 11, 2008 10:50 PM
>To: Henry Sinnreich
>Cc: [email-masked]
>> overloaded due to congestion in the access link or high CPU 
>usage due 
>> to cryptography.
>>
>
>I think this is getting to an important open issue that we 
>need to decide how we will handle (at least in whatever base 
>overlay we agree on).  Basically, there is a spectrum of 
>possibilities that range from
>
>simple to explain and implement, but not ideal in all 
>deployments to multi-featured, configurable, and complex. 
>maybe(?) scales to different size/types of deployments
>
>The DHT in reload-03 (and earlier) leans toward the simpler 
>end of things, largely on the grounds of reducing complexity 
>for ease of implementation.  But I think it certainly is an 
>open topic (and likely to be the subject of much debate for 
>some time) where the wg's base overlay should land on this scale.
>
>
>I'm not quite sure what you're referring to here.  11.2.2 and 
>11.2.3 describe the two methods of establishing a SIP dialog 
>proposed by reload-03.  The first is to use CONNECT 
>(essentially ICE) to initiate a direct connection between the 
>peers.  The second is a use of reload's generic TUNNEL 
>mechanism to route the SIP dialog over the  
>approaches separate the roles and responsibilities of the 
>various layers appropriately, but am interested in any 
>comments on how this could be improved.
>
>Bruce
>
>
>
>> Henry
>>
>> >> are defining.
>> > Right. If the standard service name method works in all 
>cases, there 
>> > is no need to develop new methods. But in some cases, this method 
>> > has some shortcomings:
>> > 2. the other shortcoming is if the service is a popular 
>service, all 
>> > query will go to the responsible peer. It may overload the 
>> > responsible peer.
>>
>> redir, or any of the others I can think of).  ReDiR, in 
>particular, is 
>> adaptive.  In ReDiR, the service providers and the queriers 
>gauge the 
>> population density of the service and use that to select where to 
>> In the technique in reload, the data is stored at random 
>locations and 
>> random queries are used to search, so again, there is no 
>overload on a 
>> single peer.
>>
>>
>> >
>> >
>> > Maybe we need collect some experiemental data to see 
>whethere random 
>> > probes could work in most cases. I mean, if the service providers 
>> > could be got within two or three transactions, IMHO, it is a 
>> > reasonable latency.
>> >
>>

---

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 11 Mar 2008 19:28:47 -0400

Well, no, I expect only P2PSIP peers to implement P2PSIP.  A non- 
p2psip URI that is registered in an overlay presumably is a publicly  
reachable address that doesn't require the CONNECT.    (So I guess my  
response should have been prefixed with something like "when  
connecting to a URI that is not a GRUU containing a PeerID..."

I don't think the current SIP usage specifies how to locate an  
outbound proxy, should one be required by the deployment.

Bruce

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 13 Mar 2008 03:02:00 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of jiangxingfeng 36340
Sent: Monday, March 10, 2008 2:43 PM
To: Bruce Lowekamp
Cc: Victor Pascual ?vila; [email-masked]
Subject: [P2PSIP] 回复 :Re: Random resource probe

more comments in line.
Regards!

JiangXingFeng

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Thu, 13 Mar 2008 09:03:00 -0500

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

Some feautres from SEP are independent from application layer and could work with other proposals than SEP, I think.

> 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.

SEP tries to use keepalive message to communicate status of downstream peers and do some more intelligent routing decisions. It may not be supported by all DHT algorithms. But I think it is a interesting issue which will influence the transactions' success rate. 

> 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>.
> 

Data model is a core structure in P2PSIP system. It is very important. Earlier RELOAD and P2PP also give descriptions on this topic. The service discovery method in SEP could be used to find a general service and could work with the core data model. 

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

I think, we need a independent service discovery method. You know, the essentienc of the P2P system is to make peers serve each other. So the important task for a peer in the overlay is to find peers where he could get help. So I think it is a important topic which should be considered in a base protocol. 

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