[p2p-sip] Some comments on Use-cases document
lowekamp at cs.wm.edu (Bruce Lowekamp) Tue, 21 March 2006 21:36 UTC
From: "lowekamp at cs.wm.edu"
Date: Tue, 21 Mar 2006 15:36:59 -0600
Subject: [p2p-sip] Some comments on Use-cases document
In-Reply-To: <010b01c64d2d$41c340a0$6400a8c0@comcast.net>
References: <200603210319.k2L3JIrj001729@cs.columbia.edu> <B225AB16-9E9C-4A5F-A3C1-97309B78A920@magma.ca> <e9132f820603211202k3024d6b1x548400900a75a742@mail.gmail.com> <e9132f820603211241m7a43eab4q3f4f3cf3530052c3@mail.gmail.com> <010b01c64d2d$41c340a0$6400a8c0@comcast.net>
Message-ID: <e9132f820603211336p78d72639g497ca0f6005712c7@mail.gmail.com>
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 > > > > > > > > > > > > > > > > > > >
- [p2p-sip] Some comments on Use-cases document Philip Matthews
- [p2p-sip] Some comments on Use-cases document David Barrett
- [p2p-sip] Some comments on Use-cases document Sathya Narayanan
- [p2p-sip] Some comments on Use-cases document Dean Willis
- [p2p-sip] Some comments on Use-cases document Sathya Narayanan
- [p2p-sip] Some comments on Use-cases document Philip Matthews
- [p2p-sip] Some comments on Use-cases document Sathya Narayanan
- [p2p-sip] Some comments on Use-cases document Bruce Lowekamp
- [p2p-sip] Some comments on Use-cases document Bruce Lowekamp
- [p2p-sip] Some comments on Use-cases document Peter Pan
- [p2p-sip] Some comments on Use-cases document Michael Slavitch
- [p2p-sip] Some comments on Use-cases document Bruce Lowekamp
- [p2p-sip] Some comments on Use-cases document Bruce Lowekamp
- [p2p-sip] Some comments on Use-cases document Peter Pan
- [p2p-sip] Some comments on Use-cases document Sathya Narayanan
- [p2p-sip] Some comments on Use-cases document Dean Willis
- [p2p-sip] Some comments on Use-cases document Dean Willis
- [p2p-sip] Some comments on Use-cases document Peter Pan
- [p2p-sip] Some comments on Use-cases document Kyara Yamamoto
- [p2p-sip] Some comments on Use-cases document Karst Bjorgson
- [p2p-sip] Some comments on Use-cases document Eunsoo Shim
- [p2p-sip] Some comments on Use-cases document Mike Robinson
- [p2p-sip] Some comments on Use-cases document Kyara Yamamoto
- [p2p-sip] Some comments on Use-cases document Karst Bjorgson
- [p2p-sip] Some comments on Use-cases document Mike Robinson
- [p2p-sip] Some comments on Use-cases document Karst Bjorgson
- [p2p-sip] Some comments on Use-cases document David A. Bryan
- [p2p-sip] Some comments on Use-cases document Karst Bjorgson
- [p2p-sip] Some comments on Use-cases document David A. Bryan
- [p2p-sip] Some comments on Use-cases document Mike Robinson
- [p2p-sip] Some comments on Use-cases document Henry Sinnreich
- [p2p-sip] Some comments on Use-cases document Peter Pan
- [p2p-sip] Some comments on Use-cases document Mike Robinson
- [p2p-sip] Some comments on Use-cases document Mike Robinson
- [p2p-sip] Some comments on Use-cases document David Barrett
- [p2p-sip] Some comments on Use-cases document Roy, Radhika R.
- [p2p-sip] Some comments on Use-cases document Greg Daley
- [p2p-sip] Some comments on Use-cases document Mike Robinson
- [p2p-sip] Some comments on Use-cases document Eunsoo Shim
- [p2p-sip] Some comments on Use-cases document Greg Daley
- [p2p-sip] Some comments on Use-cases document Mike Robinson
- [p2p-sip] Some comments on Use-cases document Peter Pan
- [p2p-sip] Some comments on Use-cases document Eunsoo Shim
- [p2p-sip] Some comments on Use-cases document Roy, Radhika R.