Subject: [p2p-sip] Concepts draft: Open Issue #1: Searching for services

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 7 Dec 2006 12:48:06 -0500

Open issue #1:  Can different peers in a P2PSIP Overlay offer
different services to the Overlay? If so, do we need the
concept of  searching for the set of peers that offer a service?

Proposed Resolution: Yes and Yes. Though we may require
that all peers offer some minimal set of services, there is likely
to be at least one service  that is not offered by every peer.
Thus we need the concept of searching for the set of peers
that offer a service.

For now, we are proposing to leave undefined the detailed
properties of the search. Thus we are proposing not
to answer questions like whether the search finds all peers
that offer the service, or whether the search returns the
"closest" peer. Instead, we propose to add these questions to the
design questions section of the document.

Comments?

- Philip

---

From: jiang.x.f at huawei.com (JiangXingFeng)
Date: Fri, 08 Dec 2006 15:47:24 +0800

Hi, Philip:
  I have some comments, please see inline.
Regards
--
Jiang XingFeng
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This e-mail and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient(s) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

--------------------------------------------------------------------
> -----Original Message-----
> From: p2p-sip-bounces at cs.columbia.edu
> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Philip Matthews
> Sent: Friday, December 08, 2006 1:48 AM
> To: P2P-SIP
> Cc: David A. Bryan
> Subject: [p2p-sip] Concepts draft: Open Issue #1: Searching for services
> 

> Thus we need the concept of searching for the set of peers
For the first issue, I agree with the proposed resolution. Peers in the
overlay have different capabilities other than basic storage and routing
service. These capabilities could be used to make some applications easier
to implement.
For the second one, I think if we think of different service as resource
like SIP URI and put these resources into overlay, it is easy to get these
resource by common search mechanism of DHT. 
A problem following the above open issues is: if there are several peers
providing the same service, how does the system choose the appropriate one
or more to serve other peers? Maybe the criteria are net-path closest away
from service requesting peers, or performance of service providing peer? I
think the criteria are dependent on the specific application. Is this
problem in the scope of P2PSIP or out of scope? 
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: jani.hautakorpi at ericsson.com (Jani Hautakorpi (JO/LMF))
Date: Fri, 08 Dec 2006 13:15:51 +0200

Hi Philip,

> concept of  searching for the set of peers that offer a service?

Do you have some concrete services in mind?

My initial impression is that a search functionality would make sense 
only if the services would be such that they couldn't be identified with 
a SIP URI.

-- 
Jani

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Fri, 8 Dec 2006 07:23:33 -0600

I agree with this proposed resolution. It seems important that we identify 
the need for the capability, but we should not go too far down the road in 
the concepts document.

We DO need to go down the road in the protocol documents later.

Thanks,

Spencer

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 8 Dec 2006 09:56:15 -0500

See inline.

On 8-Dec-06, at 02:47 , JiangXingFeng wrote:
[snip]

> problem in the scope of P2PSIP or out of scope?

I agree that the criterion of selecting a peer that is net-path  
closest would
be good for some services. Of course, for other services, different  
criteria might
be more appropriate (e.g., for a voicemail service, voicemail storage  
capacity
might be more important).

Ultimately, we might well want very sophisticated search schemes.  
However,
some have suggested that we stick with a simple scheme for now, in  
the same
way that we are sticking with a simple lookup scheme finding users.

Since the goal of the Concept draft is to specify a basic framework  
and give some terminology
to help the group discuss ideas, it seems best to us (the authors) if  
the draft
is as general as possible about the search mechanism, at least until  
the group
starts trying to narrow down the search mechanism details.

- Philip

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 8 Dec 2006 10:22:24 -0500

On 8-Dec-06, at 06:15 , Jani Hautakorpi (JO/LMF) wrote:

> My initial impression is that a search functionality would make  
> sense only if the services would be such that they couldn't be  
> identified with a SIP URI.

Hi Jani:

Here are my opinions of what such services might be (my co-authors  
may not agree! ;-).

