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

From: fwmiller at cornfed.com ([email-masked])
Date: Wed, 7 Jun 2006 15:36:52 -0500

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

I'm not sure this distinction is necessary.  If the protocol associated with "full participation" is different than "knowing about it", then it is useful.  If the "knowing about it" will end up just being a subset of "full participation" then I'm not sure it is.  To your later question about whether we need client nodes, I think the need should be defined by whether there is a separate protocol.

I'm really hoping that the "knowing about it" can be hidden behind existing SIP mechanisms, e.g. SUB/NOT or 302s or something.  If this is the case then the client becomes just a UA even though the "knowing about it" and "full participation" are using different protocols.

Seems like peer and UA is general enough if protocols are the measure by which model entities are defined.

FM

---

From: henry at pulver.com (Henry Sinnreich)
Date: Wed, 7 Jun 2006 15:45:50 -0500

> instead of contributing to it.

This is a good idea, since it allows using openDHT and similar networks as
they may appear in a commercial version. 

The advantage is that no bootstrap nodes need to be operated for small P2P
SIP networks, just using openDHT may work.

The cost of a bootstrap server can be very small, but the people to operate
it may not come very cheap.

Thanks, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of fwmiller at cornfed.com
Sent: Wednesday, June 07, 2006 3:37 PM
To: Dean Willis; Enrico Marocco
Cc: P2P-SIP; David Goeckeler
Subject: Re: [p2p-sip] P2PSIP Concepts and terminology draft posted

> instead of contributing to it.

I'm not sure this distinction is necessary.  If the protocol associated with
"full participation" is different than "knowing about it", then it is
useful.  If the "knowing about it" will end up just being a subset of "full
participation" then I'm not sure it is.  To your later question about
whether we need client nodes, I think the need should be defined by whether
there is a separate protocol.

I'm really hoping that the "knowing about it" can be hidden behind existing
SIP mechanisms, e.g. SUB/NOT or 302s or something.  If this is the case then
the client becomes just a UA even though the "knowing about it" and "full
participation" are using different protocols.

Seems like peer and UA is general enough if protocols are the measure by
which model entities are defined.

FM

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

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 08 Jun 2006 09:58:18 -0400

Clients and Peers are logical nodes from the P2P perspective, indicating
whether the node provide routing and storage or not. Peers can do always
what Clients can do, which are initiating GET and PUT.
UAs, SIP Proxy, SIP Redirector Server, and Gateway are logical nodes
from SIP perspective (or session control).
I personally see the two sets belong to different substrates (or sublayers).
Any SIP node (UA, SIP Proxy, etc.) can be either a Client or Peer.
Thanks.

Eunsoo

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 08 Jun 2006 10:12:08 -0400

Media relay is also a logical node from the SIP perspective. So media
relay can be either a Client or Peer, in principle.

Please note that media relay is used also in the context of NAT traversal.
The latest ICE draft uses the term 'STUN relay'. So I think we should
use 'STUN relay' for a node relaying SIP messages or RTP traffic in the
context of NAT traversal. We can still use media relay in a general
sense for a node that relays RTP traffic.

If capable (i.e., located outside NATs or having public IP addresses not
behind firewalls), any node can become a STUN relay.

So a physical node can be a Peer,  SIP UA, and  STUN relay. Or one can
be a Client,  SIP UA, SIP Proxy, and Gateway.

Thanks.

Eunsoo

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Thu, 08 Jun 2006 17:38:44 +0200

> what Clients can do, which are initiating GET and PUT.

This is what I like least.  If a Pear is also a Client by definition,
how do you call a Peer -- say a node participating in an iterative Chord
DHT -- which is not a Client?

Again, think about the P2PSIP scenario where the overlay is OpenDHT.  Do
you feel comfortable calling PlanetLab nodes "P2PSIP Overlay Clients"?
I think this would be confusing even if you know that actually Bamboo
nodes are able to perform GET and PUT operations.

I'd prefer to have the "Peer" defiend as a node which participetes in
the overlay contributing to storage and routing functionalities and the
"Client" as something able to query an overlay for storing and
retrieving data.

> Any SIP node (UA, SIP Proxy, etc.) can be either a Client or Peer.

According with the definitions above, any P2PSIP Overlay User _must_ be
coupled with a Client and _should_ be coupled with a Peer.

Enrico

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 08 Jun 2006 11:47:21 -0400

> "Client" as something able to query an overlay for storing and

Then, every node in the P2P network is a Client of your definition. Then
what is left is what is Peer and Non-Peer.
So the draft suggests Peer for Peer and Client for Non-Peer.
If this is helpful, you can think that Peer is equivalent to Super Node
and Client to Ordinary Node.

Would you prefer classification of 'Peer and Non-Peer' to 'Peer and Client'?

Thanks.

Eunsoo

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Thu, 08 Jun 2006 19:15:07 +0200

> what is left is what is Peer and Non-Peer.

Sorry, I cannot identify what the "P2P network" is in the Reference Model.

If by "P2P network" you mean "P2PSIP Overlay": No, they are all Peers.

