[p2p-sip] P2PSIP, Kademlia and caching

[enrico.marocco at telecomitalia.it (Enrico Marocco)]

Greg,

I think we are saying the same thing.  Let's clarify...

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

I'm also for a clear separation between SIP and the overlay and I've
been so since the early days of P2PSIP.

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

Just in case SIP were chosen for implementing the overlay layer too, but
this group doesn't seem to love much such option ;-)

> 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'm not pushing SIP for the distributed lookup service; instead, I'm
saying that whatever the protocol will be, it MUST be possible to embed
it in SIP boxes, not only for accessing the lookup service, but also for
participating in its distributed implementation.  A solution which
relies on an external lookup service like OpenDHT doesn't allow the latter.

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

I perfectly agree with the text and I also like the proposed
architecture; however, I think that a SIP-based DHT - the one described
in draft-bryan-sipping-p2p-02 is an example - is suitable for being
adopted as the SN-SN protocol of the P2P layer.
Does your draft discourage this?  Alan's one does and I think Henry's
referring to it.

Enrico