One service might be STUN and TURN server service. Some peers might  
offer both STUN and TURN, some might offer just STUN, and some might  
offer neither.
Other services might be SIP Proxy server service, or SIP Redirect  
server service, etc.  Other services might be the willingness to host  
clients.

There has been some debate over which services all peers must offer,  
and which peers can optionally offer.  Rather than continue that  
debate right now, the authors are simply saying:
              "there will be at least one service that not all peers  
will offer, and thus a search mechanism is needed".

- Philip

---

From: bryan at ethernot.org (David A. Bryan)
Date: Fri, 8 Dec 2006 10:50:43 -0500

I think I had in mind something like what Jiang had in mind -- for
now, with a simple system, things are stored by URIs, and the method
for choosing between is out of scope. I soould like a broken record
today, but I think again that a protocol for selecting the best relay
from a list is something with broader applicability than P2PSIP --
might be able to reuse something or if we have to make one, push it to
a group that can make a more general one.

And although I missed this earlier...Philip: can we use a word other
than search, since it is simple lookup we are really talking about
here? Otherwise wording looks great to me.

David

---

From: mlepinski at bbn.com (Matt Lepinski)
Date: Fri, 08 Dec 2006 11:01:39 -0500

Philip,

Thanks a lot for the clarification. In light of your examples, the 
service search issue makes a lot more sense.

However, from the text of the -03 version of the concepts draft, it is 
unclear to me what things are "services" (as opposed to say, 
"resources"). Are you planning to add a definition of a "service" to 
section 2 of the draft?

- Matt Lepinski

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Fri, 08 Dec 2006 17:15:51 +0100

> resource by common search mechanism of DHT. 

We must be very careful in taking such a decision, because, with such a
naive approach, we would store all the istances of the same service
(apart from replicas) on the same peer and cause dangerous displacements
to the DHT traffic.  For example, the peer authoritative for the URL
representing the STUN service, would receive many more queries than
almost any other peer.

> problem in the scope of P2PSIP or out of scope? 

This is a very general problem, probably out of scope for p2psip.

>> design questions section of the document.

I agree with Philip; at the moment we don't have enough ground to give a
solid definition for the generic "search" operation.

-- 
Ciao,
Enrico

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 8 Dec 2006 11:42:50 -0500

> here? Otherwise wording looks great to me.

How about we say:
"a lookup of a service returns at least one peer that supports that  
service".

First, this changes "search" to "lookup".

Second, it doesn't take a position on how many peers are returned.
If 5 peers support the service, then the lookup may return just one  
peer,
or it may return all 5. (Of course, when we define the mechanism, we may
need to answer this question, but for now we leave this question as  
open).

- Philip

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 8 Dec 2006 11:46:02 -0500

On 8-Dec-06, at 11:01 , Matt Lepinski wrote:

> However, from the text of the -03 version of the concepts draft, it  
> is unclear to me what things are "services" (as opposed to say,  
> "resources"). Are you planning to add a definition of a "service"  
> to section 2 of the draft?
>
> - Matt Lepinski
>

Another one of the open issues in the Concept draft is to clarify the  
distinction
(if any) between a "user" and a "resource". I haven't posted this one  
yet because
I don't have a proposed resolution. However, it seems that we should add
"service" to this list.

- Philip

---

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Fri, 8 Dec 2006 11:46:09 -0500

Inline [RRR].

________________________________

From: p2p-sip-bounces at cs.columbia.edu on behalf of Philip Matthews
Sent: Fri 12/8/2006 11:42 AM
To: David A. Bryan
Cc: P2P-SIP
Subject: Re: [p2p-sip] Concepts draft: Open Issue #1: Searching for services

How about we say:

[RRR] This is an important issue. In MANET, when the peer is selected to create the route toplogy (e.g., OSPFv3-MDR) in the IP layer in P2P environment, there is an algorithms which is the best one based on cost-performance trade-off distributively.

[RRR] There can be many solutions: 1. Combine application layer P2P logic with just IP network topology logic, 2. An indpendent topology optimization in the SIP application layer, and/or 3. Others.

- Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061208/f879fe18/attachment.html

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 8 Dec 2006 12:06:49 -0500

