Subject: [p2p-sip] More on peers and clients (WAS: Re: P2PSIP Concepts and terminology draft posted)

From: matteo.peraldo at gmail.com (Matteo Peraldo)
Date: Sat, 10 Jun 2006 14:24:35 +0200

It seems there is some confusion about peer and client. Someone is
viewing at them as roles, someone as real distinguished nodes.

Obviously, considering them roles, a node can play the role of peer
and client both. But peer and client are not the some role and they
are not overlapped.

When a node works in the mainteinance of DHT it acts as peer, when
initiates GET or PUT it acts as client.

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

This Peer is a node that acts as client and as peer. You can imagine
that there are no nodes in the overlay that act only as peers, but
maybe it is useful keeping the two roles separeted.

--

Matteo

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Sun, 11 Jun 2006 02:30:31 -0500

> maybe it is useful keeping the two roles separeted.

I think I like this taxonomy.

But here's a question: If a node that acts as both a "peer" and a  
"client" is executing a GET operation, does it do so using the same  
protocol that a node that only acts as a "client" would use?

This gets to the heart of whether the client protocol (from the  
concepts draft) is a syntactic subset of the peer protocol from that  
draft.

Some people have proposed that the client protocol might be SIP  
(perhaps REGISTER transactions) and that the peer protocol might be  
something entirely different that also provides a mechanism for GET  
and PUT. If we have this kind of relationship between the two  
protocols, then I don't think the above taxonomy accurately describes  
the model.

--
Dean

---

From: enrico.marocco at telecomitalia.it (Marocco Enrico)
Date: Sun, 11 Jun 2006 12:36:06 +0200

> protocol that a node that only acts as a "client" would use?

I'd say yes.  Perhaps the PUT case is more explanatory: a PUT performed
by a client has to locally retrieve credentials for signing or
encripting the record being inserted, while the PUT served and then
performed by a peer has to check them for authorizing the
operation.  I look at them as two distinct operations, both
syntactically and functionally.

> protocols, then I don't think the above taxonomy accurately describes 

With this kind of relationship the PUT operation performed by a node
which was both a client and a peer would result in a REGISTER sent
locally.  Actually it doesn't look different from the case where the
peer performs directly the PUT in place of the user agent.

Enrico
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster at telecomitalia.it.

        Thank you

                                        www.telecomitalia.it

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

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Sun, 11 Jun 2006 09:40:47 -0700

client : peer = coke : pepsi ???

imo,

  on = ua (once find itself restricted)
  sn = on + registrar + proxy + dht

for "simple session" initiation (!= "simple" session initiation:),

  p2psip(on,sn) = sip(ua,proxy)
  p2psip(sn,sn) = sip(all) + dht

minimally,

  on = aa + sip_ua + stunx_client + turn_client
  sn = aa + sip_full + stunx + turn + dht

where,

  stunx=distributed stun (!= rfc3489)
  on - aa = toy
  sn - aa = joke

simpler?

Peter
----- Original Message -----
From: Marocco Enrico
To: Dean Willis ; Matteo Peraldo
Cc: p2p-sip at cs.columbia.edu
Sent: Sunday, June 11, 2006 3:36 AM
Subject: Re: [p2p-sip] More on peers and clients (WAS: Re: P2PSIPConceptsand
terminology draft posted)

Enrico

--------------------------------------------------------------------
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by
replying to webmaster at telecomitalia.it.
        Thank you
                                        www.telecomitalia.it
--------------------------------------------------------------------

_______________________________________________
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: Mon, 12 Jun 2006 11:01:12 -0400

> syntactically and functionally.

I'd say no.
When a Client initiatiates GET/PUT, the message from Client is sent to a
Peer (GET/PUT Request message of the Client Protocol).
Then the Peer forwards the request (not the message) to other Peers
(GET/PUT Request message of the Peer Protocol) according to their
routing algorithm.

If a Peer initiates GET/PUT, why should the Peer send a GET/PUT Request
message of the Client Protocol to another Peer? That will cause just an
unnecessary message check and/or conversion from a Client Protocol's
GET/PUT Request message to a Peer Protocol's GET/PUT Request message.

