[p2p-sip] P2PSIP, Kademlia and caching

[huang-ming.pan at comcast.net (Peter Pan)]

"A cat is good as long as it catches mice."

Me dont think SIP good (economic) for transporting all kind of services on
DHT, unless P2P SIP will be just for "vanilla" sessions. We may need to
store various kinds of databases distributedly so need a slim protocol to
access various kind of database objects without worry of MTU like we are
(Netrake SBC MTU=1300). I sincerely hope for some kind of simple binary
encoding protocol like SS7 IEs from the start so that we wont have headache
on SigComp.

Please be realistic. Different DHTs can't interoperate on peer-to-peer
basis; they can, only via gateway. I sincerely propose Kademlia since
eMule/eDonkey have proved it work (and I chose it :)

Please be specific. At least be specific to start defining some comformance
levels on what to do (functionalities/features) and how to do
(protocol/overlay). Being specific helps make derived products in small
footprint. Being specific does not mean less ambitious and simple but
confident and simplex to avoid us (you) from wavering around the same point
on the today of 2007 or 2008 watching Skype gulping millions of users every
month (:

PP
----- Original Message -----
From: "Greg Daley" <gregd at research.panasonic.com>
To: "Enrico Marocco" <enrico.marocco at telecomitalia.it>
Cc: <p2p-sip at cs.columbia.edu>; <henry at pulver.com>; "'David A. Bryan'"
<bryan at ethernot.org>
Sent: Monday, May 29, 2006 8:55 PM
Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching


> Hi Enrico,
>
> Enrico Marocco wrote:
> [cut]
> >> SIP UA (perhaps with the ability to access the P2P location service)
> >>
> >> and
> >>
> >> distributed P2P location storage (for example, using DHT).
> >>
> >> These may end up being on the same box, but there's no
> >> logical constraint for them to be.  I mean: it's just a
> >> data storage service, for small blobs of data.
> >
> > Sure, but what could be achieved using a free storage service such as
> > OpenDHT could also be achieved using a free conventional SIP provider or
> > a free dynamic DNS service (e.g. dyndns.org).  Instead, the most
> > relevant use-cases for which conventional SIP doesn't work require the
> > Location Service to be distributed among some/all of the SIP phones;
> > such a solution should be the main goal IMHO.
>
>
> It's not about OpenDHT.  I think it was being discussed for
> illustrative purposes.
>
> One of the primary reasons people may want a logical separation between
> the overlay infrastructure and SIP, is because most Infrastructure SIP's
> not all about NAT traversal services, while P2P infrastructure services
> (which may just happen to be running on publically addressed SIP
> devices) may be heavily involved.
>
> Does someone have to implement the full SIP stack to run a STUN Relay?
> How about providing a robust way to discover these Relays, and
> distribute loads, etc?  Is SIP required for these functions?
>
> I'd guess not.
>
> So if the function of the NAT traversal services aren't necessarily
> tied to SIP protocol, why would the distributed lookup service?
>
> Now, if the protocol does end up being SIP or SIP-like, that's OK,
> it's just that architecturally, it's not needed.
>
> >>>> I guess we need to evaluate the criteria what to use in the DHT
> >>>> layer. SIP in the DHT layer is wrong IMHO. This is explained in:
> >>>>
> >>>> http://www.p2psip.org/drafts/draft-shim-sipping-p2p-arch-00.txt
> >>> Perhaps you mean:
> >>>
http://www.ietf.org/internet-drafts/draft-johnston-sipping-p2p-ipcom-02.txt
> >>>
> >>>
> >>> The list in sec. 8 is arguable IMHO, but now it's not time for
> >>> discussing how to transport bits.
> >> Actually, I think he meant the former.
> >
> > I should have read it more carefully ;-)  Alan's draft explicitly lists
> > issues with P2P SIP implementations (sec. 8 "SIP P2P Implementations");
> > can you please point out where it is explained in the architecture
draft?
>
> Do you mean apart from section 3: Architecture Overview, which starts:
>
>     A peer in the P2P SIP system is comprised of two layers: the P2P
>     overlay layer and the SIP layer.  The P2P overlay layer handles all
>     the P2P overlay functions.  The P2P overlay layer does not interpret
>     semantic meanings of the resources placed or looked up by the higher
>     layers including SIP.  But its design goal is serving SIP and thus
>     SIP-based real-time media applications.  That is, other applications
>     may use the P2P overlay layer presented here but the architecture and
>     the algorithm used for this P2P overlay layer may not necessarily be
>     optimal for all applications.
>
> Sure this is our take on it, but the tie between the P2P lookup function
> and SIP is, at best, one of convenience.
>
> Greg
>
>