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

From: huang-ming.pan at comcast.net (PP)
Date: Sun, 22 Jan 2006 09:37:23 -0800

Thanks a lot for the answers, David.

Yes or no. Personally I prefer all nodes born equal though they can change
configuration automatically per their working environments (eg. NAT and
bandwidth). All p2p nodes MUST do the best to help the network and
community, instead of being manually and intentionally configured to exist
as either slim or super.

For example, a smart phone may only be a slim node while it is on 2.5G
wireless network but should (even MUST) turn itself automatically to become
supernode (at least help routing if it cannot help distribute vociemail)
when moving to LAN behind a full-cone NAT. Smart p2p phone makers MUST NOT
intentionally build their phones to be slim nodes only, eg. for cost saving.

Imagine two websites allowing free download of soft phones based on final
release (if any) of p2p-sip open-source code, one of which is built to be
supernode capable and another of which is slim nodes only. Which of them
would you guess will be the favorite download by the public?

Homogenerity, autonomy, standardization as well as unselfishness should be
essences of the p2p-sip "sharing" community.

peter
----- Original Message -----
From: "David Barrett" <dbarrett at quinthar.com>
To: "'PP'" <huang-ming.pan at comcast.net>; "'Pyda Srisuresh'"
<srisuresh at yahoo.com>; "'Philip Matthews'" <philip_matthews at magma.ca>;
"'Dean Willis'" <dean.willis at softarmor.com>
Cc: "'P2P-SIP'" <p2p-sip at cs.columbia.edu>
Sent: Saturday, January 21, 2006 6:59 PM
Subject: RE: [p2p-sip] Draft charter for possible P2PSIP WG

> > -----Original Message-----
> > From: PP [mailto:huang-ming.pan at comcast.net]
> >
> > It sounds that the terms "clients" and "supernode" referred to two
> > different types (implementations/functionalities) of p2p-sip nodes.
>
> "client" and "supernode" functionality is certainly different.  It's
> possible that a single node is able to do one, the other, or both.  The
> ideal P2P deployment would have every node capable of performing both
roles,
> and some algorithm exists for promoting normal nodes into supernodes as
> befits the network.
>
> Today's SIP has "supernode" functionality firmly in the realm of the
proxy,
> and "client" functionality firmly in the user agent.  However, there's no
> reason to prevent a user agent from behaving like a proxy.  But then
again,
> there's no reason to mandate that it do so, either.  The protocol should
> support both, and then leave it up to the programmer to decide how far a
> given node will go.
>
>
> > Q1: how to know in advance during software build/release or hardware
> > manufacture phase that a node will be running as "a client only" or as a
> > supernode?
>
> Ideally, any node that can act as both should act as both.  However, not
all
> nodes *can* implement both functions.  For example, some very trim device
> might not have the computational resources to act as a supernode, but
should
> still be capable of acting as a normal client.
>
> >
> > Q2: when a node (soft or hard phone) is "made" to be working
specifically
> > as
> > a supernode, won't the scenario become another flavor of client/server
> > deployment?
>
> Yes, just as an implementer should have the option of making a pure
client,
> he should have the option of making a pure server.  But again, the
protocol
> should allow a single node to act in either or both supernode and client
> capacities.
>
> Does this answer your questions?
>
> -david
>

---

From: bryan at ethernot.org (David A. Bryan)
Date: Sun, 22 Jan 2006 18:12:56 -0500

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

On 1/22/06, PP <huang-ming.pan at comcast.net> wrote:
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>