So when a Peer initiates GET/PUT, it can and should send just a Peer
Protocol's GET/PUT Request message from the beginning. That is all
necessary.

> peer performs directly the PUT in place of the user agent.

Your assumption about the protocol is beyond the scope of the discussion.
We should stick to the logically distinguished two protocols - the
Client Protocol and the Peer Protocol - in this architectural discussion.

Another note about Client and Peer.
I think the reason Client is introduced is to accomodate devices with
limited physical resources (eg. limited cpu power or battery) or in a
limited environment (eg. private address).
To put it differently, a participant becomes a Client because it is not
capable or qualified to participate in the routing and storage service
for other participants. So there was a suggestion that a Peer be called
a Full Peer and a Client a Limited Peer.
A participatnt that can be a Peer is certainly capable of what a Client
does. Why would we define another type of a limited peer that cannot
initiate GET/PUT?

Thanks.

Eunsoo

---

From: bryan at ethernot.org (David A. Bryan)
Date: Mon, 12 Jun 2006 11:16:20 -0400

We do have lots of put/get type things as peers enter and leave and
need to move resources. I agree with the arguments you make if the two
protocols are different, but of course, that isn't decided yet. The
two *could* be different, or could be one and the same. If they are
one and the same, then of course the get/put are logically identical
between the two, if the protocols are different, then a peer should
probably use peer type operations rather than client type.

Personally, I still think we can do this with one protocol, but at
some level, this debate is a bit orthogonal to the discussion of what
we want to do at the most fundamental level. I think we can agree that
we want to:

Allow endpoints and other "edge" devices (clients, in the document) to get/put
Allow peers to get/put in some way, as well as other operations

The purpose of the get/put is the same between them, to place and
retrieve information. In some designs, it is also the same protocol
wise, and in others it isn't. That will likely be decided as the
protocol design moves forward, I would think.

David

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Mon, 12 Jun 2006 11:21:01 -0400

Sounds reasonable to me.
Thanks.

Eunsoo

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Mon, 12 Jun 2006 17:44:28 +0200

It sounds reasonable to me too.

Enrico

---

From: kyara543 at yahoo.com (K.Yamamoto)
Date: Mon, 12 Jun 2006 09:44:22 -0700 (PDT)

INTERESTING EQUATIONS, PETER. 

A INTERESTING ARTICLE BY A SOFTWARE ARCHITECT WHO WAS AN 3G/IMS ADVOCATOR BUT NOW SOUNDS DELUDED:
  
 http://www.telephonydiscussion.com/index.php?name=UpDownload&req=getit&lid=12

 HARD FOR PERSISTENCE AND GRAND PLANS TO GET WELL ALONG. 
  
 I HOPE THAT P2PSIP TEAM CAN WIN A TURING AWARD SOON. (http://en.wikipedia.org/wiki/Turing_Award)

K.Y.

  Peter Pan <huang-ming.pan at comcast.net> wrote: client : peer = coke : pepsi ???

imo,

minimally,

where,

simpler?

Peter
----- Original Message -----
From: Marocco Enrico
To: Dean Willis ; Matteo Peraldo
Cc: p2p-sip at cs.columbia.edu
Sent: Sunday, June 11, 2006 3:36 AM
Subject: Re: [p2p-sip] More on peers and clients (WAS: Re: P2PSIPConceptsand

Enrico

 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060612/653cd2c9/attachment.html

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 12 Jun 2006 10:03:51 -0700

Sorry. One more question, possibly not p2psip related, for your comment.

Is RFC 3489 based on assumption that STUN server is at least "dual-homed".

Thanks.

Peter

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Mon, 12 Jun 2006 10:10:35 -0700

> Is RFC 3489 based on assumption that STUN server is at least "dual- 

no but it is based on the idea that the stun server has two IP  
address - it is recommended that these are both on the same  
interface. However this changes in the update to it - draft-ietf- 
behave-rfc3489bis-03 does not require two IP addresses.

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 12 Jun 2006 10:19:48 -0700

Is it possible to realize a STUN sever defined by
draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP?

Peter

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Mon, 12 Jun 2006 13:36:53 -0700

> draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP?

yes.