> representing the STUN service, would receive many more queries than

Enrico:

I don't totally understand your concern.

Say I implement service lookup as follows. For each service, there is  
a unique URI for the service (e.g., "STUNServers@<Overlay  
Identifier>" or whatever). The information associated with this URI  
is stored in a single peer in the Overlay (ignoring replicas for  
robustness). Say that peer is X. Then all the peers that offer the  
service "register" with X saying that they offer the service.  When  
peer A does a lookup on "STUNServers@<Overlay Identifier>", then X  
returns one or more peers supporting the service. Peer X might return  
just three peers for each lookup query, and randomly select those  
peers each time, to make sure that no one peer is overloaded.

Is your concern that many peers would want STUN services, and thus  
there would be many lookups on "STUNServers@<Overlay Identifier>" and  
thus peer X would get overloaded?  Or are you concerned about the  
peers offering the service?

- Philip

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Fri, 08 Dec 2006 18:20:52 +0100

Philip Matthews wrote:
> Say I implement service lookup as follows. For each service, there is a
> unique URI for the service (e.g., "STUNServers@<Overlay Identifier>" or
> whatever). The information associated with this URI is stored in a
> single peer in the Overlay (ignoring replicas for robustness). Say that
> peer is X. Then all the peers that offer the service "register" with X
> saying that they offer the service.  When peer A does a lookup on
> "STUNServers@<Overlay Identifier>", then X returns one or more peers
> supporting the service. Peer X might return just three peers for each
> lookup query, and randomly select those peers each time, to make sure
> that no one peer is overloaded.
> 
> Is your concern that many peers would want STUN services, and thus there
> would be many lookups on "STUNServers@<Overlay Identifier>" and thus
> peer X would get overloaded?  Or are you concerned about the peers
> offering the service?

My concern is the former; in the case you describe, node X, not only
would get overloaded -- and that's already a good reason for being
careful in the decision -- but also, having a more important role, would
be the preferred target of attacks and, in general, a weak point of the
system.

-- 
Ciao,
Enrico

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 8 Dec 2006 12:31:58 -0500

Radhika:

Let me draw an analogy with searching for a user. Last March, I  
started arguing that it was important that a P2PSIP Overlay support  
searching for a user by attributes other than his/her AoR. For  
example, I wanted to be able to say: show me all users with a first  
name of "Jennifer", and then select the appropriate user to  dial  
from a list. However, David Bryan convinced me that if I had a simple  
AoR to user record lookup, then I could build a more sophisticated  
search mechanism on top of it. For this reason, and because I  
understood the need to reduce the scope, I agreed to the current  
charter saying that more sophisticated searching mechanisms are out- 
of-scope for now.

Similarly, if I provide you with a mechanism to get back the list of  
all peers that support a service, then you could implement a  
sophisticated selection algorithm on top of this. For example, you  
could ping all (or some fraction) of the peers, and select the one  
that was net-path closest. Meanwhile, the overall work of the group  
is reduced for now.

For that reason, I propose that the mechanism to find a service be a  
simple lookup scheme, and not something more sophisticated (for now).  
Later, once we have a peer protocol defined, we can start working on  
extensions that provide a sophisticated search scheme.

- Philip

On 8-Dec-06, at 11:46 , Roy, Radhika R. wrote:

> [RRR] This is an important issue. In MANET, when the peer is  
> selected to create the route toplogy (e.g., OSPFv3-MDR) in the IP  
> layer in P2P environment, there is an algorithms which is the best  
> one based on cost-performance trade-off distributively.
>
> [RRR] There can be many solutions: 1. Combine application layer P2P  
> logic with just IP network topology logic, 2. An indpendent  
> topology optimization in the SIP application layer, and/or 3. Others.
>
> - Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061208/fbc0a3fc/attachment-0001.html

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 8 Dec 2006 15:03:15 -0500

On 8-Dec-06, at 12:20 , Enrico Marocco wrote:

>> there

I now see the problem you are concerned about.
I haven't thought a lot about it, but I am aware that some DHTs,
Kademlia for example, attempt to deal with this by caching the
results of a lookup along the lookup path so that frequent queries
can be answered faster.

- Philip

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Sun, 10 Dec 2006 15:43:47 -0800

Range searches such as Philip mentions (last names, etc.) require
different P2P overlays and Google will reveal to you an impressive body
of work.

There are good reasons to delay this topic until someone volunteers to
write an I-D with all that's required.

Henry

From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Philip Matthews
Sent: Friday, December 08, 2006 11:32 AM
To: Roy, Radhika R.
Cc: P2P-SIP; David A. Bryan
Subject: Re: [p2p-sip] Concepts draft: Open Issue #1: Searching for
services

Radhika:

Let me draw an analogy with searching for a user. Last March, I started
arguing that it was important that a P2PSIP Overlay support searching
for a user by attributes other than his/her AoR. For example, I wanted
to be able to say: show me all users with a first name of "Jennifer",
and then select the appropriate user to  dial from a list. However,
David Bryan convinced me that if I had a simple AoR to user record
lookup, then I could build a more sophisticated search mechanism on top
of it. For this reason, and because I understood the need to reduce the
scope, I agreed to the current charter saying that more sophisticated
searching mechanisms are out-of-scope for now.

Similarly, if I provide you with a mechanism to get back the list of all
peers that support a service, then you could implement a sophisticated
selection algorithm on top of this. For example, you could ping all (or
some fraction) of the peers, and select the one that was net-path
closest. Meanwhile, the overall work of the group is reduced for now.

- Philip

Inline [RRR].

From: p2p-sip-bounces at cs.columbia.edu on behalf of Philip Matthews
Sent: Fri 12/8/2006 11:42 AM
To: David A. Bryan
Cc: P2P-SIP
Subject: Re: [p2p-sip] Concepts draft: Open Issue #1: Searching for
services

How about we say:

[RRR] This is an important issue. In MANET, when the peer is selected to
create the route toplogy (e.g., OSPFv3-MDR) in the IP layer in P2P
environment, there is an algorithms which is the best one based on
cost-performance trade-off distributively.

[RRR] There can be many solutions: 1. Combine application layer P2P
logic with just IP network topology logic, 2. An indpendent topology
optimization in the SIP application layer, and/or 3. Others.

- Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061210/d4ef266d/attachment-0001.html

---

From: eric_d_cooper at sympatico.ca (Eric Cooper)
Date: Mon, 11 Dec 2006 20:31:52 -0500

I don't quite see the connection between the AoR to user-record lookup and the subsequent ability to perform more sophisticated searches but leaving that aside, I like the description below.

However, I think the key is the ability to query for *all* the peers.  If you don't know all the peers, you probably can't apply useful filters in the future.

As applied to AoRs & contact data, it's probably not a problem to return all the contact data.  However, the list of all peers supporting a particular service could be quite large.  Possibly a significant fraction of the peers in the overlay.

If large responses are going to be a problem, we may be forced to define mechanisms for more sophisticated searches now.

That said, I don't really see a problem with large responses.  They could just keep rolling in until they are all delivered (or the lookup is cancelled).

Eric Cooper.
 
----- Original Message ----- 
From: "Philip Matthews" <philip_matthews at magma.ca>
To: "Roy, Radhika R." <RADHIKA.R.ROY at saic.com>
Cc: "P2P-SIP" <p2p-sip at cs.columbia.edu>; "David A. Bryan" <bryan at ethernot.org>
Sent: Friday, December 08, 2006 12:31 PM
Subject: Re: [p2p-sip] Concepts draft: Open Issue #1: Searching for services

>> topology optimization in the SIP application layer, and/or 3. Others.

--------------------------------------------------------------------------------

---

From: jiang.x.f at huawei.com (JiangXingFeng)
Date: Tue, 12 Dec 2006 17:32:54 +0800

Hi, David:
  Do you think that the choice from several service nodes is a reasonable
requirement which may be designed more general? If it is, I agree with your
points. The choosing criteria are changing along with different service
requirements, so a general one will be well suited to various applications. 

Regards!
--
Jiang XingFeng
> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan
> Sent: Friday, December 08, 2006 11:51 PM
> To: Philip Matthews
> Cc: P2P-SIP
services

---

From: jiang.x.f at huawei.com (JiangXingFeng)
Date: Tue, 12 Dec 2006 17:46:19 +0800

Hi, Enrico:
  If I do not mistake your points, you mean peer X is exposed to DOS
attacks, which will make X refuse to serve other peers/clients. I agree with
you. Do you have a mature idea of this problem: how to put service resources
into Overlay and avoid to be a weak point of the system?
Regards!
--
Jiang XingFeng
> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Enrico Marocco
> Sent: Saturday, December 09, 2006 1:21 AM
> To: Philip Matthews
> Cc: P2P-SIP
services

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Tue, 12 Dec 2006 12:04:39 +0100

> into Overlay and avoid to be a weak point of the system?

Peer X would have a more important role than almost any other peer in
the overlay; this leads to think that it would be the preferred target
of any potential attacker.  Moreover, it would also be subject to a load
much higher than the average.

A possible workaround would be to simply ask peers to cache most popular
values, but such a mechanism needs to deal with issues like expiration
and error detection.

A more complex solution would be to adopt some linear replication
mechanism for "special" URIs, so that any node could store the location
of a minimum number of instances and be notified of their departures.
For example, say the minimum number of stun server locations to be
stored in any peer is 2, consider an overlay formed by 6 peers (A, B, C,
D, E and F in sequence) and 4 stun servers (S1, S2, S3 and S4),
distributed as follow:

A: S1
B:
C: S2
D: S3
E: S4
F:

After the first replication cycle, the situation would be the following
(where values for which the node is authoritative are marked):

A: S1*, S4
B: S1, S4
C: S2*, S1
D: S3*, S2
E: S4*, S3
F: S4, S3

The following flow shows what happens when peer A detects S1's failure:

    A        B        C        D        E        F
    |        |        |        |        |        |
    | S?     |        |        |        |        |
    |------------------------------------------->|
    |        |        |        |        | S4, S3 |
    |<-------------------------------------------|
    | S4, S3 |        |        |        |        |
    |------->| S4, S3 |        |        |        |
    |        |------->| S2*, S4|        |        |
    |        |        |------->|        |        |
    |        |        |        |        |        |

And the resulting situation would be:

A: S4, S3
B: S4, S3
C: S2*, S4
D: S3*, S2 (unchanged)
E: S4*, S3 (unchanged)
F: S4, S3 (unchanged)

Note that with such a mechanism the peers are not authoritative on the
URL of the "stun service", but on a specific instance identifier (IP,
contact?) and the complexity isn't logarithmic any more.

-- 
Ciao,
Enrico

---

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Tue, 12 Dec 2006 10:46:38 -0500

Enrico and JiangXingFeng:

Enrico is right.

The bottom line is this: Services will also need to be distributed in
P2P system.

Best regards,
Radhika

PS: 

1. Eventually, SIP endpoints will have distributive services
capabilities in SIP-P2P system. Let us differ those discussions once the
basic P2P-SIP is standardized.

2. Henry's email points to the fact what is coming ahead of us in the
P2P-Internet breaking all business models for the so-called centralized
services.

3. When people will get all those services in mobile ad hoc networks
(MANETs), nothing will exist but only P2P systems.

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Enrico Marocco
Sent: Tuesday, December 12, 2006 6:05 AM
To: JiangXingFeng
Cc: 'P2P-SIP'
Subject: Re: [p2p-sip] Concepts draft: Open Issue #1: Searching for
services

A: S1
B:
C: S2
D: S3
E: S4
F:

A: S1*, S4
B: S1, S4
C: S2*, S1
D: S3*, S2
E: S4*, S3
F: S4, S3

    A        B        C        D        E        F
    |        |        |        |        |        |
    | S?     |        |        |        |        |

A: S4, S3
B: S4, S3
C: S2*, S4
D: S3*, S2 (unchanged)
E: S4*, S3 (unchanged)
F: S4, S3 (unchanged)

-- 
Ciao,
Enrico