Subject: [p2p-sip] Draft charter for possible P2PSIP WG

From: royrr at us.saic.com (Roy, Radhika R.)
Date: Sun, 22 Jan 2006 22:11:18 -0500

David and PP:
 
Let me interject into this discussion.
 
If we take the example of P2P-SIP, we see that this protocol will not
distinguish between UA and proxy as every peer will have all the
capabilities and may be termed as "peer Node" (instead of super-node,
slim-node, etc.).
 
So, the idea of the p2p-SIP protocol development will be how a peer-node can
satisfy the needs for p2p communications without being subordinate of other
nodes.
 
In the past, we have seen simple dump device like POTS in the PEST world,
client and sever communications protocol in the IP network, UA and Proxy
entities in the case of non-p2p-SIP protocol, and others.
 
As you have seen that we are now taking the approach of the path to make SIP
protocol completely P2P. Definitely, it will have more functionalities as no
peer wants to be subordinate compare to others.
 
Consequently, we have to develop the basic protocol that works as p2p-SIP
without assuming that some peer nodes will have super-node capabilities and
some are not. 
 
Once we develop the basic structure of the p2p-SIP protocol, we may then see
whether some kinds of hierarchical architecture of p2p configurations are
necessary or not, but definitely we MUST not bog down to this right now.
 
Any comments?
 
Best regards,
Radhika

  _____  

From: p2p-sip-bounces at cs.columbia.edu on behalf of David A. Bryan
Sent: Sun 1/22/2006 6:12 PM
To: PP
Cc: P2P-SIP
Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG

The only way to 100% ensure this sort of behavior could be enforced is 
if the protocol itself were somehow designed to require you be all of 
the above when possible. If you can build your device to not be 
anything but a "slim" peer, all the draft MUSTs in the world won't 
keep vendor from making their phones slim if there is a market for 
that. I'm not sure that designing the protocol that way is really a 
path we want to go down, so not sure we will be able to enforce it. 

Back in the bad old days when file swapping was the only thing people 
looked at P2P for, there were hacked versions of clients around that 
always claimed the user had no files to share, and free loading phones 
seem likely in the particular deployment scenario I think you are 
talking about (global public network of devices, rather than say a 
corporate P2P device network, where policy could be used to control 
this). In the corporate environments, on the other hand, I can 
actually imagine that some peers might be deliberately super-peers, 
ensuring that traffic between offices, lets say, was done using one of 
a specific set of nodes set up for this purpose, so the argument could 
be made that at times, having "non-equal" nodes may be desirable. 

Of course it is possible that a particular overlay group in a global 
public network of devices could devise some other policy mechanism for 
this somehow, possibly with a distributed accounting mechanism. 

David

---

From: bryan at ethernot.org (David A. Bryan)
Date: Mon, 23 Jan 2006 09:15:50 -0500

I don't think I agree it is clear the all features for all nodes
behavior is what we want, or that it is an issue that can be assumed
desirable until we see need for different behaviors. I think it is
open until we are clear what the services of a node are. For example,
I don't think that is true if we have TURN type media relay as a
service.

I guess I had two points in my earlier email:

1) If we decide we want all nodes always equal it would need to be
somehow explicit in the design, or in the end devices won't implement
them all. If for example, we design a basic protocol for resource
location and signalling, and one of those resource's a node can
advertise is it is willing to be a media relay (this could be one way
that nodes are defined as "slim" or "not slim" to use PP's terms),
there is no way to enforce which nodes advertise they have the service
and which don't. Any service we do decide should always be implemented
must be part of the protocol. If we wanted relay, we would need to
make it discovered in the protocol, not just advertised.

2) My second point was I can already see some cases -- the corporate
deployments I mentioned in the last email being one -- where they may
wish to control services like media relay. For managed deployments
where P2P is a way for an organization to reduce capex and opex, as
opposed to the Skype type-deployment, having different node types may
be desirable.

If we ignore it at this stage, we in effect decide implicitly by what
we design. For me it isn't obvious yet that making every node have all
capabilities is desirable for all the use cases I have seen. I think
that both types of uses (managed/unmanaged) are interesting and should
be kept in mind.

--David

---

From: srisuresh at yahoo.com (Pyda Srisuresh)
Date: Mon, 23 Jan 2006 07:01:44 -0800 (PST)

I fully agree with David' comments. For example, there are topological
requirements on a "rendezvous" server for NAT penetration. Unlike an end node
(which can be behind NAT devices), a rendezvous server is required to be on the
public Internet. We do need to be open and review the distinct roles and
serrvices as they are, without requiring all roles and services on all nodes.

cheers,
suresh 

--- "David A. Bryan" <bryan at ethernot.org> wrote:

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

---

From: huang-ming.pan at comcast.net (PP)
Date: Mon, 23 Jan 2006 08:20:12 -0800

Still very confused. When there are "explicit" supernodes and slimnodes,
what are the difference and advantage of the p2p-sip system from
contemporary well-deployed (ie. load balanced and redundant) client-server
systems?

Why would you think corporates, deployments of which are usually in small
scale, will prefer a "client-server alike" p2p-sip system instead of
Microsoft Live Communication Server (plus MSN IM) or any open SIP proxies
(eg. Yahoo!IM, teltel, Xten, headcall, free world, ...) that not only
provide free on-net calls but also provide off-net calls?

I still think why quite a few people come together attracted by the
wonderful p2p-sip initiative, seeing (:and envying:) great success and true
advantages of Skype, is to look for a "standardize" solution in SIP industry
that can compete with the proprietary giant.

Certainly, should p2p-sip finally come out with a buffet that compiles to
have 14+MB code and needs 22+MB at runtime, "it is clear the all features
for all nodes behavior is" NOT "what we want" :)

"Corporate", "Hierarchy", "Rendezvous", ... why make the thing so
complicated? Please first come out with something compact and "simplex", the
latter of which I always think to be the art of computer programming.

peter
----- Original Message -----
From: "David A. Bryan" <bryan at ethernot.org>
To: "Roy, Radhika R." <royrr at us.saic.com>
Cc: "PP" <huang-ming.pan at comcast.net>; "P2P-SIP" <p2p-sip at cs.columbia.edu>
Sent: Monday, January 23, 2006 6:15 AM
Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG

--David