Subject: [p2p-sip] Single layer vs two layers

From: sathya at research.panasonic.com (Sathya Narayanan)
Date: Tue, 21 Mar 2006 15:30:26 -0500

> I would say it's SIP, not a SIP-like protocol, but that's a minor terminology issue.

It is sorta minor. But, I would like to explore this point further, please indulge me. I called it SIP-like because there are proposed changes to the packet formats (new options) and behavior of nodes that receive these messages (for example the behavior in response to the receipt of a REGISTER message), to achieve something SIP was not designed for in the first place. 

Even assuming that the semantics of REGISTER message matches the required semantics for node join and resource add of a DHT, how are we going to address replication of resources on DHT. We have to extend the way REGISTER message is used to support whatever form of replication is developed, while AFAIK replication is not part of the REGISTER semantics today. And I am sure there will be other requirements to have a stable overlay network that will need further changes.

So, the question is how far we have to go away from the current purpose of SIP protocol before we start calling it by some other name?

my two cents,
Sathya

PS: I don't have a position regarding the use of something very much like SIP for the overlay protocol yet, I am just trying to understand the pros and cons.

> 
> -01 used INVITE to search the DHT for the contact and to place the
> call.  There was some concern that this might introduce issues when
> connecting to non-P2P UAs with p2p headers (even if they are just
> options or extension headers).
> 
> To address that issue, -02 uses REGISTER to query for the resource
> registration (as specified by 3261, a REGISTER without a contact 
> is a
> query).   The UAC then places the call using purely conventional SIP
> to the target UAS.
> 
> So it's two-layer in the sense that operations never traverse from the
> DHT to non-DHT portions of the protocol.  But it's all implemented on
> top of a standard SIP stack.
> 
> Bruce
> 
> 
> On 3/21/06, Sathya Narayanan <sathya at research.panasonic.com> wrote:
> > After I wrote this email, I went back and read Bryan's draft and 
> now I am not sure if it is proposing a single layer approach. It 
> looks to me like it is proposing a two-layer approach, with the 
> SIP layer exactly same as SIP and the overlay layer using a new 
> SIP-like protocol. Is that a correct description?
> >
> > thanks,
> > Sathya
> >
> > ----- Original Message -----
> > From: Sathya Narayanan <sathya at research.panasonic.com>
> > Date: Tuesday, March 21, 2006 2:10 pm
> > Subject: Re: [p2p-sip] Some comments on Use-cases document
> >
> > > Dean -
> > >
> > > >
> > > > I propose that we first define an abstract model of an overlay
> > > > network that includes the requisite primitives INSERT and QUERY
> > > > (anything else needed?) and use this abstraction as our middle
> > > layer.
> > > There is a section in draft-shim-sipping-p2p-arch-00.txt on P2P
> > > Overlay API which proposes a set of such primitives.
> > >
> > > > For the lower-layer, we do a binding from the abstraction to one
> > > or
> > > > more distributed database models, probably starting with CHORD.
> > > This
> > > > leaves our P2PSIP architecture independent of the database, but
> > > gives a proof-of-concept adequate for implementation.
> > >
> > > I am not sure if CHORD is the best option to start with. But, I
> > > will wait to hear other opinions/reasons before taking a position
> > > on this one.
> > >
> > > >
> > > > For the upper-layer, we have one model defined using SIP
> > > REGISTER
> > > > messages. We've also heard of work that uses REGISTER for the
> > > > "INSERT" primitive and SUBSCRIBE/NOTIFY for the "query" 
> primitive.> > >
> > > > I'm also very interested in seeing if there's an obvious binding
> > > for
> > > > TURN here, as that might kill two birds with one stone.
> > > >
> > > > I propose we start with the REGISTER/REGISTER model from the
> > > bryan
> > > > draft and talk that through a little further before we think
> > > about changing it.
> > >
> > > My understanding of Bryan's draft is that it tries to extend SIP
> > > for overlay maintenance and resource location, i.e. a single layer
> > > approach (Please correct me if I am wrong). So, proposing to start
> > > with that model implicitely chooses that approach and ignores the
> > > other possibility of having two separate layers as proposed in
> > > draft-shim. I think we should have an explicit discussion on that
> > > "key" question before proceeding any further.
> > >
> > > thanks,
> > > Sathya
> > >
> > > > _______________________________________________
> > > > p2p-sip mailing list
> > > > p2p-sip at cs.columbia.edu
> > > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> > > >
> > >
> > > _______________________________________________
> > > p2p-sip mailing list
> > > p2p-sip at cs.columbia.edu
> > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> > >
> >
> > _______________________________________________
> > p2p-sip mailing list
> > p2p-sip at cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> >
> >
>

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Tue, 21 Mar 2006 14:37:34 -0600

Our -02 draft suggests the idea of making a UA responsible for storing
replicas by modifying the resource URI and registering each replica
separately.  There are pros and cons to this, but it does avoid having
the responsible node also be responsible for maintaining replicas just
because it received a REGISTER.  I haven't contemplated yet whether we
can simply use sip-outbound techniques to accomplish replicas, but
that might be an interesting question.

Bruce