Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 7 Jun 2006 00:32:52 -0500

David Bryan, Eunsoo Shim, Philip Matthews and I have spent about 100  
hours of conference bridge time trying to come to a rough consensus  
on what we're talking about, with Henning and Cullen popping in for a  
few dozen hours each. I finally wrote it all down in a draft format,  
leaving lots of questions listed but unanswered, and got them to  
agree that it was at least sort of close to what they were thinking.  
It was somewhat like pulling the hind teeth out of an angry moose  
using nothing but Swiss Army Knife tweezers (or at least like I  
imagine that might be, not having been so daring myself), but now we  
have a document for the rest of you to shred, which I'm sure you will.

It'll be on the IETF draft site soon. In the meantime, check out:

http://www.softarmor.com/dwillis/docs/draft-willis-p2psip- 
concepts-00.html
http://www.softarmor.com/dwillis/docs/draft-willis-p2psip- 
concepts-00.txt
http://www.softarmor.com/dwillis/docs/draft-willis-p2psip- 
concepts-00.xml

--
Dean

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Wed, 7 Jun 2006 05:13:20 -0700

Dean - thanks for getting this done.

On Jun 6, 2006, at 10:32 PM, Dean Willis wrote:

>
> David Bryan, Eunsoo Shim, Philip Matthews and I have spent about  
> 100 hours of conference bridge time trying to come to a rough  
> consensus on what we're talking about, with Henning and Cullen  
> popping in for a few dozen hours each. I finally wrote it all down  
> in a draft format, leaving lots of questions listed but unanswered,  
> and got them to agree that it was at least sort of close to what  
> they were thinking. It was somewhat like pulling the hind teeth out  
> of an angry moose using nothing but Swiss Army Knife tweezers (or  
> at least like I imagine that might be, not having been so daring  
> myself), but now we have a document for the rest of you to shred,  
> which I'm sure you will.
>

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Wed, 07 Jun 2006 18:47:30 +0200

> have a document for the rest of you to shred, which I'm sure you will.

The document is very good and I think it will be very useful.

But... there's one thing I fail to understand.  Given the distinction
between clients and peers -- which I don't like but accept -- why do you
define the client protocol as a subset of the peer protocol?  I can only
figure a clear division with doGet, doPut, doSend on the client side and
serveGet, servePut, serveSend plus whatever is needed for their
implementation (e.g. doJoin, serveJoin...) on the peer side.  Keeping
them functionally complementary rather than alternative helps in
distinguishing the roles of peers and clients.

Just some more minor typos from a quick read:
+ In P2PSIP Overlay Bootstrap Server definition (sec. 2), in the Example
  you write "...uses a P2PSIP Overlay Bootstrap Server other peers...";
  something like "to discover" is missing.
+ Item 4 of the list in sec. 3.1 restricts the redirection to INVITE
  messages; I'd substitute "INVITE" with "request message".
+ In the last sentence of the first paragraph in sec. 3.3.2 "(get)" and
  "(put)" are inverted.

Enrico

---

From: bryan at ethernot.org (David A. Bryan)
Date: Wed, 7 Jun 2006 13:03:46 -0400

> distinguishing the roles of peers and clients.

I think the reason folks stressed that was that in such a design, the
get/put functions of the clients would also be needed between the
peers, if nothing else for those peers that had associated UAs. They
likely also need the same sort of primitive to move information
between themselves as peers join and leave.

Personally, if we did do clients and peers, I would hope that the
client protocol was either SIP or else a proper subset of the peer
protocol, such that peers did everything that clients did, and then
some more.

David Bryan

> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 7 Jun 2006 13:23:16 -0500

> distinguishing the roles of peers and clients.

It's a "functional subset", not necessarily a syntactic subset. All  
of the functions that the client protocol would perform would also be  
needed in the peer protocol. But the peer protocol would need some  
additional functions.

>   something like "to discover" is missing.

yes indeed.

>   messages; I'd substitute "INVITE" with "request message".

Reasonable.

> + In the last sentence of the first paragraph in sec. 3.3.2 "(get)"  

Far out.

Thanks,

--
Dean

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Wed, 07 Jun 2006 21:30:01 +0200

Dean Willis wrote:
> It's a "functional subset", not necessarily a syntactic subset. All of
> the functions that the client protocol would perform would also be

In some cases (e.g. iterative chord) the peer protocol wouldn't need a
get function.

Ok, I know there's not much difference, but the picture would be fairly
clearer, at least to me, with a straight separation between the P2P
layer, place of peers, and the SIP layer, place of clients.  Needless to
say, I'd love to see both a peer and a client on the same device where
the UA is.

Anyway, I think that such a document was defenitly needed.  Please
ignore my distinction, if it exists only in my mind ;-)

