[p2p-sip] Some comments on Use-cases document

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

Hi Bruce,

Thanks for sharing the thought of protocol mixing.

Unfortunately, whoever chooses Kademlia often must handle value retrieval at
the same time as key lookup. For example, FIND_VALUE implies FIND_NODE. It
is beyond my imagination to mix SIP and (eg.) MSRP in one single primitive
:-(

By the way, some overlay operations may be parallel and asynchronous. Though
much less than those in SS7, RFC 3261 defines some timers
(T1/.../A/B/C/.../K) in SIP protocol. Will P2P SIP regulate possible
asynchronous/timed activities? It seems essential for interoperability.

peter
----- Original Message -----
From: "Bruce Lowekamp" <lowekamp at cs.wm.edu>
To: "Peter Pan" <huang-ming.pan at comcast.net>
Cc: "Philip Matthews" <philip_matthews at magma.ca>; "P2P-SIP"
<p2p-sip at cs.columbia.edu>
Sent: Tuesday, March 21, 2006 1:36 PM
Subject: Re: [p2p-sip] Some comments on Use-cases document


The DHT is well-suited for storing URIs.  My thought for storing
arbitrary data (voicemail, configuration, etc) is to have the DHT
store the URI of a configuration file that is accessed via other
standard means (MSRP, etc).  That keeps the DHT as simple as possible.

Bruce

On 3/21/06, Peter Pan <huang-ming.pan at comcast.net> wrote:
> > The exact DHT algorithm we implement, the exact way the we use SIP,
> > the methods, etc I think are all going to need some careful thought.
> > But for P2P SIP, I think SIP is the obvious choice for DHT operations,
> > and I would consider it the default unless a convincing argument is
> > made against it.
>
> Not an argument but a question: how to efficiently implement Kademlia
> STORE_VALUE primitive in SIP INVITE/REGISTER when the stored values can be
> of any length and type?
>
> peter
>
> *** dont bash me, we are of the same country ***
>
> ----- Original Message -----
> From: "Bruce Lowekamp" <lowekamp at cs.wm.edu>
> To: "Philip Matthews" <philip_matthews at magma.ca>
> Cc: "P2P-SIP" <p2p-sip at cs.columbia.edu>
> Sent: Tuesday, March 21, 2006 12:41 PM
> Subject: Re: [p2p-sip] Some comments on Use-cases document
>
>
> > resending since this hasn't been acked by the mailing list or appeared
> > after over 30 minutes.  (I'm sure it will now immediately appear)
> >
> > On 3/21/06, Bruce Lowekamp <lowekamp at cs.wm.edu> wrote:
> > > I don't thnk it has anything to do with use-cases, either
> > >
> > > but
> > >
> > > Building DHT maintenance on top of SIP gives us all of the advantages
> > > of the routing, addressing, naming, and security issues already built
> > > into SIP.  Plus the NAT traversal capabilities of STUN, TURN, and ICE.
> > >  While not perfect for our use, I think with very minimal
> > > modifications (whatever the final protocol is) they will provide a
> > > very good solution.
> > >
> > > A proposal to use something else needs to:
> > > - explain what the shortcomings of SIP are for this purpose
> > > - explain how a new or different solution will provide equivalent
> functionality
> > > - explain how/why the new protocol will be better after resolving the
> > > complexities that SIP has become so complex to address
> > > - make a convincing enough case to justify deploying devices (and
> > > we're frequently talking about very small devices) to implement two
> > > separate protocol stacks.
> > >
> > >
> > > The exact DHT algorithm we implement, the exact way the we use SIP,
> > > the methods, etc I think are all going to need some careful thought.
> > > But for P2P SIP, I think SIP is the obvious choice for DHT operations,
> > > and I would consider it the default unless a convincing argument is
> > > made against it.
> > >
> > > A number of comments have been made stating that NATs must be taken
> > > into account from the beginning.  Again, one of the issues that using
> > > SIP helps address already is NAT traversal.  It's not perfect for
> > > signalling, but the framework is there.
> > >
> > > Bruce
> > >
> > > On 3/21/06, Philip Matthews <philip_matthews at magma.ca> wrote:
> > > > On 20-Mar-06, at 21:19 , David Barrett wrote:
> > > >
> > > > > I'd add to that this key question:
> > > > >
> > > > >       "Will we extend SIP, or create a new protocol?"
> > > > >
> > > > > I'm finding it hard to make any headway without understanding the
> > > > > above.
> > > > > Basically, I see two major directions we could go:
> > > > >
> > > > > 1) Extend SIP with overlay-maintenance and resource-location
> messages.
> > > > >
> > > > > 2) Create a new overlay protocol and develop bindings for SIP and
> > > > > ICE (eg,
> > > > > distributed proxy service and STUN/TURN resource-location
service).
> > > > >
> > > > > It seems this high-level decision keeps coming up again and again
in
> > > > > discussions of the smaller issues.
> > > > >
> > > >
> > > > For what it is worth, I can say that my own views on this subject
> > > > have changed.
> > > >
> > > > For all of last year, I strongly believed that there should be two
> > > > distinct layers:
> > > > a SIP layer and a P2P layer (i.e., option 2). See the arguments I
> > > > wrote in
> > > >
http://www.p2psip.org/drafts/draft-matthews-sipping-p2p-industrial-
> > > > strength-00.txt
> > > > as well as those on Alan Johnston in
> > > >
> http://www.p2psip.org/drafts/draft-johnston-sipping-p2p-ipcom-01.txt
> > > >
> > > > However, in the last few months, I have come to see that there are
> > > > some good reasons
> > > > to put the two layers together into one (i.e., option 1):
> > > >         a) NAT Traversal becomes easier because there is just one
> port,
> > > > rather than two
> > > >            (this assumes that the P2P layer would run on a different
> port
> > > > than SIP)
> > > >         b) Possible performance improvements. With two layers, you
> have to
> > > > first ask
> > > >           "where is user U?" and then send the Invite message. With
> one
> > > > layer, there is
> > > >           the possibility of sending the Invite and having it routed
> to the
> > > > user.
> > > >           (David et al removed this from their latest draft, but
this
> was an
> > > > option in the
> > > >           earlier version, and also in the work done by Henning's
> group).
> > > >
> > > > As others have pointed out, there are also drawbacks, so I haven't
> > > > concluded anything
> > > > yet, but I am a lot more open to option 1 than I was a few months
ago.
> > > >
> > > >
> > > > - Philip
> > > >
> > > > PS. What this has to do with the use-cases document, however, I am
> > > > not clear on  ;-)
> > > > _______________________________________________
> > > > p2p-sip mailing list
> > > > p2p-sip at cs.columbia.edu
> > > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> > > >
> > > >
> > >
> >
> >
> >
>
>