If by "P2P network" you mean the whole system made of nodes which just
work for providing storage stuff (say "Horses"), nodes which just use
storage service (say "Parasites") and nodes which both work and use it
(say "Workers"): No again.  According with my definitions, an "Horse" is
a Peer, a "Parasite" is a Clients and a "Worker" is both a Peer and a
Client.

> and Client to Ordinary Node.

The draft suggests "Peer" for "Worker" and "Client" for "Parasite", but
it doesn't suggest anything for "Horse"; since a Super Node may be an
"Horse" too, it is lacking a definition.

> Would you prefer classification of 'Peer and Non-Peer' to 'Peer and Client'?

I'd prefer classification of "Horse, Worker and Parasite" ;-)

Anyway, I like the classification of "Peer and Client", but when a Peer
is acting as a client - i.e. is storing or retrieving data for
establishing SIP sessions he's involved in - I would call it a Client.

Enrico

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 08 Jun 2006 13:53:33 -0400

> Sorry, I cannot identify what the "P2P network" is in the Reference Model.
I meant "P2PSIP Overlay Network" by "P2P Network".

> If by "P2P network" you mean "P2PSIP Overlay": No, they are all Peers.
A P2PSIP Overlay Network can consist of Peers and Clients. Not
necessarily all the nodes of a P2PSIP Overlay Network are Peers.
If this is not clear in the concept draft, that point should be
described better in the draft.

> a Peer, a "Parasite" is a Clients and a "Worker" is both a Peer and a

At least in the concept draft, there is no node in the P2PSIP Overlay
Network that cannot initiate GET and PUT. I don't think we need to
define Horses.

In a sense, a Peer is a Server and Client. If we define something like
Horse, it will be a Server.

> establishing SIP sessions he's involved in - I would call it a Client.

Well, I hope we use the term Peer and Client in the same meaning.

Thanks.

Eunsoo

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Thu, 08 Jun 2006 21:33:33 +0200

Eunsoo Shim wrote:
> Network that cannot initiate GET and PUT.

In real life scenarios there are some: an example is OpenDHT nodes.

Using concepts currently present in the draft, you'd define an OpenDHT
node not only a Peer, but also a Client (because a Peer *is* a Client).
 I'm sorry, but I think it's misleading.

Enrico

---

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

> DHT -- which is not a Client?

If (and this is an open question) the client is a syntactic or  
protocol subset of the peer, then there is no peer that is not also a  
client.

If the client is merely a functional subset, then a client is a  
client and a peer is a peer, and they;re different things.

> nodes are able to perform GET and PUT operations.

yes.

> "Client" as something able to query an overlay for storing and

Ok, I'm confused, as I thought that's what the existing definition  
said. Could you pelase write the full definitions up in the style  
used in the draft for comparison purposes, and start a new thread on  
peer and client definitions?

> coupled with a Client and _should_ be coupled with a Peer.

Again, depending on the subset relationship (currently unresolved)  
between client and peer.

--
Dean

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 08 Jun 2006 17:42:47 -0400

> In real life scenarios there are some: an example is OpenDHT nodes.
I am not sure an OpenDHT node cannot initiate GET and PUT.
Logically it does not make a sense if a DHT node cannot initiate GET and
PUT.
Even for JOIN, a node should be able to initiate GET.

>  I'm sorry, but I think it's misleading.

Probably the definition in the draft needs to be improved.
Here is my understanding.

A Peer is a node that can do the four things.
- JOIN and LEAVE (the DHT).
- Route messages (based on the DHT routing table it maintains).
- Store data for other nodes.
- Initiate GET and PUT.

A Client is a node that can do one thing.
- Initiate GET and PUT.
(Whether a Client should store data for other nodes is an open question.
For now, we can ignore the possibility.)

Please note that a P2PSIP Overlay Network can consist of only Peers.

Thanks.

Eunsoo

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Fri, 09 Jun 2006 00:32:14 +0200

> Logically it does not make a sense if a DHT node cannot initiate GET and

I'm not sure that client GET/PUT operations - which cope with user
credentials other than data - could be considered functionally
equivalent to maintainance operations.

> Even for JOIN, a node should be able to initiate GET.

Arguable.  In Chord JOIN and GET are similar, but this does not imply
that they are generally related.

> - Store data for other nodes.

I would let only clients initiate GET and PUT, but, hey... maybe it's
just me.

> Please note that a P2PSIP Overlay Network can consist of only Peers.

Sure.  But then you need clients for storing and retrieving user records
needed for SIP communications.  Ok, it sounds like we are disagreeing
again :-)

Enrico

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Fri, 09 Jun 2006 00:36:50 +0200

Dean Willis wrote:
> Ok, I'm confused, as I thought that's what the existing definition said.
> Could you pelase write the full definitions up in the style used in the
> draft for comparison purposes, and start a new thread on peer and client
> definitions?

Client and peer definitions are not bad per se.  What's confusing, IMHO,
is the inheritance relationship between them or, better, between their
protocols.

> Again, depending on the subset relationship (currently unresolved)

Indeed.

Enrico