Enrico

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 7 Jun 2006 15:17:56 -0500

> say, I'd love to see both a peer and a client on the same device where

This is a good question, and one the David/Eunsoo/Philip/Dean calls  
went around and around on.

I ended up with three different abstract beasties:

A "peer" that fully participates in the P2PSIP overlay, including  
storing stuff and routing stuff for other nodes (if recursive routing  
is used).

A "client" that knows about the P2PSIP overlay , but just uses it  
instead of contributing to it.

a "user agent" that knows how to do SIP stuff, and might be coupled  
to a peer or a client so it can use the P2PSIP Overlay in addition to  
conventional client-server SIP.

I originally had a single-layer model, then two (peer and client,  
where the client contained a UA), then moved to the three layer model  
to encompass the range of concepts in the discussion.

Do we need "client" nodes? They're certainly not required in all  
deployment scenarios, but they might be useful in other scenarios.  
For example, in an environment where some nodes are crippled due to  
low bandwidth, low power reserves, and minimal CPU and storage  
capacity, those nodes might be able to interact as clients but would  
mess the whole thing up if they tried to serve as peers. This is  
probably the case with GPRS mobile phones.

Do we need to have a peer, a client, and a UA on the same device?  
This depends on whether the client behavior is a proper subset of the  
peer behavior. If it is a proper subset (not just a functional  
subset), then a node finding itself marginally connected/empowered  
could fall back to a "client" mode of operation without having to  
actually change protocols. If we can do this, then all we need is a  
"peer" and a "ua", since the "client" mode is just "peer" with some  
things turned off.

--
Dean

---

From: salman at cs.columbia.edu (Salman Abdul Baset)
Date: Wed, 7 Jun 2006 18:22:23 -0400 (EDT)

Nice draft.

Notational issue
----------------
-'P2PSIP' should perhaps be removed from the terminology heading such as
'P2PSIP Overlay Peer' as its inclusion seems implicit and redundant.
Currently, all terminology headings except for the first two include it.
Likewise for 'Overlay'.

Other issues
------------
-Overlay Peer Enrollment
Maybe required again if the user logs in the p2p network from a different
machine which does not have his credentials. This is not necessarily a
loss of credentials.

-Section 3.2. The UA client should hang from a overlay peer because
otherwise it has no way of accessing the DHT.

-I am confused by the addition of the term 'peer' to the SIP redirection and
proxy servers. A redirection server is generally per domain and responsible
for all users in that domain. If the sys admin of that domain wants its
conventional SIP redir server to participate in the p2p network, the redir
server will have to register/insert all the user identifiers of all its users
in the p2p network making the role of redir server redundant.

Ofcourse, it is possible to store the registrar IP address against the
user identifier so that a lookup query lands at the registrar. But this
just adds another hop to the lookup.

It also seems that a peer needs to decide whether to lookup for a user
identifier in a p2p network or directly contact the SIP proxy server based
on the host name (cs.columbia.edu for salman at cs.columbia.edu). For a
network in which both conventional and p2p SIP nodes are participating,
p2p or SIP proxy lookup can respectively increase or decrease the lookup
time for an identifier.

Regards,
Salman

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 07 Jun 2006 22:08:01 -0500

> Nice draft.

Thanks.

> Notational issue

We argued that, but it sees all words have multiple meanings, so the 
fully-qualified format may be useful. There are, for example, overlays 
that are not P2PSIP overlays.

> Other issues

I view "enrollment" as being akin to "signing up for an account".

If you use a different PC to access your email server, do you have to 
sign up for a new account on the email server?

But you raise a good question -- is enrollment the same thing as 
credential recovery?

Do we need a credential recovery operation that is not the same as 
enrollment? My guess is that this depends on the credential system used.

> otherwise it has no way of accessing the DHT.

Huh? No, the client can access the routing data of the DHT without 
having a fixed relationship with a peer. It might interact with any 
peer, chosen possibly by configuration, DNS, bootstrap server, 
multicast, or broadcast, just as any peer might start up. A client that 
has been running for some time could conceivably (if allowed in the 
design) cache knowledge of a large number of peers, and pick one for a 
given request due to some sort of distribution algorithm.

> in the p2p network making the role of redir server redundant.

A proxy or redirect server would implement proxy or redirect functions 
in plain SIP, using the routing knowledge of the overlay instead of a 
local database. For that proxy or redirect server to access the routing 
knowledge of the overlay, that proxy or redirect server must be coupled 
to an overlay peer or an overlay client.

The diagram describes a proxy coupled to an overlay peer. It could just 
as easily be coupled to an overlay client, but would arguably be less 
useful done that way.

> just adds another hop to the lookup.

Yes, and this is an example of iterative lookup, as an alternative to 
direct or recursive lookups. We probably ought to add all these to the 
definitions section.

