Subject: [p2p-sip] P2P Universe [was Public P2P SIP service: Damaka.com]

From: matthewsp at avaya.com (Matthews, Philip (Philip))
Date: Thu, 12 Jan 2006 13:50:57 -0500

Benny,

Your proposal for a P2P SIP "universe" is certainly technically
feasible.

However, there is a question of how acceptable it would be to customers
and 'service providers' (where 'service provider' in this context has a
somewhat unusual meaning!!).

Consider the application that I am interested in, that of an Enterprise
PBX built using P2P SIP technology. 

Under your proposal, information about users and devices (= hard and
soft
phones) for company X may well be stored on devices owned by company Y.
If company X and Y are fierce competitors, that may not be politically
acceptable. Or course, if both companies use Skype this happens today,
but perception can be important.

Also, this proposal doesn't work in the "Ad-Hoc and Ephemeral Groups"
case
where phones do not have access to the Internet.

I think this is an interesting question for us to debate.
Are we building a protocol for one world-wide network,  or for multiple
independent networks?

- Philip

> -----Original Message-----
> From: Benny Prijono [mailto:lists at bulukucing.org] 
> Sent: January 12, 2006 13:32
> To: Matthews, Philip (Philip)
> Cc: p2p-sip at cs.columbia.edu
> Subject: Re: [p2p-sip] P2P Universe [was Public P2P SIP 
> service: Damaka.com]
> 
> [changed the subject]
> 
> Philip,
> 
> What you said below are all valid problems that are being solved by 
> our dear SIP P2P designers (i.e. not me, hehe..). I'm just 
> saying from 
> what I read in drafts/articles.
> 
> But I just came up with an idea.
> 
> Instead of designing SIP P2P *protocol*, why don't we design 
> a SIP P2P 
> *universe*. Just like we have one universe for IP network (the 
> Internet), we will have *one* SIP P2P network for the whole universe. 
> Only one.
> 
> All service providers shares the same network infrastructure (i.e. 
> nodes, supernodes). They will just have different 
> domain/realm. So are 
> "Ad-Hoc and Ephemeral Groups", they're just a temporary domain/realm.
> 
> I believe that would solve our little bootstrapping problems. :)
> 
> Does this make sense? Any study been done in this area?
> 
> -benny
> 
> Matthews, Philip (Philip) wrote:
> >  Benny Prijono wrote:
> > 
> >>draft-bryan-sipping-p2p-01.txt talks about several ways to 
> bootstrap 
> >>the client:
> >>
> >>1. to contact list of "well known" supernodes.
> >>2. to contact cached address of my buddies, if I already 
> have buddies.
> >>3. or to "flood" (multicast, or whatever).
> >>
> > 
> > 
> > These three techniques all work pretty well in large P2P 
> SIP networks
> > (many thousands of peers). Thus Skype and most of the large 
> file-sharing
> > P2P networks
> > rely on these techniques.
> > 
> > But they do not work as well in smaller P2P SIP networks. 
> Consider, for
> > example,
> > the "Ad-Hoc and Ephemeral Group" use-case described in the use-case
> > draft. 
> > In this use-case:
> > - There are no "well known" supernodes since the network was only
> > recently created.
> > - When you join for the first time, you have no buddy list.
> >   Or, if it has been a while since you last were on the 
> network, your
> > buddies may all
> >   have different IP addresses (for DHCP and/or NAT reasons).
> > - If the nodes are located on different subnets, multicast 
> may not work.
> > 
> > In this case, you must either learn an IP address (and 
> port, if NATs are
> > involved)
> > of another peer through out-of-band techniques ("Hey Joe, 
> what's your IP
> > address?")
> > or use a rendevous server.
> > 
> > - Philip
> > 
> 
>

---

From: lists at bulukucing.org (Benny Prijono)
Date: Thu, 12 Jan 2006 21:36:50 +0000

Philip,

let me again assert my position that I'm not in any way knowledgeable 
in P2P technology, so what I'm going to say here is purely based only 
on reading couple of sip p2p drafts. But I would say they're quite 
logical.

For the sake of discussions, let me try to push my argument to the 
limit, until someone says "stop! it's silly, get out of here!".

I have two main motivation for proposing a single sip p2p universe.

First, it sounds great! A trully global, free, sip p2p network without 
border.

Second, because once we solved all the problems with "normal" sip p2p 
protocol, I suppose we'll end up with a protocol that is good enough 
to build this global sip p2p network. Because the issues that we need 
to solve in "global" sip p2p network *are* basicly the same issues in 
"normal" sip p2p.

The only differences are:
- number of nodes will be bigger, which I suppose is not a big deal. 
Once we design p2p protocol to accomodate 221 million users, it should 
be good enough to handle 10 billion users (or limit it to 4 billion, 
if we want to stick with 32bit unsigned integer).

- p2p overlays need to work together. So if a request arrive in a node 
from different overlay, the node should at least be able to direct the 
request to other node which it thinks belong to/or closer to the 
correct overlay.

While the benetifs of one global sip p2p network are:
- more supernodes, means easier bootstrap, more reliable, more 
connectivity, more routing choices, better network quality.

- no more walled garden. People (or "service providers") know that 
they need to work together to make the network works. Once they put 
wall in their garden, everybody will put wall in their garden too, and 
the network will collapse, and so is their business.

Now to address specific issues that you raised:
- security. Same issue with "normal" and "global" sip p2p. Remember 
that there is only one sip p2p protocol. If this issue is not 
addressed in "normal" sip p2p protocol, then there is nothing to 
protect you against malicious users trying to get access to your 
overlay, because the protocol itself is open and anybody can build a 
custom UA. But once this has been solved, it should be good for the 
"global" version of sip p2p.

- local, ephemeral overlay. There is no reason why it shouldn't work. 
Just like the IP protocol, where you can build a local/private 
network, there's nothing stopping you from building your local SIP p2p 
network using the very same sip p2p protocol.

Same as you, I'm waiting for someone more knowledgeable to step-in in 
the discussion.

-benny

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Thu, 12 Jan 2006 16:52:30 -0500

This is EXACTLY what I want to see with P2P SIP. A global SIP galaxy,
interconnecting thousands  of small communities or sub-communities or
sub-sub-communities.  Now the sub-communites could be P2P communities,
regular SIP domains, or even proprietary things like MSN, or (horrors) the
traditional PSTN using gateways that convert the global P2P context to
whatever context the local domain is in.

Now, define "free".  Communications between P2P entities will likely be
"free" after the pipe and the bits are paid for, but the P2P services that
operate on the network? That's something else, something that could be
subscribed to and charged for.  How that subscription is done is another
issue, for a later standard, once the dust settles and global P2P SIP is a
reality.  How sub-communities,  services and such publish themselves in the
global community, so that they can be found? That too is for later once the
dust settles.

But first, let us build the underlying infrastructure that supports this.
Let's stop pussyfooting around.

On 12/01/06, Benny Prijono <lists at bulukucing.org> wrote:
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>

--
Michael Slavitch
Ottawa, Ontario Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060112/86dfae47/attachment.html

---

From: huang-ming.pan at comcast.net (PP)
Date: Fri, 13 Jan 2006 11:24:28 -0800

Quoted: "But first, let us build the underlying infrastructure that supports this.  Let's stop pussyfooting around."

I agree with Michael on putting "underlying infrastructure" on the first place, before P2P and SIP, in my opinion. This is why I've been curious and worry why nobody here so far would like to address the "security" layer of the underlying infrastructure, which seems to be the most bottom layer of the foundation above transport layers. 

Sorry, I must mention Skype again, but Skype did spend lots of (smart) efforts on its security mechansim, though it is based on grandpa's RSA-1536/2048 public-key cryptograph that consumes much network bandwidth on key exchanging and negotiation among nodes, and not a little cpu time on private-key related operations especially on the signup servers which are responsible for signing node certificates. 

Without STRONG and EFFICIENT security, even 100% of SIP-related RFCs and aboundance of features are placed upon the infrastructure, the network will be severely criticized and challenged, won't it?

peter
  ----- Original Message ----- 
  From: Michael Slavitch 
  To: Benny Prijono ; p2p-sip at cs.columbia.edu 
  Sent: Thursday, January 12, 2006 1:52 PM
  Subject: Re: [p2p-sip] P2P Universe [was Public P2P SIP service: Damaka.com]

  This is EXACTLY what I want to see with P2P SIP. A global SIP galaxy, interconnecting thousands  of small communities or sub-communities or sub-sub-communities.  Now the sub-communites could be P2P communities, regular SIP domains, or even proprietary things like MSN, or (horrors) the traditional PSTN using gateways that convert the global P2P context to whatever context the local domain is in. 

  Now, define "free".  Communications between P2P entities will likely be "free" after the pipe and the bits are paid for, but the P2P services that operate on the network? That's something else, something that could be subscribed to and charged for.  How that subscription is done is another issue, for a later standard, once the dust settles and global P2P SIP is a reality.  How sub-communities,  services and such publish themselves in the global community, so that they can be found? That too is for later once the dust settles. 

  But first, let us build the underlying infrastructure that supports this.  Let's stop pussyfooting around.

    -benny

  -- 
  Michael Slavitch
  Ottawa, Ontario Canada 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060113/bf0fb36a/attachment.html