> p2p or SIP proxy lookup can respectively increase or decrease the lookup

One would presume a single domain either has all of its primary routing 
knowledge in an overlay, or has it all in a conventional structure.

So if you're in an overlay, and you want to look up something in your 
domain, you look in the overlay. If you want to look up something in 
another domain, you use standard SIP resolution procedures, which could 
involve asking your proxy or using DNS ala RFC 3263.

So if cs.columbia.edu is an overlay, any node (conventional or p2p) 
trying to contact slaman at cs.columbia.edu would, either directly or 
indirectly, access that overlay.

A peer or client in the same overlay would access the overlay directly.

A UA outside the overlay would use RFC 3263 or equivalent procdures to 
find an outward-facing proxy or redirect server that's participating in 
the  cs.columbia.edu overlay, then send the request to that proxy or 
redirect server. If its a proxy, it looks up the target in the overlay 
and routes the request to it. If it is a redirect server, it looks up 
the target in the overlay and returns an appropriate 300-class response.

--
Dean

---

From: hu.xinyu at huawei.com (Seaward Hu)
Date: Thu, 08 Jun 2006 21:30:47 +0800

Hello Dean,
       I have several question about your draft:
       
1.In the definition of P2PSIP Overlay user, you said the media relay is a
kind of user, but in the reference model diagram , the gateway peer act as a
P2PSIP Overlay Peer, so may I consider the media relay   a peer also? 
       
 2.In the definition of bootstrap server, it was used by peer and client to
locate an entry into the overlay network, but how a UA find a client or peer
without any cached information while UA is not coupled to a peer or client?
Must the UA be coupled to peer of client?

Thanks.

Seaward hu

---

From: salman at cs.columbia.edu (Salman Abdul Baset)
Date: Thu, 8 Jun 2006 14:57:52 -0400 (EDT)

Inline.

> that are not P2PSIP overlays.

Since the term names are quite long, people will tend to use their
abbreviations when writing a draft. For example, I will prefer writing
POUA instead of 'P2PSIP Overlay User Agent'. Perhaps, it will help
to come up with unambiguous abbreviations for corresponding key terms.

> involve asking your proxy or using DNS ala RFC 3263.

The definition for P2PSIP Overlay Identifier states:
"Information that identifies a specific P2PSIP Overlay. This is presumed
in the general case to be scoped to a name within the DNS, but other
scopes may apply, particularly in ad-hoc environments. Short forms:
overlay identifier, overlay ID."

Since overlay ID is not always a DNS name, it implies that two nodes in
different domains can potentially participate in the same overlay. This
may not be a recommended practice and a BCP draft might help clarify this.

Some questions not necessarily for this draft are:

-What should happen if we want to run a P2PSIP overlay in an existing SIP
domain? Do the existing redir/proxy servers need to be coupled with a peer
layer? When would an overlay peer want to discover them as opposed to looking
in the overlay?
-Is better not to run conventional SIP with overlay SIP?
-When conventional and P2PSIP are run together, shall the existing redir
servers keep their local databases or switch to the overlay storage.

-salman

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Thu, 8 Jun 2006 15:45:46 -0500

> P2PSIP Overlay Peer, so may I consider the media relay   a peer also?

A media relay might be a peer or a client or neither. Whether or not  
it is a "user" is probably debatable.

The entire peoblem of finding media relays is wide-open.

> Must the UA be coupled to peer of client?

A P2PSIP UA must be coupled to a peer or a client.

A SIP UA might use a proxy server that is coupled to a peer or a  
client, or it might use a redirect server that is coupled to a peer  
or a client, or it might not interact with the overlay at all.

--
Dean

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Thu, 8 Jun 2006 15:56:48 -0500

> to come up with unambiguous abbreviations for corresponding key terms.

feel free to propose some on-list and we'll discuss them. I have no  
objection to adding thme to the draft if we have consensus.
> may not be a recommended practice and a BCP draft might help  

That's not precluded by anything in this draft, but should probably  
be clarified.

> layer? When would an overlay peer want to discover them as opposed  

If we ran a P2PSIP overlay inside a existing client/server (CS) SIP  
domain, we'd have to have some way to establish routing. One  
possibility would be for a registrar-assist agent to 3rd-party  
register each P2P user into the CS SIP domain. Another approach would  
be to have the CS domain route all unknown users to the overlay.

> -Is better not to run conventional SIP with overlay SIP?

Good religious question. Define your parameters for "better"?

> servers keep their local databases or switch to the overlay storage.

The answer is an unambiguous "yes", but that probably doesn't answer  
the question you meant to ask. Write it up as an open question and  
send to list with a title like "Another question for concepts draft:  
combining database" or some such, and I'll add it to the working  
draft if nobody screams.

--
Dean