From enrico.marocco at telecomitalia.it Thu May 11 08:28:00 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Thu, 11 May 2006 14:28:00 +0200 Subject: [p2p-sip] Open Source P2P SIP implementation Message-ID: <44632DD0.4030103@telecomitalia.it> Folks: eventually I've created a SourceForge project for an open implentation of draft-bryan-sipping-p2p-02. The URL is: > http://sipdht.sourceforge.net/ So far, release 0.0.1 is available; it is a non-compliant early implementation with a lot of open issues (see TODO), but it still works. It is fairly simple (<3500 lines of code) and depends on a patched version of Nokia's Sofia-SIP libraries; try it and let me know... Any contribution is welcome! Enrico From Kasthuriram_V at infosys.com Thu May 11 08:47:20 2006 From: Kasthuriram_V at infosys.com (Kasthuri Ram V.) Date: Thu, 11 May 2006 18:17:20 +0530 Subject: [p2p-sip] Open Source P2P SIP implementation In-Reply-To: <44632DD0.4030103@telecomitalia.it> References: <44632DD0.4030103@telecomitalia.it> Message-ID: <1147351640.16105.0.camel@dakota> > eventually I've created a SourceForge project for an open implentation > of draft-bryan-sipping-p2p-02. The URL is: > > http://sipdht.sourceforge.net/ Thanks. Was looking for one for quite sometime. Thanks, KasthuriRam -- > > So far, release 0.0.1 is available; it is a non-compliant early > implementation with a lot of open issues (see TODO), but it still works. > > It is fairly simple (<3500 lines of code) and depends on a patched > version of Nokia's Sofia-SIP libraries; try it and let me know... Any > contribution is welcome! > > Enrico > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From slavitch at gmail.com Thu May 11 14:13:12 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Thu, 11 May 2006 14:13:12 -0400 Subject: [p2p-sip] Open Source P2P SIP implementation In-Reply-To: <44632DD0.4030103@telecomitalia.it> References: <44632DD0.4030103@telecomitalia.it> Message-ID: <1fc32c8f0605111113u4465570aoc403e0c0473f78b4@mail.gmail.com> Love it. Let's get moving on this. On 5/11/06, Enrico Marocco wrote: > > Folks: > > eventually I've created a SourceForge project for an open implentation > of draft-bryan-sipping-p2p-02. The URL is: > > http://sipdht.sourceforge.net/ > > So far, release 0.0.1 is available; it is a non-compliant early > implementation with a lot of open issues (see TODO), but it still works. > > It is fairly simple (<3500 lines of code) and depends on a patched > version of Nokia's Sofia-SIP libraries; try it and let me know... Any > contribution is welcome! > > Enrico > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > -- Michael Slavitch Ottawa, Ontario Canada "Yet another P2PSIP Henchman" -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060511/28a52999/attachment.html From enrico.marocco at telecomitalia.it Mon May 15 10:04:26 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Mon, 15 May 2006 16:04:26 +0200 Subject: [p2p-sip] New P2P SIP scenarios draft Message-ID: <44688A6A.3090408@telecomitalia.it> Folks, we have just submitted an I-D about "P2P SIP in Disconnected or Limited Connectivity Scenarios". Until it becomes available in the repository, it can be downloaded at the following URLs: http://sipdemo.tilab.com/drafts/draft-marocco-sipping-p2p-scenarios-00.txt http://sipdemo.tilab.com/drafts/draft-marocco-sipping-p2p-scenarios-00.html We look forward to any comments from the list. Thanks, Enrico and David From sayer at cs.tu-berlin.de Tue May 23 20:01:36 2006 From: sayer at cs.tu-berlin.de (Stefan Sayer) Date: Wed, 24 May 2006 02:01:36 +0200 Subject: [p2p-sip] P2PSIP, Kademlia and caching Message-ID: <4473A260.7040007@cs.tu-berlin.de> Hello p2psippers, does Kademlia's caching scheme disqualify it from being used as DHT for P2PSIP? I see two problems with it: - stale values of the user's location could persist, as the update performed by the client will probably not reach all the cached copies - is it possible to require authentication for a stored record? in the caching scheme in the original kademlia paper it says "For caching purposes, once a lookup succeeds, the requesting node stores the (key,value) pair at the closest node it observed to the key that did not return the value.", and the requesting node does not have the credentials. Especially the second one troubles me, any mechanism to prevent identity theft needs authentication. For example, draft-shim-sipping-p2p-arch-00 Section 9. for the add function mentiones that a security credential will be associated with the record, if its updatable, and it seems to me that this clearly disqualifies Kademlia. Or is it that just the caching would not be used and only the original publisher be allowed to update or remove an entry? Regards Stefan Sayer From henry at pulver.com Wed May 24 08:56:32 2006 From: henry at pulver.com (Henry Sinnreich) Date: Wed, 24 May 2006 07:56:32 -0500 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <4473A260.7040007@cs.tu-berlin.de> Message-ID: <00d301c67f31$7bdc5480$2800a8c0@DSX400> >From a practical point of view, it seems Bamboo (http://bamboo-dht.org/ ) used in Open DHT (http://www.opendht.org/ ) is the most obvious option at this point in time. A lot of experience and work went into Bamboo; it is quite mature apparently. More research will probably reveal even more refined application level routing protocols, but Bamboo seems OK for now. Do any p2psippers have an opinion on this? Thanks, Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Stefan Sayer Sent: Tuesday, May 23, 2006 7:02 PM To: p2p-sip at cs.columbia.edu Subject: [p2p-sip] P2PSIP, Kademlia and caching Hello p2psippers, does Kademlia's caching scheme disqualify it from being used as DHT for P2PSIP? I see two problems with it: - stale values of the user's location could persist, as the update performed by the client will probably not reach all the cached copies - is it possible to require authentication for a stored record? in the caching scheme in the original kademlia paper it says "For caching purposes, once a lookup succeeds, the requesting node stores the (key,value) pair at the closest node it observed to the key that did not return the value.", and the requesting node does not have the credentials. Especially the second one troubles me, any mechanism to prevent identity theft needs authentication. For example, draft-shim-sipping-p2p-arch-00 Section 9. for the add function mentiones that a security credential will be associated with the record, if its updatable, and it seems to me that this clearly disqualifies Kademlia. Or is it that just the caching would not be used and only the original publisher be allowed to update or remove an entry? Regards Stefan Sayer _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From eunsoo at research.panasonic.com Wed May 24 11:37:55 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 24 May 2006 11:37:55 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <00d301c67f31$7bdc5480$2800a8c0@DSX400> References: <00d301c67f31$7bdc5480$2800a8c0@DSX400> Message-ID: <44747DD3.6080607@research.panasonic.com> I think Bamboo is a good starting point. Still we might want to define our requirements for the DHT algorithm(s) for P2PSIP. Thanks. Eunsoo Henry Sinnreich wrote: >>From a practical point of view, it seems Bamboo (http://bamboo-dht.org/ ) > used in Open DHT (http://www.opendht.org/ ) is the most obvious option at > this point in time. A lot of experience and work went into Bamboo; it is > quite mature apparently. > > More research will probably reveal even more refined application level > routing protocols, but Bamboo seems OK for now. > > Do any p2psippers have an opinion on this? > > Thanks, Henry > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Stefan Sayer > Sent: Tuesday, May 23, 2006 7:02 PM > To: p2p-sip at cs.columbia.edu > Subject: [p2p-sip] P2PSIP, Kademlia and caching > > Hello p2psippers, > > does Kademlia's caching scheme disqualify it from being used as DHT > for P2PSIP? > > I see two problems with it: > - stale values of the user's location could persist, as the update > performed by the client will probably not reach all the cached copies > - is it possible to require authentication for a stored record? in > the caching scheme in the original kademlia paper it says "For caching > purposes, once a lookup succeeds, the requesting node stores the > (key,value) pair at the closest node it observed to the key that did > not return the value.", and the requesting node does not have the > credentials. > > Especially the second one troubles me, any mechanism to prevent > identity theft needs authentication. For example, > draft-shim-sipping-p2p-arch-00 Section 9. for the add function > mentiones that a security credential will be associated with the > record, if its updatable, and it seems to me that this clearly > disqualifies Kademlia. > > Or is it that just the caching would not be used and only the original > publisher be allowed to update or remove an entry? > > Regards > Stefan Sayer > _______________________________________________ > 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 Wed May 24 12:08:44 2006 From: lowekamp at cs.wm.edu (Bruce Lowekamp) Date: Wed, 24 May 2006 12:08:44 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <4473A260.7040007@cs.tu-berlin.de> References: <4473A260.7040007@cs.tu-berlin.de> Message-ID: I think there are a lot of good points about Kademlia, but I'm not sure that the caching component is a good idea for p2psip. (this will be easier to answer, of course, with a more formal requirements analysis.) Kademlia's caching is designed for systems where there is a lot of search locality---some items are much more popular than others. I don't think we have the same type of locality in any/most p2psip environment(s), so I don't think the caching buys us any performance increase. As you point out, it actually increases the likelihood of retrieving a stale registration (presumably cached values would time out quickly, but there's still that chance). I don't think caching adds any complexities for authentication---if you're working in an open P2P system you're probably assuming you have an untrusted network to begin with and will be trying to validate any registration, regardless of whether it's cached or not. Bruce On 5/23/06, Stefan Sayer wrote: > Hello p2psippers, > > does Kademlia's caching scheme disqualify it from being used as DHT > for P2PSIP? > > I see two problems with it: > - stale values of the user's location could persist, as the update > performed by the client will probably not reach all the cached copies > - is it possible to require authentication for a stored record? in > the caching scheme in the original kademlia paper it says "For caching > purposes, once a lookup succeeds, the requesting node stores the > (key,value) pair at the closest node it observed to the key that did > not return the value.", and the requesting node does not have the > credentials. From bryan at ethernot.org Wed May 24 12:23:23 2006 From: bryan at ethernot.org (David A. Bryan) Date: Wed, 24 May 2006 12:23:23 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <44747DD3.6080607@research.panasonic.com> References: <00d301c67f31$7bdc5480$2800a8c0@DSX400> <44747DD3.6080607@research.panasonic.com> Message-ID: <8b2769930605240923p5d17ce6dp826203082919611c@mail.gmail.com> I think Bamboo is certainly one to consider, but I think others are strong contenders too. Kademlia is certainly one that has a number of things going for it. It is used in eDonkey, so I think it is as well established (maybe more so) than Bamboo. (Not that there is anything wrong with Bamboo, either). I think we should also consider implementation ease when choosing one. Has anyone here implemented both? Any thoughts? David On 5/24/06, Eunsoo Shim wrote: > I think Bamboo is a good starting point. > Still we might want to define our requirements for the DHT algorithm(s) > for P2PSIP. > Thanks. > > Eunsoo > > Henry Sinnreich wrote: > >>From a practical point of view, it seems Bamboo (http://bamboo-dht.org/ ) > > used in Open DHT (http://www.opendht.org/ ) is the most obvious option at > > this point in time. A lot of experience and work went into Bamboo; it is > > quite mature apparently. > > > > More research will probably reveal even more refined application level > > routing protocols, but Bamboo seems OK for now. > > > > Do any p2psippers have an opinion on this? > > > > Thanks, Henry > > > > -----Original Message----- > > From: p2p-sip-bounces at cs.columbia.edu > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Stefan Sayer > > Sent: Tuesday, May 23, 2006 7:02 PM > > To: p2p-sip at cs.columbia.edu > > Subject: [p2p-sip] P2PSIP, Kademlia and caching > > > > Hello p2psippers, > > > > does Kademlia's caching scheme disqualify it from being used as DHT > > for P2PSIP? > > > > I see two problems with it: > > - stale values of the user's location could persist, as the update > > performed by the client will probably not reach all the cached copies > > - is it possible to require authentication for a stored record? in > > the caching scheme in the original kademlia paper it says "For caching > > purposes, once a lookup succeeds, the requesting node stores the > > (key,value) pair at the closest node it observed to the key that did > > not return the value.", and the requesting node does not have the > > credentials. > > > > Especially the second one troubles me, any mechanism to prevent > > identity theft needs authentication. For example, > > draft-shim-sipping-p2p-arch-00 Section 9. for the add function > > mentiones that a security credential will be associated with the > > record, if its updatable, and it seems to me that this clearly > > disqualifies Kademlia. > > > > Or is it that just the caching would not be used and only the original > > publisher be allowed to update or remove an entry? > > > > Regards > > Stefan Sayer > > _______________________________________________ > > 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 henry at pulver.com Wed May 24 15:54:47 2006 From: henry at pulver.com (Henry Sinnreich) Date: Wed, 24 May 2006 14:54:47 -0500 Subject: [p2p-sip] Itiva white paper Message-ID: <007601c67f6b$e9309020$2800a8c0@DSX400> The Itiva white paper tries to make hay from comparing their web page cashing approach with P2P. It may be useful to read so as to have the right arguments that it does not apply to RT communications, such as P2P SIP. But it sure is another nail in the coffin of IPTV :-) http://www.itiva.com/special/Quantum-Transport-white-paper-04.pdf Thanks, Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060524/f0bf007b/attachment.html From henry at pulver.com Wed May 24 15:54:47 2006 From: henry at pulver.com (Henry Sinnreich) Date: Wed, 24 May 2006 14:54:47 -0500 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <8b2769930605240923p5d17ce6dp826203082919611c@mail.gmail.com> Message-ID: <008901c67f6b$eaf598b0$2800a8c0@DSX400> > Any thoughts? Maybe a list of criteria for selection would make sense: An I-D with selection criteria and/or requirements. My two cents, Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan Sent: Wednesday, May 24, 2006 11:23 AM To: Eunsoo Shim Cc: p2p-sip at cs.columbia.edu; henry at pulver.com Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching I think Bamboo is certainly one to consider, but I think others are strong contenders too. Kademlia is certainly one that has a number of things going for it. It is used in eDonkey, so I think it is as well established (maybe more so) than Bamboo. (Not that there is anything wrong with Bamboo, either). I think we should also consider implementation ease when choosing one. Has anyone here implemented both? Any thoughts? David On 5/24/06, Eunsoo Shim wrote: > I think Bamboo is a good starting point. > Still we might want to define our requirements for the DHT algorithm(s) > for P2PSIP. > Thanks. > > Eunsoo > > Henry Sinnreich wrote: > >>From a practical point of view, it seems Bamboo (http://bamboo-dht.org/ ) > > used in Open DHT (http://www.opendht.org/ ) is the most obvious option at > > this point in time. A lot of experience and work went into Bamboo; it is > > quite mature apparently. > > > > More research will probably reveal even more refined application level > > routing protocols, but Bamboo seems OK for now. > > > > Do any p2psippers have an opinion on this? > > > > Thanks, Henry > > > > -----Original Message----- > > From: p2p-sip-bounces at cs.columbia.edu > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Stefan Sayer > > Sent: Tuesday, May 23, 2006 7:02 PM > > To: p2p-sip at cs.columbia.edu > > Subject: [p2p-sip] P2PSIP, Kademlia and caching > > > > Hello p2psippers, > > > > does Kademlia's caching scheme disqualify it from being used as DHT > > for P2PSIP? > > > > I see two problems with it: > > - stale values of the user's location could persist, as the update > > performed by the client will probably not reach all the cached copies > > - is it possible to require authentication for a stored record? in > > the caching scheme in the original kademlia paper it says "For caching > > purposes, once a lookup succeeds, the requesting node stores the > > (key,value) pair at the closest node it observed to the key that did > > not return the value.", and the requesting node does not have the > > credentials. > > > > Especially the second one troubles me, any mechanism to prevent > > identity theft needs authentication. For example, > > draft-shim-sipping-p2p-arch-00 Section 9. for the add function > > mentiones that a security credential will be associated with the > > record, if its updatable, and it seems to me that this clearly > > disqualifies Kademlia. > > > > Or is it that just the caching would not be used and only the original > > publisher be allowed to update or remove an entry? > > > > Regards > > Stefan Sayer > > _______________________________________________ > > 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 > _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From bk9001 at gmail.com Wed May 24 17:58:42 2006 From: bk9001 at gmail.com (Brijesh Kumar) Date: Wed, 24 May 2006 17:58:42 -0400 Subject: [p2p-sip] Itiva white paper References: <007601c67f6b$e9309020$2800a8c0@DSX400> Message-ID: <006f01c67f7d$3a7e19a0$110aa8c0@Shikky> Henry: Thanks for a reference to itiva's white paper. After doing a quick read, I think that work is about caching contents in the content servers along the path, and delivering movies. Itiva's premise is that they can optimize the caching in the caching servers along the delivery route by creating delivery chunks of large files. For their applications, the RT mode is not required (their focus is more on efficiency and bandwidth conservation - pretty nobel goals I believe :-)). I don't think their comparison with p2p is invalid since there cannot be a requirement that media contents distributed with sip p2p or otherwise need to be in "RT". It is not clear why would you say "RT communications, such as P2P SIP". cheers, --bk ----- Original Message ----- From: Henry Sinnreich To: p2p-sip at cs.columbia.edu Sent: Wednesday, May 24, 2006 3:54 PM Subject: [p2p-sip] Itiva white paper The Itiva white paper tries to make hay from comparing their web page cashing approach with P2P. It may be useful to read so as to have the right arguments that it does not apply to RT communications, such as P2P SIP. But it sure is another nail in the coffin of IPTV J http://www.itiva.com/special/Quantum-Transport-white-paper-04.pdf Thanks, Henry ------------------------------------------------------------------------------ _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060524/b09f3eb8/attachment.html From mike_robnson at yahoo.com Wed May 24 18:17:42 2006 From: mike_robnson at yahoo.com (Mike Robinson) Date: Wed, 24 May 2006 15:17:42 -0700 (PDT) Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <008901c67f6b$eaf598b0$2800a8c0@DSX400> Message-ID: <20060524221742.63934.qmail@web38501.mail.mud.yahoo.com> With all these mails on DHTs, it is obvious that there cannot be an agreement on what DHT to use for any p2p protocol. As for in-house stuff one is free to use any DHT algorithm, but to standardize a protocol on a particular DHT by pushing through IETF process will be a grave mistake, unless someone tells me that the final word on DHT has been spoken. I would rather see many approaches developed and code put on sourceforge.net from people that are asking to standardize so that interested persons can run the code and compare before any standardization discussion gets done in this direction in any forum. Once we have comparable code, it will be easy to form opinions on various DHTs. The people that are pushing white papers from their company labs should instead submit actual code, if they so believe in the merit of their design proposal if any. - Mike Henry Sinnreich wrote: > Any thoughts? Maybe a list of criteria for selection would make sense: An I-D with selection criteria and/or requirements. My two cents, Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan Sent: Wednesday, May 24, 2006 11:23 AM To: Eunsoo Shim Cc: p2p-sip at cs.columbia.edu; henry at pulver.com Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching I think Bamboo is certainly one to consider, but I think others are strong contenders too. Kademlia is certainly one that has a number of things going for it. It is used in eDonkey, so I think it is as well established (maybe more so) than Bamboo. (Not that there is anything wrong with Bamboo, either). I think we should also consider implementation ease when choosing one. Has anyone here implemented both? Any thoughts? David On 5/24/06, Eunsoo Shim wrote: > I think Bamboo is a good starting point. > Still we might want to define our requirements for the DHT algorithm(s) > for P2PSIP. > Thanks. > > Eunsoo > > Henry Sinnreich wrote: > >>From a practical point of view, it seems Bamboo (http://bamboo-dht.org/ ) > > used in Open DHT (http://www.opendht.org/ ) is the most obvious option at > > this point in time. A lot of experience and work went into Bamboo; it is > > quite mature apparently. > > > > More research will probably reveal even more refined application level > > routing protocols, but Bamboo seems OK for now. > > > > Do any p2psippers have an opinion on this? > > > > Thanks, Henry > > > > -----Original Message----- > > From: p2p-sip-bounces at cs.columbia.edu > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Stefan Sayer > > Sent: Tuesday, May 23, 2006 7:02 PM > > To: p2p-sip at cs.columbia.edu > > Subject: [p2p-sip] P2PSIP, Kademlia and caching > > > > Hello p2psippers, > > > > does Kademlia's caching scheme disqualify it from being used as DHT > > for P2PSIP? > > > > I see two problems with it: > > - stale values of the user's location could persist, as the update > > performed by the client will probably not reach all the cached copies > > - is it possible to require authentication for a stored record? in > > the caching scheme in the original kademlia paper it says "For caching > > purposes, once a lookup succeeds, the requesting node stores the > > (key,value) pair at the closest node it observed to the key that did > > not return the value.", and the requesting node does not have the > > credentials. > > > > Especially the second one troubles me, any mechanism to prevent > > identity theft needs authentication. For example, > > draft-shim-sipping-p2p-arch-00 Section 9. for the add function > > mentiones that a security credential will be associated with the > > record, if its updatable, and it seems to me that this clearly > > disqualifies Kademlia. > > > > Or is it that just the caching would not be used and only the original > > publisher be allowed to update or remove an entry? > > > > Regards > > Stefan Sayer > > _______________________________________________ > > 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 > _______________________________________________ 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 --------------------------------- Be a chatter box. Enjoy free PC-to-PC calls with Yahoo! Messenger with Voice. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060524/6a2ad851/attachment-0001.html From gregd at research.panasonic.com Wed May 24 19:10:00 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Wed, 24 May 2006 19:10:00 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <20060524221742.63934.qmail@web38501.mail.mud.yahoo.com> References: <20060524221742.63934.qmail@web38501.mail.mud.yahoo.com> Message-ID: <4474E7C8.9080106@research.panasonic.com> Hi Mike, Mike Robinson wrote: > > With all these mails on DHTs, it is obvious that there cannot be an > agreement on what DHT to use for any p2p protocol. As for in-house stuff > one is free to use any DHT algorithm, but to standardize a protocol on a > particular DHT by pushing through IETF process will be a grave mistake, > unless someone tells me that the final word on DHT has been spoken. > > I would rather see many approaches developed and code put on > sourceforge.net from people that are asking to standardize so that > interested persons can run the code and compare before any > standardization discussion gets done in this direction in any forum. > Once we have comparable code, it will be easy to form opinions on > various DHTs. The people that are pushing white papers from their > company labs should instead submit actual code, if they so believe in > the merit of their design proposal if any. > Henry's idea of requirements and assessment criteria is a really good one though, which necessarily predates that. Unless we know what we're designing for, it doesn't make sense to go ahead and cite (or implement) protocols. I'd much prefer to be comparing apples to apples. Greg From br at brianrosen.net Wed May 24 19:21:19 2006 From: br at brianrosen.net (Brian Rosen) Date: Wed, 24 May 2006 19:21:19 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <4474E7C8.9080106@research.panasonic.com> Message-ID: <012d01c67f88$c5bf82a0$640fa8c0@cis.neustar.com> But then the question is: Can we, at this point in time, create a meaningful requirement/assessment document? One way to figure that out is to just propose a requirement, right here on the list. If we get a bunch, and we see some consensus on direction, perhaps we could make progress. That would be nice. Anyone got a requirement to share? Brian -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley Sent: Wednesday, May 24, 2006 7:10 PM To: Mike Robinson Cc: p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan' Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching Hi Mike, Mike Robinson wrote: > > With all these mails on DHTs, it is obvious that there cannot be an > agreement on what DHT to use for any p2p protocol. As for in-house stuff > one is free to use any DHT algorithm, but to standardize a protocol on a > particular DHT by pushing through IETF process will be a grave mistake, > unless someone tells me that the final word on DHT has been spoken. > > I would rather see many approaches developed and code put on > sourceforge.net from people that are asking to standardize so that > interested persons can run the code and compare before any > standardization discussion gets done in this direction in any forum. > Once we have comparable code, it will be easy to form opinions on > various DHTs. The people that are pushing white papers from their > company labs should instead submit actual code, if they so believe in > the merit of their design proposal if any. > Henry's idea of requirements and assessment criteria is a really good one though, which necessarily predates that. Unless we know what we're designing for, it doesn't make sense to go ahead and cite (or implement) protocols. I'd much prefer to be comparing apples to apples. Greg _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From sayer at cs.tu-berlin.de Wed May 24 20:16:55 2006 From: sayer at cs.tu-berlin.de (Stefan Sayer) Date: Thu, 25 May 2006 02:16:55 +0200 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: References: <4473A260.7040007@cs.tu-berlin.de> Message-ID: <4474F777.1070300@cs.tu-berlin.de> Hello, Bruce Lowekamp wrote: > I don't think caching adds any complexities for authentication---if > you're working in an open P2P system you're probably assuming you have > an untrusted network to begin with and will be trying to validate any > registration, regardless of whether it's cached or not. 'validate' means for me in this context that the one who wants to register really is the one that has on sign-up reserved that name. What I don't understand: If every node is admitted to publish or update a record (which is true for a system that does caching), for example my location record, how can identity theft be prevented? * if every node is admitted to change a value associated to a key then anyone can steal the identity very easily * if every node is admitted to republish a pair (be it at cache places or some original root of the key), regardless of whether it is the original publisher of the pair, then an attacker could still litter the overlay with corrupted values So I would see the requirement as follows: The overlay MUST support binding a credential to a key, in order to authenticate the original publisher of a pair in update and remove operations. On the API level, for example starting from the definition in draft-shim-sipping-p2p-arch-00 Section 9, I would add the credentials directly as parameter to the functions add, update, and remove: get(in overlay_id, in key, out records, out error) add(in overlay_id, in key, in record, in lifetime, in option, in credential, out error) update(in overlay_id, in key, in record, in lifetime, in option, in credential, out error) remove(in overlay_id, in key, in credential, out error) As much as I like Kademlia, as I understand it at the moment without modifications it does not support this. But I might very well have overlooked something. Regards Stefan > > Bruce From gregd at research.panasonic.com Thu May 25 07:28:26 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Thu, 25 May 2006 07:28:26 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <012d01c67f88$c5bf82a0$640fa8c0@cis.neustar.com> References: <012d01c67f88$c5bf82a0$640fa8c0@cis.neustar.com> Message-ID: <447594DA.2000008@research.panasonic.com> Hi Brian, I do think that we are ready to start gathering the requirements and some people are working on that now. What we have to remember is that the main goal at the moment is to get a working group chartered, rather than a DHT chosen though (let's see if we can be productive and get some firm requirements without adding confusion to the charter discussion). Discussion on list seems a good way to start gathering requirements, but there are others which will turn up through systematic appraisal too. Greg Brian Rosen wrote: > But then the question is: > > Can we, at this point in time, create a meaningful requirement/assessment > document? > > One way to figure that out is to just propose a requirement, right here on > the list. If we get a bunch, and we see some consensus on direction, > perhaps we could make progress. > > That would be nice. > > Anyone got a requirement to share? > > Brian > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley > Sent: Wednesday, May 24, 2006 7:10 PM > To: Mike Robinson > Cc: p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan' > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > > Hi Mike, > > Mike Robinson wrote: >> With all these mails on DHTs, it is obvious that there cannot be an >> agreement on what DHT to use for any p2p protocol. As for in-house stuff >> one is free to use any DHT algorithm, but to standardize a protocol on a >> particular DHT by pushing through IETF process will be a grave mistake, >> unless someone tells me that the final word on DHT has been spoken. >> >> I would rather see many approaches developed and code put on >> sourceforge.net from people that are asking to standardize so that >> interested persons can run the code and compare before any >> standardization discussion gets done in this direction in any forum. >> Once we have comparable code, it will be easy to form opinions on >> various DHTs. The people that are pushing white papers from their >> company labs should instead submit actual code, if they so believe in >> the merit of their design proposal if any. >> > > Henry's idea of requirements and assessment criteria is a really > good one though, which necessarily predates that. > > Unless we know what we're designing for, it doesn't make sense > to go ahead and cite (or implement) protocols. I'd much prefer > to be comparing apples to apples. > > Greg > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From gregd at research.panasonic.com Thu May 25 07:33:18 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Thu, 25 May 2006 07:33:18 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <4474F777.1070300@cs.tu-berlin.de> References: <4473A260.7040007@cs.tu-berlin.de> <4474F777.1070300@cs.tu-berlin.de> Message-ID: <447595FE.5020006@research.panasonic.com> Hi Stefan, Short comment at the bottom. Stefan Sayer wrote: > Hello, > Bruce Lowekamp wrote: >> I don't think caching adds any complexities for authentication---if >> you're working in an open P2P system you're probably assuming you have >> an untrusted network to begin with and will be trying to validate any >> registration, regardless of whether it's cached or not. > 'validate' means for me in this context that the one who wants to > register really is the one that has on sign-up reserved that name. > > What I don't understand: If every node is admitted to publish or > update a record (which is true for a system that does caching), for > example my location record, how can identity theft be prevented? > > * if every node is admitted to change a value associated to a key then > anyone can steal the identity very easily > > * if every node is admitted to republish a pair (be it at > cache places or some original root of the key), regardless of whether > it is the original publisher of the pair, then an attacker could still > litter the overlay with corrupted values > > So I would see the requirement as follows: > The overlay MUST support binding a credential to a key, in order to > authenticate the original publisher of a pair in update > and remove operations. > > On the API level, for example starting from the definition in > draft-shim-sipping-p2p-arch-00 Section 9, I would add the credentials > directly as parameter to the functions add, update, and remove: > get(in overlay_id, in key, out records, out error) > add(in overlay_id, in key, in record, in lifetime, in option, > in credential, out error) > update(in overlay_id, in key, in record, in lifetime, in option, > in credential, out error) > remove(in overlay_id, in key, in credential, out error) > > As much as I like Kademlia, as I understand it at the moment without > modifications it does not support this. But I might very well have > overlooked something. Thanks for your analysis. You're right in that without security built into the DHT, it is potentially possible to overwrite, or swamp a particular record (dependent on the particular DHT's semantics). This a good example why we cannot use an existing system without thorough requirements analysis. Greg From niedermayer at informatik.uni-tuebingen.de Thu May 25 08:14:02 2006 From: niedermayer at informatik.uni-tuebingen.de (Heiko Niedermayer) Date: Thu, 25 May 2006 14:14:02 +0200 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <4474F777.1070300@cs.tu-berlin.de> References: <4473A260.7040007@cs.tu-berlin.de> <4474F777.1070300@cs.tu-berlin.de> Message-ID: <44759F8A.2040009@informatik.uni-tuebingen.de> Hello, commenting on all the mails on DHts. Well, I assume that the choice of DHT is of minor importance and that any DHT will at least do after adapting it to P2PSIP. But, why not build a specialized p2p network for P2PSIP. SIP is not a pure hash table service, so why transform a SIP network to a hash table? However, the big problem I see is that there is no convincing solution to provide security. Say, if I want to communicate with Nokia I might end up at Ericsson, that is fatal. And moreover, I do not want my personal data and behaviour be manged and tracked by peers I can and do not trust. So, the general question is if there is a way to secure P2PSIP and to provide privacy. In an open environment this is probably not possible. A closed P2PSIP network is no real value-add from my point-of-view. With respect to credentials, I assume that credentials are fine if the network is a closed infrastructure network and clients are not part of the network. Regards Heiko Stefan Sayer wrote: > Hello, > Bruce Lowekamp wrote: > >> I don't think caching adds any complexities for authentication---if >> you're working in an open P2P system you're probably assuming you have >> an untrusted network to begin with and will be trying to validate any >> registration, regardless of whether it's cached or not. >> > 'validate' means for me in this context that the one who wants to > register really is the one that has on sign-up reserved that name. > > What I don't understand: If every node is admitted to publish or > update a record (which is true for a system that does caching), for > example my location record, how can identity theft be prevented? > > * if every node is admitted to change a value associated to a key then > anyone can steal the identity very easily > > * if every node is admitted to republish a pair (be it at > cache places or some original root of the key), regardless of whether > it is the original publisher of the pair, then an attacker could still > litter the overlay with corrupted values > > So I would see the requirement as follows: > The overlay MUST support binding a credential to a key, in order to > authenticate the original publisher of a pair in update > and remove operations. > > On the API level, for example starting from the definition in > draft-shim-sipping-p2p-arch-00 Section 9, I would add the credentials > directly as parameter to the functions add, update, and remove: > get(in overlay_id, in key, out records, out error) > add(in overlay_id, in key, in record, in lifetime, in option, > in credential, out error) > update(in overlay_id, in key, in record, in lifetime, in option, > in credential, out error) > remove(in overlay_id, in key, in credential, out error) > > As much as I like Kademlia, as I understand it at the moment without > modifications it does not support this. But I might very well have > overlooked something. > > Regards > Stefan > > >> Bruce >> > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From br at brianrosen.net Thu May 25 08:53:47 2006 From: br at brianrosen.net (Brian Rosen) Date: Thu, 25 May 2006 08:53:47 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <447594DA.2000008@research.panasonic.com> Message-ID: <01e701c67ffa$457561b0$640fa8c0@cis.neustar.com> >From what I can gather, one of the big sticky issues associated with a charter is whether there is sufficient grounds to achieve consensus. If the big picture on requirements was established, that is prima fascia evidence that there is some consensus on how to go forward. So, I think requirements discussions, now, before there is a charter, is a good idea. Seems like you agree, so let's have some on the table. If there are groups working on some, get a draft published, and let's look at them. Let's start with DHTs: 1. Do we have consensus that P2PSIP, as would be defined by this group, is DHT based? 2. Is there a requirement for support of multiple DHTs? What would be the requirements a DHT needed to have in order to be acceptable? Brian -----Original Message----- From: Greg Daley [mailto:gregd at research.panasonic.com] Sent: Thursday, May 25, 2006 7:28 AM To: Brian Rosen Cc: 'Mike Robinson'; p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan' Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching Hi Brian, I do think that we are ready to start gathering the requirements and some people are working on that now. What we have to remember is that the main goal at the moment is to get a working group chartered, rather than a DHT chosen though (let's see if we can be productive and get some firm requirements without adding confusion to the charter discussion). Discussion on list seems a good way to start gathering requirements, but there are others which will turn up through systematic appraisal too. Greg Brian Rosen wrote: > But then the question is: > > Can we, at this point in time, create a meaningful requirement/assessment > document? > > One way to figure that out is to just propose a requirement, right here on > the list. If we get a bunch, and we see some consensus on direction, > perhaps we could make progress. > > That would be nice. > > Anyone got a requirement to share? > > Brian > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley > Sent: Wednesday, May 24, 2006 7:10 PM > To: Mike Robinson > Cc: p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan' > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > > Hi Mike, > > Mike Robinson wrote: >> With all these mails on DHTs, it is obvious that there cannot be an >> agreement on what DHT to use for any p2p protocol. As for in-house stuff >> one is free to use any DHT algorithm, but to standardize a protocol on a >> particular DHT by pushing through IETF process will be a grave mistake, >> unless someone tells me that the final word on DHT has been spoken. >> >> I would rather see many approaches developed and code put on >> sourceforge.net from people that are asking to standardize so that >> interested persons can run the code and compare before any >> standardization discussion gets done in this direction in any forum. >> Once we have comparable code, it will be easy to form opinions on >> various DHTs. The people that are pushing white papers from their >> company labs should instead submit actual code, if they so believe in >> the merit of their design proposal if any. >> > > Henry's idea of requirements and assessment criteria is a really > good one though, which necessarily predates that. > > Unless we know what we're designing for, it doesn't make sense > to go ahead and cite (or implement) protocols. I'd much prefer > to be comparing apples to apples. > > Greg > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From henry at pulver.com Thu May 25 11:17:45 2006 From: henry at pulver.com (Henry Sinnreich) Date: Thu, 25 May 2006 10:17:45 -0500 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <447594DA.2000008@research.panasonic.com> Message-ID: <007101c6800e$6730d9b0$2800a8c0@DSX400> >What we have to remember is that the main goal at the moment is to get a >working group chartered Yes, and can everybody on the list please remember this one and only one goal at this point in time? Thanks, Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley Sent: Thursday, May 25, 2006 6:28 AM To: Brian Rosen Cc: p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan' Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching Hi Brian, I do think that we are ready to start gathering the requirements and some people are working on that now. What we have to remember is that the main goal at the moment is to get a working group chartered, rather than a DHT chosen though (let's see if we can be productive and get some firm requirements without adding confusion to the charter discussion). Discussion on list seems a good way to start gathering requirements, but there are others which will turn up through systematic appraisal too. Greg Brian Rosen wrote: > But then the question is: > > Can we, at this point in time, create a meaningful requirement/assessment > document? > > One way to figure that out is to just propose a requirement, right here on > the list. If we get a bunch, and we see some consensus on direction, > perhaps we could make progress. > > That would be nice. > > Anyone got a requirement to share? > > Brian > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley > Sent: Wednesday, May 24, 2006 7:10 PM > To: Mike Robinson > Cc: p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan' > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > > Hi Mike, > > Mike Robinson wrote: >> With all these mails on DHTs, it is obvious that there cannot be an >> agreement on what DHT to use for any p2p protocol. As for in-house stuff >> one is free to use any DHT algorithm, but to standardize a protocol on a >> particular DHT by pushing through IETF process will be a grave mistake, >> unless someone tells me that the final word on DHT has been spoken. >> >> I would rather see many approaches developed and code put on >> sourceforge.net from people that are asking to standardize so that >> interested persons can run the code and compare before any >> standardization discussion gets done in this direction in any forum. >> Once we have comparable code, it will be easy to form opinions on >> various DHTs. The people that are pushing white papers from their >> company labs should instead submit actual code, if they so believe in >> the merit of their design proposal if any. >> > > Henry's idea of requirements and assessment criteria is a really > good one though, which necessarily predates that. > > Unless we know what we're designing for, it doesn't make sense > to go ahead and cite (or implement) protocols. I'd much prefer > to be comparing apples to apples. > > Greg > _______________________________________________ > 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 slavitch at gmail.com Thu May 25 11:37:53 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Thu, 25 May 2006 11:37:53 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <007101c6800e$6730d9b0$2800a8c0@DSX400> References: <447594DA.2000008@research.panasonic.com> <007101c6800e$6730d9b0$2800a8c0@DSX400> Message-ID: <1fc32c8f0605250837o71818418l7fbe4bb782ee0440@mail.gmail.com> I concur with that. Focus focus focus. On 5/25/06, Henry Sinnreich wrote: > > >What we have to remember is that the main goal at the moment is to get a > >working group chartered > > Yes, and can everybody on the list please remember this one and only one > goal at this point in time? > > Thanks, Henry > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060525/646c8a15/attachment.html From lowekamp at cs.wm.edu Thu May 25 11:43:20 2006 From: lowekamp at cs.wm.edu (Bruce Lowekamp) Date: Thu, 25 May 2006 11:43:20 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <4474F777.1070300@cs.tu-berlin.de> References: <4473A260.7040007@cs.tu-berlin.de> <4474F777.1070300@cs.tu-berlin.de> Message-ID: I think one of the lessons from working on the use-cases draft is that there are a wide range of scenarios with differing levels of trust and authorities that make good scenarios for p2psip. What exactly we'll attempt to standardize will come out of the WG charter and requirements drafts. Personally, I'm a big fan of having a protocol that supports several identity authentication options, since I don't think there will be a single one-size-fits-all solution for the different use-cases. The scenario you propose is easily solvable if you allow for the existence of loosely-connected CAs and use the DHT to store certificates. I think there are ideas for how to do it in a more distributed manner, but I don't know that they are at the level of something we could write a standard for, whereas certificate chains are well-understood. There are other variations, though---if you don't have CAs, then everyone can generate and publish their own public keys. I couldn't prevent someone else from claiming to be lowekamp at cs.wm.edu, but they couldn't fake signing my messages with my key (they could confuse the situation because there would be multiple lowekamp at cs.wm.edu identities with different keys). What you have then is basically the same as the current pgp keyserver system, which works as long as you have some way of verifying the key when you first acquire it. Bruce On 5/24/06, Stefan Sayer wrote: > Hello, > Bruce Lowekamp wrote: > > I don't think caching adds any complexities for authentication---if > > you're working in an open P2P system you're probably assuming you have > > an untrusted network to begin with and will be trying to validate any > > registration, regardless of whether it's cached or not. > 'validate' means for me in this context that the one who wants to > register really is the one that has on sign-up reserved that name. > > What I don't understand: If every node is admitted to publish or > update a record (which is true for a system that does caching), for > example my location record, how can identity theft be prevented? > > * if every node is admitted to change a value associated to a key then > anyone can steal the identity very easily > > * if every node is admitted to republish a pair (be it at > cache places or some original root of the key), regardless of whether > it is the original publisher of the pair, then an attacker could still > litter the overlay with corrupted values > > So I would see the requirement as follows: > The overlay MUST support binding a credential to a key, in order to > authenticate the original publisher of a pair in update > and remove operations. > > On the API level, for example starting from the definition in > draft-shim-sipping-p2p-arch-00 Section 9, I would add the credentials > directly as parameter to the functions add, update, and remove: > get(in overlay_id, in key, out records, out error) > add(in overlay_id, in key, in record, in lifetime, in option, > in credential, out error) > update(in overlay_id, in key, in record, in lifetime, in option, > in credential, out error) > remove(in overlay_id, in key, in credential, out error) > > As much as I like Kademlia, as I understand it at the moment without > modifications it does not support this. But I might very well have > overlooked something. > > Regards > Stefan > > > > > Bruce > > From henry at pulver.com Thu May 25 11:55:00 2006 From: henry at pulver.com (Henry Sinnreich) Date: Thu, 25 May 2006 10:55:00 -0500 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: Message-ID: <000c01c68013$946a82a0$2800a8c0@DSX400> > have some way of verifying the key when you first acquire it. Yes, this is exactly what ZRTP and the Zfone are doing. http://www.philzimmermann.com/EN/zfone/index.html Thanks, Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Bruce Lowekamp Sent: Thursday, May 25, 2006 10:43 AM To: Stefan Sayer Cc: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching I think one of the lessons from working on the use-cases draft is that there are a wide range of scenarios with differing levels of trust and authorities that make good scenarios for p2psip. What exactly we'll attempt to standardize will come out of the WG charter and requirements drafts. Personally, I'm a big fan of having a protocol that supports several identity authentication options, since I don't think there will be a single one-size-fits-all solution for the different use-cases. The scenario you propose is easily solvable if you allow for the existence of loosely-connected CAs and use the DHT to store certificates. I think there are ideas for how to do it in a more distributed manner, but I don't know that they are at the level of something we could write a standard for, whereas certificate chains are well-understood. There are other variations, though---if you don't have CAs, then everyone can generate and publish their own public keys. I couldn't prevent someone else from claiming to be lowekamp at cs.wm.edu, but they couldn't fake signing my messages with my key (they could confuse the situation because there would be multiple lowekamp at cs.wm.edu identities with different keys). What you have then is basically the same as the current pgp keyserver system, which works as long as you have some way of verifying the key when you first acquire it. Bruce On 5/24/06, Stefan Sayer wrote: > Hello, > Bruce Lowekamp wrote: > > I don't think caching adds any complexities for authentication---if > > you're working in an open P2P system you're probably assuming you have > > an untrusted network to begin with and will be trying to validate any > > registration, regardless of whether it's cached or not. > 'validate' means for me in this context that the one who wants to > register really is the one that has on sign-up reserved that name. > > What I don't understand: If every node is admitted to publish or > update a record (which is true for a system that does caching), for > example my location record, how can identity theft be prevented? > > * if every node is admitted to change a value associated to a key then > anyone can steal the identity very easily > > * if every node is admitted to republish a pair (be it at > cache places or some original root of the key), regardless of whether > it is the original publisher of the pair, then an attacker could still > litter the overlay with corrupted values > > So I would see the requirement as follows: > The overlay MUST support binding a credential to a key, in order to > authenticate the original publisher of a pair in update > and remove operations. > > On the API level, for example starting from the definition in > draft-shim-sipping-p2p-arch-00 Section 9, I would add the credentials > directly as parameter to the functions add, update, and remove: > get(in overlay_id, in key, out records, out error) > add(in overlay_id, in key, in record, in lifetime, in option, > in credential, out error) > update(in overlay_id, in key, in record, in lifetime, in option, > in credential, out error) > remove(in overlay_id, in key, in credential, out error) > > As much as I like Kademlia, as I understand it at the moment without > modifications it does not support this. But I might very well have > overlooked something. > > Regards > Stefan > > > > > Bruce > > _______________________________________________ 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 Thu May 25 12:04:02 2006 From: lowekamp at cs.wm.edu (Bruce Lowekamp) Date: Thu, 25 May 2006 12:04:02 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <000c01c68013$946a82a0$2800a8c0@DSX400> References: <000c01c68013$946a82a0$2800a8c0@DSX400> Message-ID: Henry, I haven't looked at ZRTP much, but doesn't he explicitly say he doesn't do this in the last FAQ at http://www.philzimmermann.com/EN/zfone/index-faq.html ? I'm not entirely sure I agree with this argument, BTW. I mean, he's right about the current PSTN security model, but I really think that a system that supports instant messaging needs a bit more---impersonation is much easier there. Bruce On 5/25/06, Henry Sinnreich wrote: > > have some way of verifying the key when you first acquire it. > > Yes, this is exactly what ZRTP and the Zfone are doing. > > http://www.philzimmermann.com/EN/zfone/index.html > > Thanks, Henry > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Bruce Lowekamp > Sent: Thursday, May 25, 2006 10:43 AM > To: Stefan Sayer > Cc: p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > I think one of the lessons from working on the use-cases draft is that > there are a wide range of scenarios with differing levels of trust and > authorities that make good scenarios for p2psip. What exactly we'll > attempt to standardize will come out of the WG charter and > requirements drafts. > > Personally, I'm a big fan of having a protocol that supports several > identity authentication options, since I don't think there will be a > single one-size-fits-all solution for the different use-cases. The > scenario you propose is easily solvable if you allow for the existence > of loosely-connected CAs and use the DHT to store certificates. I > think there are ideas for how to do it in a more distributed manner, > but I don't know that they are at the level of something we could > write a standard for, whereas certificate chains are well-understood. > > There are other variations, though---if you don't have CAs, then > everyone can generate and publish their own public keys. I couldn't > prevent someone else from claiming to be lowekamp at cs.wm.edu, but they > couldn't fake signing my messages with my key (they could confuse the > situation because there would be multiple lowekamp at cs.wm.edu > identities with different keys). What you have then is basically > the same as the current pgp keyserver system, which works as long as > you have some way of verifying the key when you first acquire it. > > Bruce > > > > > On 5/24/06, Stefan Sayer wrote: > > Hello, > > Bruce Lowekamp wrote: > > > I don't think caching adds any complexities for authentication---if > > > you're working in an open P2P system you're probably assuming you have > > > an untrusted network to begin with and will be trying to validate any > > > registration, regardless of whether it's cached or not. > > 'validate' means for me in this context that the one who wants to > > register really is the one that has on sign-up reserved that name. > > > > What I don't understand: If every node is admitted to publish or > > update a record (which is true for a system that does caching), for > > example my location record, how can identity theft be prevented? > > > > * if every node is admitted to change a value associated to a key then > > anyone can steal the identity very easily > > > > * if every node is admitted to republish a pair (be it at > > cache places or some original root of the key), regardless of whether > > it is the original publisher of the pair, then an attacker could still > > litter the overlay with corrupted values > > > > So I would see the requirement as follows: > > The overlay MUST support binding a credential to a key, in order to > > authenticate the original publisher of a pair in update > > and remove operations. > > > > On the API level, for example starting from the definition in > > draft-shim-sipping-p2p-arch-00 Section 9, I would add the credentials > > directly as parameter to the functions add, update, and remove: > > get(in overlay_id, in key, out records, out error) > > add(in overlay_id, in key, in record, in lifetime, in option, > > in credential, out error) > > update(in overlay_id, in key, in record, in lifetime, in option, > > in credential, out error) > > remove(in overlay_id, in key, in credential, out error) > > > > As much as I like Kademlia, as I understand it at the moment without > > modifications it does not support this. But I might very well have > > overlooked something. > > > > Regards > > Stefan > > > > > > > > Bruce > > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > From mike_robnson at yahoo.com Thu May 25 14:23:09 2006 From: mike_robnson at yahoo.com (Mike Robinson) Date: Thu, 25 May 2006 11:23:09 -0700 (PDT) Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <4474E7C8.9080106@research.panasonic.com> Message-ID: <20060525182309.13371.qmail@web38512.mail.mud.yahoo.com> Greg: I am a little confused as to what is you are suggesting. On one hand, you are accepting that you need time to understand differences of DHT algorithms behavior and we need time to study that, on the other you and your colleagues are saying there is need to chart an IETF group for design of p2p sip and push a pre-mature design through in a hurry. Both can't be true since they are contradictory in nature. P2p DHTs in general belong to the IRTF p2p group which already exists. Any comparative work on DHTs belongs there, and unless that group reaches some meaningful conclusions, proposing a p2p sip design, based on a particular versions of DHT, is simply harmful to the interests of every one except those who have vested interest to speedup adoption of their view of the world. No one is even sure if sip is the right protocol for DHT management except that someone thought so, or found it easier to code for whatever reason. My 2 cents. o Mike Greg Daley wrote: Hi Mike, Mike Robinson wrote: > > With all these mails on DHTs, it is obvious that there cannot be an > agreement on what DHT to use for any p2p protocol. As for in-house stuff > one is free to use any DHT algorithm, but to standardize a protocol on a > particular DHT by pushing through IETF process will be a grave mistake, > unless someone tells me that the final word on DHT has been spoken. > > I would rather see many approaches developed and code put on > sourceforge.net from people that are asking to standardize so that > interested persons can run the code and compare before any > standardization discussion gets done in this direction in any forum. > Once we have comparable code, it will be easy to form opinions on > various DHTs. The people that are pushing white papers from their > company labs should instead submit actual code, if they so believe in > the merit of their design proposal if any. > Henry's idea of requirements and assessment criteria is a really good one though, which necessarily predates that. Unless we know what we're designing for, it doesn't make sense to go ahead and cite (or implement) protocols. I'd much prefer to be comparing apples to apples. Greg --------------------------------- How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060525/de446445/attachment-0001.html From mike_robnson at yahoo.com Thu May 25 14:42:19 2006 From: mike_robnson at yahoo.com (Mike Robinson) Date: Thu, 25 May 2006 11:42:19 -0700 (PDT) Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <007101c6800e$6730d9b0$2800a8c0@DSX400> Message-ID: <20060525184219.94913.qmail@web38511.mail.mud.yahoo.com> Henry Sinnreich wrote: >What we have to remember is that the main goal at the moment is to get a >working group chartered Yes, and can everybody on the list please remember this one and only one goal at this point in time? And by the way, whose "goal" are we talking here? Unless someone can tell us clearly why sip should be used to create, manage and re-configure DHT, the goal should remain a "proposed goal" till then. IETF, or for that matter any standard organization should't be a willing tool to fulfil any particular company's vested interests (even when supposedly supported by (a company funded) researchers at a University). I am not opposed to p2p sip in whatever form - but don't understand the urgency being shown to push a certain design without evaluating alternative approaches. You don't need standardization right away to show that your model works- post your code to sourceforge.net and let me see how good your design is by experimenting with it. o Mike Henry Sinnreich wrote: >What we have to remember is that the main goal at the moment is to get a >working group chartered Yes, and can everybody on the list please remember this one and only one goal at this point in time? Thanks, Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley Sent: Thursday, May 25, 2006 6:28 AM To: Brian Rosen Cc: p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan' Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching Hi Brian, I do think that we are ready to start gathering the requirements and some people are working on that now. What we have to remember is that the main goal at the moment is to get a working group chartered, rather than a DHT chosen though (let's see if we can be productive and get some firm requirements without adding confusion to the charter discussion). Discussion on list seems a good way to start gathering requirements, but there are others which will turn up through systematic appraisal too. Greg Brian Rosen wrote: > But then the question is: > > Can we, at this point in time, create a meaningful requirement/assessment > document? > > One way to figure that out is to just propose a requirement, right here on > the list. If we get a bunch, and we see some consensus on direction, > perhaps we could make progress. > > That would be nice. > > Anyone got a requirement to share? > > Brian > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley > Sent: Wednesday, May 24, 2006 7:10 PM > To: Mike Robinson > Cc: p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan' > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > > Hi Mike, > > Mike Robinson wrote: >> With all these mails on DHTs, it is obvious that there cannot be an >> agreement on what DHT to use for any p2p protocol. As for in-house stuff >> one is free to use any DHT algorithm, but to standardize a protocol on a >> particular DHT by pushing through IETF process will be a grave mistake, >> unless someone tells me that the final word on DHT has been spoken. >> >> I would rather see many approaches developed and code put on >> sourceforge.net from people that are asking to standardize so that >> interested persons can run the code and compare before any >> standardization discussion gets done in this direction in any forum. >> Once we have comparable code, it will be easy to form opinions on >> various DHTs. The people that are pushing white papers from their >> company labs should instead submit actual code, if they so believe in >> the merit of their design proposal if any. >> > > Henry's idea of requirements and assessment criteria is a really > good one though, which necessarily predates that. > > Unless we know what we're designing for, it doesn't make sense > to go ahead and cite (or implement) protocols. I'd much prefer > to be comparing apples to apples. > > Greg > _______________________________________________ > 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 --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060525/795568c6/attachment.html From alan at sipstation.com Thu May 25 14:54:39 2006 From: alan at sipstation.com (Alan Johnston) Date: Thu, 25 May 2006 13:54:39 -0500 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: References: <000c01c68013$946a82a0$2800a8c0@DSX400> Message-ID: <4475FD6F.9020008@sipstation.com> Bruce, I think Henry's point was that ZRTP provides confidentiality and authentication services without certificates or a PKI. In simple terms, it uses key continuity similar to (but not the same as) SSH across subsequent media sessions between two endpoints. This type of architecture could be a useful for P2P SIP. Thanks, Alan Bruce Lowekamp wrote: >Henry, > >I haven't looked at ZRTP much, but doesn't he explicitly say he >doesn't do this in the last FAQ at >http://www.philzimmermann.com/EN/zfone/index-faq.html >? > >I'm not entirely sure I agree with this argument, BTW. I mean, he's >right about the current PSTN security model, but I really think that a >system that supports instant messaging needs a bit >more---impersonation is much easier there. > >Bruce > > >On 5/25/06, Henry Sinnreich wrote: > > >>>have some way of verifying the key when you first acquire it. >>> >>> >>Yes, this is exactly what ZRTP and the Zfone are doing. >> >>http://www.philzimmermann.com/EN/zfone/index.html >> >>Thanks, Henry >> >>-----Original Message----- >>From: p2p-sip-bounces at cs.columbia.edu >>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Bruce Lowekamp >>Sent: Thursday, May 25, 2006 10:43 AM >>To: Stefan Sayer >>Cc: p2p-sip at cs.columbia.edu >>Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching >> >>I think one of the lessons from working on the use-cases draft is that >>there are a wide range of scenarios with differing levels of trust and >>authorities that make good scenarios for p2psip. What exactly we'll >>attempt to standardize will come out of the WG charter and >>requirements drafts. >> >>Personally, I'm a big fan of having a protocol that supports several >>identity authentication options, since I don't think there will be a >>single one-size-fits-all solution for the different use-cases. The >>scenario you propose is easily solvable if you allow for the existence >>of loosely-connected CAs and use the DHT to store certificates. I >>think there are ideas for how to do it in a more distributed manner, >>but I don't know that they are at the level of something we could >>write a standard for, whereas certificate chains are well-understood. >> >>There are other variations, though---if you don't have CAs, then >>everyone can generate and publish their own public keys. I couldn't >>prevent someone else from claiming to be lowekamp at cs.wm.edu, but they >>couldn't fake signing my messages with my key (they could confuse the >>situation because there would be multiple lowekamp at cs.wm.edu >>identities with different keys). What you have then is basically >>the same as the current pgp keyserver system, which works as long as >>you have some way of verifying the key when you first acquire it. >> >>Bruce >> >> >> >> >>On 5/24/06, Stefan Sayer wrote: >> >> >>>Hello, >>>Bruce Lowekamp wrote: >>> >>> >>>>I don't think caching adds any complexities for authentication---if >>>>you're working in an open P2P system you're probably assuming you have >>>>an untrusted network to begin with and will be trying to validate any >>>>registration, regardless of whether it's cached or not. >>>> >>>> >>>'validate' means for me in this context that the one who wants to >>>register really is the one that has on sign-up reserved that name. >>> >>>What I don't understand: If every node is admitted to publish or >>>update a record (which is true for a system that does caching), for >>>example my location record, how can identity theft be prevented? >>> >>>* if every node is admitted to change a value associated to a key then >>>anyone can steal the identity very easily >>> >>>* if every node is admitted to republish a pair (be it at >>>cache places or some original root of the key), regardless of whether >>>it is the original publisher of the pair, then an attacker could still >>>litter the overlay with corrupted values >>> >>>So I would see the requirement as follows: >>> The overlay MUST support binding a credential to a key, in order to >>> authenticate the original publisher of a pair in update >>> and remove operations. >>> >>>On the API level, for example starting from the definition in >>>draft-shim-sipping-p2p-arch-00 Section 9, I would add the credentials >>>directly as parameter to the functions add, update, and remove: >>>get(in overlay_id, in key, out records, out error) >>>add(in overlay_id, in key, in record, in lifetime, in option, >>> in credential, out error) >>>update(in overlay_id, in key, in record, in lifetime, in option, >>> in credential, out error) >>>remove(in overlay_id, in key, in credential, out error) >>> >>>As much as I like Kademlia, as I understand it at the moment without >>>modifications it does not support this. But I might very well have >>>overlooked something. >>> >>>Regards >>>Stefan >>> >>> >>> >>>>Bruce >>>> >>>> >>> >>> >>_______________________________________________ >>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 slavitch at gmail.com Thu May 25 15:34:10 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Thu, 25 May 2006 15:34:10 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <4475FD6F.9020008@sipstation.com> References: <000c01c68013$946a82a0$2800a8c0@DSX400> <4475FD6F.9020008@sipstation.com> Message-ID: <1fc32c8f0605251234u93b5865id214434e835251e@mail.gmail.com> It does exactly that. It replaces certs with humans, which are more trustworthy. If P2P can also mean H2H (Human to Human) there is nothing stopping this approach from being valid. We have to step back sometimes and remember that humans are part of the equation, we underestimate ourselves. M On 5/25/06, Alan Johnston wrote: > > Bruce, > > I think Henry's point was that ZRTP provides confidentiality and > authentication services without certificates or a PKI. > > In simple terms, it uses key continuity similar to (but not the same as) > SSH across subsequent media sessions between two endpoints. > > This type of architecture could be a useful for P2P SIP. > > Thanks, > Alan > > Bruce Lowekamp wrote: > > >Henry, > > > >I haven't looked at ZRTP much, but doesn't he explicitly say he > >doesn't do this in the last FAQ at > >http://www.philzimmermann.com/EN/zfone/index-faq.html > >? > > > >I'm not entirely sure I agree with this argument, BTW. I mean, he's > >right about the current PSTN security model, but I really think that a > >system that supports instant messaging needs a bit > >more---impersonation is much easier there. > > > >Bruce > > > > > >On 5/25/06, Henry Sinnreich wrote: > > > > > >>>have some way of verifying the key when you first acquire it. > >>> > >>> > >>Yes, this is exactly what ZRTP and the Zfone are doing. > >> > >>http://www.philzimmermann.com/EN/zfone/index.html > >> > >>Thanks, Henry > >> > >>-----Original Message----- > >>From: p2p-sip-bounces at cs.columbia.edu > >>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Bruce Lowekamp > >>Sent: Thursday, May 25, 2006 10:43 AM > >>To: Stefan Sayer > >>Cc: p2p-sip at cs.columbia.edu > >>Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > >> > >>I think one of the lessons from working on the use-cases draft is that > >>there are a wide range of scenarios with differing levels of trust and > >>authorities that make good scenarios for p2psip. What exactly we'll > >>attempt to standardize will come out of the WG charter and > >>requirements drafts. > >> > >>Personally, I'm a big fan of having a protocol that supports several > >>identity authentication options, since I don't think there will be a > >>single one-size-fits-all solution for the different use-cases. The > >>scenario you propose is easily solvable if you allow for the existence > >>of loosely-connected CAs and use the DHT to store certificates. I > >>think there are ideas for how to do it in a more distributed manner, > >>but I don't know that they are at the level of something we could > >>write a standard for, whereas certificate chains are well-understood. > >> > >>There are other variations, though---if you don't have CAs, then > >>everyone can generate and publish their own public keys. I couldn't > >>prevent someone else from claiming to be lowekamp at cs.wm.edu, but they > >>couldn't fake signing my messages with my key (they could confuse the > >>situation because there would be multiple lowekamp at cs.wm.edu > >>identities with different keys). What you have then is basically > >>the same as the current pgp keyserver system, which works as long as > >>you have some way of verifying the key when you first acquire it. > >> > >>Bruce > >> > >> > >> > >> > >>On 5/24/06, Stefan Sayer wrote: > >> > >> > >>>Hello, > >>>Bruce Lowekamp wrote: > >>> > >>> > >>>>I don't think caching adds any complexities for authentication---if > >>>>you're working in an open P2P system you're probably assuming you have > >>>>an untrusted network to begin with and will be trying to validate any > >>>>registration, regardless of whether it's cached or not. > >>>> > >>>> > >>>'validate' means for me in this context that the one who wants to > >>>register really is the one that has on sign-up reserved that name. > >>> > >>>What I don't understand: If every node is admitted to publish or > >>>update a record (which is true for a system that does caching), for > >>>example my location record, how can identity theft be prevented? > >>> > >>>* if every node is admitted to change a value associated to a key then > >>>anyone can steal the identity very easily > >>> > >>>* if every node is admitted to republish a pair (be it at > >>>cache places or some original root of the key), regardless of whether > >>>it is the original publisher of the pair, then an attacker could still > >>>litter the overlay with corrupted values > >>> > >>>So I would see the requirement as follows: > >>> The overlay MUST support binding a credential to a key, in order to > >>> authenticate the original publisher of a pair in update > >>> and remove operations. > >>> > >>>On the API level, for example starting from the definition in > >>>draft-shim-sipping-p2p-arch-00 Section 9, I would add the credentials > >>>directly as parameter to the functions add, update, and remove: > >>>get(in overlay_id, in key, out records, out error) > >>>add(in overlay_id, in key, in record, in lifetime, in option, > >>> in credential, out error) > >>>update(in overlay_id, in key, in record, in lifetime, in option, > >>> in credential, out error) > >>>remove(in overlay_id, in key, in credential, out error) > >>> > >>>As much as I like Kademlia, as I understand it at the moment without > >>>modifications it does not support this. But I might very well have > >>>overlooked something. > >>> > >>>Regards > >>>Stefan > >>> > >>> > >>> > >>>>Bruce > >>>> > >>>> > >>> > >>> > >>_______________________________________________ > >>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 > -- Michael Slavitch Ottawa, Ontario Canada "Yet another P2PSIP Henchman" -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060525/62e78ea3/attachment-0001.html From henry at pulver.com Thu May 25 15:37:23 2006 From: henry at pulver.com (Henry Sinnreich) Date: Thu, 25 May 2006 14:37:23 -0500 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <20060525184219.94913.qmail@web38511.mail.mud.yahoo.com> Message-ID: <008401c68032$a6af1510$2800a8c0@DSX400> Mike, There seems to be some confusion here: >Unless someone can tell us clearly why sip should be used to create, manage >and re-configure DHT, This was not meant at all. Actually, several recent I-Ds propose SIP to use an external or separate DHT instead of the location database and/or DNS as are used by SIP proxies in the CS model. Please see: http://www.ietf.org/internet-drafts/draft-johnston-sipping-p2p-ipcom-02.txt The authors would appreciate comments on this I-D :-) The _Location Service Protocol_ is proposed there to link SIP to an unspecified DHT. Actually, using the openDHT would be a practical start IMHO: http://opendht.org/ Thanks, Henry ________________________________________ From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Mike Robinson Sent: Thursday, May 25, 2006 1:42 PM To: henry at pulver.com; 'Greg Daley'; 'Brian Rosen' Cc: p2p-sip at cs.columbia.edu; 'David A. Bryan' Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching Henry Sinnreich wrote: >What we have to remember is that the main goal at the moment is to get a >working group chartered Yes, and can everybody on the list please remember this one and only one goal at this point in time? And by the way,? whose "goal" are we talking here? Unless someone can tell us clearly why sip should be used to create, manage and re-configure DHT, the goal should remain a "proposed goal" till then. IETF, or for that matter any standard organization should't be a willing tool to fulfil any particular company's vested interests (even when supposedly supported by? (a company? funded) researchers at a University). I am not opposed to p2p sip in whatever form - but don't understand the urgency being shown to push a certain design without evaluating alternative approaches. You don't? need standardization right away to show that your model works- post your code to sourceforge.net and let me see how good your design is by experimenting with it. o Mike Henry Sinnreich wrote: >What we have to remember is that the main goal at the moment is to get a >working group chartered Yes, and can everybody on the list please remember this one and only one goal at this point in time? Thanks, Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley Sent: Thursday, May 25, 2006 6:28 AM To: Brian Rosen Cc: p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan' Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching Hi Brian, I do think that we are ready to start gathering the requirements and some people are working on that now. What we have to remember is that the main goal at the moment is to get a working group chartered, rather than a DHT chosen though (let's see if we can be productive and get some firm requirements without adding confusion to the charter discussion). Discussion on list seems a good way to start gathering requirements, but there are others which will turn up through systematic appraisal too. Greg Brian Rosen wrote: > But then the question is: > > Can we, at this point in time, create a meaningful requirement/assessment > document? > > One way to figure that out is to just propose a requirement, right here on > the list. If we get a bunch, and we see some consensus on direction, > perhaps we could make progress. > > That would be nice. > > Anyone got a requirement to share? > > Brian > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley > Sent: Wednesday, May 24, 2006 7:10 PM > To: Mike Robinson > Cc: p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan' > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > > Hi Mike, > > Mike Robinson wrote: >> With all these mails on DHTs, it is obvious that there cannot be an >> agreement on what DHT to use for any p2p protocol. As for in-house stuff >> one is free to use any DHT algorithm, but to standardize a protocol on a >> particular DHT by pushing through IETF process will be a grave mistake, >> unless someone tells me that the final word on DHT has been spoken. >> >> I would rather see many approaches developed and code put on >> sourceforge.net from people that are asking to standardize so that >> interested persons can run the code and compare before any >> standardization discussion gets done in this direction in any forum. >> Once we have comparable code, it will be easy to form opinions on >> various DHTs. The people that are pushing white papers from their >> company labs should instead submit actual code, if they so believe in >> the merit of their design proposal if any. >> > > Henry's idea of requirements and assessment criteria is a really > good one though, which necessarily predates that. > > Unless we know what we're designing for, it doesn't make sense > to go ahead and cite (or implement) protocols. I'd much prefer > to be comparing apples to apples. > > Greg > _______________________________________________ > 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 ________________________________________ New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. From bk9001 at gmail.com Thu May 25 15:41:34 2006 From: bk9001 at gmail.com (Brijesh Kumar) Date: Thu, 25 May 2006 15:41:34 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching References: <4473A260.7040007@cs.tu-berlin.de> <4474F777.1070300@cs.tu-berlin.de> <44759F8A.2040009@informatik.uni-tuebingen.de> Message-ID: <019b01c68033$3c9df4b0$110aa8c0@Shikky> ----- Original Message ----- From: "Heiko Niedermayer" > commenting on all the mails on DHts. Well, I assume that the choice of > DHT is of minor importance and that any DHT will at least do after > adapting it to P2PSIP. But, why not build a specialized p2p network for > P2PSIP. SIP is not a pure hash table service, so why transform a SIP > network to a hash table? Good question that is very hard to answer except to say that this is the easiest thing to do, and code. Well, hopefully someone will comeout with more cogent answer. > However, the big problem I see is that there is no convincing solution > to provide security. Say, if I want to communicate with Nokia I might > end up at Ericsson, that is fatal. And moreover, I do not want my > personal data and behaviour be manged and tracked by peers I can and do > not trust. As you know, p2p application security without a confederated security framework is not possible. You need to trust someone to be able to get in - the question is who will issue credentials, for a large network, who is willing to accept those credentials. > So, the general question is if there is a way to secure P2PSIP and to > provide privacy. In an open environment this is probably not possible. A > closed P2PSIP network is no real value-add from my point-of-view. With > respect to credentials, I assume that credentials are fine if the > network is a closed infrastructure network and clients are not part of > the network. Very valid observation .. cheers, --bk > Stefan Sayer wrote: >> Hello, >> Bruce Lowekamp wrote: >> >>> I don't think caching adds any complexities for authentication---if >>> you're working in an open P2P system you're probably assuming you have >>> an untrusted network to begin with and will be trying to validate any >>> registration, regardless of whether it's cached or not. >>> >> 'validate' means for me in this context that the one who wants to >> register really is the one that has on sign-up reserved that name. >> >> What I don't understand: If every node is admitted to publish or >> update a record (which is true for a system that does caching), for >> example my location record, how can identity theft be prevented? >> >> * if every node is admitted to change a value associated to a key then >> anyone can steal the identity very easily >> >> * if every node is admitted to republish a pair (be it at >> cache places or some original root of the key), regardless of whether >> it is the original publisher of the pair, then an attacker could still >> litter the overlay with corrupted values >> >> So I would see the requirement as follows: >> The overlay MUST support binding a credential to a key, in order to >> authenticate the original publisher of a pair in update >> and remove operations. >> >> On the API level, for example starting from the definition in >> draft-shim-sipping-p2p-arch-00 Section 9, I would add the credentials >> directly as parameter to the functions add, update, and remove: >> get(in overlay_id, in key, out records, out error) >> add(in overlay_id, in key, in record, in lifetime, in option, >> in credential, out error) >> update(in overlay_id, in key, in record, in lifetime, in option, >> in credential, out error) >> remove(in overlay_id, in key, in credential, out error) >> >> As much as I like Kademlia, as I understand it at the moment without >> modifications it does not support this. But I might very well have >> overlooked something. >> >> Regards >> Stefan >> >> >>> Bruce >>> >> >> _______________________________________________ >> 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 gregd at research.panasonic.com Thu May 25 15:50:27 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Thu, 25 May 2006 15:50:27 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <01e701c67ffa$457561b0$640fa8c0@cis.neustar.com> References: <01e701c67ffa$457561b0$640fa8c0@cis.neustar.com> Message-ID: <44760A83.7030708@research.panasonic.com> Hi Brian, I've tried to answer your questions based on my opinion only. Certainly I don't want people to read anything into my statements about an implied direction of the group ;) Brian Rosen wrote: > From what I can gather, one of the big sticky issues associated with a > charter is whether there is sufficient grounds to achieve consensus. > If the big picture on requirements was established, that is prima fascia > evidence that there is some consensus on how to go forward. This is sufficient, but not necessary. (It would do the job, but so long as we have agreement on the scope of work, rather than the minutiae, there's no impediment to forming a WG). > So, I think requirements discussions, now, before there is a charter, is a > good idea. Seems like you agree, so let's have some on the table. If there > are groups working on some, get a draft published, and let's look at them. Let's not get bogged down now though. If we identify an issue which isn't going to be resolved, let's flag it for work when the group is being chartered. > Let's start with DHTs: > 1. Do we have consensus that P2PSIP, as would be defined by this group, is > DHT based? my opinions only: We should probably aim at identifying a set of requirements, based on what we want rather than worrying about a technology. I guess my take on it is that we know DHTs are likely to work. Probably we should write a protocol which uses one DHT, as the default incarnation (for interoperability), hopefully with enough room to incorporate alternative technologies which also meet the requirements. > 2. Is there a requirement for support of multiple DHTs? What would be the > requirements a DHT needed to have in order to be acceptable? I guess this is two questions. 2.a) I think that we can design the protocol to be expanded to other P2P structures or alternative DHTs if this doesn't compromise the requirements. Since we know this is a possible upgrade path, we can keep it in mind when building the protocol. A caveat would be that IMO we can't break the base protocol, for a future need which may change or not eventuate, though. 2.b) I guess that in internet terms, there will be network protection (rate-limiting, no multiplicative attacks, etc) as well as data protection (message integrity, potentially secured transport), and robustness (bootstrap, fallback, authentication) requirements. There will also be structural requirements, such as what infrastructure is assumed to be part of the network (such as authentication services, bootstrap servers, etc). Some of these things need high-level/architectural agreement before we definitively mark them as requirements. I hope this is helpful, Greg From lowekamp at cs.wm.edu Thu May 25 15:31:09 2006 From: lowekamp at cs.wm.edu (Bruce Lowekamp) Date: Thu, 25 May 2006 15:31:09 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <4475FD6F.9020008@sipstation.com> References: <000c01c68013$946a82a0$2800a8c0@DSX400> <4475FD6F.9020008@sipstation.com> Message-ID: Alan, Oh, I absolutely didn't mean to imply it wouldn't be useful. I think it's very useful. Key continuity is clearly useful, and the voice-based SAS may well be the best option available for (voice) p2p sip. I was only observing that there are limitations to this approach in terms of establishing initial identity and in terms of non-voice or automatic systems that a CA system doesn't have. (I'm basing this on my reading of Zimmerman's FAQ and a quick read through the draft.) I think this is another example of it being useful to support different authentication systems for p2p sip because different environments will have different needs. Bruce On 5/25/06, Alan Johnston wrote: > Bruce, > > I think Henry's point was that ZRTP provides confidentiality and > authentication services without certificates or a PKI. > > In simple terms, it uses key continuity similar to (but not the same as) > SSH across subsequent media sessions between two endpoints. > > This type of architecture could be a useful for P2P SIP. > > Thanks, > Alan > > Bruce Lowekamp wrote: > > >Henry, > > > >I haven't looked at ZRTP much, but doesn't he explicitly say he > >doesn't do this in the last FAQ at > >http://www.philzimmermann.com/EN/zfone/index-faq.html > >? > > > >I'm not entirely sure I agree with this argument, BTW. I mean, he's > >right about the current PSTN security model, but I really think that a > >system that supports instant messaging needs a bit > >more---impersonation is much easier there. > > > >Bruce > > > > > >On 5/25/06, Henry Sinnreich wrote: > > > > > >>>have some way of verifying the key when you first acquire it. > >>> > >>> > >>Yes, this is exactly what ZRTP and the Zfone are doing. > >> > >>http://www.philzimmermann.com/EN/zfone/index.html > >> > >>Thanks, Henry > >> > >>-----Original Message----- > >>From: p2p-sip-bounces at cs.columbia.edu > >>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Bruce Lowekamp > >>Sent: Thursday, May 25, 2006 10:43 AM > >>To: Stefan Sayer > >>Cc: p2p-sip at cs.columbia.edu > >>Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > >> > >>I think one of the lessons from working on the use-cases draft is that > >>there are a wide range of scenarios with differing levels of trust and > >>authorities that make good scenarios for p2psip. What exactly we'll > >>attempt to standardize will come out of the WG charter and > >>requirements drafts. > >> > >>Personally, I'm a big fan of having a protocol that supports several > >>identity authentication options, since I don't think there will be a > >>single one-size-fits-all solution for the different use-cases. The > >>scenario you propose is easily solvable if you allow for the existence > >>of loosely-connected CAs and use the DHT to store certificates. I > >>think there are ideas for how to do it in a more distributed manner, > >>but I don't know that they are at the level of something we could > >>write a standard for, whereas certificate chains are well-understood. > >> > >>There are other variations, though---if you don't have CAs, then > >>everyone can generate and publish their own public keys. I couldn't > >>prevent someone else from claiming to be lowekamp at cs.wm.edu, but they > >>couldn't fake signing my messages with my key (they could confuse the > >>situation because there would be multiple lowekamp at cs.wm.edu > >>identities with different keys). What you have then is basically > >>the same as the current pgp keyserver system, which works as long as > >>you have some way of verifying the key when you first acquire it. > >> > >>Bruce > >> > >> > >> > >> > >>On 5/24/06, Stefan Sayer wrote: > >> > >> > >>>Hello, > >>>Bruce Lowekamp wrote: > >>> > >>> > >>>>I don't think caching adds any complexities for authentication---if > >>>>you're working in an open P2P system you're probably assuming you have > >>>>an untrusted network to begin with and will be trying to validate any > >>>>registration, regardless of whether it's cached or not. > >>>> > >>>> > >>>'validate' means for me in this context that the one who wants to > >>>register really is the one that has on sign-up reserved that name. > >>> > >>>What I don't understand: If every node is admitted to publish or > >>>update a record (which is true for a system that does caching), for > >>>example my location record, how can identity theft be prevented? > >>> > >>>* if every node is admitted to change a value associated to a key then > >>>anyone can steal the identity very easily > >>> > >>>* if every node is admitted to republish a pair (be it at > >>>cache places or some original root of the key), regardless of whether > >>>it is the original publisher of the pair, then an attacker could still > >>>litter the overlay with corrupted values > >>> > >>>So I would see the requirement as follows: > >>> The overlay MUST support binding a credential to a key, in order to > >>> authenticate the original publisher of a pair in update > >>> and remove operations. > >>> > >>>On the API level, for example starting from the definition in > >>>draft-shim-sipping-p2p-arch-00 Section 9, I would add the credentials > >>>directly as parameter to the functions add, update, and remove: > >>>get(in overlay_id, in key, out records, out error) > >>>add(in overlay_id, in key, in record, in lifetime, in option, > >>> in credential, out error) > >>>update(in overlay_id, in key, in record, in lifetime, in option, > >>> in credential, out error) > >>>remove(in overlay_id, in key, in credential, out error) > >>> > >>>As much as I like Kademlia, as I understand it at the moment without > >>>modifications it does not support this. But I might very well have > >>>overlooked something. > >>> > >>>Regards > >>>Stefan > >>> > >>> > >>> > >>>>Bruce > >>>> > >>>> > >>> > >>> > >>_______________________________________________ > >>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 gregd at research.panasonic.com Thu May 25 16:02:01 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Thu, 25 May 2006 16:02:01 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <20060525182309.13371.qmail@web38512.mail.mud.yahoo.com> References: <20060525182309.13371.qmail@web38512.mail.mud.yahoo.com> Message-ID: <44760D39.6080109@research.panasonic.com> Hi Mike. Chartering a WG is the first step to _begin_ work in the IETF. Stopping to talk about details doesn't help if there's no WG. it's as simple as that. Greg Comments below Mike Robinson wrote: > Greg: > > I am a little confused as to what is you are suggesting. > > On one hand, you are accepting that you need time to understand > differences of DHT algorithms behavior and we need time to study that, > on the other you and your colleagues are saying there is need to chart > an IETF group for design of p2p sip and push a pre-mature design through > in a hurry. Both can't be true since they are contradictory in nature. We don't have to have the complete protocol before we charter! A charter is an agreement on what work will be delivered. One of the items is an analysis of what needs to be put in the protocol! We know there are uncertainties and problems which will pop-up. The issue is whether the group will be unable to apply existing knowledge to the problem or not (research vs. engineering). I'm firmly on the side that protocol engineering is the bulk of the work. > P2p DHTs in general belong to the IRTF p2p group which already exists. > Any comparative work on DHTs belongs there, and unless that group > reaches some meaningful conclusions, proposing a p2p sip design, based > on a particular versions of DHT, is simply harmful to the interests of > every one except those who have vested interest to speedup adoption of > their view of the world. I think you're confusing different classes of applications. We have a small constrained goal: distributing location URIs without a single registration server. This is a small chunk out of a very wide body of work. As an example: Not every part of packet-switching theory was mature enough to standardize when IETF made the Internet. Some parts are still under development. The trick is to Engineer a useful constrained subset. This is standard operating procedure for the IETF. This isn't about a research project people want to standardize. It's being done in a proprietary way today. DHT based P2P location services are being done commercially. DHT based P2P location systems scale to _very_ large networks. Now is the time to stop the balkanization of these peer-to-peer services, and provide an open standard. > No one is even sure if sip is the right protocol for DHT management > except that someone thought so, or found it easier to code for whatever > reason. No one has designed the protocol. Dave's idea is a strawman. There's no explicit tie to SIP from the conceptual level. The details can be discussed when there's a WG. Greg From br at brianrosen.net Thu May 25 16:38:45 2006 From: br at brianrosen.net (Brian Rosen) Date: Thu, 25 May 2006 16:38:45 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <44760D39.6080109@research.panasonic.com> Message-ID: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> You seem to be making an assumption that there will be a charter, and the charter will be accepted, and it might have a requirements document as one of its charter items. My impression coming out of the BOF was that unless we demonstrated a lot more coalescing of ideas, what was on the table was not something the IESG could get their hands around, and therefore, while it was clear there was interest in doing "something" it wasn't clear what that "something" was. List discussion so far has not convinced me, and I suspect the IESG, that we have had much coalescing of ideas yet. An agreed upon requirements list, whether it was in a fully baked draft or just the big picture bullet list, would, it seem to me, go a long way towards illustrating to the IESG that there IS enough of a consensus on what to do that a WG could be chartered with the expectation that it would produce something of value. This thread is illustrating the issues. There is a suggestion that there is a requirement to have one mandatory-to-implement DHT. I'm not at all sure that is a realistic requirement, given the level of discourse so far, but I sure would like to be wrong about that. If we don't think we could agree on one, then we would need to agree on some other requirement, or we don't have any level of interoperability. If there is no level of agreement on something that fundamental, I'm pretty sure you can't get a charter that is accepted. Brian -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley Sent: Thursday, May 25, 2006 4:02 PM To: Mike Robinson Cc: p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan' Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching Hi Mike. Chartering a WG is the first step to _begin_ work in the IETF. Stopping to talk about details doesn't help if there's no WG. it's as simple as that. Greg Comments below Mike Robinson wrote: > Greg: > > I am a little confused as to what is you are suggesting. > > On one hand, you are accepting that you need time to understand > differences of DHT algorithms behavior and we need time to study that, > on the other you and your colleagues are saying there is need to chart > an IETF group for design of p2p sip and push a pre-mature design through > in a hurry. Both can't be true since they are contradictory in nature. We don't have to have the complete protocol before we charter! A charter is an agreement on what work will be delivered. One of the items is an analysis of what needs to be put in the protocol! We know there are uncertainties and problems which will pop-up. The issue is whether the group will be unable to apply existing knowledge to the problem or not (research vs. engineering). I'm firmly on the side that protocol engineering is the bulk of the work. > P2p DHTs in general belong to the IRTF p2p group which already exists. > Any comparative work on DHTs belongs there, and unless that group > reaches some meaningful conclusions, proposing a p2p sip design, based > on a particular versions of DHT, is simply harmful to the interests of > every one except those who have vested interest to speedup adoption of > their view of the world. I think you're confusing different classes of applications. We have a small constrained goal: distributing location URIs without a single registration server. This is a small chunk out of a very wide body of work. As an example: Not every part of packet-switching theory was mature enough to standardize when IETF made the Internet. Some parts are still under development. The trick is to Engineer a useful constrained subset. This is standard operating procedure for the IETF. This isn't about a research project people want to standardize. It's being done in a proprietary way today. DHT based P2P location services are being done commercially. DHT based P2P location systems scale to _very_ large networks. Now is the time to stop the balkanization of these peer-to-peer services, and provide an open standard. > No one is even sure if sip is the right protocol for DHT management > except that someone thought so, or found it easier to code for whatever > reason. No one has designed the protocol. Dave's idea is a strawman. There's no explicit tie to SIP from the conceptual level. The details can be discussed when there's a WG. Greg _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From gregd at research.panasonic.com Thu May 25 16:41:39 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Thu, 25 May 2006 16:41:39 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <20060525184219.94913.qmail@web38511.mail.mud.yahoo.com> References: <20060525184219.94913.qmail@web38511.mail.mud.yahoo.com> Message-ID: <44761683.8040702@research.panasonic.com> Hi Mike, Mike Robinson wrote: [cut] > Unless someone can tell us clearly why sip should be used to create, > manage and re-configure DHT, the goal should remain a "proposed goal" > till then. IETF, or for that matter any standard organization should't > be a willing tool to fulfil any particular company's vested interests > (even when supposedly supported by (a company funded) researchers at a > University). Only one of the (strawman) proposals says that SIP messages are used. Alternative view on this have also been presented in the Ad-hoc sessions leading up to the BoFs (and are still on the table). There's no clear winner, there's not even a coalition of people who have backed one. Of course authors will each have points to make about their own ideas, but that's why there's got to be a working group. So the community can work on the requirements and make sure that the best solution is used. If we didn't care about that, we'd just use/sell a proprietary system. > I am not opposed to p2p sip in whatever form - but don't understand the > urgency being shown to push a certain design without evaluating > alternative approaches. You don't need standardization right away to > show that your model works- post your code to sourceforge.net and let me > see how good your design is by experimenting with it. I think you've misread the situation. There is code for at least one implementation of a proposal available (is it on sourceforge?). AFAIK, there's no-one here pushing a particular cart. People here have a real desire to bring about the best system for p2p sip. There are people here willing to do the work on assessing the protocol requirements, reviewing documents, designing and building a protocol, following the IETF's procedures. If we just wanted to get something out commercially and push a particular agenda, we'd have made an industry consortium. It's a lot faster, it has more chance of success, and has less inconvenient review. Help us to charter the WG, because that's where the IETF can have control of the outputs, and ensure protocol quality. Greg From br at brianrosen.net Thu May 25 16:51:18 2006 From: br at brianrosen.net (Brian Rosen) Date: Thu, 25 May 2006 16:51:18 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <44761683.8040702@research.panasonic.com> Message-ID: <00d601c6803c$faaa0f80$640fa8c0@cis.neustar.com> Okay, so here we are again. You are looking for an approved charter, and we don't know what we are trying to do. If there is consensus that this is to be a p2psip thing, then that's a whole lot less work then if the sip part is still under discussion. I'd go so far as to say, if it's NOT p2psip, then we are really in IRTF land. So, what is it? p2psip or p2p-some-kind-of-multimedi-session-control-protocol? Brian -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley Sent: Thursday, May 25, 2006 4:42 PM To: Mike Robinson Cc: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching Hi Mike, Mike Robinson wrote: [cut] > Unless someone can tell us clearly why sip should be used to create, > manage and re-configure DHT, the goal should remain a "proposed goal" > till then. IETF, or for that matter any standard organization should't > be a willing tool to fulfil any particular company's vested interests > (even when supposedly supported by (a company funded) researchers at a > University). Only one of the (strawman) proposals says that SIP messages are used. Alternative view on this have also been presented in the Ad-hoc sessions leading up to the BoFs (and are still on the table). There's no clear winner, there's not even a coalition of people who have backed one. Of course authors will each have points to make about their own ideas, but that's why there's got to be a working group. So the community can work on the requirements and make sure that the best solution is used. If we didn't care about that, we'd just use/sell a proprietary system. > I am not opposed to p2p sip in whatever form - but don't understand the > urgency being shown to push a certain design without evaluating > alternative approaches. You don't need standardization right away to > show that your model works- post your code to sourceforge.net and let me > see how good your design is by experimenting with it. I think you've misread the situation. There is code for at least one implementation of a proposal available (is it on sourceforge?). AFAIK, there's no-one here pushing a particular cart. People here have a real desire to bring about the best system for p2p sip. There are people here willing to do the work on assessing the protocol requirements, reviewing documents, designing and building a protocol, following the IETF's procedures. If we just wanted to get something out commercially and push a particular agenda, we'd have made an industry consortium. It's a lot faster, it has more chance of success, and has less inconvenient review. Help us to charter the WG, because that's where the IETF can have control of the outputs, and ensure protocol quality. Greg _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From gregd at research.panasonic.com Thu May 25 16:52:48 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Thu, 25 May 2006 16:52:48 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> Message-ID: <44761920.7030403@research.panasonic.com> Hi Brian, I agree with you that we need a solid charter, and that we need to discuss it well before going into the next BoF. I also know that the chairs and ADs, and a couple of others (not me) are putting a lot of work into the charter right now and have been doing so ever since Dallas. There's been radio silence as-yet on list, so the interested community hasn't been able to see what rat-holes they've delved and what progress they've made. Really, I think it's a good thing that discussion has started up on-list, and hopefully the chairs will be able to contribute something soon, which will allow us to debate it in good time, and develop our own consensus. Just my opinion. Greg Brian Rosen wrote: > You seem to be making an assumption that there will be a charter, and the > charter will be accepted, and it might have a requirements document as one > of its charter items. > > My impression coming out of the BOF was that unless we demonstrated a lot > more coalescing of ideas, what was on the table was not something the IESG > could get their hands around, and therefore, while it was clear there was > interest in doing "something" it wasn't clear what that "something" was. > > List discussion so far has not convinced me, and I suspect the IESG, that we > have had much coalescing of ideas yet. > > An agreed upon requirements list, whether it was in a fully baked draft or > just the big picture bullet list, would, it seem to me, go a long way > towards illustrating to the IESG that there IS enough of a consensus on what > to do that a WG could be chartered with the expectation that it would > produce something of value. > > This thread is illustrating the issues. There is a suggestion that there is > a requirement to have one mandatory-to-implement DHT. I'm not at all sure > that is a realistic requirement, given the level of discourse so far, but I > sure would like to be wrong about that. > > If we don't think we could agree on one, then we would need to agree on some > other requirement, or we don't have any level of interoperability. > > If there is no level of agreement on something that fundamental, I'm pretty > sure you can't get a charter that is accepted. > > Brian > > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley > Sent: Thursday, May 25, 2006 4:02 PM > To: Mike Robinson > Cc: p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan' > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > Hi Mike. > > Chartering a WG is the first step to _begin_ work in the IETF. > > Stopping to talk about details doesn't help if there's no WG. > > it's as simple as that. > > Greg > Comments below > > > Mike Robinson wrote: >> Greg: >> >> I am a little confused as to what is you are suggesting. >> >> On one hand, you are accepting that you need time to understand >> differences of DHT algorithms behavior and we need time to study that, >> on the other you and your colleagues are saying there is need to chart >> an IETF group for design of p2p sip and push a pre-mature design through >> in a hurry. Both can't be true since they are contradictory in nature. > > > We don't have to have the complete protocol before we charter! > > A charter is an agreement on what work will be delivered. > > One of the items is an analysis of what needs to be put in the protocol! > > We know there are uncertainties and problems which will pop-up. > > The issue is whether the group will be unable to apply existing > knowledge to the problem or not (research vs. engineering). > > I'm firmly on the side that protocol engineering is the bulk > of the work. > >> P2p DHTs in general belong to the IRTF p2p group which already exists. >> Any comparative work on DHTs belongs there, and unless that group >> reaches some meaningful conclusions, proposing a p2p sip design, based >> on a particular versions of DHT, is simply harmful to the interests of >> every one except those who have vested interest to speedup adoption of >> their view of the world. > > I think you're confusing different classes of applications. > We have a small constrained goal: distributing location URIs > without a single registration server. > > This is a small chunk out of a very wide body of work. > > As an example: > Not every part of packet-switching theory was mature enough to > standardize when IETF made the Internet. Some parts are still > under development. > > The trick is to Engineer a useful constrained subset. > > This is standard operating procedure for the IETF. > > This isn't about a research project people want to > standardize. It's being done in a proprietary way today. > > DHT based P2P location services are being done commercially. > DHT based P2P location systems scale to _very_ large networks. > > Now is the time to stop the balkanization of these > peer-to-peer services, and provide an open standard. > >> No one is even sure if sip is the right protocol for DHT management >> except that someone thought so, or found it easier to code for whatever >> reason. > > No one has designed the protocol. > Dave's idea is a strawman. There's no explicit tie to SIP from the > conceptual level. The details can be discussed when there's a WG. > > Greg > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From gregd at research.panasonic.com Thu May 25 16:59:04 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Thu, 25 May 2006 16:59:04 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <00d601c6803c$faaa0f80$640fa8c0@cis.neustar.com> References: <00d601c6803c$faaa0f80$640fa8c0@cis.neustar.com> Message-ID: <44761A98.2020303@research.panasonic.com> Hi Brian, There's a distinction between P2P FOR sip and P2P USING sip. P2P FOR sip is a system which handles distributed lookup of SIP location URIs, P2P USING sip is a realization of how to do P2P FOR sip, using SIP protocol (or SIP protocol-like) messages or extensions. There's broad agreement that we want P2P FOR sip (the goal), but not necessarily agreement that we need P2P USING sip. This is not surprising, because the charter discussion is about what we want to get done (P2P FOR sip), rather than on exactly how to do it (e.g. P2P USING sip). Clear now? Brian Rosen wrote: > Okay, so here we are again. You are looking for an approved charter, and we > don't know what we are trying to do. > > If there is consensus that this is to be a p2psip thing, then that's a whole > lot less work then if the sip part is still under discussion. > > I'd go so far as to say, if it's NOT p2psip, then we are really in IRTF > land. > > So, what is it? p2psip or > p2p-some-kind-of-multimedi-session-control-protocol? > > > > Brian > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley > Sent: Thursday, May 25, 2006 4:42 PM > To: Mike Robinson > Cc: p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > Hi Mike, > > Mike Robinson wrote: > [cut] >> Unless someone can tell us clearly why sip should be used to create, >> manage and re-configure DHT, the goal should remain a "proposed goal" >> till then. IETF, or for that matter any standard organization should't >> be a willing tool to fulfil any particular company's vested interests >> (even when supposedly supported by (a company funded) researchers at a >> University). > > Only one of the (strawman) proposals says that SIP messages are used. > Alternative view on this have also been presented in the Ad-hoc sessions > leading up to the BoFs (and are still on the table). > > There's no clear winner, there's not even a coalition of people who > have backed one. > > Of course authors will each have points to make about their own ideas, > but that's why there's got to be a working group. So the community > can work on the requirements and make sure that the best solution is > used. > > If we didn't care about that, we'd just use/sell a proprietary system. > >> I am not opposed to p2p sip in whatever form - but don't understand the >> urgency being shown to push a certain design without evaluating >> alternative approaches. You don't need standardization right away to >> show that your model works- post your code to sourceforge.net and let me >> see how good your design is by experimenting with it. > > I think you've misread the situation. There is code for at least > one implementation of a proposal available (is it on sourceforge?). > > AFAIK, there's no-one here pushing a particular cart. > > People here have a real desire to bring about the best system > for p2p sip. There are people here willing to do the work > on assessing the protocol requirements, reviewing documents, > designing and building a protocol, following the IETF's > procedures. > > If we just wanted to get something out commercially and push a > particular agenda, we'd have made an industry consortium. > > It's a lot faster, it has more chance of success, and has less > inconvenient review. > > Help us to charter the WG, because that's where the IETF can > have control of the outputs, and ensure protocol quality. > > Greg > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From br at brianrosen.net Thu May 25 17:15:51 2006 From: br at brianrosen.net (Brian Rosen) Date: Thu, 25 May 2006 17:15:51 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <44761A98.2020303@research.panasonic.com> Message-ID: <00e401c68040$6a4d4930$640fa8c0@cis.neustar.com> I'm sorry, I don't get it. No one is proposing to use sip to do something equivalent to what a DHT does. Everyone is proposing to use sip messages to control session establishment. A User Agent is going to send a pretty normal looking INVITE message. The question at hand is how it routes it. It doesn't use the procedures in 3261. I don't understand the difference. I think that means I don't understand what p2p using sip means. As long as we are all agreeing that its sip messages to do session management, at least I think we're in a do-able situation. Brian -----Original Message----- From: Greg Daley [mailto:gregd at research.panasonic.com] Sent: Thursday, May 25, 2006 4:59 PM To: Brian Rosen Cc: 'Mike Robinson'; p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching Hi Brian, There's a distinction between P2P FOR sip and P2P USING sip. P2P FOR sip is a system which handles distributed lookup of SIP location URIs, P2P USING sip is a realization of how to do P2P FOR sip, using SIP protocol (or SIP protocol-like) messages or extensions. There's broad agreement that we want P2P FOR sip (the goal), but not necessarily agreement that we need P2P USING sip. This is not surprising, because the charter discussion is about what we want to get done (P2P FOR sip), rather than on exactly how to do it (e.g. P2P USING sip). Clear now? Brian Rosen wrote: > Okay, so here we are again. You are looking for an approved charter, and we > don't know what we are trying to do. > > If there is consensus that this is to be a p2psip thing, then that's a whole > lot less work then if the sip part is still under discussion. > > I'd go so far as to say, if it's NOT p2psip, then we are really in IRTF > land. > > So, what is it? p2psip or > p2p-some-kind-of-multimedi-session-control-protocol? > > > > Brian > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley > Sent: Thursday, May 25, 2006 4:42 PM > To: Mike Robinson > Cc: p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > Hi Mike, > > Mike Robinson wrote: > [cut] >> Unless someone can tell us clearly why sip should be used to create, >> manage and re-configure DHT, the goal should remain a "proposed goal" >> till then. IETF, or for that matter any standard organization should't >> be a willing tool to fulfil any particular company's vested interests >> (even when supposedly supported by (a company funded) researchers at a >> University). > > Only one of the (strawman) proposals says that SIP messages are used. > Alternative view on this have also been presented in the Ad-hoc sessions > leading up to the BoFs (and are still on the table). > > There's no clear winner, there's not even a coalition of people who > have backed one. > > Of course authors will each have points to make about their own ideas, > but that's why there's got to be a working group. So the community > can work on the requirements and make sure that the best solution is > used. > > If we didn't care about that, we'd just use/sell a proprietary system. > >> I am not opposed to p2p sip in whatever form - but don't understand the >> urgency being shown to push a certain design without evaluating >> alternative approaches. You don't need standardization right away to >> show that your model works- post your code to sourceforge.net and let me >> see how good your design is by experimenting with it. > > I think you've misread the situation. There is code for at least > one implementation of a proposal available (is it on sourceforge?). > > AFAIK, there's no-one here pushing a particular cart. > > People here have a real desire to bring about the best system > for p2p sip. There are people here willing to do the work > on assessing the protocol requirements, reviewing documents, > designing and building a protocol, following the IETF's > procedures. > > If we just wanted to get something out commercially and push a > particular agenda, we'd have made an industry consortium. > > It's a lot faster, it has more chance of success, and has less > inconvenient review. > > Help us to charter the WG, because that's where the IETF can > have control of the outputs, and ensure protocol quality. > > Greg > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From gregd at research.panasonic.com Thu May 25 17:46:09 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Thu, 25 May 2006 17:46:09 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <00e401c68040$6a4d4930$640fa8c0@cis.neustar.com> References: <00e401c68040$6a4d4930$640fa8c0@cis.neustar.com> Message-ID: <447625A1.5030509@research.panasonic.com> Hi Brian, Brian Rosen wrote: > I'm sorry, I don't get it. I guess my cutting corners didn't help. I'll try to be more explicit and we'll see if there's a clearer picture emerges through discussion. > No one is proposing to use sip to do something equivalent to what a DHT > does. There has been some discussion of sending P2P storage mechanisms mapped onto existing REGISTER messages. This is one of the P2P USING sip ideas I was trying to touch on. Setting up communications for a peer-to-peer network using INVITEs etc, I agree are not proposed. > Everyone is proposing to use sip messages to control session establishment. Agreed. > A User Agent is going to send a pretty normal looking INVITE message. The > question at hand is how it routes it. It doesn't use the procedures in > 3261. Actually, I think that the primary mechanism being proposed is the location lookup service, similar to that provided by RFC 3263 (though focussed on resolving the specific URIs for a user, rather than the domain Proxy, if possible). This may alter how registration is done (possibly adds a routine to place the URI onto a DHT, for example). How the INVITE/session-management signalling is routed is another question. Although there's been some discussion that SIP INVITEs can be hop-by-hop routed across the DHT, that's not necessarily the prevailng view (personally I'm against it). INVITE is likely to go peer-to-peer directly (as the name implies) with modifications only for ICE, or some "peerish" additional parameters (again, I'd prefer none). The routing is compliant with RFC 3261, in that the message is routed to the address contained in the location URI. This address may be the UA's address though (so a P2P UA can talk to another UA without going through a Proxy, perhaps). Depending on the scenario, the address in the DHT (for example) may point to an address at a proxy, instead. In my guess the only reasons the SIP session management signalling wouldn't go direct would be for NAT traversal (SIP-Outbound/STUN Relay). Of course, these are opinions, but they may illustrate what I was thinking of for as the primary goal of P2P SIP: Just a lookup service. Try not to modify SIP for call-management messaging. > I don't understand the difference. I think that means I don't understand > what p2p using sip means. As long as we are all agreeing that its sip > messages to do session management, at least I think we're in a do-able > situation. Definitely we use SIP messages for session management. Personally, I'd prefer no modifications at all to those messages. Greg From bryan at ethernot.org Thu May 25 21:20:24 2006 From: bryan at ethernot.org (David A. Bryan) Date: Thu, 25 May 2006 21:20:24 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <012d01c67f88$c5bf82a0$640fa8c0@cis.neustar.com> References: <4474E7C8.9080106@research.panasonic.com> <012d01c67f88$c5bf82a0$640fa8c0@cis.neustar.com> Message-ID: <8b2769930605251820m65bde191h1035a9359277bb2b@mail.gmail.com> Sorry for the late response. There has been some work on this issue. In fact, there is a draft that generated a great deal of discussion. It came out back in October of 2005: http://www1.cs.columbia.edu/~salman/drafts/draft-baset-sipping-p2preq-00.txt Certainly wasn't complete, but I think most folks here agreed it was a good start in that direction. David On 5/24/06, Brian Rosen
wrote: > But then the question is: > > Can we, at this point in time, create a meaningful requirement/assessment > document? > > One way to figure that out is to just propose a requirement, right here on > the list. If we get a bunch, and we see some consensus on direction, > perhaps we could make progress. > > That would be nice. > > Anyone got a requirement to share? > > Brian > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley > Sent: Wednesday, May 24, 2006 7:10 PM > To: Mike Robinson > Cc: p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan' > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > > Hi Mike, > > Mike Robinson wrote: > > > > With all these mails on DHTs, it is obvious that there cannot be an > > agreement on what DHT to use for any p2p protocol. As for in-house stuff > > one is free to use any DHT algorithm, but to standardize a protocol on a > > particular DHT by pushing through IETF process will be a grave mistake, > > unless someone tells me that the final word on DHT has been spoken. > > > > I would rather see many approaches developed and code put on > > sourceforge.net from people that are asking to standardize so that > > interested persons can run the code and compare before any > > standardization discussion gets done in this direction in any forum. > > Once we have comparable code, it will be easy to form opinions on > > various DHTs. The people that are pushing white papers from their > > company labs should instead submit actual code, if they so believe in > > the merit of their design proposal if any. > > > > Henry's idea of requirements and assessment criteria is a really > good one though, which necessarily predates that. > > Unless we know what we're designing for, it doesn't make sense > to go ahead and cite (or implement) protocols. I'd much prefer > to be comparing apples to apples. > > Greg > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From bryan at ethernot.org Thu May 25 21:29:32 2006 From: bryan at ethernot.org (David A. Bryan) Date: Thu, 25 May 2006 21:29:32 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <00e401c68040$6a4d4930$640fa8c0@cis.neustar.com> References: <44761A98.2020303@research.panasonic.com> <00e401c68040$6a4d4930$640fa8c0@cis.neustar.com> Message-ID: <8b2769930605251829t42a246e4saed220406a5e21cd@mail.gmail.com> A bit more clarification. P2P over SIP means: "build a distributed lookup that SIP agents use to locate each other, and use SIP messages to convey the queries/organization for the distributed seach". The group would standardize the extensions to SIP to do this. P2P for SIP means: "build a distributed lookup that SIP agents use to locate each other, but it may use other message formats (I've heard SOAP proposed) to convey the queries/organization for the distributed search" The group would standardize that other protocol In both cases, the idea is regular SIP is used between the nodes. As Greg points out, some (including my early work) proposed routing SIP over the P2P layer as well. I backed off this a bit when many folks objected in Vancouver, although I must admit that for NAT traversal reasons, I'm liking it again. This is list of several hundred people. People have proposed building a generic multi-purpose DHT using SIP here, and people have proposed replacing SIP here. It has seemed quite clear from the responses that the majority of people do not agree with that, and that certainly those of us trying to organize P2PSIP do not support those things. --David On 5/25/06, Brian Rosen
wrote: > I'm sorry, I don't get it. > > No one is proposing to use sip to do something equivalent to what a DHT > does. > > Everyone is proposing to use sip messages to control session establishment. > > A User Agent is going to send a pretty normal looking INVITE message. The > question at hand is how it routes it. It doesn't use the procedures in > 3261. > > I don't understand the difference. I think that means I don't understand > what p2p using sip means. As long as we are all agreeing that its sip > messages to do session management, at least I think we're in a do-able > situation. > > Brian > > -----Original Message----- > From: Greg Daley [mailto:gregd at research.panasonic.com] > Sent: Thursday, May 25, 2006 4:59 PM > To: Brian Rosen > Cc: 'Mike Robinson'; p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > Hi Brian, > > There's a distinction between P2P FOR sip and > P2P USING sip. > > P2P FOR sip is a system which handles distributed > lookup of SIP location URIs, > > P2P USING sip is a realization of how to do P2P FOR sip, > using SIP protocol (or SIP protocol-like) messages or > extensions. > > There's broad agreement that we want P2P FOR sip > (the goal), but not necessarily agreement that > we need P2P USING sip. > > This is not surprising, because the charter discussion > is about what we want to get done (P2P FOR sip), > rather than on exactly how to do it (e.g. P2P USING sip). > > Clear now? > > > Brian Rosen wrote: > > Okay, so here we are again. You are looking for an approved charter, and > we > > don't know what we are trying to do. > > > > If there is consensus that this is to be a p2psip thing, then that's a > whole > > lot less work then if the sip part is still under discussion. > > > > I'd go so far as to say, if it's NOT p2psip, then we are really in IRTF > > land. > > > > So, what is it? p2psip or > > p2p-some-kind-of-multimedi-session-control-protocol? > > > > > > > > Brian > > > > -----Original Message----- > > From: p2p-sip-bounces at cs.columbia.edu > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley > > Sent: Thursday, May 25, 2006 4:42 PM > > To: Mike Robinson > > Cc: p2p-sip at cs.columbia.edu > > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > > > Hi Mike, > > > > Mike Robinson wrote: > > [cut] > >> Unless someone can tell us clearly why sip should be used to create, > >> manage and re-configure DHT, the goal should remain a "proposed goal" > >> till then. IETF, or for that matter any standard organization should't > >> be a willing tool to fulfil any particular company's vested interests > >> (even when supposedly supported by (a company funded) researchers at a > >> University). > > > > Only one of the (strawman) proposals says that SIP messages are used. > > Alternative view on this have also been presented in the Ad-hoc sessions > > leading up to the BoFs (and are still on the table). > > > > There's no clear winner, there's not even a coalition of people who > > have backed one. > > > > Of course authors will each have points to make about their own ideas, > > but that's why there's got to be a working group. So the community > > can work on the requirements and make sure that the best solution is > > used. > > > > If we didn't care about that, we'd just use/sell a proprietary system. > > > >> I am not opposed to p2p sip in whatever form - but don't understand the > >> urgency being shown to push a certain design without evaluating > >> alternative approaches. You don't need standardization right away to > >> show that your model works- post your code to sourceforge.net and let me > >> see how good your design is by experimenting with it. > > > > I think you've misread the situation. There is code for at least > > one implementation of a proposal available (is it on sourceforge?). > > > > AFAIK, there's no-one here pushing a particular cart. > > > > People here have a real desire to bring about the best system > > for p2p sip. There are people here willing to do the work > > on assessing the protocol requirements, reviewing documents, > > designing and building a protocol, following the IETF's > > procedures. > > > > If we just wanted to get something out commercially and push a > > particular agenda, we'd have made an industry consortium. > > > > It's a lot faster, it has more chance of success, and has less > > inconvenient review. > > > > Help us to charter the WG, because that's where the IETF can > > have control of the outputs, and ensure protocol quality. > > > > Greg > > _______________________________________________ > > 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 karstbj at yahoo.com Fri May 26 01:46:01 2006 From: karstbj at yahoo.com (Karst Bjorgson) Date: Thu, 25 May 2006 22:46:01 -0700 (PDT) Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <8b2769930605251829t42a246e4saed220406a5e21cd@mail.gmail.com> Message-ID: <20060526054601.75761.qmail@web53007.mail.yahoo.com> > This is list of several hundred people. People have > proposed building > a generic multi-purpose DHT using SIP here, and > people have proposed > replacing SIP here. It has seemed quite clear from > the responses that > the majority of people do not agree with that, and > that certainly > those of us trying to organize P2PSIP do not support > those things. Agree 100%. The goal is not to produce yet another DHT. The goal is to enable sessions between peers, using SIP messages to set-up these sessions. In fact, it seems that we have convergence on some kind of two-phase approach: 1) Location: Given a SIP URL, find the IP address to which SIP messages shall be sent; 2) Establishment: using SIP messages between the peers, establish sessions, etc. There are problems in both phases. In the location phase, there are obvious issues of security (how does Brian know he has located the real Henry), privacy (if my friends can locate me easily, what about my foes), and reliability (how do we protect against the Sybill attack). In the establishment phase, the obvious problem is NAT traversal. -- Karst __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From enrico.marocco at telecomitalia.it Fri May 26 06:22:23 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Fri, 26 May 2006 12:22:23 +0200 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <44761683.8040702@research.panasonic.com> References: <20060525184219.94913.qmail@web38511.mail.mud.yahoo.com> <44761683.8040702@research.panasonic.com> Message-ID: <4476D6DF.3060707@telecomitalia.it> Greg Daley wrote: >> I am not opposed to p2p sip in whatever form - but don't understand the >> urgency being shown to push a certain design without evaluating >> alternative approaches. You don't need standardization right away to >> show that your model works- post your code to sourceforge.net and let me >> see how good your design is by experimenting with it. > > I think you've misread the situation. There is code for at least > one implementation of a proposal available (is it on sourceforge?). (yes, it is) At this point both written and coded proposals are only meant to show that a solution is feasible. There is a lot of discussion about the algorithm and the protocol for DHT maintainance; hey... are they really important, now? If a WG were formed people would be happily struggling for chord/kademlia/bamboo over SIP/SOAP/RMI; until a WG is started, such arguements are only wasted time. > AFAIK, there's no-one here pushing a particular cart. There's no cart either; maybe someone's pushing a strawman, but not a cart ;-) Enrico From enrico.marocco at telecomitalia.it Fri May 26 06:27:26 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Fri, 26 May 2006 12:27:26 +0200 Subject: [p2p-sip] Solid Charter [WAS: Re: P2PSIP, Kademlia and caching] In-Reply-To: <44761920.7030403@research.panasonic.com> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> Message-ID: <4476D80E.7070100@telecomitalia.it> Greg Daley wrote: > I agree with you that we need a solid charter, and that > we need to discuss it well before going into the next > BoF. My opinion is that we still have a pretty good charter, which needs just small changes according to issues raised during the BOF. For facing concerns expressed by IAB and IESG members, we should clearly assert that: 1. P2PSIP is not a replacement for SIP. Instead its primary use is for extending SIP connectivity in environments where traditional SIP registrars/proxies cannot be practically deployed; 2. P2PSIP work will reuse existing IETF works (i.e. ICE for NAT traversal). The charter was contraddictory on this point, but broad consensus for fixing it was found during the BOF; 3. P2PSIP group will not do research work. The goal of distributing functionalities for lookup and NAT traversal will be achieved using existing and well-known algorithms. The ambiguity of the term "P2P" and the appeal of Skype-like solutions (which for many reasons _won't_ be standardized in IETF) may have obfuscated those key points, worring ADs and IAB members. IMHO the changes needed are not so drastic and the group would quickly agree on them. Enrico From henry at pulver.com Fri May 26 09:40:00 2006 From: henry at pulver.com (Henry Sinnreich) Date: Fri, 26 May 2006 08:40:00 -0500 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <8b2769930605251829t42a246e4saed220406a5e21cd@mail.gmail.com> Message-ID: <004601c680c9$e58d91c0$2800a8c0@DSX400> Maybe we should all talk using the same reference material, such as: http://opendht.org/pubs.html and then we can discuss the issues item by item, such as routing modes, response time, delay aware routing, partial search, etc. Last but not least open running code and experimental results. Clearly SIP has not been designed to address these issues and there is no reason to duplicate all this work. Any opinions on the technology at http://opendht.org/pubs.html ? Publications Related to OpenDHT Distributed Segment Tree: Support of Range Query and Cover Query over DHT. Changxi Zheng, Guobin Shen, Shipeng Li, and Scott Shenker. 5th International Workshop on Peer-to-Peer Systems (IPTPS 2006), February 2006. Fixing the Embarrassing Slowness of OpenDHT on PlanetLab. Sean Rhea, Byung-Gon Chun, John Kubiatowicz, and Scott Shenker. Proceedings of USENIX WORLDS 2005, December 2005. Non-Transitive Connectivity and DHTs. Michael J. Freedman, Karthik Lakshminarayanan, Sean Rhea, and Ion Stoica. Proceedings of USENIX WORLDS 2005, December 2005. OpenDHT: A Public DHT Service and Its Uses. Sean Rhea, Brighten Godfrey, Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, and Harlan Yu. Proceedings of ACM SIGCOMM 2005, August 2005. A Case Study in Building Layered DHT Applications. Yatin Chawathe, Sriram Ramabhadran, Sylvia Ratnasamy, Anthony LaMarca, Scott Shenker, and Joseph Hellerstein. Proceedings of ACM SIGCOMM 2005, August 2005. Spurring Adoption of DHTs with OpenHash, a Public DHT Service. Brad Karp, Sylvia Ratnasamy, Sean Rhea, and Scott Shenker. Proceedings of the 3rd International Workshop on Peer-to-Peer Systems (IPTPS 2004), Springer-Verlag Lecture Notes in Computer Science Hot Topics Series, San Diego, CA, February, 2004. (The OpenDHT project was originally titled "OpenHash".) Thanks, Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan Sent: Thursday, May 25, 2006 8:30 PM To: Brian Rosen Cc: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching A bit more clarification. P2P over SIP means: "build a distributed lookup that SIP agents use to locate each other, and use SIP messages to convey the queries/organization for the distributed seach". The group would standardize the extensions to SIP to do this. P2P for SIP means: "build a distributed lookup that SIP agents use to locate each other, but it may use other message formats (I've heard SOAP proposed) to convey the queries/organization for the distributed search" The group would standardize that other protocol In both cases, the idea is regular SIP is used between the nodes. As Greg points out, some (including my early work) proposed routing SIP over the P2P layer as well. I backed off this a bit when many folks objected in Vancouver, although I must admit that for NAT traversal reasons, I'm liking it again. This is list of several hundred people. People have proposed building a generic multi-purpose DHT using SIP here, and people have proposed replacing SIP here. It has seemed quite clear from the responses that the majority of people do not agree with that, and that certainly those of us trying to organize P2PSIP do not support those things. --David On 5/25/06, Brian Rosen
wrote: > I'm sorry, I don't get it. > > No one is proposing to use sip to do something equivalent to what a DHT > does. > > Everyone is proposing to use sip messages to control session establishment. > > A User Agent is going to send a pretty normal looking INVITE message. The > question at hand is how it routes it. It doesn't use the procedures in > 3261. > > I don't understand the difference. I think that means I don't understand > what p2p using sip means. As long as we are all agreeing that its sip > messages to do session management, at least I think we're in a do-able > situation. > > Brian > > -----Original Message----- > From: Greg Daley [mailto:gregd at research.panasonic.com] > Sent: Thursday, May 25, 2006 4:59 PM > To: Brian Rosen > Cc: 'Mike Robinson'; p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > Hi Brian, > > There's a distinction between P2P FOR sip and > P2P USING sip. > > P2P FOR sip is a system which handles distributed > lookup of SIP location URIs, > > P2P USING sip is a realization of how to do P2P FOR sip, > using SIP protocol (or SIP protocol-like) messages or > extensions. > > There's broad agreement that we want P2P FOR sip > (the goal), but not necessarily agreement that > we need P2P USING sip. > > This is not surprising, because the charter discussion > is about what we want to get done (P2P FOR sip), > rather than on exactly how to do it (e.g. P2P USING sip). > > Clear now? > > > Brian Rosen wrote: > > Okay, so here we are again. You are looking for an approved charter, and > we > > don't know what we are trying to do. > > > > If there is consensus that this is to be a p2psip thing, then that's a > whole > > lot less work then if the sip part is still under discussion. > > > > I'd go so far as to say, if it's NOT p2psip, then we are really in IRTF > > land. > > > > So, what is it? p2psip or > > p2p-some-kind-of-multimedi-session-control-protocol? > > > > > > > > Brian > > > > -----Original Message----- > > From: p2p-sip-bounces at cs.columbia.edu > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley > > Sent: Thursday, May 25, 2006 4:42 PM > > To: Mike Robinson > > Cc: p2p-sip at cs.columbia.edu > > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > > > Hi Mike, > > > > Mike Robinson wrote: > > [cut] > >> Unless someone can tell us clearly why sip should be used to create, > >> manage and re-configure DHT, the goal should remain a "proposed goal" > >> till then. IETF, or for that matter any standard organization should't > >> be a willing tool to fulfil any particular company's vested interests > >> (even when supposedly supported by (a company funded) researchers at a > >> University). > > > > Only one of the (strawman) proposals says that SIP messages are used. > > Alternative view on this have also been presented in the Ad-hoc sessions > > leading up to the BoFs (and are still on the table). > > > > There's no clear winner, there's not even a coalition of people who > > have backed one. > > > > Of course authors will each have points to make about their own ideas, > > but that's why there's got to be a working group. So the community > > can work on the requirements and make sure that the best solution is > > used. > > > > If we didn't care about that, we'd just use/sell a proprietary system. > > > >> I am not opposed to p2p sip in whatever form - but don't understand the > >> urgency being shown to push a certain design without evaluating > >> alternative approaches. You don't need standardization right away to > >> show that your model works- post your code to sourceforge.net and let me > >> see how good your design is by experimenting with it. > > > > I think you've misread the situation. There is code for at least > > one implementation of a proposal available (is it on sourceforge?). > > > > AFAIK, there's no-one here pushing a particular cart. > > > > People here have a real desire to bring about the best system > > for p2p sip. There are people here willing to do the work > > on assessing the protocol requirements, reviewing documents, > > designing and building a protocol, following the IETF's > > procedures. > > > > If we just wanted to get something out commercially and push a > > particular agenda, we'd have made an industry consortium. > > > > It's a lot faster, it has more chance of success, and has less > > inconvenient review. > > > > Help us to charter the WG, because that's where the IETF can > > have control of the outputs, and ensure protocol quality. > > > > Greg > > _______________________________________________ > > 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 bryan at ethernot.org Fri May 26 11:50:58 2006 From: bryan at ethernot.org (David A. Bryan) Date: Fri, 26 May 2006 11:50:58 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <004601c680c9$e58d91c0$2800a8c0@DSX400> References: <8b2769930605251829t42a246e4saed220406a5e21cd@mail.gmail.com> <004601c680c9$e58d91c0$2800a8c0@DSX400> Message-ID: <8b2769930605260850w2261051s844edbf641db4db8@mail.gmail.com> Hi Henry, So obviously everyone here knows I've got a bit different approach, and there are a few things about an OpenDHT approach I don't understand. I think that my biggest concern is that using OpenDHT, I can only see how to address some of the use cases proposed. In the use cases draft, I can't see how an OpenDHT approach could solve the scenarios in 3.2, 3.3 or 3.4, only how to use it to solve 3.1 I also don't see what it is this group would standardize if we use OpenDHT. I don't think this WG is the right place to standardize OpenDHT -- that certainly wouldn't be P2PSIP, but rather a general P2P working group. My idea for this group is to build a specialized, limited to SIP, light weight P2P mechanism, so that we can have many interoperable UAs from different vendors/open source development teams, all locating resources using P2P mechanisms, and not dependent on external agents for that resolution (only the UAs themselves, possibly not connected to the big-I Internet). In other words, we specify an alternate location protocol for SIP between the devices themselves. Am I just confused about OpenDHT? David On 5/26/06, Henry Sinnreich wrote: > Maybe we should all talk using the same reference material, such as: > > http://opendht.org/pubs.html > > and then we can discuss the issues item by item, such as routing modes, > response time, delay aware routing, partial search, etc. > > Last but not least open running code and experimental results. Clearly SIP > has not been designed to address these issues and there is no reason to > duplicate all this work. > > Any opinions on the technology at http://opendht.org/pubs.html ? > > Publications Related to OpenDHT > > Distributed Segment Tree: Support of Range Query and Cover Query over DHT. > Changxi Zheng, Guobin Shen, Shipeng Li, and Scott Shenker. 5th International > Workshop on Peer-to-Peer Systems (IPTPS 2006), February 2006. > > Fixing the Embarrassing Slowness of OpenDHT on PlanetLab. Sean Rhea, > Byung-Gon Chun, John Kubiatowicz, and Scott Shenker. Proceedings of USENIX > WORLDS 2005, December 2005. > > Non-Transitive Connectivity and DHTs. Michael J. Freedman, Karthik > Lakshminarayanan, Sean Rhea, and Ion Stoica. Proceedings of USENIX WORLDS > 2005, December 2005. > > OpenDHT: A Public DHT Service and Its Uses. Sean Rhea, Brighten Godfrey, > Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, > and Harlan Yu. Proceedings of ACM SIGCOMM 2005, August 2005. > > A Case Study in Building Layered DHT Applications. Yatin Chawathe, Sriram > Ramabhadran, Sylvia Ratnasamy, Anthony LaMarca, Scott Shenker, and Joseph > Hellerstein. Proceedings of ACM SIGCOMM 2005, August 2005. > > Spurring Adoption of DHTs with OpenHash, a Public DHT Service. Brad Karp, > Sylvia Ratnasamy, Sean Rhea, and Scott Shenker. Proceedings of the 3rd > International Workshop on Peer-to-Peer Systems (IPTPS 2004), Springer-Verlag > Lecture Notes in Computer Science Hot Topics Series, San Diego, CA, > February, 2004. (The OpenDHT project was originally titled "OpenHash".) > > Thanks, Henry > > > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan > Sent: Thursday, May 25, 2006 8:30 PM > To: Brian Rosen > Cc: p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > A bit more clarification. > > P2P over SIP means: "build a distributed lookup that SIP agents use to > locate each other, and use SIP messages to convey the > queries/organization for the distributed seach". The group would > standardize the extensions to SIP to do this. > > P2P for SIP means: "build a distributed lookup that SIP agents use to > locate each other, but it may use other message formats (I've heard > SOAP proposed) to convey the queries/organization for the distributed > search" The group would standardize that other protocol > > In both cases, the idea is regular SIP is used between the nodes. As > Greg points out, some (including my early work) proposed routing SIP > over the P2P layer as well. I backed off this a bit when many folks > objected in Vancouver, although I must admit that for NAT traversal > reasons, I'm liking it again. > > This is list of several hundred people. People have proposed building > a generic multi-purpose DHT using SIP here, and people have proposed > replacing SIP here. It has seemed quite clear from the responses that > the majority of people do not agree with that, and that certainly > those of us trying to organize P2PSIP do not support those things. > > --David > > > On 5/25/06, Brian Rosen
wrote: > > I'm sorry, I don't get it. > > > > No one is proposing to use sip to do something equivalent to what a DHT > > does. > > > > Everyone is proposing to use sip messages to control session > establishment. > > > > A User Agent is going to send a pretty normal looking INVITE message. The > > question at hand is how it routes it. It doesn't use the procedures in > > 3261. > > > > I don't understand the difference. I think that means I don't understand > > what p2p using sip means. As long as we are all agreeing that its sip > > messages to do session management, at least I think we're in a do-able > > situation. > > > > Brian > > > > -----Original Message----- > > From: Greg Daley [mailto:gregd at research.panasonic.com] > > Sent: Thursday, May 25, 2006 4:59 PM > > To: Brian Rosen > > Cc: 'Mike Robinson'; p2p-sip at cs.columbia.edu > > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > > > Hi Brian, > > > > There's a distinction between P2P FOR sip and > > P2P USING sip. > > > > P2P FOR sip is a system which handles distributed > > lookup of SIP location URIs, > > > > P2P USING sip is a realization of how to do P2P FOR sip, > > using SIP protocol (or SIP protocol-like) messages or > > extensions. > > > > There's broad agreement that we want P2P FOR sip > > (the goal), but not necessarily agreement that > > we need P2P USING sip. > > > > This is not surprising, because the charter discussion > > is about what we want to get done (P2P FOR sip), > > rather than on exactly how to do it (e.g. P2P USING sip). > > > > Clear now? > > > > > > Brian Rosen wrote: > > > Okay, so here we are again. You are looking for an approved charter, > and > > we > > > don't know what we are trying to do. > > > > > > If there is consensus that this is to be a p2psip thing, then that's a > > whole > > > lot less work then if the sip part is still under discussion. > > > > > > I'd go so far as to say, if it's NOT p2psip, then we are really in IRTF > > > land. > > > > > > So, what is it? p2psip or > > > p2p-some-kind-of-multimedi-session-control-protocol? > > > > > > > > > > > > Brian > > > > > > -----Original Message----- > > > From: p2p-sip-bounces at cs.columbia.edu > > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley > > > Sent: Thursday, May 25, 2006 4:42 PM > > > To: Mike Robinson > > > Cc: p2p-sip at cs.columbia.edu > > > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > > > > > Hi Mike, > > > > > > Mike Robinson wrote: > > > [cut] > > >> Unless someone can tell us clearly why sip should be used to create, > > >> manage and re-configure DHT, the goal should remain a "proposed goal" > > >> till then. IETF, or for that matter any standard organization should't > > >> be a willing tool to fulfil any particular company's vested interests > > >> (even when supposedly supported by (a company funded) researchers at > a > > >> University). > > > > > > Only one of the (strawman) proposals says that SIP messages are used. > > > Alternative view on this have also been presented in the Ad-hoc sessions > > > leading up to the BoFs (and are still on the table). > > > > > > There's no clear winner, there's not even a coalition of people who > > > have backed one. > > > > > > Of course authors will each have points to make about their own ideas, > > > but that's why there's got to be a working group. So the community > > > can work on the requirements and make sure that the best solution is > > > used. > > > > > > If we didn't care about that, we'd just use/sell a proprietary system. > > > > > >> I am not opposed to p2p sip in whatever form - but don't understand the > > >> urgency being shown to push a certain design without evaluating > > >> alternative approaches. You don't need standardization right away to > > >> show that your model works- post your code to sourceforge.net and let > me > > >> see how good your design is by experimenting with it. > > > > > > I think you've misread the situation. There is code for at least > > > one implementation of a proposal available (is it on sourceforge?). > > > > > > AFAIK, there's no-one here pushing a particular cart. > > > > > > People here have a real desire to bring about the best system > > > for p2p sip. There are people here willing to do the work > > > on assessing the protocol requirements, reviewing documents, > > > designing and building a protocol, following the IETF's > > > procedures. > > > > > > If we just wanted to get something out commercially and push a > > > particular agenda, we'd have made an industry consortium. > > > > > > It's a lot faster, it has more chance of success, and has less > > > inconvenient review. > > > > > > Help us to charter the WG, because that's where the IETF can > > > have control of the outputs, and ensure protocol quality. > > > > > > Greg > > > _______________________________________________ > > > 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 > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From henry at pulver.com Fri May 26 12:33:23 2006 From: henry at pulver.com (Henry Sinnreich) Date: Fri, 26 May 2006 11:33:23 -0500 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <8b2769930605260850w2261051s844edbf641db4db8@mail.gmail.com> Message-ID: <001d01c680e2$1b53f890$2800a8c0@DSX400> The DHT layer can be (1) inside the SIP Peer UAs as suggested by Eunsoo Shim: http://www.p2psip.org/drafts/draft-shim-sipping-p2p-arch-00.txt See Fig. 2 ...or (2) just to start, one can use openDHT as an emerging _DHT service_. 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 Thanks, Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan Sent: Friday, May 26, 2006 10:51 AM To: henry at pulver.com Cc: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching Hi Henry, So obviously everyone here knows I've got a bit different approach, and there are a few things about an OpenDHT approach I don't understand. I think that my biggest concern is that using OpenDHT, I can only see how to address some of the use cases proposed. In the use cases draft, I can't see how an OpenDHT approach could solve the scenarios in 3.2, 3.3 or 3.4, only how to use it to solve 3.1 I also don't see what it is this group would standardize if we use OpenDHT. I don't think this WG is the right place to standardize OpenDHT -- that certainly wouldn't be P2PSIP, but rather a general P2P working group. My idea for this group is to build a specialized, limited to SIP, light weight P2P mechanism, so that we can have many interoperable UAs from different vendors/open source development teams, all locating resources using P2P mechanisms, and not dependent on external agents for that resolution (only the UAs themselves, possibly not connected to the big-I Internet). In other words, we specify an alternate location protocol for SIP between the devices themselves. Am I just confused about OpenDHT? David On 5/26/06, Henry Sinnreich wrote: > Maybe we should all talk using the same reference material, such as: > > http://opendht.org/pubs.html > > and then we can discuss the issues item by item, such as routing modes, > response time, delay aware routing, partial search, etc. > > Last but not least open running code and experimental results. Clearly SIP > has not been designed to address these issues and there is no reason to > duplicate all this work. > > Any opinions on the technology at http://opendht.org/pubs.html ? > > Publications Related to OpenDHT > > Distributed Segment Tree: Support of Range Query and Cover Query over DHT. > Changxi Zheng, Guobin Shen, Shipeng Li, and Scott Shenker. 5th International > Workshop on Peer-to-Peer Systems (IPTPS 2006), February 2006. > > Fixing the Embarrassing Slowness of OpenDHT on PlanetLab. Sean Rhea, > Byung-Gon Chun, John Kubiatowicz, and Scott Shenker. Proceedings of USENIX > WORLDS 2005, December 2005. > > Non-Transitive Connectivity and DHTs. Michael J. Freedman, Karthik > Lakshminarayanan, Sean Rhea, and Ion Stoica. Proceedings of USENIX WORLDS > 2005, December 2005. > > OpenDHT: A Public DHT Service and Its Uses. Sean Rhea, Brighten Godfrey, > Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, > and Harlan Yu. Proceedings of ACM SIGCOMM 2005, August 2005. > > A Case Study in Building Layered DHT Applications. Yatin Chawathe, Sriram > Ramabhadran, Sylvia Ratnasamy, Anthony LaMarca, Scott Shenker, and Joseph > Hellerstein. Proceedings of ACM SIGCOMM 2005, August 2005. > > Spurring Adoption of DHTs with OpenHash, a Public DHT Service. Brad Karp, > Sylvia Ratnasamy, Sean Rhea, and Scott Shenker. Proceedings of the 3rd > International Workshop on Peer-to-Peer Systems (IPTPS 2004), Springer-Verlag > Lecture Notes in Computer Science Hot Topics Series, San Diego, CA, > February, 2004. (The OpenDHT project was originally titled "OpenHash".) > > Thanks, Henry > > > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan > Sent: Thursday, May 25, 2006 8:30 PM > To: Brian Rosen > Cc: p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > A bit more clarification. > > P2P over SIP means: "build a distributed lookup that SIP agents use to > locate each other, and use SIP messages to convey the > queries/organization for the distributed seach". The group would > standardize the extensions to SIP to do this. > > P2P for SIP means: "build a distributed lookup that SIP agents use to > locate each other, but it may use other message formats (I've heard > SOAP proposed) to convey the queries/organization for the distributed > search" The group would standardize that other protocol > > In both cases, the idea is regular SIP is used between the nodes. As > Greg points out, some (including my early work) proposed routing SIP > over the P2P layer as well. I backed off this a bit when many folks > objected in Vancouver, although I must admit that for NAT traversal > reasons, I'm liking it again. > > This is list of several hundred people. People have proposed building > a generic multi-purpose DHT using SIP here, and people have proposed > replacing SIP here. It has seemed quite clear from the responses that > the majority of people do not agree with that, and that certainly > those of us trying to organize P2PSIP do not support those things. > > --David > > > On 5/25/06, Brian Rosen
wrote: > > I'm sorry, I don't get it. > > > > No one is proposing to use sip to do something equivalent to what a DHT > > does. > > > > Everyone is proposing to use sip messages to control session > establishment. > > > > A User Agent is going to send a pretty normal looking INVITE message. The > > question at hand is how it routes it. It doesn't use the procedures in > > 3261. > > > > I don't understand the difference. I think that means I don't understand > > what p2p using sip means. As long as we are all agreeing that its sip > > messages to do session management, at least I think we're in a do-able > > situation. > > > > Brian > > > > -----Original Message----- > > From: Greg Daley [mailto:gregd at research.panasonic.com] > > Sent: Thursday, May 25, 2006 4:59 PM > > To: Brian Rosen > > Cc: 'Mike Robinson'; p2p-sip at cs.columbia.edu > > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > > > Hi Brian, > > > > There's a distinction between P2P FOR sip and > > P2P USING sip. > > > > P2P FOR sip is a system which handles distributed > > lookup of SIP location URIs, > > > > P2P USING sip is a realization of how to do P2P FOR sip, > > using SIP protocol (or SIP protocol-like) messages or > > extensions. > > > > There's broad agreement that we want P2P FOR sip > > (the goal), but not necessarily agreement that > > we need P2P USING sip. > > > > This is not surprising, because the charter discussion > > is about what we want to get done (P2P FOR sip), > > rather than on exactly how to do it (e.g. P2P USING sip). > > > > Clear now? > > > > > > Brian Rosen wrote: > > > Okay, so here we are again. You are looking for an approved charter, > and > > we > > > don't know what we are trying to do. > > > > > > If there is consensus that this is to be a p2psip thing, then that's a > > whole > > > lot less work then if the sip part is still under discussion. > > > > > > I'd go so far as to say, if it's NOT p2psip, then we are really in IRTF > > > land. > > > > > > So, what is it? p2psip or > > > p2p-some-kind-of-multimedi-session-control-protocol? > > > > > > > > > > > > Brian > > > > > > -----Original Message----- > > > From: p2p-sip-bounces at cs.columbia.edu > > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley > > > Sent: Thursday, May 25, 2006 4:42 PM > > > To: Mike Robinson > > > Cc: p2p-sip at cs.columbia.edu > > > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > > > > > Hi Mike, > > > > > > Mike Robinson wrote: > > > [cut] > > >> Unless someone can tell us clearly why sip should be used to create, > > >> manage and re-configure DHT, the goal should remain a "proposed goal" > > >> till then. IETF, or for that matter any standard organization should't > > >> be a willing tool to fulfil any particular company's vested interests > > >> (even when supposedly supported by (a company funded) researchers at > a > > >> University). > > > > > > Only one of the (strawman) proposals says that SIP messages are used. > > > Alternative view on this have also been presented in the Ad-hoc sessions > > > leading up to the BoFs (and are still on the table). > > > > > > There's no clear winner, there's not even a coalition of people who > > > have backed one. > > > > > > Of course authors will each have points to make about their own ideas, > > > but that's why there's got to be a working group. So the community > > > can work on the requirements and make sure that the best solution is > > > used. > > > > > > If we didn't care about that, we'd just use/sell a proprietary system. > > > > > >> I am not opposed to p2p sip in whatever form - but don't understand the > > >> urgency being shown to push a certain design without evaluating > > >> alternative approaches. You don't need standardization right away to > > >> show that your model works- post your code to sourceforge.net and let > me > > >> see how good your design is by experimenting with it. > > > > > > I think you've misread the situation. There is code for at least > > > one implementation of a proposal available (is it on sourceforge?). > > > > > > AFAIK, there's no-one here pushing a particular cart. > > > > > > People here have a real desire to bring about the best system > > > for p2p sip. There are people here willing to do the work > > > on assessing the protocol requirements, reviewing documents, > > > designing and building a protocol, following the IETF's > > > procedures. > > > > > > If we just wanted to get something out commercially and push a > > > particular agenda, we'd have made an industry consortium. > > > > > > It's a lot faster, it has more chance of success, and has less > > > inconvenient review. > > > > > > Help us to charter the WG, because that's where the IETF can > > > have control of the outputs, and ensure protocol quality. > > > > > > Greg > > > _______________________________________________ > > > 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 > > > _______________________________________________ > 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 gregd at research.panasonic.com Fri May 26 12:56:57 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Fri, 26 May 2006 12:56:57 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <4476D6DF.3060707@telecomitalia.it> References: <20060525184219.94913.qmail@web38511.mail.mud.yahoo.com> <44761683.8040702@research.panasonic.com> <4476D6DF.3060707@telecomitalia.it> Message-ID: <44773359.9070909@research.panasonic.com> Hi Enrico, Enrico Marocco wrote: [cut] > (yes, it is) At this point both written and coded proposals are only > meant to show that a solution is feasible. Can you please repost the URL? > There is a lot of discussion about the algorithm and the protocol for > DHT maintainance; hey... are they really important, now? If a WG were > formed people would be happily struggling for chord/kademlia/bamboo over > SIP/SOAP/RMI; until a WG is started, such arguements are only wasted time. Arguments certainly may be a waste of time now. If we start contributing requirements, this may help though. Having implementation experience certainly helps there. >> AFAIK, there's no-one here pushing a particular cart. > > There's no cart either; maybe someone's pushing a strawman, but not a > cart ;-) That's OK, so long as it's not a brick man. ;) Greg From gregd at research.panasonic.com Fri May 26 13:00:12 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Fri, 26 May 2006 13:00:12 -0400 Subject: [p2p-sip] Solid Charter [WAS: Re: P2PSIP, Kademlia and caching] In-Reply-To: <4476D80E.7070100@telecomitalia.it> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> Message-ID: <4477341C.5000107@research.panasonic.com> Hi Enrico, Enrico Marocco wrote: > Greg Daley wrote: >> I agree with you that we need a solid charter, and that >> we need to discuss it well before going into the next >> BoF. > > My opinion is that we still have a pretty good charter, which needs just > small changes according to issues raised during the BOF. > > For facing concerns expressed by IAB and IESG members, we should clearly > assert that: > 1. P2PSIP is not a replacement for SIP. Instead its primary use is for > extending SIP connectivity in environments where traditional SIP > registrars/proxies cannot be practically deployed; > 2. P2PSIP work will reuse existing IETF works (i.e. ICE for NAT > traversal). The charter was contraddictory on this point, but broad > consensus for fixing it was found during the BOF; > 3. P2PSIP group will not do research work. The goal of distributing > functionalities for lookup and NAT traversal will be achieved > using existing and well-known algorithms. > > The ambiguity of the term "P2P" and the appeal of Skype-like solutions > (which for many reasons _won't_ be standardized in IETF) may have > obfuscated those key points, worring ADs and IAB members. IMHO the > changes needed are not so drastic and the group would quickly agree on them. I agree that the charter was in fairly good shape, and I hear is developing to address some of those issues (I like your text though). But there's no predicting mailing list discussion... Greg From RADHIKA.R.ROY at saic.com Fri May 26 13:14:29 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Fri, 26 May 2006 13:14:29 -0400 Subject: [p2p-sip] Solid Charter [WAS: Re: P2PSIP, Kademlia and cachin g] Message-ID: <62D92A9A02BCC845B202323D49A48426209CF2@0591-ITS-EXMP02.us.saic.com> Moreover, we can also enhance/modify charter if we need to do so as time goes by. So, if we make a charter making a rough consensus to the best of our ability now, still we have the option to update/modify it. Let us spend a reasonable amount of time in discussing the charter instead of waiting too long. Best regards, Radhika _____ From: p2p-sip-bounces at cs.columbia.edu on behalf of Greg Daley Sent: Fri 5/26/2006 1:00 PM To: Enrico Marocco Cc: p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan' Subject: Re: [p2p-sip] Solid Charter [WAS: Re: P2PSIP, Kademlia and caching] Hi Enrico, Enrico Marocco wrote: > Greg Daley wrote: >> I agree with you that we need a solid charter, and that >> we need to discuss it well before going into the next >> BoF. > > My opinion is that we still have a pretty good charter, which needs just > small changes according to issues raised during the BOF. > > For facing concerns expressed by IAB and IESG members, we should clearly > assert that: > 1. P2PSIP is not a replacement for SIP. Instead its primary use is for > extending SIP connectivity in environments where traditional SIP > registrars/proxies cannot be practically deployed; > 2. P2PSIP work will reuse existing IETF works (i.e. ICE for NAT > traversal). The charter was contraddictory on this point, but broad > consensus for fixing it was found during the BOF; > 3. P2PSIP group will not do research work. The goal of distributing > functionalities for lookup and NAT traversal will be achieved > using existing and well-known algorithms. > > The ambiguity of the term "P2P" and the appeal of Skype-like solutions > (which for many reasons _won't_ be standardized in IETF) may have > obfuscated those key points, worring ADs and IAB members. IMHO the > changes needed are not so drastic and the group would quickly agree on them. I agree that the charter was in fairly good shape, and I hear is developing to address some of those issues (I like your text though). But there's no predicting mailing list discussion... Greg From bryan at ethernot.org Fri May 26 13:26:19 2006 From: bryan at ethernot.org (David A. Bryan) Date: Fri, 26 May 2006 13:26:19 -0400 Subject: [p2p-sip] Solid Charter [WAS: Re: P2PSIP, Kademlia and cachin g] In-Reply-To: <8b2769930605261025m17fd59f8k96e0284e984c5de@mail.gmail.com> References: <62D92A9A02BCC845B202323D49A48426209CF2@0591-ITS-EXMP02.us.saic.com> <8b2769930605261025m17fd59f8k96e0284e984c5de@mail.gmail.com> Message-ID: <8b2769930605261026l2a1ec329g532bff57edbda728@mail.gmail.com> So I already see that the RAI area director on this should be Cullen now. Count that as my first edit ;) --David On 5/26/06, David A. Bryan wrote: > So the last iteration we had is here: > > http://www.p2psip.org/ietf-65/charter_draft_060212.php > > The bigest objection was that we were not clear on "what is the > specific problem/work item the WG would go and do" if I recall. > > Lets take another stab. Lets look and see if we can think about this > again, and start a discussion here. > > David > > On 5/26/06, Roy, Radhika R. wrote: > > Moreover, we can also enhance/modify charter if we need to do so as time > > goes by. > > > > So, if we make a charter making a rough consensus to the best of our ability > > now, still we have the option to update/modify it. Let us spend a reasonable > > amount of time in discussing the charter instead of waiting too long. > > > > Best regards, > > Radhika > > > > _____ > > > > From: p2p-sip-bounces at cs.columbia.edu on behalf of Greg Daley > > Sent: Fri 5/26/2006 1:00 PM > > To: Enrico Marocco > > Cc: p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan' > > Subject: Re: [p2p-sip] Solid Charter [WAS: Re: P2PSIP, Kademlia and caching] > > > > > > > > Hi Enrico, > > > > Enrico Marocco wrote: > > > Greg Daley wrote: > > >> I agree with you that we need a solid charter, and that > > >> we need to discuss it well before going into the next > > >> BoF. > > > > > > My opinion is that we still have a pretty good charter, which needs just > > > small changes according to issues raised during the BOF. > > > > > > For facing concerns expressed by IAB and IESG members, we should clearly > > > assert that: > > > 1. P2PSIP is not a replacement for SIP. Instead its primary use is for > > > extending SIP connectivity in environments where traditional SIP > > > registrars/proxies cannot be practically deployed; > > > 2. P2PSIP work will reuse existing IETF works (i.e. ICE for NAT > > > traversal). The charter was contraddictory on this point, but broad > > > consensus for fixing it was found during the BOF; > > > 3. P2PSIP group will not do research work. The goal of distributing > > > functionalities for lookup and NAT traversal will be achieved > > > using existing and well-known algorithms. > > > > > > The ambiguity of the term "P2P" and the appeal of Skype-like solutions > > > (which for many reasons _won't_ be standardized in IETF) may have > > > obfuscated those key points, worring ADs and IAB members. IMHO the > > > changes needed are not so drastic and the group would quickly agree on > > them. > > > > I agree that the charter was in fairly good shape, and > > I hear is developing to address some of those issues > > (I like your text though). > > > > But there's no predicting mailing list discussion... > > > > Greg > > > > > > > From bryan at ethernot.org Fri May 26 13:25:30 2006 From: bryan at ethernot.org (David A. Bryan) Date: Fri, 26 May 2006 13:25:30 -0400 Subject: [p2p-sip] Solid Charter [WAS: Re: P2PSIP, Kademlia and cachin g] In-Reply-To: <62D92A9A02BCC845B202323D49A48426209CF2@0591-ITS-EXMP02.us.saic.com> References: <62D92A9A02BCC845B202323D49A48426209CF2@0591-ITS-EXMP02.us.saic.com> Message-ID: <8b2769930605261025m17fd59f8k96e0284e984c5de@mail.gmail.com> So the last iteration we had is here: http://www.p2psip.org/ietf-65/charter_draft_060212.php The bigest objection was that we were not clear on "what is the specific problem/work item the WG would go and do" if I recall. Lets take another stab. Lets look and see if we can think about this again, and start a discussion here. David On 5/26/06, Roy, Radhika R. wrote: > Moreover, we can also enhance/modify charter if we need to do so as time > goes by. > > So, if we make a charter making a rough consensus to the best of our ability > now, still we have the option to update/modify it. Let us spend a reasonable > amount of time in discussing the charter instead of waiting too long. > > Best regards, > Radhika > > _____ > > From: p2p-sip-bounces at cs.columbia.edu on behalf of Greg Daley > Sent: Fri 5/26/2006 1:00 PM > To: Enrico Marocco > Cc: p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan' > Subject: Re: [p2p-sip] Solid Charter [WAS: Re: P2PSIP, Kademlia and caching] > > > > Hi Enrico, > > Enrico Marocco wrote: > > Greg Daley wrote: > >> I agree with you that we need a solid charter, and that > >> we need to discuss it well before going into the next > >> BoF. > > > > My opinion is that we still have a pretty good charter, which needs just > > small changes according to issues raised during the BOF. > > > > For facing concerns expressed by IAB and IESG members, we should clearly > > assert that: > > 1. P2PSIP is not a replacement for SIP. Instead its primary use is for > > extending SIP connectivity in environments where traditional SIP > > registrars/proxies cannot be practically deployed; > > 2. P2PSIP work will reuse existing IETF works (i.e. ICE for NAT > > traversal). The charter was contraddictory on this point, but broad > > consensus for fixing it was found during the BOF; > > 3. P2PSIP group will not do research work. The goal of distributing > > functionalities for lookup and NAT traversal will be achieved > > using existing and well-known algorithms. > > > > The ambiguity of the term "P2P" and the appeal of Skype-like solutions > > (which for many reasons _won't_ be standardized in IETF) may have > > obfuscated those key points, worring ADs and IAB members. IMHO the > > changes needed are not so drastic and the group would quickly agree on > them. > > I agree that the charter was in fairly good shape, and > I hear is developing to address some of those issues > (I like your text though). > > But there's no predicting mailing list discussion... > > Greg > > > From alan at sipstation.com Fri May 26 13:32:51 2006 From: alan at sipstation.com (Alan Johnston) Date: Fri, 26 May 2006 12:32:51 -0500 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <8b2769930605260850w2261051s844edbf641db4db8@mail.gmail.com> References: <8b2769930605251829t42a246e4saed220406a5e21cd@mail.gmail.com> <004601c680c9$e58d91c0$2800a8c0@DSX400> <8b2769930605260850w2261051s844edbf641db4db8@mail.gmail.com> Message-ID: <44773BC3.8040800@sipstation.com> David, Your reply seems to suggest that you think a single DHT will solve all these use cases. I believe that concentrating on a single DHT or other P2P technology is not a good idea. Also, I'm a little uncomfortable signing this group up to designing or implementing a specific DHT algorithm. Instead, I think this IETF group should concentrate on defining protocols on the wire. I'm still putting my thoughts together and will detail them in a draft soon, but rather than standardizing a particular DHT, we need to define an RFC 3263-like document that describes how SIP UAs can utilize a P2P Location Service. This would include a protocol for how things like Contact URIs, certificates, presence data, etc. can be pushed and retrieved from a DHT. With a standard protocol defined for this interaction, any DHT implementation or technology could implement this interface and be usable for P2P SIP. We would also need to define some discovery mechanisms, as well. Perhaps with a clear scope like this in our charter we could get our working group going. Once this basic work is complete, we can start discussing the merits of one DHT vs. another, and also perhaps architectures, although P2P SIP architectures might be better done somewhere like the SIP Forum. Look for a more detailed proposal to come... Thanks, Alan David A. Bryan wrote: >Hi Henry, > >So obviously everyone here knows I've got a bit different approach, >and there are a few things about an OpenDHT approach I don't >understand. > >I think that my biggest concern is that using OpenDHT, I can only see >how to address some of the use cases proposed. In the use cases draft, >I can't see how an OpenDHT approach could solve the scenarios in 3.2, >3.3 or 3.4, only how to use it to solve 3.1 > >I also don't see what it is this group would standardize if we use >OpenDHT. I don't think this WG is the right place to standardize >OpenDHT -- that certainly wouldn't be P2PSIP, but rather a general P2P >working group. My idea for this group is to build a specialized, >limited to SIP, light weight P2P mechanism, so that we can have many >interoperable UAs from different vendors/open source development >teams, all locating resources using P2P mechanisms, and not dependent >on external agents for that resolution (only the UAs themselves, >possibly not connected to the big-I Internet). In other words, we >specify an alternate location protocol for SIP between the devices >themselves. > >Am I just confused about OpenDHT? > >David > >On 5/26/06, Henry Sinnreich wrote: > > >>Maybe we should all talk using the same reference material, such as: >> >>http://opendht.org/pubs.html >> >>and then we can discuss the issues item by item, such as routing modes, >>response time, delay aware routing, partial search, etc. >> >>Last but not least open running code and experimental results. Clearly SIP >>has not been designed to address these issues and there is no reason to >>duplicate all this work. >> >>Any opinions on the technology at http://opendht.org/pubs.html ? >> >>Publications Related to OpenDHT >> >>Distributed Segment Tree: Support of Range Query and Cover Query over DHT. >>Changxi Zheng, Guobin Shen, Shipeng Li, and Scott Shenker. 5th International >>Workshop on Peer-to-Peer Systems (IPTPS 2006), February 2006. >> >>Fixing the Embarrassing Slowness of OpenDHT on PlanetLab. Sean Rhea, >>Byung-Gon Chun, John Kubiatowicz, and Scott Shenker. Proceedings of USENIX >>WORLDS 2005, December 2005. >> >>Non-Transitive Connectivity and DHTs. Michael J. Freedman, Karthik >>Lakshminarayanan, Sean Rhea, and Ion Stoica. Proceedings of USENIX WORLDS >>2005, December 2005. >> >>OpenDHT: A Public DHT Service and Its Uses. Sean Rhea, Brighten Godfrey, >>Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, >>and Harlan Yu. Proceedings of ACM SIGCOMM 2005, August 2005. >> >>A Case Study in Building Layered DHT Applications. Yatin Chawathe, Sriram >>Ramabhadran, Sylvia Ratnasamy, Anthony LaMarca, Scott Shenker, and Joseph >>Hellerstein. Proceedings of ACM SIGCOMM 2005, August 2005. >> >>Spurring Adoption of DHTs with OpenHash, a Public DHT Service. Brad Karp, >>Sylvia Ratnasamy, Sean Rhea, and Scott Shenker. Proceedings of the 3rd >>International Workshop on Peer-to-Peer Systems (IPTPS 2004), Springer-Verlag >>Lecture Notes in Computer Science Hot Topics Series, San Diego, CA, >>February, 2004. (The OpenDHT project was originally titled "OpenHash".) >> >>Thanks, Henry >> >> >> >>-----Original Message----- >>From: p2p-sip-bounces at cs.columbia.edu >>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan >>Sent: Thursday, May 25, 2006 8:30 PM >>To: Brian Rosen >>Cc: p2p-sip at cs.columbia.edu >>Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching >> >>A bit more clarification. >> >>P2P over SIP means: "build a distributed lookup that SIP agents use to >>locate each other, and use SIP messages to convey the >>queries/organization for the distributed seach". The group would >>standardize the extensions to SIP to do this. >> >>P2P for SIP means: "build a distributed lookup that SIP agents use to >>locate each other, but it may use other message formats (I've heard >>SOAP proposed) to convey the queries/organization for the distributed >>search" The group would standardize that other protocol >> >>In both cases, the idea is regular SIP is used between the nodes. As >>Greg points out, some (including my early work) proposed routing SIP >>over the P2P layer as well. I backed off this a bit when many folks >>objected in Vancouver, although I must admit that for NAT traversal >>reasons, I'm liking it again. >> >>This is list of several hundred people. People have proposed building >>a generic multi-purpose DHT using SIP here, and people have proposed >>replacing SIP here. It has seemed quite clear from the responses that >>the majority of people do not agree with that, and that certainly >>those of us trying to organize P2PSIP do not support those things. >> >>--David >> >> >>On 5/25/06, Brian Rosen
wrote: >> >> >>>I'm sorry, I don't get it. >>> >>>No one is proposing to use sip to do something equivalent to what a DHT >>>does. >>> >>>Everyone is proposing to use sip messages to control session >>> >>> >>establishment. >> >> >>>A User Agent is going to send a pretty normal looking INVITE message. The >>>question at hand is how it routes it. It doesn't use the procedures in >>>3261. >>> >>>I don't understand the difference. I think that means I don't understand >>>what p2p using sip means. As long as we are all agreeing that its sip >>>messages to do session management, at least I think we're in a do-able >>>situation. >>> >>>Brian >>> >>>-----Original Message----- >>>From: Greg Daley [mailto:gregd at research.panasonic.com] >>>Sent: Thursday, May 25, 2006 4:59 PM >>>To: Brian Rosen >>>Cc: 'Mike Robinson'; p2p-sip at cs.columbia.edu >>>Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching >>> >>>Hi Brian, >>> >>>There's a distinction between P2P FOR sip and >>>P2P USING sip. >>> >>>P2P FOR sip is a system which handles distributed >>>lookup of SIP location URIs, >>> >>>P2P USING sip is a realization of how to do P2P FOR sip, >>>using SIP protocol (or SIP protocol-like) messages or >>>extensions. >>> >>>There's broad agreement that we want P2P FOR sip >>>(the goal), but not necessarily agreement that >>>we need P2P USING sip. >>> >>>This is not surprising, because the charter discussion >>>is about what we want to get done (P2P FOR sip), >>>rather than on exactly how to do it (e.g. P2P USING sip). >>> >>>Clear now? >>> >>> >>>Brian Rosen wrote: >>> >>> >>>>Okay, so here we are again. You are looking for an approved charter, >>>> >>>> >>and >> >> >>>we >>> >>> >>>>don't know what we are trying to do. >>>> >>>>If there is consensus that this is to be a p2psip thing, then that's a >>>> >>>> >>>whole >>> >>> >>>>lot less work then if the sip part is still under discussion. >>>> >>>>I'd go so far as to say, if it's NOT p2psip, then we are really in IRTF >>>>land. >>>> >>>>So, what is it? p2psip or >>>>p2p-some-kind-of-multimedi-session-control-protocol? >>>> >>>> >>>> >>>>Brian >>>> >>>>-----Original Message----- >>>>From: p2p-sip-bounces at cs.columbia.edu >>>>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley >>>>Sent: Thursday, May 25, 2006 4:42 PM >>>>To: Mike Robinson >>>>Cc: p2p-sip at cs.columbia.edu >>>>Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching >>>> >>>>Hi Mike, >>>> >>>>Mike Robinson wrote: >>>>[cut] >>>> >>>> >>>>>Unless someone can tell us clearly why sip should be used to create, >>>>>manage and re-configure DHT, the goal should remain a "proposed goal" >>>>>till then. IETF, or for that matter any standard organization should't >>>>>be a willing tool to fulfil any particular company's vested interests >>>>>(even when supposedly supported by (a company funded) researchers at >>>>> >>>>> >>a >> >> >>>>>University). >>>>> >>>>> >>>>Only one of the (strawman) proposals says that SIP messages are used. >>>>Alternative view on this have also been presented in the Ad-hoc sessions >>>>leading up to the BoFs (and are still on the table). >>>> >>>>There's no clear winner, there's not even a coalition of people who >>>>have backed one. >>>> >>>>Of course authors will each have points to make about their own ideas, >>>>but that's why there's got to be a working group. So the community >>>>can work on the requirements and make sure that the best solution is >>>>used. >>>> >>>>If we didn't care about that, we'd just use/sell a proprietary system. >>>> >>>> >>>> >>>>>I am not opposed to p2p sip in whatever form - but don't understand the >>>>>urgency being shown to push a certain design without evaluating >>>>>alternative approaches. You don't need standardization right away to >>>>>show that your model works- post your code to sourceforge.net and let >>>>> >>>>> >>me >> >> >>>>>see how good your design is by experimenting with it. >>>>> >>>>> >>>>I think you've misread the situation. There is code for at least >>>>one implementation of a proposal available (is it on sourceforge?). >>>> >>>>AFAIK, there's no-one here pushing a particular cart. >>>> >>>>People here have a real desire to bring about the best system >>>>for p2p sip. There are people here willing to do the work >>>>on assessing the protocol requirements, reviewing documents, >>>>designing and building a protocol, following the IETF's >>>>procedures. >>>> >>>>If we just wanted to get something out commercially and push a >>>>particular agenda, we'd have made an industry consortium. >>>> >>>>It's a lot faster, it has more chance of success, and has less >>>>inconvenient review. >>>> >>>>Help us to charter the WG, because that's where the IETF can >>>>have control of the outputs, and ensure protocol quality. >>>> >>>>Greg >>>>_______________________________________________ >>>>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 >> >> >>_______________________________________________ >>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 ag at ag-projects.com Fri May 26 15:28:05 2006 From: ag at ag-projects.com (Adrian Georgescu) Date: Fri, 26 May 2006 21:28:05 +0200 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <44773BC3.8040800@sipstation.com> References: <8b2769930605251829t42a246e4saed220406a5e21cd@mail.gmail.com> <004601c680c9$e58d91c0$2800a8c0@DSX400> <8b2769930605260850w2261051s844edbf641db4db8@mail.gmail.com> <44773BC3.8040800@sipstation.com> Message-ID: <0AB4EED7-CBFE-428D-81A4-6327ADE09E77@ag-projects.com> I also support Alan's idea of an "RFC 3263-like document" which allows standard SIP peers to locate each others using structured or unstructured overlays. The goal of the WG should be: Allowing standard SIP sessions between end-points by using either: 1. Central naming and addressing authority like DNS 2. P2P self-organizing network overlay while preserving interoperability between the two models. The overlay implementation should remain an implementation issue, the work must be directed to standardize an API between SIP end-points and the overlay. Like the DNS query and response pair. Adrian On May 26, 2006, at 7:32 PM, Alan Johnston wrote: > David, > > Your reply seems to suggest that you think a single DHT will solve all > these use cases. > > I believe that concentrating on a single DHT or other P2P > technology is > not a good idea. Also, I'm a little uncomfortable signing this > group up > to designing or implementing a specific DHT algorithm. > > Instead, I think this IETF group should concentrate on defining > protocols on the wire. I'm still putting my thoughts together and > will > detail them in a draft soon, but rather than standardizing a > particular > DHT, we need to define an RFC 3263-like document that describes how > SIP > UAs can utilize a P2P Location Service. This would include a protocol > for how things like Contact URIs, certificates, presence data, etc. > can > be pushed and retrieved from a DHT. > > With a standard protocol defined for this interaction, any DHT > implementation or technology could implement this interface and be > usable for P2P SIP. > > We would also need to define some discovery mechanisms, as well. > > Perhaps with a clear scope like this in our charter we could get our > working group going. Once this basic work is complete, we can start > discussing the merits of one DHT vs. another, and also perhaps > architectures, although P2P SIP architectures might be better done > somewhere like the SIP Forum. > > Look for a more detailed proposal to come... > > Thanks, > Alan > > David A. Bryan wrote: > >> Hi Henry, >> >> So obviously everyone here knows I've got a bit different approach, >> and there are a few things about an OpenDHT approach I don't >> understand. >> >> I think that my biggest concern is that using OpenDHT, I can only see >> how to address some of the use cases proposed. In the use cases >> draft, >> I can't see how an OpenDHT approach could solve the scenarios in 3.2, >> 3.3 or 3.4, only how to use it to solve 3.1 >> >> I also don't see what it is this group would standardize if we use >> OpenDHT. I don't think this WG is the right place to standardize >> OpenDHT -- that certainly wouldn't be P2PSIP, but rather a general >> P2P >> working group. My idea for this group is to build a specialized, >> limited to SIP, light weight P2P mechanism, so that we can have many >> interoperable UAs from different vendors/open source development >> teams, all locating resources using P2P mechanisms, and not dependent >> on external agents for that resolution (only the UAs themselves, >> possibly not connected to the big-I Internet). In other words, we >> specify an alternate location protocol for SIP between the devices >> themselves. >> >> Am I just confused about OpenDHT? >> >> David >> >> On 5/26/06, Henry Sinnreich wrote: >> >> >>> Maybe we should all talk using the same reference material, such as: >>> >>> http://opendht.org/pubs.html >>> >>> and then we can discuss the issues item by item, such as routing >>> modes, >>> response time, delay aware routing, partial search, etc. >>> >>> Last but not least open running code and experimental results. >>> Clearly SIP >>> has not been designed to address these issues and there is no >>> reason to >>> duplicate all this work. >>> >>> Any opinions on the technology at http://opendht.org/pubs.html ? >>> >>> Publications Related to OpenDHT >>> >>> Distributed Segment Tree: Support of Range Query and Cover Query >>> over DHT. >>> Changxi Zheng, Guobin Shen, Shipeng Li, and Scott Shenker. 5th >>> International >>> Workshop on Peer-to-Peer Systems (IPTPS 2006), February 2006. >>> >>> Fixing the Embarrassing Slowness of OpenDHT on PlanetLab. Sean Rhea, >>> Byung-Gon Chun, John Kubiatowicz, and Scott Shenker. Proceedings >>> of USENIX >>> WORLDS 2005, December 2005. >>> >>> Non-Transitive Connectivity and DHTs. Michael J. Freedman, Karthik >>> Lakshminarayanan, Sean Rhea, and Ion Stoica. Proceedings of >>> USENIX WORLDS >>> 2005, December 2005. >>> >>> OpenDHT: A Public DHT Service and Its Uses. Sean Rhea, Brighten >>> Godfrey, >>> Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion >>> Stoica, >>> and Harlan Yu. Proceedings of ACM SIGCOMM 2005, August 2005. >>> >>> A Case Study in Building Layered DHT Applications. Yatin >>> Chawathe, Sriram >>> Ramabhadran, Sylvia Ratnasamy, Anthony LaMarca, Scott Shenker, >>> and Joseph >>> Hellerstein. Proceedings of ACM SIGCOMM 2005, August 2005. >>> >>> Spurring Adoption of DHTs with OpenHash, a Public DHT Service. >>> Brad Karp, >>> Sylvia Ratnasamy, Sean Rhea, and Scott Shenker. Proceedings of >>> the 3rd >>> International Workshop on Peer-to-Peer Systems (IPTPS 2004), >>> Springer-Verlag >>> Lecture Notes in Computer Science Hot Topics Series, San Diego, CA, >>> February, 2004. (The OpenDHT project was originally titled >>> "OpenHash".) >>> >>> Thanks, Henry >>> >>> >>> >>> -----Original Message----- >>> From: p2p-sip-bounces at cs.columbia.edu >>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan >>> Sent: Thursday, May 25, 2006 8:30 PM >>> To: Brian Rosen >>> Cc: p2p-sip at cs.columbia.edu >>> Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching >>> >>> A bit more clarification. >>> >>> P2P over SIP means: "build a distributed lookup that SIP agents >>> use to >>> locate each other, and use SIP messages to convey the >>> queries/organization for the distributed seach". The group would >>> standardize the extensions to SIP to do this. >>> >>> P2P for SIP means: "build a distributed lookup that SIP agents >>> use to >>> locate each other, but it may use other message formats (I've heard >>> SOAP proposed) to convey the queries/organization for the >>> distributed >>> search" The group would standardize that other protocol >>> >>> In both cases, the idea is regular SIP is used between the nodes. As >>> Greg points out, some (including my early work) proposed routing SIP >>> over the P2P layer as well. I backed off this a bit when many folks >>> objected in Vancouver, although I must admit that for NAT traversal >>> reasons, I'm liking it again. >>> >>> This is list of several hundred people. People have proposed >>> building >>> a generic multi-purpose DHT using SIP here, and people have proposed >>> replacing SIP here. It has seemed quite clear from the responses >>> that >>> the majority of people do not agree with that, and that certainly >>> those of us trying to organize P2PSIP do not support those things. >>> >>> --David >>> >>> >>> On 5/25/06, Brian Rosen
wrote: >>> >>> >>>> I'm sorry, I don't get it. >>>> >>>> No one is proposing to use sip to do something equivalent to >>>> what a DHT >>>> does. >>>> >>>> Everyone is proposing to use sip messages to control session >>>> >>>> >>> establishment. >>> >>> >>>> A User Agent is going to send a pretty normal looking INVITE >>>> message. The >>>> question at hand is how it routes it. It doesn't use the >>>> procedures in >>>> 3261. >>>> >>>> I don't understand the difference. I think that means I don't >>>> understand >>>> what p2p using sip means. As long as we are all agreeing that >>>> its sip >>>> messages to do session management, at least I think we're in a >>>> do-able >>>> situation. >>>> >>>> Brian >>>> >>>> -----Original Message----- >>>> From: Greg Daley [mailto:gregd at research.panasonic.com] >>>> Sent: Thursday, May 25, 2006 4:59 PM >>>> To: Brian Rosen >>>> Cc: 'Mike Robinson'; p2p-sip at cs.columbia.edu >>>> Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching >>>> >>>> Hi Brian, >>>> >>>> There's a distinction between P2P FOR sip and >>>> P2P USING sip. >>>> >>>> P2P FOR sip is a system which handles distributed >>>> lookup of SIP location URIs, >>>> >>>> P2P USING sip is a realization of how to do P2P FOR sip, >>>> using SIP protocol (or SIP protocol-like) messages or >>>> extensions. >>>> >>>> There's broad agreement that we want P2P FOR sip >>>> (the goal), but not necessarily agreement that >>>> we need P2P USING sip. >>>> >>>> This is not surprising, because the charter discussion >>>> is about what we want to get done (P2P FOR sip), >>>> rather than on exactly how to do it (e.g. P2P USING sip). >>>> >>>> Clear now? >>>> >>>> >>>> Brian Rosen wrote: >>>> >>>> >>>>> Okay, so here we are again. You are looking for an approved >>>>> charter, >>>>> >>>>> >>> and >>> >>> >>>> we >>>> >>>> >>>>> don't know what we are trying to do. >>>>> >>>>> If there is consensus that this is to be a p2psip thing, then >>>>> that's a >>>>> >>>>> >>>> whole >>>> >>>> >>>>> lot less work then if the sip part is still under discussion. >>>>> >>>>> I'd go so far as to say, if it's NOT p2psip, then we are really >>>>> in IRTF >>>>> land. >>>>> >>>>> So, what is it? p2psip or >>>>> p2p-some-kind-of-multimedi-session-control-protocol? >>>>> >>>>> >>>>> >>>>> Brian >>>>> >>>>> -----Original Message----- >>>>> From: p2p-sip-bounces at cs.columbia.edu >>>>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley >>>>> Sent: Thursday, May 25, 2006 4:42 PM >>>>> To: Mike Robinson >>>>> Cc: p2p-sip at cs.columbia.edu >>>>> Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching >>>>> >>>>> Hi Mike, >>>>> >>>>> Mike Robinson wrote: >>>>> [cut] >>>>> >>>>> >>>>>> Unless someone can tell us clearly why sip should be used to >>>>>> create, >>>>>> manage and re-configure DHT, the goal should remain a >>>>>> "proposed goal" >>>>>> till then. IETF, or for that matter any standard organization >>>>>> should't >>>>>> be a willing tool to fulfil any particular company's vested >>>>>> interests >>>>>> (even when supposedly supported by (a company funded) >>>>>> researchers at >>>>>> >>>>>> >>> a >>> >>> >>>>>> University). >>>>>> >>>>>> >>>>> Only one of the (strawman) proposals says that SIP messages are >>>>> used. >>>>> Alternative view on this have also been presented in the Ad-hoc >>>>> sessions >>>>> leading up to the BoFs (and are still on the table). >>>>> >>>>> There's no clear winner, there's not even a coalition of people >>>>> who >>>>> have backed one. >>>>> >>>>> Of course authors will each have points to make about their own >>>>> ideas, >>>>> but that's why there's got to be a working group. So the >>>>> community >>>>> can work on the requirements and make sure that the best >>>>> solution is >>>>> used. >>>>> >>>>> If we didn't care about that, we'd just use/sell a proprietary >>>>> system. >>>>> >>>>> >>>>> >>>>>> I am not opposed to p2p sip in whatever form - but don't >>>>>> understand the >>>>>> urgency being shown to push a certain design without evaluating >>>>>> alternative approaches. You don't need standardization right >>>>>> away to >>>>>> show that your model works- post your code to sourceforge.net >>>>>> and let >>>>>> >>>>>> >>> me >>> >>> >>>>>> see how good your design is by experimenting with it. >>>>>> >>>>>> >>>>> I think you've misread the situation. There is code for at least >>>>> one implementation of a proposal available (is it on >>>>> sourceforge?). >>>>> >>>>> AFAIK, there's no-one here pushing a particular cart. >>>>> >>>>> People here have a real desire to bring about the best system >>>>> for p2p sip. There are people here willing to do the work >>>>> on assessing the protocol requirements, reviewing documents, >>>>> designing and building a protocol, following the IETF's >>>>> procedures. >>>>> >>>>> If we just wanted to get something out commercially and push a >>>>> particular agenda, we'd have made an industry consortium. >>>>> >>>>> It's a lot faster, it has more chance of success, and has less >>>>> inconvenient review. >>>>> >>>>> Help us to charter the WG, because that's where the IETF can >>>>> have control of the outputs, and ensure protocol quality. >>>>> >>>>> Greg >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> _______________________________________________ >>> 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 henry at pulver.com Fri May 26 16:19:16 2006 From: henry at pulver.com (Henry Sinnreich) Date: Fri, 26 May 2006 15:19:16 -0500 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <1635153708-1148672148-cardhu_blackberry.rim.net-6725-@engine03-cell05> Message-ID: <013201c68101$a9c26e80$2800a8c0@DSX400> >If we don't define at least one common dht, how can devices interop? Worst case would be using the DNS domain via gateway supernodes. Best case is if the proposed WG selects a DHT and/or uses some emerging public DHT service. Henry -----Original Message----- From: David A. Bryan [mailto:dbryan at sipeerior.com] Sent: Friday, May 26, 2006 2:31 PM To: Alan Johnston; p2p-sip-bounces at cs.columbia.edu; David Bryan Cc: p2p-sip at cs.columbia.edu; henry at pulver.com Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching My big worry there is interoperability. If we don't define at least one common dht, how can devices interop? I definitely agree that we should allow many, but I think we must specify at least one. [Sent from my mobile device] -----Original Message----- From: Alan Johnston Date: Fri, 26 May 2006 12:32:51 To:"David A. Bryan" Cc:p2p-sip at cs.columbia.edu, henry at pulver.com Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching David, Your reply seems to suggest that you think a single DHT will solve all these use cases. I believe that concentrating on a single DHT or other P2P technology is not a good idea. Also, I'm a little uncomfortable signing this group up to designing or implementing a specific DHT algorithm. Instead, I think this IETF group should concentrate on defining protocols on the wire. I'm still putting my thoughts together and will detail them in a draft soon, but rather than standardizing a particular DHT, we need to define an RFC 3263-like document that describes how SIP UAs can utilize a P2P Location Service. This would include a protocol for how things like Contact URIs, certificates, presence data, etc. can be pushed and retrieved from a DHT. With a standard protocol defined for this interaction, any DHT implementation or technology could implement this interface and be usable for P2P SIP. We would also need to define some discovery mechanisms, as well. Perhaps with a clear scope like this in our charter we could get our working group going. Once this basic work is complete, we can start discussing the merits of one DHT vs. another, and also perhaps architectures, although P2P SIP architectures might be better done somewhere like the SIP Forum. Look for a more detailed proposal to come... Thanks, Alan David A. Bryan wrote: >Hi Henry, > >So obviously everyone here knows I've got a bit different approach, >and there are a few things about an OpenDHT approach I don't >understand. > >I think that my biggest concern is that using OpenDHT, I can only see >how to address some of the use cases proposed. In the use cases draft, >I can't see how an OpenDHT approach could solve the scenarios in 3.2, >3.3 or 3.4, only how to use it to solve 3.1 > >I also don't see what it is this group would standardize if we use >OpenDHT. I don't think this WG is the right place to standardize >OpenDHT -- that certainly wouldn't be P2PSIP, but rather a general P2P >working group. My idea for this group is to build a specialized, >limited to SIP, light weight P2P mechanism, so that we can have many >interoperable UAs from different vendors/open source development >teams, all locating resources using P2P mechanisms, and not dependent >on external agents for that resolution (only the UAs themselves, >possibly not connected to the big-I Internet). In other words, we >specify an alternate location protocol for SIP between the devices >themselves. > >Am I just confused about OpenDHT? > >David > >On 5/26/06, Henry Sinnreich wrote: > > >>Maybe we should all talk using the same reference material, such as: >> >>http://opendht.org/pubs.html >> >>and then we can discuss the issues item by item, such as routing modes, >>response time, delay aware routing, partial search, etc. >> >>Last but not least open running code and experimental results. Clearly SIP >>has not been designed to address these issues and there is no reason to >>duplicate all this work. >> >>Any opinions on the technology at http://opendht.org/pubs.html ? >> >>Publications Related to OpenDHT >> >>Distributed Segment Tree: Support of Range Query and Cover Query over DHT. >>Changxi Zheng, Guobin Shen, Shipeng Li, and Scott Shenker. 5th International >>Workshop on Peer-to-Peer Systems (IPTPS 2006), February 2006. >> >>Fixing the Embarrassing Slowness of OpenDHT on PlanetLab. Sean Rhea, >>Byung-Gon Chun, John Kubiatowicz, and Scott Shenker. Proceedings of USENIX >>WORLDS 2005, December 2005. >> >>Non-Transitive Connectivity and DHTs. Michael J. Freedman, Karthik >>Lakshminarayanan, Sean Rhea, and Ion Stoica. Proceedings of USENIX WORLDS >>2005, December 2005. >> >>OpenDHT: A Public DHT Service and Its Uses. Sean Rhea, Brighten Godfrey, >>Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, >>and Harlan Yu. Proceedings of ACM SIGCOMM 2005, August 2005. >> >>A Case Study in Building Layered DHT Applications. Yatin Chawathe, Sriram >>Ramabhadran, Sylvia Ratnasamy, Anthony LaMarca, Scott Shenker, and Joseph >>Hellerstein. Proceedings of ACM SIGCOMM 2005, August 2005. >> >>Spurring Adoption of DHTs with OpenHash, a Public DHT Service. Brad Karp, >>Sylvia Ratnasamy, Sean Rhea, and Scott Shenker. Proceedings of the 3rd >>International Workshop on Peer-to-Peer Systems (IPTPS 2004), Springer-Verlag >>Lecture Notes in Computer Science Hot Topics Series, San Diego, CA, >>February, 2004. (The OpenDHT project was originally titled "OpenHash".) >> >>Thanks, Henry >> >> >> >>-----Original Message----- >>From: p2p-sip-bounces at cs.columbia.edu >>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan >>Sent: Thursday, May 25, 2006 8:30 PM >>To: Brian Rosen >>Cc: p2p-sip at cs.columbia.edu >>Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching >> >>A bit more clarification. >> >>P2P over SIP means: "build a distributed lookup that SIP agents use to >>locate each other, and use SIP messages to convey the >>queries/organization for the distributed seach". The group would >>standardize the extensions to SIP to do this. >> >>P2P for SIP means: "build a distributed lookup that SIP agents use to >>locate each other, but it may use other message formats (I've heard >>SOAP proposed) to convey the queries/organization for the distributed >>search" The group would standardize that other protocol >> >>In both cases, the idea is regular SIP is used between the nodes. As >>Greg points out, some (including my early work) proposed routing SIP >>over the P2P layer as well. I backed off this a bit when many folks >>objected in Vancouver, although I must admit that for NAT traversal >>reasons, I'm liking it again. >> >>This is list of several hundred people. People have proposed building >>a generic multi-purpose DHT using SIP here, and people have proposed >>replacing SIP here. It has seemed quite clear from the responses that >>the majority of people do not agree with that, and that certainly >>those of us trying to organize P2PSIP do not support those things. >> >>--David >> >> >>On 5/25/06, Brian Rosen
wrote: >> >> >>>I'm sorry, I don't get it. >>> >>>No one is proposing to use sip to do something equivalent to what a DHT >>>does. >>> >>>Everyone is proposing to use sip messages to control session >>> >>> >>establishment. >> >> >>>A User Agent is going to send a pretty normal looking INVITE message. The >>>question at hand is how it routes it. It doesn't use the procedures in >>>3261. >>> >>>I don't understand the difference. I think that means I don't understand >>>what p2p using sip means. As long as we are all agreeing that its sip >>>messages to do session management, at least I think we're in a do-able >>>situation. >>> >>>Brian >>> >>>-----Original Message----- >>>From: Greg Daley [mailto:gregd at research.panasonic.com] >>>Sent: Thursday, May 25, 2006 4:59 PM >>>To: Brian Rosen >>>Cc: 'Mike Robinson'; p2p-sip at cs.columbia.edu >>>Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching >>> >>>Hi Brian, >>> >>>There's a distinction between P2P FOR sip and >>>P2P USING sip. >>> >>>P2P FOR sip is a system which handles distributed >>>lookup of SIP location URIs, >>> >>>P2P USING sip is a realization of how to do P2P FOR sip, >>>using SIP protocol (or SIP protocol-like) messages or >>>extensions. >>> >>>There's broad agreement that we want P2P FOR sip >>>(the goal), but not necessarily agreement that >>>we need P2P USING sip. >>> >>>This is not surprising, because the charter discussion >>>is about what we want to get done (P2P FOR sip), >>>rather than on exactly how to do it (e.g. P2P USING sip). >>> >>>Clear now? >>> >>> >>>Brian Rosen wrote: >>> >>> >>>>Okay, so here we are again. You are looking for an approved charter, >>>> >>>> >>and >> >> >>>we >>> >>> >>>>don't know what we are trying to do. >>>> >>>>If there is consensus that this is to be a p2psip thing, then that's a >>>> >>>> >>>whole >>> >>> >>>>lot less work then if the sip part is still under discussion. >>>> >>>>I'd go so far as to say, if it's NOT p2psip, then we are really in IRTF >>>>land. >>>> >>>>So, what is it? p2psip or >>>>p2p-some-kind-of-multimedi-session-control-protocol? >>>> >>>> >>>> >>>>Brian >>>> >>>>-----Original Message----- >>>>From: p2p-sip-bounces at cs.columbia.edu >>>>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley >>>>Sent: Thursday, May 25, 2006 4:42 PM >>>>To: Mike Robinson >>>>Cc: p2p-sip at cs.columbia.edu >>>>Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching >>>> >>>>Hi Mike, >>>> >>>>Mike Robinson wrote: >>>>[cut] >>>> >>>> >>>>>Unless someone can tell us clearly why sip should be used to create, >>>>>manage and re-configure DHT, the goal should remain a "proposed goal" >>>>>till then. IETF, or for that matter any standard organization should't >>>>>be a willing tool to fulfil any particular company's vested interests >>>>>(even when supposedly supported by (a company funded) researchers at >>>>> >>>>> >>a >> >> >>>>>University). >>>>> >>>>> >>>>Only one of the (strawman) proposals says that SIP messages are used. >>>>Alternative view on this have also been presented in the Ad-hoc sessions >>>>leading up to the BoFs (and are still on the table). >>>> >>>>There's no clear winner, there's not even a coalition of people who >>>>have backed one. >>>> >>>>Of course authors will each have points to make about their own ideas, >>>>but that's why there's got to be a working group. So the community >>>>can work on the requirements and make sure that the best solution is >>>>used. >>>> >>>>If we didn't care about that, we'd just use/sell a proprietary system. >>>> >>>> >>>> >>>>>I am not opposed to p2p sip in whatever form - but don't understand the >>>>>urgency being shown to push a certain design without evaluating >>>>>alternative approaches. You don't need standardization right away to >>>>>show that your model works- post your code to sourceforge.net and let >>>>> >>>>> >>me >> >> >>>>>see how good your design is by experimenting with it. >>>>> >>>>> >>>>I think you've misread the situation. There is code for at least >>>>one implementation of a proposal available (is it on sourceforge?). >>>> >>>>AFAIK, there's no-one here pushing a particular cart. >>>> >>>>People here have a real desire to bring about the best system >>>>for p2p sip. There are people here willing to do the work >>>>on assessing the protocol requirements, reviewing documents, >>>>designing and building a protocol, following the IETF's >>>>procedures. >>>> >>>>If we just wanted to get something out commercially and push a >>>>particular agenda, we'd have made an industry consortium. >>>> >>>>It's a lot faster, it has more chance of success, and has less >>>>inconvenient review. >>>> >>>>Help us to charter the WG, because that's where the IETF can >>>>have control of the outputs, and ensure protocol quality. >>>> >>>>Greg >>>>_______________________________________________ >>>>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 >> >> >>_______________________________________________ >>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 eunsoo at research.panasonic.com Fri May 26 17:28:34 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Fri, 26 May 2006 17:28:34 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <013201c68101$a9c26e80$2800a8c0@DSX400> References: <013201c68101$a9c26e80$2800a8c0@DSX400> Message-ID: <44777302.4010905@research.panasonic.com> I also think the best case is that the proposed WG selects a DHT. What I hear these days is that most well-known DHTs adopted good features of each other and now experts say there is not much difference among them in terms of features or performances. Certainly we don't have to review and compare all kinds of DHTs and select the very best one. We can adopt a new one later. I believe there is a consensus about that. So far what have been proposed on the list are Bamboo/Pastry, Kademlia, and Chord. Selecting one of three may not be as difficult as selecting a DHT sounds from scratch. Thanks. Eunsoo Henry Sinnreich wrote: >> If we don't define at least one common dht, how can devices interop? > > Worst case would be using the DNS domain via gateway supernodes. > > Best case is if the proposed WG selects a DHT and/or uses some emerging > public DHT service. > > Henry > > -----Original Message----- > From: David A. Bryan [mailto:dbryan at sipeerior.com] > Sent: Friday, May 26, 2006 2:31 PM > To: Alan Johnston; p2p-sip-bounces at cs.columbia.edu; David Bryan > Cc: p2p-sip at cs.columbia.edu; henry at pulver.com > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > My big worry there is interoperability. If we don't define at least one > common dht, how can devices interop? I definitely agree that we should allow > many, but I think we must specify at least one. > [Sent from my mobile device] > > -----Original Message----- > From: Alan Johnston > Date: Fri, 26 May 2006 12:32:51 > To:"David A. Bryan" > Cc:p2p-sip at cs.columbia.edu, henry at pulver.com > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > David, > > Your reply seems to suggest that you think a single DHT will solve all > these use cases. > > I believe that concentrating on a single DHT or other P2P technology is > not a good idea. Also, I'm a little uncomfortable signing this group up > to designing or implementing a specific DHT algorithm. > > Instead, I think this IETF group should concentrate on defining > protocols on the wire. I'm still putting my thoughts together and will > detail them in a draft soon, but rather than standardizing a particular > DHT, we need to define an RFC 3263-like document that describes how SIP > UAs can utilize a P2P Location Service. This would include a protocol > for how things like Contact URIs, certificates, presence data, etc. can > be pushed and retrieved from a DHT. > > With a standard protocol defined for this interaction, any DHT > implementation or technology could implement this interface and be > usable for P2P SIP. > > We would also need to define some discovery mechanisms, as well. > > Perhaps with a clear scope like this in our charter we could get our > working group going. Once this basic work is complete, we can start > discussing the merits of one DHT vs. another, and also perhaps > architectures, although P2P SIP architectures might be better done > somewhere like the SIP Forum. > > Look for a more detailed proposal to come... > > Thanks, > Alan > > David A. Bryan wrote: > >> Hi Henry, >> >> So obviously everyone here knows I've got a bit different approach, >> and there are a few things about an OpenDHT approach I don't >> understand. >> >> I think that my biggest concern is that using OpenDHT, I can only see >> how to address some of the use cases proposed. In the use cases draft, >> I can't see how an OpenDHT approach could solve the scenarios in 3.2, >> 3.3 or 3.4, only how to use it to solve 3.1 >> >> I also don't see what it is this group would standardize if we use >> OpenDHT. I don't think this WG is the right place to standardize >> OpenDHT -- that certainly wouldn't be P2PSIP, but rather a general P2P >> working group. My idea for this group is to build a specialized, >> limited to SIP, light weight P2P mechanism, so that we can have many >> interoperable UAs from different vendors/open source development >> teams, all locating resources using P2P mechanisms, and not dependent >> on external agents for that resolution (only the UAs themselves, >> possibly not connected to the big-I Internet). In other words, we >> specify an alternate location protocol for SIP between the devices >> themselves. >> >> Am I just confused about OpenDHT? >> >> David >> >> On 5/26/06, Henry Sinnreich wrote: >> >> >>> Maybe we should all talk using the same reference material, such as: >>> >>> http://opendht.org/pubs.html >>> >>> and then we can discuss the issues item by item, such as routing modes, >>> response time, delay aware routing, partial search, etc. >>> >>> Last but not least open running code and experimental results. Clearly SIP >>> has not been designed to address these issues and there is no reason to >>> duplicate all this work. >>> >>> Any opinions on the technology at http://opendht.org/pubs.html ? >>> >>> Publications Related to OpenDHT >>> >>> Distributed Segment Tree: Support of Range Query and Cover Query over DHT. >>> Changxi Zheng, Guobin Shen, Shipeng Li, and Scott Shenker. 5th > International >>> Workshop on Peer-to-Peer Systems (IPTPS 2006), February 2006. >>> >>> Fixing the Embarrassing Slowness of OpenDHT on PlanetLab. Sean Rhea, >>> Byung-Gon Chun, John Kubiatowicz, and Scott Shenker. Proceedings of USENIX >>> WORLDS 2005, December 2005. >>> >>> Non-Transitive Connectivity and DHTs. Michael J. Freedman, Karthik >>> Lakshminarayanan, Sean Rhea, and Ion Stoica. Proceedings of USENIX WORLDS >>> 2005, December 2005. >>> >>> OpenDHT: A Public DHT Service and Its Uses. Sean Rhea, Brighten Godfrey, >>> Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, >>> and Harlan Yu. Proceedings of ACM SIGCOMM 2005, August 2005. >>> >>> A Case Study in Building Layered DHT Applications. Yatin Chawathe, Sriram >>> Ramabhadran, Sylvia Ratnasamy, Anthony LaMarca, Scott Shenker, and Joseph >>> Hellerstein. Proceedings of ACM SIGCOMM 2005, August 2005. >>> >>> Spurring Adoption of DHTs with OpenHash, a Public DHT Service. Brad Karp, >>> Sylvia Ratnasamy, Sean Rhea, and Scott Shenker. Proceedings of the 3rd >>> International Workshop on Peer-to-Peer Systems (IPTPS 2004), > Springer-Verlag >>> Lecture Notes in Computer Science Hot Topics Series, San Diego, CA, >>> February, 2004. (The OpenDHT project was originally titled "OpenHash".) >>> >>> Thanks, Henry >>> >>> >>> >>> -----Original Message----- >>> From: p2p-sip-bounces at cs.columbia.edu >>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan >>> Sent: Thursday, May 25, 2006 8:30 PM >>> To: Brian Rosen >>> Cc: p2p-sip at cs.columbia.edu >>> Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching >>> >>> A bit more clarification. >>> >>> P2P over SIP means: "build a distributed lookup that SIP agents use to >>> locate each other, and use SIP messages to convey the >>> queries/organization for the distributed seach". The group would >>> standardize the extensions to SIP to do this. >>> >>> P2P for SIP means: "build a distributed lookup that SIP agents use to >>> locate each other, but it may use other message formats (I've heard >>> SOAP proposed) to convey the queries/organization for the distributed >>> search" The group would standardize that other protocol >>> >>> In both cases, the idea is regular SIP is used between the nodes. As >>> Greg points out, some (including my early work) proposed routing SIP >>> over the P2P layer as well. I backed off this a bit when many folks >>> objected in Vancouver, although I must admit that for NAT traversal >>> reasons, I'm liking it again. >>> >>> This is list of several hundred people. People have proposed building >>> a generic multi-purpose DHT using SIP here, and people have proposed >>> replacing SIP here. It has seemed quite clear from the responses that >>> the majority of people do not agree with that, and that certainly >>> those of us trying to organize P2PSIP do not support those things. >>> >>> --David >>> >>> >>> On 5/25/06, Brian Rosen
wrote: >>> >>> >>>> I'm sorry, I don't get it. >>>> >>>> No one is proposing to use sip to do something equivalent to what a DHT >>>> does. >>>> >>>> Everyone is proposing to use sip messages to control session >>>> >>>> >>> establishment. >>> >>> >>>> A User Agent is going to send a pretty normal looking INVITE message. > The >>>> question at hand is how it routes it. It doesn't use the procedures in >>>> 3261. >>>> >>>> I don't understand the difference. I think that means I don't understand >>>> what p2p using sip means. As long as we are all agreeing that its sip >>>> messages to do session management, at least I think we're in a do-able >>>> situation. >>>> >>>> Brian >>>> >>>> -----Original Message----- >>>> From: Greg Daley [mailto:gregd at research.panasonic.com] >>>> Sent: Thursday, May 25, 2006 4:59 PM >>>> To: Brian Rosen >>>> Cc: 'Mike Robinson'; p2p-sip at cs.columbia.edu >>>> Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching >>>> >>>> Hi Brian, >>>> >>>> There's a distinction between P2P FOR sip and >>>> P2P USING sip. >>>> >>>> P2P FOR sip is a system which handles distributed >>>> lookup of SIP location URIs, >>>> >>>> P2P USING sip is a realization of how to do P2P FOR sip, >>>> using SIP protocol (or SIP protocol-like) messages or >>>> extensions. >>>> >>>> There's broad agreement that we want P2P FOR sip >>>> (the goal), but not necessarily agreement that >>>> we need P2P USING sip. >>>> >>>> This is not surprising, because the charter discussion >>>> is about what we want to get done (P2P FOR sip), >>>> rather than on exactly how to do it (e.g. P2P USING sip). >>>> >>>> Clear now? >>>> >>>> >>>> Brian Rosen wrote: >>>> >>>> >>>>> Okay, so here we are again. You are looking for an approved charter, >>>>> >>>>> >>> and >>> >>> >>>> we >>>> >>>> >>>>> don't know what we are trying to do. >>>>> >>>>> If there is consensus that this is to be a p2psip thing, then that's a >>>>> >>>>> >>>> whole >>>> >>>> >>>>> lot less work then if the sip part is still under discussion. >>>>> >>>>> I'd go so far as to say, if it's NOT p2psip, then we are really in IRTF >>>>> land. >>>>> >>>>> So, what is it? p2psip or >>>>> p2p-some-kind-of-multimedi-session-control-protocol? >>>>> >>>>> >>>>> >>>>> Brian >>>>> >>>>> -----Original Message----- >>>>> From: p2p-sip-bounces at cs.columbia.edu >>>>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley >>>>> Sent: Thursday, May 25, 2006 4:42 PM >>>>> To: Mike Robinson >>>>> Cc: p2p-sip at cs.columbia.edu >>>>> Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching >>>>> >>>>> Hi Mike, >>>>> >>>>> Mike Robinson wrote: >>>>> [cut] >>>>> >>>>> >>>>>> Unless someone can tell us clearly why sip should be used to create, >>>>>> manage and re-configure DHT, the goal should remain a "proposed goal" >>>>>> till then. IETF, or for that matter any standard organization should't >>>>>> be a willing tool to fulfil any particular company's vested interests >>>>>> (even when supposedly supported by (a company funded) researchers at >>>>>> >>>>>> >>> a >>> >>> >>>>>> University). >>>>>> >>>>>> >>>>> Only one of the (strawman) proposals says that SIP messages are used. >>>>> Alternative view on this have also been presented in the Ad-hoc sessions >>>>> leading up to the BoFs (and are still on the table). >>>>> >>>>> There's no clear winner, there's not even a coalition of people who >>>>> have backed one. >>>>> >>>>> Of course authors will each have points to make about their own ideas, >>>>> but that's why there's got to be a working group. So the community >>>>> can work on the requirements and make sure that the best solution is >>>>> used. >>>>> >>>>> If we didn't care about that, we'd just use/sell a proprietary system. >>>>> >>>>> >>>>> >>>>>> I am not opposed to p2p sip in whatever form - but don't understand the >>>>>> urgency being shown to push a certain design without evaluating >>>>>> alternative approaches. You don't need standardization right away to >>>>>> show that your model works- post your code to sourceforge.net and let >>>>>> >>>>>> >>> me >>> >>> >>>>>> see how good your design is by experimenting with it. >>>>>> >>>>>> >>>>> I think you've misread the situation. There is code for at least >>>>> one implementation of a proposal available (is it on sourceforge?). >>>>> >>>>> AFAIK, there's no-one here pushing a particular cart. >>>>> >>>>> People here have a real desire to bring about the best system >>>>> for p2p sip. There are people here willing to do the work >>>>> on assessing the protocol requirements, reviewing documents, >>>>> designing and building a protocol, following the IETF's >>>>> procedures. >>>>> >>>>> If we just wanted to get something out commercially and push a >>>>> particular agenda, we'd have made an industry consortium. >>>>> >>>>> It's a lot faster, it has more chance of success, and has less >>>>> inconvenient review. >>>>> >>>>> Help us to charter the WG, because that's where the IETF can >>>>> have control of the outputs, and ensure protocol quality. >>>>> >>>>> Greg >>>>> _______________________________________________ From gregd at research.panasonic.com Fri May 26 18:07:58 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Fri, 26 May 2006 18:07:58 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <44773BC3.8040800@sipstation.com> References: <8b2769930605251829t42a246e4saed220406a5e21cd@mail.gmail.com> <004601c680c9$e58d91c0$2800a8c0@DSX400> <8b2769930605260850w2261051s844edbf641db4db8@mail.gmail.com> <44773BC3.8040800@sipstation.com> Message-ID: <44777C3E.9040500@research.panasonic.com> Hi Alan, Alan Johnston wrote: > David, > > Your reply seems to suggest that you think a single DHT will solve all > these use cases. > > I believe that concentrating on a single DHT or other P2P technology is > not a good idea. Also, I'm a little uncomfortable signing this group up > to designing or implementing a specific DHT algorithm. > > Instead, I think this IETF group should concentrate on defining > protocols on the wire. I'm still putting my thoughts together and will > detail them in a draft soon, but rather than standardizing a particular > DHT, we need to define an RFC 3263-like document that describes how SIP > UAs can utilize a P2P Location Service. This would include a protocol > for how things like Contact URIs, certificates, presence data, etc. can > be pushed and retrieved from a DHT. > > With a standard protocol defined for this interaction, any DHT > implementation or technology could implement this interface and be > usable for P2P SIP. One of the underlying assumptions of RFC3263 is the presence of DNS, and this provides a single interoperable message query fabric available to discover SIP locations. To assume things will work if there is not an interoperable query fabric which will be able to be used (at least by default) by P2P-SIP nodes is probably incorrect (unless we say fall back to CS/SIP), which can use DNS. I also agree that the group should focus on message formats and behaviours for the location service. I'm not proposing research into DHTs. I think that most of the DHTs people have been talking about, Chord, Pastry, etc, are different ways of cutting the same cake. It really doesn't matter which we pick, so long as the effort to design and secure such a protocol isn't exacerbated. > We would also need to define some discovery mechanisms, as well. Sure, but let's try to use existing methods where possible. > Perhaps with a clear scope like this in our charter we could get our > working group going. Once this basic work is complete, we can start > discussing the merits of one DHT vs. another, and also perhaps > architectures, although P2P SIP architectures might be better done > somewhere like the SIP Forum. I agree that discussion of one DHT over another is for later. Really, we need enough architecture to get the initial work going here, without relying on another body to crank up an effort, though. Greg From mike_robnson at yahoo.com Fri May 26 23:02:24 2006 From: mike_robnson at yahoo.com (Mike Robinson) Date: Fri, 26 May 2006 20:02:24 -0700 (PDT) Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <44777302.4010905@research.panasonic.com> Message-ID: <20060527030224.3004.qmail@web38512.mail.mud.yahoo.com> >> Selecting one of three may not be as difficult as selecting a >> DHT sounds from scratch. Not sure what is the criteria you based above assertion on? Either something is difficult to get consensus on, or it is resolved, there are no in between status in standards. Given the mails on the topic on this list or otherwise, I don't see how study of DHTs fits in p2p sip charter. o Mike Eunsoo Shim wrote: I also think the best case is that the proposed WG selects a DHT. What I hear these days is that most well-known DHTs adopted good features of each other and now experts say there is not much difference among them in terms of features or performances. Certainly we don't have to review and compare all kinds of DHTs and select the very best one. We can adopt a new one later. I believe there is a consensus about that. So far what have been proposed on the list are Bamboo/Pastry, Kademlia, and Chord. Selecting one of three may not be as difficult as selecting a DHT sounds from scratch. Thanks. Eunsoo Henry Sinnreich wrote: >> If we don't define at least one common dht, how can devices interop? > > Worst case would be using the DNS domain via gateway supernodes. > > Best case is if the proposed WG selects a DHT and/or uses some emerging > public DHT service. > > Henry > > -----Original Message----- > From: David A. Bryan [mailto:dbryan at sipeerior.com] > Sent: Friday, May 26, 2006 2:31 PM > To: Alan Johnston; p2p-sip-bounces at cs.columbia.edu; David Bryan > Cc: p2p-sip at cs.columbia.edu; henry at pulver.com > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > My big worry there is interoperability. If we don't define at least one > common dht, how can devices interop? I definitely agree that we should allow > many, but I think we must specify at least one. > [Sent from my mobile device] > > -----Original Message----- > From: Alan Johnston > Date: Fri, 26 May 2006 12:32:51 > To:"David A. Bryan" > Cc:p2p-sip at cs.columbia.edu, henry at pulver.com > Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching > > David, > > Your reply seems to suggest that you think a single DHT will solve all > these use cases. > > I believe that concentrating on a single DHT or other P2P technology is > not a good idea. Also, I'm a little uncomfortable signing this group up > to designing or implementing a specific DHT algorithm. > > Instead, I think this IETF group should concentrate on defining > protocols on the wire. I'm still putting my thoughts together and will > detail them in a draft soon, but rather than standardizing a particular > DHT, we need to define an RFC 3263-like document that describes how SIP > UAs can utilize a P2P Location Service. This would include a protocol > for how things like Contact URIs, certificates, presence data, etc. can > be pushed and retrieved from a DHT. > > With a standard protocol defined for this interaction, any DHT > implementation or technology could implement this interface and be > usable for P2P SIP. > > We would also need to define some discovery mechanisms, as well. > > Perhaps with a clear scope like this in our charter we could get our > working group going. Once this basic work is complete, we can start > discussing the merits of one DHT vs. another, and also perhaps > architectures, although P2P SIP architectures might be better done > somewhere like the SIP Forum. > > Look for a more detailed proposal to come... > > Thanks, > Alan > > David A. Bryan wrote: > >> Hi Henry, >> >> So obviously everyone here knows I've got a bit different approach, >> and there are a few things about an OpenDHT approach I don't >> understand. >> >> I think that my biggest concern is that using OpenDHT, I can only see >> how to address some of the use cases proposed. In the use cases draft, >> I can't see how an OpenDHT approach could solve the scenarios in 3.2, >> 3.3 or 3.4, only how to use it to solve 3.1 >> >> I also don't see what it is this group would standardize if we use >> OpenDHT. I don't think this WG is the right place to standardize >> OpenDHT -- that certainly wouldn't be P2PSIP, but rather a general P2P >> working group. My idea for this group is to build a specialized, >> limited to SIP, light weight P2P mechanism, so that we can have many >> interoperable UAs from different vendors/open source development >> teams, all locating resources using P2P mechanisms, and not dependent >> on external agents for that resolution (only the UAs themselves, >> possibly not connected to the big-I Internet). In other words, we >> specify an alternate location protocol for SIP between the devices >> themselves. >> >> Am I just confused about OpenDHT? >> >> David >> >> On 5/26/06, Henry Sinnreich wrote: >> >> >>> Maybe we should all talk using the same reference material, such as: >>> >>> http://opendht.org/pubs.html >>> >>> and then we can discuss the issues item by item, such as routing modes, >>> response time, delay aware routing, partial search, etc. >>> >>> Last but not least open running code and experimental results. Clearly SIP >>> has not been designed to address these issues and there is no reason to >>> duplicate all this work. >>> >>> Any opinions on the technology at http://opendht.org/pubs.html ? >>> >>> Publications Related to OpenDHT >>> >>> Distributed Segment Tree: Support of Range Query and Cover Query over DHT. >>> Changxi Zheng, Guobin Shen, Shipeng Li, and Scott Shenker. 5th > International >>> Workshop on Peer-to-Peer Systems (IPTPS 2006), February 2006. >>> >>> Fixing the Embarrassing Slowness of OpenDHT on PlanetLab. Sean Rhea, >>> Byung-Gon Chun, John Kubiatowicz, and Scott Shenker. Proceedings of USENIX >>> WORLDS 2005, December 2005. >>> >>> Non-Transitive Connectivity and DHTs. Michael J. Freedman, Karthik >>> Lakshminarayanan, Sean Rhea, and Ion Stoica. Proceedings of USENIX WORLDS >>> 2005, December 2005. >>> >>> OpenDHT: A Public DHT Service and Its Uses. Sean Rhea, Brighten Godfrey, >>> Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, >>> and Harlan Yu. Proceedings of ACM SIGCOMM 2005, August 2005. >>> >>> A Case Study in Building Layered DHT Applications. Yatin Chawathe, Sriram >>> Ramabhadran, Sylvia Ratnasamy, Anthony LaMarca, Scott Shenker, and Joseph >>> Hellerstein. Proceedings of ACM SIGCOMM 2005, August 2005. >>> >>> Spurring Adoption of DHTs with OpenHash, a Public DHT Service. Brad Karp, >>> Sylvia Ratnasamy, Sean Rhea, and Scott Shenker. Proceedings of the 3rd >>> International Workshop on Peer-to-Peer Systems (IPTPS 2004), > Springer-Verlag >>> Lecture Notes in Computer Science Hot Topics Series, San Diego, CA, >>> February, 2004. (The OpenDHT project was originally titled "OpenHash".) >>> >>> Thanks, Henry >>> >>> >>> >>> -----Original Message----- >>> From: p2p-sip-bounces at cs.columbia.edu >>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan >>> Sent: Thursday, May 25, 2006 8:30 PM >>> To: Brian Rosen >>> Cc: p2p-sip at cs.columbia.edu >>> Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching >>> >>> A bit more clarification. >>> >>> P2P over SIP means: "build a distributed lookup that SIP agents use to >>> locate each other, and use SIP messages to convey the >>> queries/organization for the distributed seach". The group would >>> standardize the extensions to SIP to do this. >>> >>> P2P for SIP means: "build a distributed lookup that SIP agents use to >>> locate each other, but it may use other message formats (I've heard >>> SOAP proposed) to convey the queries/organization for the distributed >>> search" The group would standardize that other protocol >>> >>> In both cases, the idea is regular SIP is used between the nodes. As >>> Greg points out, some (including my early work) proposed routing SIP >>> over the P2P layer as well. I backed off this a bit when many folks >>> objected in Vancouver, although I must admit that for NAT traversal >>> reasons, I'm liking it again. >>> >>> This is list of several hundred people. People have proposed building >>> a generic multi-purpose DHT using SIP here, and people have proposed >>> replacing SIP here. It has seemed quite clear from the responses that >>> the majority of people do not agree with that, and that certainly >>> those of us trying to organize P2PSIP do not support those things. >>> >>> --David >>> >>> >>> On 5/25/06, Brian Rosen wrote: >>> >>> >>>> I'm sorry, I don't get it. >>>> >>>> No one is proposing to use sip to do something equivalent to what a DHT >>>> does. >>>> >>>> Everyone is proposing to use sip messages to control session >>>> >>>> >>> establishment. >>> >>> >>>> A User Agent is going to send a pretty normal looking INVITE message. > The >>>> question at hand is how it routes it. It doesn't use the procedures in >>>> 3261. >>>> >>>> I don't understand the difference. I think that means I don't understand >>>> what p2p using sip means. As long as we are all agreeing that its sip >>>> messages to do session management, at least I think we're in a do-able >>>> situation. >>>> >>>> Brian >>>> >>>> -----Original Message----- >>>> From: Greg Daley [mailto:gregd at research.panasonic.com] >>>> Sent: Thursday, May 25, 2006 4:59 PM >>>> To: Brian Rosen >>>> Cc: 'Mike Robinson'; p2p-sip at cs.columbia.edu >>>> Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching >>>> >>>> Hi Brian, >>>> >>>> There's a distinction between P2P FOR sip and >>>> P2P USING sip. >>>> >>>> P2P FOR sip is a system which handles distributed >>>> lookup of SIP location URIs, >>>> >>>> P2P USING sip is a realization of how to do P2P FOR sip, >>>> using SIP protocol (or SIP protocol-like) messages or >>>> extensions. >>>> >>>> There's broad agreement that we want P2P FOR sip >>>> (the goal), but not necessarily agreement that >>>> we need P2P USING sip. >>>> >>>> This is not surprising, because the charter discussion >>>> is about what we want to get done (P2P FOR sip), >>>> rather than on exactly how to do it (e.g. P2P USING sip). >>>> >>>> Clear now? >>>> >>>> >>>> Brian Rosen wrote: >>>> >>>> >>>>> Okay, so here we are again. You are looking for an approved charter, >>>>> >>>>> >>> and >>> >>> >>>> we >>>> >>>> >>>>> don't know what we are trying to do. >>>>> >>>>> If there is consensus that this is to be a p2psip thing, then that's a >>>>> >>>>> >>>> whole >>>> >>>> >>>>> lot less work then if the sip part is still under discussion. >>>>> >>>>> I'd go so far as to say, if it's NOT p2psip, then we are really in IRTF >>>>> land. >>>>> >>>>> So, what is it? p2psip or >>>>> p2p-some-kind-of-multimedi-session-control-protocol? >>>>> >>>>> >>>>> >>>>> Brian >>>>> >>>>> -----Original Message----- >>>>> From: p2p-sip-bounces at cs.columbia.edu >>>>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley >>>>> Sent: Thursday, May 25, 2006 4:42 PM >>>>> To: Mike Robinson >>>>> Cc: p2p-sip at cs.columbia.edu >>>>> Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching >>>>> >>>>> Hi Mike, >>>>> >>>>> Mike Robinson wrote: >>>>> [cut] >>>>> >>>>> >>>>>> Unless someone can tell us clearly why sip should be used to create, >>>>>> manage and re-configure DHT, the goal should remain a "proposed goal" >>>>>> till then. IETF, or for that matter any standard organization should't >>>>>> be a willing tool to fulfil any particular company's vested interests >>>>>> (even when supposedly supported by (a company funded) researchers at >>>>>> >>>>>> >>> a >>> >>> >>>>>> University). >>>>>> >>>>>> >>>>> Only one of the (strawman) proposals says that SIP messages are used. >>>>> Alternative view on this have also been presented in the Ad-hoc sessions >>>>> leading up to the BoFs (and are still on the table). >>>>> >>>>> There's no clear winner, there's not even a coalition of people who >>>>> have backed one. >>>>> >>>>> Of course authors will each have points to make about their own ideas, >>>>> but that's why there's got to be a working group. So the community >>>>> can work on the requirements and make sure that the best solution is >>>>> used. >>>>> >>>>> If we didn't care about that, we'd just use/sell a proprietary system. >>>>> >>>>> >>>>> >>>>>> I am not opposed to p2p sip in whatever form - but don't understand the >>>>>> urgency being shown to push a certain design without evaluating >>>>>> alternative approaches. You don't need standardization right away to >>>>>> show that your model works- post your code to sourceforge.net and let >>>>>> >>>>>> >>> me >>> >>> >>>>>> see how good your design is by experimenting with it. >>>>>> >>>>>> >>>>> I think you've misread the situation. There is code for at least >>>>> one implementation of a proposal available (is it on sourceforge?). >>>>> >>>>> AFAIK, there's no-one here pushing a particular cart. >>>>> >>>>> People here have a real desire to bring about the best system >>>>> for p2p sip. There are people here willing to do the work >>>>> on assessing the protocol requirements, reviewing documents, >>>>> designing and building a protocol, following the IETF's >>>>> procedures. >>>>> >>>>> If we just wanted to get something out commercially and push a >>>>> particular agenda, we'd have made an industry consortium. >>>>> >>>>> It's a lot faster, it has more chance of success, and has less >>>>> inconvenient review. >>>>> >>>>> Help us to charter the WG, because that's where the IETF can >>>>> have control of the outputs, and ensure protocol quality. >>>>> >>>>> Greg >>>>> _______________________________________________ _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip --------------------------------- Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060526/b4d2256d/attachment-0001.html From enrico.marocco at telecomitalia.it Sat May 27 04:38:45 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Sat, 27 May 2006 10:38:45 +0200 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <44773359.9070909@research.panasonic.com> References: <20060525184219.94913.qmail@web38511.mail.mud.yahoo.com> <44761683.8040702@research.panasonic.com> <4476D6DF.3060707@telecomitalia.it> <44773359.9070909@research.panasonic.com> Message-ID: <44781015.2080305@telecomitalia.it> Greg Daley wrote: >> (yes, it is) At this point both written and coded proposals are only >> meant to show that a solution is feasible. > > Can you please repost the URL? http://sipdht.sourceforge.net Repository and snapshots are ok; mailing list doesn't work yet. >> There is a lot of discussion about the algorithm and the protocol for >> DHT maintainance; hey... are they really important, now? If a WG were >> formed people would be happily struggling for chord/kademlia/bamboo over >> SIP/SOAP/RMI; until a WG is started, such arguements are only wasted >> time. > > Arguments certainly may be a waste of time now. > > If we start contributing requirements, this may help though. > Having implementation experience certainly helps there. Agreed. Enrico From enrico.marocco at telecomitalia.it Sat May 27 06:15:27 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Sat, 27 May 2006 12:15:27 +0200 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <001d01c680e2$1b53f890$2800a8c0@DSX400> References: <001d01c680e2$1b53f890$2800a8c0@DSX400> Message-ID: <447826BF.5020500@telecomitalia.it> Henry, > ...or (2) just to start, one can use openDHT as an emerging _DHT service_. Is an external DHT service really different from a traditional location service (e.g. a SIP registrar or a dynamic DNS service)? I can understand it only as a temporary solution; if the location service wasn't distributed across SIP UAs, would this work have any real value? > 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. BTW: I've missed some messages and have had to look for them on the archive; does anyone have encountered the same problem? Enrico From gregd at research.panasonic.com Mon May 29 00:06:30 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Mon, 29 May 2006 00:06:30 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <447826BF.5020500@telecomitalia.it> References: <001d01c680e2$1b53f890$2800a8c0@DSX400> <447826BF.5020500@telecomitalia.it> Message-ID: <447A7346.1080102@research.panasonic.com> Hi Enrico, Enrico Marocco wrote: > Henry, > >> ...or (2) just to start, one can use openDHT as an emerging _DHT service_. > > Is an external DHT service really different from a traditional location > service (e.g. a SIP registrar or a dynamic DNS service)? I can > understand it only as a temporary solution; if the location service > wasn't distributed across SIP UAs, would this work have any real value? There are two logically distinct roles: 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. >> 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. Greg From enrico.marocco at telecomitalia.it Mon May 29 06:38:08 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Mon, 29 May 2006 12:38:08 +0200 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <447A7346.1080102@research.panasonic.com> References: <001d01c680e2$1b53f890$2800a8c0@DSX400> <447826BF.5020500@telecomitalia.it> <447A7346.1080102@research.panasonic.com> Message-ID: <447ACF10.30502@telecomitalia.it> Greg Daley wrote: >>> ...or (2) just to start, one can use openDHT as an emerging _DHT >>> service_. >> >> Is an external DHT service really different from a traditional location >> service (e.g. a SIP registrar or a dynamic DNS service)? I can >> understand it only as a temporary solution; if the location service >> wasn't distributed across SIP UAs, would this work have any real value? > > There are two logically distinct roles: > > 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. >>> 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? Enrico From gregd at research.panasonic.com Mon May 29 23:55:39 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Mon, 29 May 2006 23:55:39 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <447ACF10.30502@telecomitalia.it> References: <001d01c680e2$1b53f890$2800a8c0@DSX400> <447826BF.5020500@telecomitalia.it> <447A7346.1080102@research.panasonic.com> <447ACF10.30502@telecomitalia.it> Message-ID: <447BC23B.5060806@research.panasonic.com> 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 From fluffy at cisco.com Tue May 30 01:44:53 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Mon, 29 May 2006 22:44:53 -0700 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <4477341C.5000107@research.panasonic.com> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> Message-ID: One of the things that was confusing to people at the last BOF was what were you trying to standardize. Presumably the purpose of the a standard would be so that two different vendors could implement something that they would work together. Now I have tried to listen to the whole conversation and let me point out something that has caused me confusion. An architecture that we are tying to move away from with this work is that all the UAs connect to a proxy farm. The proxy farm has some complex and proprietary way to of sharing the state so that the UAs can find other UAs. This has central servers that, as Henry points out are expensive because of the support staff they imply which implies a spiraling circle of things this work is trying to avoid. Now the group is sticking with the idea that there is some sort of SIP location database and perhaps distributed TURN servers. However this would be stored in a DHT (or something like one). The storage would be distributed across a bunch of nodes that participated in the storage. Now we come to what I see as the first critical question of what is this group proposing to do. Who can build one of these nodes that participates in the storage of the location database information? If your answer is they all have to come from one vendor and speak a proprietary protocol, then I don't really see why this will be different from the model above that we are trying to avoid and I don't see who will run these, and furthermore I don't see what standardization is needed. I do not object to this path if this is where the group wants to go but theses are some of the next level down questions to answer on this path. An alternative path is that more than one vendor can build the things that participate in the DHT or store the location database information and that in some cases they same devices or computer that is the end UA will also have participate in this way. This answers the question of who will deploy and build these - everyone will and the end users will scale the location database storage as they connect more devices to the system. Who will run them will be the end users. However, it opens another set of questions. To do this you will need to standardize some DHT or set of DHTs like things and the protocols to update and mange them as well as store and retrieve information in them. I believe you could specify some protocol to build a DHT for the location database purpose and base it on some simple DHT today and include enough capabilities information that it could negotiate to different or more complex DHTs in the future. I find it easier to understand how this path will reach the goals we want of not having reliance on central providers for complex services - this may just be I don't understand the other path well enough and need to have it explained to me. I have asked but have not heard many answers yet. I have many more question down each branch of this tree but I think the high order bit is "who do we expect to run the servers that store information in the DHT". One answer is a central provider. The other answer is the users of the system. We need a crisp decision on this. Cullen (with my individual contributor hat on) From enrico.marocco at telecomitalia.it Tue May 30 06:19:21 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Tue, 30 May 2006 12:19:21 +0200 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <447BC23B.5060806@research.panasonic.com> References: <001d01c680e2$1b53f890$2800a8c0@DSX400> <447826BF.5020500@telecomitalia.it> <447A7346.1080102@research.panasonic.com> <447ACF10.30502@telecomitalia.it> <447BC23B.5060806@research.panasonic.com> Message-ID: <447C1C29.8040801@telecomitalia.it> 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 From enrico.marocco at telecomitalia.it Tue May 30 06:57:54 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Tue, 30 May 2006 12:57:54 +0200 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> Message-ID: <447C2532.7010805@telecomitalia.it> Cullen Jennings wrote: > I have many more question down each branch of this tree but I think > the high order bit is "who do we expect to run the servers that store > information in the DHT". One answer is a central provider. The other > answer is the users of the system. We need a crisp decision on this. Off course there is broad consensus for the latter. I think nobody really wants to rely on a central provider for storing information; someone - mainly Alan and Henry - are proposing to begin with the definition of a Location Service Protocol, which could be implemented from both external and P2P DHT-based services. The group would then focus on the definition of some protocols to let SIP devices build such DHTs. Actually, I think the strongest consensus is only for the second part, but it's just a feeling. Enrico From huang-ming.pan at comcast.net Tue May 30 12:20:51 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Tue, 30 May 2006 09:20:51 -0700 Subject: [p2p-sip] P2PSIP, Kademlia and caching References: <001d01c680e2$1b53f890$2800a8c0@DSX400><447826BF.5020500@telecomitalia.it><447A7346.1080102@research.panasonic.com><447ACF10.30502@telecomitalia.it> <447BC23B.5060806@research.panasonic.com> Message-ID: <001c01c68405$05dcfef0$6400a8c0@comcast.net> "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" To: "Enrico Marocco" Cc: ; ; "'David A. Bryan'" 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 > > From eunsoo at research.panasonic.com Tue May 30 12:46:22 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Tue, 30 May 2006 12:46:22 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <447C2532.7010805@telecomitalia.it> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> Message-ID: <447C76DE.8070303@research.panasonic.com> Enrico Marocco wrote: > Cullen Jennings wrote: >> I have many more question down each branch of this tree but I think >> the high order bit is "who do we expect to run the servers that store >> information in the DHT". One answer is a central provider. The other >> answer is the users of the system. We need a crisp decision on this. > > Off course there is broad consensus for the latter. > > I think nobody really wants to rely on a central provider for storing > information; someone - mainly Alan and Henry - are proposing to begin > with the definition of a Location Service Protocol, which could be > implemented from both external and P2P DHT-based services. The group > would then focus on the definition of some protocols to let SIP devices > build such DHTs. > I agree with Enrico. The motivation of the proposal of using OpenDHT (or any public DHT service) for most, if not all, people who are talking about it is that it will be easier for the proposed WG to start with the work of designing the access protocol (basically GET/PUT messages between the UAs and the DHT nodes and then work on the more difficult DHT protocol. I used to call the former the ON-SN protocol and the latter the SN-SN protocol (GET/PUT/JOIN/LEAVE). I believe that there is a strong consensus that eventually P2PSIP users should be able to build their own P2PSIP network without relying on any centralized provider. So the issue is whether we will work on two protocols in parallel or sequentially in my understanding but not whether we will enable UAs to participate in a DHT. My preference is that we put both protocols as deliverables in the initial charter but plan to finish the access protocol before the other protocol. > Actually, I think the strongest consensus is only for the second part, > but it's just a feeling. > Thanks. Eunsoo From gregd at research.panasonic.com Tue May 30 12:45:29 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Tue, 30 May 2006 12:45:29 -0400 Subject: [p2p-sip] P2PSIP, Kademlia and caching In-Reply-To: <447C1C29.8040801@telecomitalia.it> References: <001d01c680e2$1b53f890$2800a8c0@DSX400> <447826BF.5020500@telecomitalia.it> <447A7346.1080102@research.panasonic.com> <447ACF10.30502@telecomitalia.it> <447BC23B.5060806@research.panasonic.com> <447C1C29.8040801@telecomitalia.it> Message-ID: <447C76A9.1090408@research.panasonic.com> Hi Enrico, We're in violent agreement. Just answering the final question... Enrico Marocco wrote: [cut] > > 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. I don't think our draft explicitly discourages anything, but it did make assumptions (even having record formats, etc). Sathya's fixing this up for the next revision. It did concentrate on the separation of lookup and SIP, for the reasons mentioned earlier. Greg From fluffy at cisco.com Tue May 30 13:25:43 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Tue, 30 May 2006 10:25:43 -0700 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <447C76DE.8070303@research.panasonic.com> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> Message-ID: Ok, I'm glad to hear that at least some people think we have some consensus on this. It's been hard to tell following the list so I appreciate people speaking up about it. I'll be very blunt about doing both proposal. It is not clear to me if people think we should do both because 1) this is the technical long term solution we want, or 2) this would make it so at some level everyone agreed. Doing both will no doubt slow down finishing either. It is not clear to the that the GET/PUT only protocol would be used if the other GET/ PUT/JOIN/LEAVE exists - it seems like you would just want the later of the two. So if we look at our end goal, is there a need for GET/ PUT only. On May 30, 2006, at 9:46 AM, Eunsoo Shim wrote: > Enrico Marocco wrote: >> Cullen Jennings wrote: >>> I have many more question down each branch of this tree but I think >>> the high order bit is "who do we expect to run the servers that >>> store >>> information in the DHT". One answer is a central provider. The other >>> answer is the users of the system. We need a crisp decision on this. >> >> Off course there is broad consensus for the latter. >> >> I think nobody really wants to rely on a central provider for storing >> information; someone - mainly Alan and Henry - are proposing to begin >> with the definition of a Location Service Protocol, which could be >> implemented from both external and P2P DHT-based services. The group >> would then focus on the definition of some protocols to let SIP >> devices >> build such DHTs. >> > > I agree with Enrico. > The motivation of the proposal of using OpenDHT (or any public DHT > service) for most, if not all, people who are talking about it is that > it will be easier for the proposed WG to start with the work of > designing the access protocol (basically GET/PUT messages between the > UAs and the DHT nodes and then work on the more difficult DHT > protocol. > I used to call the former the ON-SN protocol and the latter the SN-SN > protocol (GET/PUT/JOIN/LEAVE). > > I believe that there is a strong consensus that eventually P2PSIP > users > should be able to build their own P2PSIP network without relying on > any > centralized provider. > > So the issue is whether we will work on two protocols in parallel or > sequentially in my understanding but not whether we will enable UAs to > participate in a DHT. > > My preference is that we put both protocols as deliverables in the > initial charter but plan to finish the access protocol before the > other > protocol. > > >> Actually, I think the strongest consensus is only for the second >> part, >> but it's just a feeling. >> > > Thanks. > > Eunsoo From alan at sipstation.com Tue May 30 13:39:52 2006 From: alan at sipstation.com (Alan Johnston) Date: Tue, 30 May 2006 12:39:52 -0500 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> Message-ID: <447C8368.2070104@sipstation.com> Cullen Jennings wrote: >Ok, I'm glad to hear that at least some people think we have some >consensus on this. It's been hard to tell following the list so I >appreciate people speaking up about it. > >I'll be very blunt about doing both proposal. It is not clear to me >if people think we should do both because >1) this is the technical long term solution we want, or >2) this would make it so at some level everyone agreed. > >Doing both will no doubt slow down finishing either. It is not clear >to the that the GET/PUT only protocol would be used if the other GET/ >PUT/JOIN/LEAVE exists - it seems like you would just want the later >of the two. So if we look at our end goal, is there a need for GET/ >PUT only. > > Yes. Real DHT nodes typically interact with 100s if not 1000s of peer nodes at any given instant. Will every SIP UA be capable of doing this? Think wireless, low bandwidth, and embedded UAs. There is a very clear layering and architectural choices here that if we only somehow choose one single DHT and standardize it that we will loose. Also, I think we need to first decide what information should be pushed and pulled from the DHT, what format it is, and how it will be retrieved. Then, and only then do we have the requirements for our DHT layer. To do both of these efforts them at the same time makes no sense to me. Thanks, Alan >On May 30, 2006, at 9:46 AM, Eunsoo Shim wrote: > > > >>Enrico Marocco wrote: >> >> >>>Cullen Jennings wrote: >>> >>> >>>>I have many more question down each branch of this tree but I think >>>>the high order bit is "who do we expect to run the servers that >>>>store >>>>information in the DHT". One answer is a central provider. The other >>>>answer is the users of the system. We need a crisp decision on this. >>>> >>>> >>>Off course there is broad consensus for the latter. >>> >>>I think nobody really wants to rely on a central provider for storing >>>information; someone - mainly Alan and Henry - are proposing to begin >>>with the definition of a Location Service Protocol, which could be >>>implemented from both external and P2P DHT-based services. The group >>>would then focus on the definition of some protocols to let SIP >>>devices >>>build such DHTs. >>> >>> >>> >>I agree with Enrico. >>The motivation of the proposal of using OpenDHT (or any public DHT >>service) for most, if not all, people who are talking about it is that >>it will be easier for the proposed WG to start with the work of >>designing the access protocol (basically GET/PUT messages between the >>UAs and the DHT nodes and then work on the more difficult DHT >>protocol. >>I used to call the former the ON-SN protocol and the latter the SN-SN >>protocol (GET/PUT/JOIN/LEAVE). >> >>I believe that there is a strong consensus that eventually P2PSIP >>users >>should be able to build their own P2PSIP network without relying on >>any >>centralized provider. >> >>So the issue is whether we will work on two protocols in parallel or >>sequentially in my understanding but not whether we will enable UAs to >>participate in a DHT. >> >>My preference is that we put both protocols as deliverables in the >>initial charter but plan to finish the access protocol before the >>other >>protocol. >> >> >> >> >>>Actually, I think the strongest consensus is only for the second >>>part, >>>but it's just a feeling. >>> >>> >>> >>Thanks. >> >>Eunsoo >> >> >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > From ksankar at cisco.com Tue May 30 13:47:21 2006 From: ksankar at cisco.com (Krishna Sankar (ksankar)) Date: Tue, 30 May 2006 10:47:21 -0700 Subject: [p2p-sip] What are we doing - question 1 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A4577E1@xmb-sjc-219.amer.cisco.com> Good thoughts. Yep, first we need to define the layers, information model and exchange mechanics. In the process if we can define a generic DHT mechanism that would be good as well. We should not prematurely choose a DHT. IMHO, any one of them will work and most probably newer ones will be coming soon to a computer nearby anyway ... Of course, after we have crisp and clear requirements, having worked on the various documents and implementations, we could recommend one or two DHT mechanisms that fits the bill. Most probably we would influence the DHT domain to come up with more optimized setup for SIP ... "A very efficient optimized rat catching cat will not help if we are looking for a horse" ;o) Cheers > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Alan Johnston > Sent: Tuesday, May 30, 2006 10:40 AM > To: Cullen Jennings (fluffy) > Cc: P2P-SIP > Subject: Re: [p2p-sip] What are we doing - question 1 > > Cullen Jennings wrote: > > >Ok, I'm glad to hear that at least some people think we have some > >consensus on this. It's been hard to tell following the list so I > >appreciate people speaking up about it. > > > >I'll be very blunt about doing both proposal. It is not > clear to me if > >people think we should do both because > >1) this is the technical long term solution we want, or > >2) this would make it so at some level everyone agreed. > > > >Doing both will no doubt slow down finishing either. It is > not clear to > >the that the GET/PUT only protocol would be used if the other GET/ > >PUT/JOIN/LEAVE exists - it seems like you would just want > the later of > >the two. So if we look at our end goal, is there a need for GET/ PUT > >only. > > > > > Yes. Real DHT nodes typically interact with 100s if not > 1000s of peer > nodes at any given instant. Will every SIP UA be capable of doing > this? Think wireless, low bandwidth, and embedded UAs. > > There is a very clear layering and architectural choices here > that if we > only somehow choose one single DHT and standardize it that we > will loose. > > Also, I think we need to first decide what information should > be pushed > and pulled from the DHT, what format it is, and how it will be > retrieved. Then, and only then do we have the requirements > for our DHT > layer. To do both of these efforts them at the same time > makes no sense > to me. > > Thanks, > Alan > > >On May 30, 2006, at 9:46 AM, Eunsoo Shim wrote: > > > > > > > >>Enrico Marocco wrote: > >> > >> > >>>Cullen Jennings wrote: > >>> > >>> > >>>>I have many more question down each branch of this tree > but I think > >>>>the high order bit is "who do we expect to run the servers that > >>>>store > >>>>information in the DHT". One answer is a central > provider. The other > >>>>answer is the users of the system. We need a crisp > decision on this. > >>>> > >>>> > >>>Off course there is broad consensus for the latter. > >>> > >>>I think nobody really wants to rely on a central provider > for storing > >>>information; someone - mainly Alan and Henry - are > proposing to begin > >>>with the definition of a Location Service Protocol, which could be > >>>implemented from both external and P2P DHT-based services. > The group > >>>would then focus on the definition of some protocols to let SIP > >>>devices > >>>build such DHTs. > >>> > >>> > >>> > >>I agree with Enrico. > >>The motivation of the proposal of using OpenDHT (or any public DHT > >>service) for most, if not all, people who are talking about > it is that > >>it will be easier for the proposed WG to start with the work of > >>designing the access protocol (basically GET/PUT messages > between the > >>UAs and the DHT nodes and then work on the more difficult DHT > >>protocol. > >>I used to call the former the ON-SN protocol and the latter > the SN-SN > >>protocol (GET/PUT/JOIN/LEAVE). > >> > >>I believe that there is a strong consensus that eventually P2PSIP > >>users > >>should be able to build their own P2PSIP network without > relying on > >>any > >>centralized provider. > >> > >>So the issue is whether we will work on two protocols in parallel or > >>sequentially in my understanding but not whether we will > enable UAs to > >>participate in a DHT. > >> > >>My preference is that we put both protocols as deliverables in the > >>initial charter but plan to finish the access protocol before the > >>other > >>protocol. > >> > >> > >> > >> > >>>Actually, I think the strongest consensus is only for the second > >>>part, > >>>but it's just a feeling. > >>> > >>> > >>> > >>Thanks. > >> > >>Eunsoo > >> > >> > >_______________________________________________ > >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 RADHIKA.R.ROY at saic.com Tue May 30 13:56:49 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Tue, 30 May 2006 13:56:49 -0400 Subject: [p2p-sip] What are we doing - question 1 Message-ID: <62D92A9A02BCC845B202323D49A48426230E01@0591-ITS-EXMP02.us.saic.com> May be couple of BCP drafts can be created with certain DHTs as example implementations. Best regards, Radhika -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Krishna Sankar (ksankar) Sent: Tuesday, May 30, 2006 1:47 PM To: Alan Johnston; Cullen Jennings (fluffy) Cc: P2P-SIP Subject: Re: [p2p-sip] What are we doing - question 1 Good thoughts. Yep, first we need to define the layers, information model and exchange mechanics. In the process if we can define a generic DHT mechanism that would be good as well. We should not prematurely choose a DHT. IMHO, any one of them will work and most probably newer ones will be coming soon to a computer nearby anyway ... Of course, after we have crisp and clear requirements, having worked on the various documents and implementations, we could recommend one or two DHT mechanisms that fits the bill. Most probably we would influence the DHT domain to come up with more optimized setup for SIP ... "A very efficient optimized rat catching cat will not help if we are looking for a horse" ;o) Cheers From bryan at ethernot.org Tue May 30 14:01:56 2006 From: bryan at ethernot.org (David A. Bryan) Date: Tue, 30 May 2006 14:01:56 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <447C8368.2070104@sipstation.com> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> Message-ID: <8b2769930605301101s321caad2m65b1e8e85aa55746@mail.gmail.com> What do you have in mind as far as what is to be pushed/pulled? I know there have been discussions here of registration, and possibly locations of peers capable of functioning as relays. Are you thinking VM here? Arbitrary data? Agree what we store could influence the design. If we put too much in, we are however rapidly approaching a generic DHT, which while cool, wouldn't really be P2P SIP anymore. David On 5/30/06, Alan Johnston wrote: > Cullen Jennings wrote: > > >Ok, I'm glad to hear that at least some people think we have some > >consensus on this. It's been hard to tell following the list so I > >appreciate people speaking up about it. > > > >I'll be very blunt about doing both proposal. It is not clear to me > >if people think we should do both because > >1) this is the technical long term solution we want, or > >2) this would make it so at some level everyone agreed. > > > >Doing both will no doubt slow down finishing either. It is not clear > >to the that the GET/PUT only protocol would be used if the other GET/ > >PUT/JOIN/LEAVE exists - it seems like you would just want the later > >of the two. So if we look at our end goal, is there a need for GET/ > >PUT only. > > > > > Yes. Real DHT nodes typically interact with 100s if not 1000s of peer > nodes at any given instant. Will every SIP UA be capable of doing > this? Think wireless, low bandwidth, and embedded UAs. > > There is a very clear layering and architectural choices here that if we > only somehow choose one single DHT and standardize it that we will loose. > > Also, I think we need to first decide what information should be pushed > and pulled from the DHT, what format it is, and how it will be > retrieved. Then, and only then do we have the requirements for our DHT > layer. To do both of these efforts them at the same time makes no sense > to me. > > Thanks, > Alan > > >On May 30, 2006, at 9:46 AM, Eunsoo Shim wrote: > > > > > > > >>Enrico Marocco wrote: > >> > >> > >>>Cullen Jennings wrote: > >>> > >>> > >>>>I have many more question down each branch of this tree but I think > >>>>the high order bit is "who do we expect to run the servers that > >>>>store > >>>>information in the DHT". One answer is a central provider. The other > >>>>answer is the users of the system. We need a crisp decision on this. > >>>> > >>>> > >>>Off course there is broad consensus for the latter. > >>> > >>>I think nobody really wants to rely on a central provider for storing > >>>information; someone - mainly Alan and Henry - are proposing to begin > >>>with the definition of a Location Service Protocol, which could be > >>>implemented from both external and P2P DHT-based services. The group > >>>would then focus on the definition of some protocols to let SIP > >>>devices > >>>build such DHTs. > >>> > >>> > >>> > >>I agree with Enrico. > >>The motivation of the proposal of using OpenDHT (or any public DHT > >>service) for most, if not all, people who are talking about it is that > >>it will be easier for the proposed WG to start with the work of > >>designing the access protocol (basically GET/PUT messages between the > >>UAs and the DHT nodes and then work on the more difficult DHT > >>protocol. > >>I used to call the former the ON-SN protocol and the latter the SN-SN > >>protocol (GET/PUT/JOIN/LEAVE). > >> > >>I believe that there is a strong consensus that eventually P2PSIP > >>users > >>should be able to build their own P2PSIP network without relying on > >>any > >>centralized provider. > >> > >>So the issue is whether we will work on two protocols in parallel or > >>sequentially in my understanding but not whether we will enable UAs to > >>participate in a DHT. > >> > >>My preference is that we put both protocols as deliverables in the > >>initial charter but plan to finish the access protocol before the > >>other > >>protocol. > >> > >> > >> > >> > >>>Actually, I think the strongest consensus is only for the second > >>>part, > >>>but it's just a feeling. > >>> > >>> > >>> > >>Thanks. > >> > >>Eunsoo > >> > >> > >_______________________________________________ > >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 bryan at ethernot.org Tue May 30 14:06:05 2006 From: bryan at ethernot.org (David A. Bryan) Date: Tue, 30 May 2006 14:06:05 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <9FA16888AD1BF64ABCE6C2532CCEB98A4577E1@xmb-sjc-219.amer.cisco.com> References: <9FA16888AD1BF64ABCE6C2532CCEB98A4577E1@xmb-sjc-219.amer.cisco.com> Message-ID: <8b2769930605301106m47880f6dy43ba294feae61165@mail.gmail.com> I agree that we likely will discover most any DHT will work. However, many of the (very) recent optimization of DHT papers I have seen are marginally more efficient at a cost of massively increased complexity, so it isn't always clear to me that newer=better. The folks designing these are often (although certainly not always) algorithms researchers, and often implementation is the furthest thing from the mind of the paper author. We should be a bit careful. David On 5/30/06, Krishna Sankar (ksankar) wrote: > > Good thoughts. Yep, first we need to define the layers, information > model and exchange mechanics. In the process if we can define a generic > DHT mechanism that would be good as well. We should not prematurely > choose a DHT. > > IMHO, any one of them will work and most probably newer ones will be > coming soon to a computer nearby anyway ... Of course, after we have > crisp and clear requirements, having worked on the various documents and > implementations, we could recommend one or two DHT mechanisms that fits > the bill. Most probably we would influence the DHT domain to come up > with more optimized setup for SIP ... > > "A very efficient optimized rat catching cat will not help if we are > looking for a horse" ;o) > > Cheers > > > > -----Original Message----- > > From: p2p-sip-bounces at cs.columbia.edu > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Alan Johnston > > Sent: Tuesday, May 30, 2006 10:40 AM > > To: Cullen Jennings (fluffy) > > Cc: P2P-SIP > > Subject: Re: [p2p-sip] What are we doing - question 1 > > > > Cullen Jennings wrote: > > > > >Ok, I'm glad to hear that at least some people think we have some > > >consensus on this. It's been hard to tell following the list so I > > >appreciate people speaking up about it. > > > > > >I'll be very blunt about doing both proposal. It is not > > clear to me if > > >people think we should do both because > > >1) this is the technical long term solution we want, or > > >2) this would make it so at some level everyone agreed. > > > > > >Doing both will no doubt slow down finishing either. It is > > not clear to > > >the that the GET/PUT only protocol would be used if the other GET/ > > >PUT/JOIN/LEAVE exists - it seems like you would just want > > the later of > > >the two. So if we look at our end goal, is there a need for GET/ PUT > > >only. > > > > > > > > Yes. Real DHT nodes typically interact with 100s if not > > 1000s of peer > > nodes at any given instant. Will every SIP UA be capable of doing > > this? Think wireless, low bandwidth, and embedded UAs. > > > > There is a very clear layering and architectural choices here > > that if we > > only somehow choose one single DHT and standardize it that we > > will loose. > > > > Also, I think we need to first decide what information should > > be pushed > > and pulled from the DHT, what format it is, and how it will be > > retrieved. Then, and only then do we have the requirements > > for our DHT > > layer. To do both of these efforts them at the same time > > makes no sense > > to me. > > > > Thanks, > > Alan > > > > >On May 30, 2006, at 9:46 AM, Eunsoo Shim wrote: > > > > > > > > > > > >>Enrico Marocco wrote: > > >> > > >> > > >>>Cullen Jennings wrote: > > >>> > > >>> > > >>>>I have many more question down each branch of this tree > > but I think > > >>>>the high order bit is "who do we expect to run the servers that > > >>>>store > > >>>>information in the DHT". One answer is a central > > provider. The other > > >>>>answer is the users of the system. We need a crisp > > decision on this. > > >>>> > > >>>> > > >>>Off course there is broad consensus for the latter. > > >>> > > >>>I think nobody really wants to rely on a central provider > > for storing > > >>>information; someone - mainly Alan and Henry - are > > proposing to begin > > >>>with the definition of a Location Service Protocol, which could be > > >>>implemented from both external and P2P DHT-based services. > > The group > > >>>would then focus on the definition of some protocols to let SIP > > >>>devices > > >>>build such DHTs. > > >>> > > >>> > > >>> > > >>I agree with Enrico. > > >>The motivation of the proposal of using OpenDHT (or any public DHT > > >>service) for most, if not all, people who are talking about > > it is that > > >>it will be easier for the proposed WG to start with the work of > > >>designing the access protocol (basically GET/PUT messages > > between the > > >>UAs and the DHT nodes and then work on the more difficult DHT > > >>protocol. > > >>I used to call the former the ON-SN protocol and the latter > > the SN-SN > > >>protocol (GET/PUT/JOIN/LEAVE). > > >> > > >>I believe that there is a strong consensus that eventually P2PSIP > > >>users > > >>should be able to build their own P2PSIP network without > > relying on > > >>any > > >>centralized provider. > > >> > > >>So the issue is whether we will work on two protocols in parallel or > > >>sequentially in my understanding but not whether we will > > enable UAs to > > >>participate in a DHT. > > >> > > >>My preference is that we put both protocols as deliverables in the > > >>initial charter but plan to finish the access protocol before the > > >>other > > >>protocol. > > >> > > >> > > >> > > >> > > >>>Actually, I think the strongest consensus is only for the second > > >>>part, > > >>>but it's just a feeling. > > >>> > > >>> > > >>> > > >>Thanks. > > >> > > >>Eunsoo > > >> > > >> > > >_______________________________________________ > > >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 ksankar at cisco.com Tue May 30 15:03:42 2006 From: ksankar at cisco.com (Krishna Sankar (ksankar)) Date: Tue, 30 May 2006 12:03:42 -0700 Subject: [p2p-sip] What are we doing - question 1 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A45786C@xmb-sjc-219.amer.cisco.com> Agreed. We should keep the accidental complexities (e.g. DHT et al) to a minimum and ascertain the essential domain complexity (i.e. the mechanics for SIP). As you aptly said, the goal is to have a P2P-SIP stressing min complexity, faster organization without a pure central authority, easier interoperability, good architecture and orthogonal extensibility to incorporate newer technologies. Cheers > -----Original Message----- > From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > Behalf Of David A. Bryan > Sent: Tuesday, May 30, 2006 11:06 AM > To: Krishna Sankar (ksankar) > Cc: Alan Johnston; Cullen Jennings (fluffy); P2P-SIP > Subject: Re: [p2p-sip] What are we doing - question 1 > > I agree that we likely will discover most any DHT will work. > However, many of the (very) recent optimization of DHT papers > I have seen are marginally more efficient at a cost of > massively increased complexity, so it isn't always clear to > me that newer=better. The folks designing these are often > (although certainly not always) algorithms researchers, and > often implementation is the furthest thing from the mind of > the paper author. We should be a bit careful. > > David > > On 5/30/06, Krishna Sankar (ksankar) wrote: > > > > Good thoughts. Yep, first we need to define the layers, information > > model and exchange mechanics. In the process if we can define a > > generic DHT mechanism that would be good as well. We should not > > prematurely choose a DHT. > > > > IMHO, any one of them will work and most probably newer > ones will be > > coming soon to a computer nearby anyway ... Of course, > after we have > > crisp and clear requirements, having worked on the various > documents > > and implementations, we could recommend one or two DHT > mechanisms that > > fits the bill. Most probably we would influence the DHT > domain to come > > up with more optimized setup for SIP ... > > > > "A very efficient optimized rat catching cat will not help > if we are > > looking for a horse" ;o) > > > > Cheers > > > > > > > -----Original Message----- > > > From: p2p-sip-bounces at cs.columbia.edu > > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of > Alan Johnston > > > Sent: Tuesday, May 30, 2006 10:40 AM > > > To: Cullen Jennings (fluffy) > > > Cc: P2P-SIP > > > Subject: Re: [p2p-sip] What are we doing - question 1 > > > > > > Cullen Jennings wrote: > > > > > > >Ok, I'm glad to hear that at least some people think we > have some > > > >consensus on this. It's been hard to tell following the > list so I > > > >appreciate people speaking up about it. > > > > > > > >I'll be very blunt about doing both proposal. It is not > > > clear to me if > > > >people think we should do both because > > > >1) this is the technical long term solution we want, or > > > >2) this would make it so at some level everyone agreed. > > > > > > > >Doing both will no doubt slow down finishing either. It is > > > not clear to > > > >the that the GET/PUT only protocol would be used if the > other GET/ > > > >PUT/JOIN/LEAVE exists - it seems like you would just want > > > the later of > > > >the two. So if we look at our end goal, is there a need for GET/ > > > >PUT only. > > > > > > > > > > > Yes. Real DHT nodes typically interact with 100s if not 1000s of > > > peer nodes at any given instant. Will every SIP UA be capable of > > > doing this? Think wireless, low bandwidth, and embedded UAs. > > > > > > There is a very clear layering and architectural choices > here that > > > if we only somehow choose one single DHT and standardize > it that we > > > will loose. > > > > > > Also, I think we need to first decide what information should be > > > pushed and pulled from the DHT, what format it is, and > how it will > > > be retrieved. Then, and only then do we have the > requirements for > > > our DHT layer. To do both of these efforts them at the same time > > > makes no sense to me. > > > > > > Thanks, > > > Alan > > > > > > >On May 30, 2006, at 9:46 AM, Eunsoo Shim wrote: > > > > > > > > > > > > > > > >>Enrico Marocco wrote: > > > >> > > > >> > > > >>>Cullen Jennings wrote: > > > >>> > > > >>> > > > >>>>I have many more question down each branch of this tree > > > but I think > > > >>>>the high order bit is "who do we expect to run the > servers that > > > >>>>store information in the DHT". One answer is a central > > > provider. The other > > > >>>>answer is the users of the system. We need a crisp > > > decision on this. > > > >>>> > > > >>>> > > > >>>Off course there is broad consensus for the latter. > > > >>> > > > >>>I think nobody really wants to rely on a central provider > > > for storing > > > >>>information; someone - mainly Alan and Henry - are > > > proposing to begin > > > >>>with the definition of a Location Service Protocol, > which could > > > >>>be implemented from both external and P2P DHT-based services. > > > The group > > > >>>would then focus on the definition of some protocols > to let SIP > > > >>>devices build such DHTs. > > > >>> > > > >>> > > > >>> > > > >>I agree with Enrico. > > > >>The motivation of the proposal of using OpenDHT (or any > public DHT > > > >>service) for most, if not all, people who are talking about > > > it is that > > > >>it will be easier for the proposed WG to start with the work of > > > >>designing the access protocol (basically GET/PUT messages > > > between the > > > >>UAs and the DHT nodes and then work on the more difficult DHT > > > >>protocol. > > > >>I used to call the former the ON-SN protocol and the latter > > > the SN-SN > > > >>protocol (GET/PUT/JOIN/LEAVE). > > > >> > > > >>I believe that there is a strong consensus that > eventually P2PSIP > > > >>users should be able to build their own P2PSIP network without > > > relying on > > > >>any > > > >>centralized provider. > > > >> > > > >>So the issue is whether we will work on two protocols > in parallel > > > >>or sequentially in my understanding but not whether we will > > > enable UAs to > > > >>participate in a DHT. > > > >> > > > >>My preference is that we put both protocols as > deliverables in the > > > >>initial charter but plan to finish the access protocol > before the > > > >>other protocol. > > > >> > > > >> > > > >> > > > >> > > > >>>Actually, I think the strongest consensus is only for > the second > > > >>>part, but it's just a feeling. > > > >>> > > > >>> > > > >>> > > > >>Thanks. > > > >> > > > >>Eunsoo > > > >> > > > >> > > > >_______________________________________________ > > > >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 eunsoo at research.panasonic.com Tue May 30 15:07:51 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Tue, 30 May 2006 15:07:51 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <447C8368.2070104@sipstation.com> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> Message-ID: <447C9807.4000904@research.panasonic.com> Alan Johnston wrote: > Cullen Jennings wrote: > >> Ok, I'm glad to hear that at least some people think we have some >> consensus on this. It's been hard to tell following the list so I >> appreciate people speaking up about it. >> >> I'll be very blunt about doing both proposal. It is not clear to me >> if people think we should do both because >> 1) this is the technical long term solution we want, or >> 2) this would make it so at some level everyone agreed. >> >> Doing both will no doubt slow down finishing either. It is not clear >> to the that the GET/PUT only protocol would be used if the other GET/ >> PUT/JOIN/LEAVE exists - it seems like you would just want the later >> of the two. So if we look at our end goal, is there a need for GET/ >> PUT only. >> >> > Yes. Real DHT nodes typically interact with 100s if not 1000s of peer > nodes at any given instant. Will every SIP UA be capable of doing > this? Think wireless, low bandwidth, and embedded UAs. An excellent explanation. There is a need to package just GET/PUT into a protocol even though the DHT protocol contains GET/PUT as well as JOIN/LEAVE. It is too early to talk about syntax of the protocols but in general the GET/PUT only protocol may or may not have the same syntax as the DHT protocol. Depending on the detailed design, the GET/PUT only protocol specification may be just a subset of the other protocol's specification or may be a completely different protocol. > There is a very clear layering and architectural choices here that if we > only somehow choose one single DHT and standardize it that we will loose. > I think there is also a consensus that the DHTs (or P2P overlay technologies) are evolving continuously and the proposed WG should not / cannot decide which DHT is the best but it is not wise either to wait until someone picks the best DHT algorithm for us or it becomes certain no new better DHT algorithm will appear. So what has been proposed was that we need to pick at least one DHT algorithm but may pick more (not many but just a few) later so that we can have implementation, experiments, and interoperability. I think we all agree that there is no DHT algorithm fitting all scenarios the best way. Since the call setup logic and the DHT function are separate and quite independent, by a proper modular architecture, we will be able to adopt new DHTs (or other P2P algorithms) fairly straightforwardly or at least without breaking too many things. > Also, I think we need to first decide what information should be pushed > and pulled from the DHT, what format it is, and how it will be > retrieved. Then, and only then do we have the requirements for our DHT > layer. I agree. This is another important deliverable. So we have three key deliverables: (1) the GET/PUT only protocol (2) the GET/PUT/JOIN/LEAVE protocol (a DHT) (3) Information to be stored at and retrieved from the DHT, how it will be handled. (This may include some basic call procedures.) Another deliverable proposed and stressed so far was (4) how to find proper (close) media relays or STUN relays. I think (3) and (4) are or can be independent of the selected DHT algorithm as long as the DHT algorithm meet the requirements. That is, we can change the underling DHT algorithm without breaking (3) and (4). We may have even (1) independent of the DHT algorithm choice. For (1) and (2), the basic functions are all well-understood. But what security and reliability features we want will have significant influence on the protocol specifics. To do both of these efforts them at the same time makes no sense > to me. > Hmm.. Alan is proposing to put a minimum set in the initial charter while I am somewhat liberal about it. Thanks. Eunsoo >> On May 30, 2006, at 9:46 AM, Eunsoo Shim wrote: >> >> >> >>> Enrico Marocco wrote: >>> >>>> Cullen Jennings wrote: >>>> >>>>> I have many more question down each branch of this tree but I think >>>>> the high order bit is "who do we expect to run the servers that store >>>>> information in the DHT". One answer is a central provider. The other >>>>> answer is the users of the system. We need a crisp decision on this. >>>>> >>>> Off course there is broad consensus for the latter. >>>> >>>> I think nobody really wants to rely on a central provider for storing >>>> information; someone - mainly Alan and Henry - are proposing to begin >>>> with the definition of a Location Service Protocol, which could be >>>> implemented from both external and P2P DHT-based services. The group >>>> would then focus on the definition of some protocols to let SIP >>>> devices >>>> build such DHTs. >>>> >>>> >>> I agree with Enrico. >>> The motivation of the proposal of using OpenDHT (or any public DHT >>> service) for most, if not all, people who are talking about it is that >>> it will be easier for the proposed WG to start with the work of >>> designing the access protocol (basically GET/PUT messages between the >>> UAs and the DHT nodes and then work on the more difficult DHT protocol. >>> I used to call the former the ON-SN protocol and the latter the SN-SN >>> protocol (GET/PUT/JOIN/LEAVE). >>> >>> I believe that there is a strong consensus that eventually P2PSIP users >>> should be able to build their own P2PSIP network without relying on any >>> centralized provider. >>> >>> So the issue is whether we will work on two protocols in parallel or >>> sequentially in my understanding but not whether we will enable UAs to >>> participate in a DHT. >>> >>> My preference is that we put both protocols as deliverables in the >>> initial charter but plan to finish the access protocol before the other >>> protocol. >>> >>> >>> >>>> Actually, I think the strongest consensus is only for the second part, >>>> but it's just a feeling. >>>> >>>> >>> Thanks. >>> >>> Eunsoo >>> >> _______________________________________________ >> p2p-sip mailing list >> p2p-sip at cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >> >> >> >> > From fluffy at cisco.com Tue May 30 18:09:25 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Tue, 30 May 2006 15:09:25 -0700 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <447C8368.2070104@sipstation.com> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> Message-ID: On May 30, 2006, at 10:39 AM, Alan Johnston wrote: > Cullen Jennings wrote: > >> Ok, I'm glad to hear that at least some people think we have some >> consensus on this. It's been hard to tell following the list so I >> appreciate people speaking up about it. >> >> I'll be very blunt about doing both proposal. It is not clear to >> me if people think we should do both because >> 1) this is the technical long term solution we want, or >> 2) this would make it so at some level everyone agreed. >> >> Doing both will no doubt slow down finishing either. It is not >> clear to the that the GET/PUT only protocol would be used if the >> other GET/ PUT/JOIN/LEAVE exists - it seems like you would just >> want the later of the two. So if we look at our end goal, is >> there a need for GET/ PUT only. >> > Yes. Real DHT nodes typically interact with 100s if not 1000s of > peer nodes at any given instant. Will every SIP UA be capable of > doing this? I'll use chord as an example here not because I think chord is the right DHT but only as a concrete example. A node that knew a few other chord nodes but was not storing any data could easily interact with the DHT and only have very few connections. > Think wireless, low bandwidth, and embedded UAs. > There is a very clear layering and architectural choices here that > if we only somehow choose one single DHT and standardize it that we > will loose. So I take it you are saying we should NOT do the GET/PUT/JOIN/LEAVE protocol. This is the part that I am failing to understand. I think it would be great if we could have no central servers and not standardized a P2P protocol but I don't see how we can have our cake and eat it too. > > Also, I think we need to first decide what information should be > pushed and pulled from the DHT, what format it is, and how it will > be retrieved. Then, and only then do we have the requirements for > our DHT layer. I agree here but I don't see how this has to do with making a protocol for the GET/PUT. > To do both of these efforts them at the same time makes no sense to > me. Agree here too. From karstbj at yahoo.com Wed May 31 03:58:12 2006 From: karstbj at yahoo.com (Karst Bjorgson) Date: Wed, 31 May 2006 00:58:12 -0700 (PDT) Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: Message-ID: <20060531075812.67764.qmail@web53004.mail.yahoo.com> > So I take it you are saying we should NOT do the > GET/PUT/JOIN/LEAVE > protocol. This is the part that I am failing to > understand. I think > it would be great if we could have no central > servers and not > standardized a P2P protocol but I don't see how we > can have our cake > and eat it too. The classic DHT protocols are optimized to publish many hash indices on a relatively smaller number of nodes. This is the basis for the "PUT" primitive: find the node most appropriate to publish a given index. The typical use is a large database, in which each node holds thousands of records. Much efficiency is gained by pushing the indices of these records at the nodes with the closest ID. In such networks, the overhead of maintaining a "routing table" between the nodes is not much of a concern. P2PSIP has a very different structure. The average P2P SIP UA publishes exactly one SIP URL. In these conditions, there is not much value in the "PUT" primitive. The SIP URL is the node's ID, so the PUT is a strictly local operation. The DHT for the P2PSIP application will typically operate with "one record per node". Routing overhead is going to matter a lot. Designs like Chord or Pastry may be seriously suboptimal. -- Karst __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From enrico.marocco at telecomitalia.it Wed May 31 10:56:19 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Wed, 31 May 2006 16:56:19 +0200 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> Message-ID: <447DAE93.1090205@telecomitalia.it> Cullen Jennings wrote: > Doing both will no doubt slow down finishing either. It is not clear to > the that the GET/PUT only protocol would be used if the other > GET/PUT/JOIN/LEAVE exists - it seems like you would just want the later > of the two. So if we look at our end goal, is there a need for GET/PUT > only. No, there isn't. Moreover, aren't IMS Cx, Dx and Sh interfaces (based on DIAMETER) a superset of the G/P you are talking about? I think it would be an error submitting a charter with such a goal. The group should instead focus on (unordered): + defining the general architecture which would let canonical and P2P SIP interoperate; + defining a DHT negotiation mechanism; + defining some discovery mechanisms; + defining some DHTs for different usages (e.g. in ad-hoc networks, metropolitan wlans...). The more advanced/structured they are, the more generally adopted they will be; the more basic, the more specifically. My 2 cents. Enrico From bryan at ethernot.org Wed May 31 10:58:53 2006 From: bryan at ethernot.org (David A. Bryan) Date: Wed, 31 May 2006 10:58:53 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <20060531075812.67764.qmail@web53004.mail.yahoo.com> References: <20060531075812.67764.qmail@web53004.mail.yahoo.com> Message-ID: <8b2769930605310758u7f3a40a5v8dc705642f08408b@mail.gmail.com> I think it is very unlikely that the URL will be the node's ID. In fact, you explicitly want users to be able to choose a URI of some meaning (hopefully more meaning and easier to remember than a phone number, which a 160 bit Node ID certainly isn't), while a node ID should (to prevent many of the placement of a node in the overlay based attacks on DHTs) be random and not chosen by the user. I agree it is likely a user will publish one record per node, although it may refresh it periodically, and redundancy may lead to storing on average more than 1 item per node (likely n where n is the number of mirrors of each registration you store for redundancy). All of this assumes a flat architecture, of course. If you used a supernode type structure then obviously you might have many registrations per DHT node. If other information is stored beyond registrations, as people have mentioned doing in the future, that would also increase the items being stored by each node. --David On 5/31/06, Karst Bjorgson wrote: > > So I take it you are saying we should NOT do the > > GET/PUT/JOIN/LEAVE > > protocol. This is the part that I am failing to > > understand. I think > > it would be great if we could have no central > > servers and not > > standardized a P2P protocol but I don't see how we > > can have our cake > > and eat it too. > > The classic DHT protocols are optimized to publish > many hash indices on a relatively smaller number of > nodes. This is the basis for the "PUT" primitive: find > the node most appropriate to publish a given index. > The typical use is a large database, in which each > node holds thousands of records. Much efficiency is > gained by pushing the indices of these records at the > nodes with the closest ID. In such networks, the > overhead of maintaining a "routing table" between the > nodes is not much of a concern. > > P2PSIP has a very different structure. The average P2P > SIP UA publishes exactly one SIP URL. In these > conditions, there is not much value in the "PUT" > primitive. The SIP URL is the node's ID, so the PUT is > a strictly local operation. The DHT for the P2PSIP > application will typically operate with "one record > per node". Routing overhead is going to matter a lot. > Designs like Chord or Pastry may be seriously > suboptimal. > > -- Karst > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From eunsoo at research.panasonic.com Wed May 31 11:29:10 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 31 May 2006 11:29:10 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <20060531075812.67764.qmail@web53004.mail.yahoo.com> References: <20060531075812.67764.qmail@web53004.mail.yahoo.com> Message-ID: <447DB646.2050300@research.panasonic.com> Karst Bjorgson wrote: >>So I take it you are saying we should NOT do the >>GET/PUT/JOIN/LEAVE >>protocol. This is the part that I am failing to >>understand. I think >>it would be great if we could have no central >>servers and not >>standardized a P2P protocol but I don't see how we >>can have our cake >>and eat it too. >> >> > >The classic DHT protocols are optimized to publish >many hash indices on a relatively smaller number of >nodes. This is the basis for the "PUT" primitive: find >the node most appropriate to publish a given index. >The typical use is a large database, in which each >node holds thousands of records. Much efficiency is >gained by pushing the indices of these records at the >nodes with the closest ID. In such networks, the >overhead of maintaining a "routing table" between the >nodes is not much of a concern. > >P2PSIP has a very different structure. The average P2P >SIP UA publishes exactly one SIP URL. In these >conditions, there is not much value in the "PUT" >primitive. > I guess you mean publishing user location information (URL -> IP address mapping) by 'publishing a SIP URL'. User location information is certainly the most important information to be published in the P2PSIP network but not the only one. We can imagine easily that P2PSIP networks need to support presence information and VM exchange between users which might be done via the P2P network as well. >The SIP URL is the node's ID, so the PUT is >a strictly local operation. > I am not sure I understand this. How does a caller find the mapping of URI to IP address if the mapping is not published using the DHT PUT operation? >The DHT for the P2PSIP >application will typically operate with "one record >per node". Routing overhead is going to matter a lot. >Designs like Chord or Pastry may be seriously >suboptimal. > > Thanks. Eunsoo From bk9001 at gmail.com Wed May 31 11:53:42 2006 From: bk9001 at gmail.com (Brijesh Kumar) Date: Wed, 31 May 2006 11:53:42 -0400 Subject: [p2p-sip] What are we doing - question 1 References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com><44761920.7030403@research.panasonic.com><4476D80E.7070100@telecomitalia.it><4477341C.5000107@research.panasonic.com><447C2532.7010805@telecomitalia.it><447C76DE.8070303@research.panasonic.com> <447DAE93.1090205@telecomitalia.it> Message-ID: <00ee01c684ca$6b5e7310$110aa8c0@Shikky> ----- Original Message ----- From: "Enrico Marocco" > > The group should instead focus on (unordered): > + defining the general architecture which would let canonical and P2P > SIP interoperate; > + defining a DHT negotiation mechanism; > + defining some discovery mechanisms; > + defining some DHTs for different usages (e.g. in ad-hoc networks, > metropolitan wlans...). The more advanced/structured they are, the > more generally adopted they will be; the more basic, the more > specifically. For a small network, a DHT is not needed - one can create a simple table of SIP URIs and node mapping, or learn such a mapping through a simple service discovery protocol (use SLP, UPnP (SSDP) or other networking means (Dynamic DNS, DHCP, Radius Extension etc.)). I think the real benefit of DHT is in scalability - so if the scale does not require a DHT, it makes little sense to have one since you can have lot simpler implementation in your nodes. cheers, --bk From eunsoo at research.panasonic.com Wed May 31 12:07:45 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 31 May 2006 12:07:45 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> Message-ID: <447DBF51.8030803@research.panasonic.com> Cullen Jennings wrote: > > On May 30, 2006, at 10:39 AM, Alan Johnston wrote: > >> Cullen Jennings wrote: >> >>> Ok, I'm glad to hear that at least some people think we have some >>> consensus on this. It's been hard to tell following the list so I >>> appreciate people speaking up about it. >>> >>> I'll be very blunt about doing both proposal. It is not clear to >>> me if people think we should do both because >>> 1) this is the technical long term solution we want, or >>> 2) this would make it so at some level everyone agreed. >>> >>> Doing both will no doubt slow down finishing either. It is not >>> clear to the that the GET/PUT only protocol would be used if the >>> other GET/ PUT/JOIN/LEAVE exists - it seems like you would just >>> want the later of the two. So if we look at our end goal, is there >>> a need for GET/ PUT only. >>> >> Yes. Real DHT nodes typically interact with 100s if not 1000s of >> peer nodes at any given instant. Will every SIP UA be capable of >> doing this? > > > I'll use chord as an example here not because I think chord is the > right DHT but only as a concrete example. A node that knew a few > other chord nodes but was not storing any data could easily interact > with the DHT and only have very few connections. > Please let me try to clarify the issure a little bit more. A node in Chord must maintain a finger table and data with keys of a certain range or locations of such data. Chord requires each node (in the Chord network) to have around log N fingers (where N is the total number of nodes in the Chord network and the base is 2). So if the network size is around 64,000, the number of fingers for each node is around 16. For a network of around a million nodes, the number becomes around 20. There is a cost for maintaining the finger table when the network is dynamic (nodes join and leave). Furthermore, each node should provide routing for various Chord messages such as GET/PUT/JOIN/LEAVE. When a node has limited bandwidth or battery power, the above requirements may be too much. If the node is behind NAT, it is not simple maintaining connections with fingers and other nodes for which the node is a finger. What I said kind of justifies the distinction between devices (SIP UAs) that participate in the DHT (Chord) and devices (SIP UAs) that do not. The devices that do not participate in the DHT don't need to support JOIN and LEAVE but need to do just GET/PUT. So now we have two interfaces. Node in DHT Node in DHT Node not in DHT |<---------------------------------------->|<------------------------------------------------------>| (a) GET/PUT (b) GET/PUT JOIN/LEAVE Now the question has a few angles. - Will (a) GET/PUT be dependent of the underling DHT algorithm? - Will (a) GET/PUT and (b) GET/PUT have any difference in the syntax and semantics? - Will it be difficult to separate (a) GET/PUT from JOIN/LEAVE? If an answer for any of the above question is 'yes', I think we'd be better off by defining (b) GET/PUT as a separate protocol. And I think it is a safe assumption. If we find out none of the answers is 'yes', then we would not need a separate protocol for (b) GET/PUT. Nodes not in DHT can safely just implement and support GET/PUT but not JOIN/LEAVE. Hope I added some clarity, not confusion. >> Think wireless, low bandwidth, and embedded UAs. >> There is a very clear layering and architectural choices here that >> if we only somehow choose one single DHT and standardize it that we >> will loose. > > > So I take it you are saying we should NOT do the GET/PUT/JOIN/LEAVE > protocol. This is the part that I am failing to understand. I think > it would be great if we could have no central servers and not > standardized a P2P protocol but I don't see how we can have our cake > and eat it too. > >> >> Also, I think we need to first decide what information should be >> pushed and pulled from the DHT, what format it is, and how it will >> be retrieved. Then, and only then do we have the requirements for >> our DHT layer. > > I agree here but I don't see how this has to do with making a > protocol for the GET/PUT. > > >> To do both of these efforts them at the same time makes no sense to me. > > Agree here too. > Thanks. Eunsoo From ggb at tid.es Wed May 31 12:39:10 2006 From: ggb at tid.es (=?iso-8859-1?Q?Gustavo_Garc=EDa_Bernardo?=) Date: Wed, 31 May 2006 18:39:10 +0200 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <00ee01c684ca$6b5e7310$110aa8c0@Shikky> Message-ID: <01d001c684d0$be723ea0$1603fea9@matrix2> > I think the real benefit of DHT is in scalability - so if the scale does > not > require > a DHT, it makes little sense to have one since you can have lot simpler > implementation in your nodes. It think the benefit is not only scalability, there are other benefits as easy deployment and robustness for example. I think DHT is also useful in small networks. Regards G. From bk9001 at gmail.com Wed May 31 13:55:11 2006 From: bk9001 at gmail.com (Brijesh Kumar) Date: Wed, 31 May 2006 13:55:11 -0400 Subject: [p2p-sip] What are we doing - question 1 References: <01d001c684d0$be723ea0$1603fea9@matrix2> Message-ID: <012b01c684db$5d8ffea0$110aa8c0@Shikky> ----- Original Message ----- From: "Gustavo Garc?a Bernardo" To: "'Brijesh Kumar'" ; "'Enrico Marocco'" ; "'Cullen Jennings'" Cc: "'P2P-SIP'" Sent: Wednesday, May 31, 2006 12:39 PM Subject: RE: [p2p-sip] What are we doing - question 1 >> I think the real benefit of DHT is in scalability - so if the scale does >> not >> require >> a DHT, it makes little sense to have one since you can have lot simpler >> implementation in your nodes. > > It think the benefit is not only scalability, there are other benefits as > easy deployment and robustness for example. I think DHT is also useful in > small networks. Gustavo: It appears there is divergence in the definition of "small". Basically, I don't see how registration and recovery of SIP URI and corresponding node IP address in a DHT is any different than basic service discovery in which a node registers its services so that other nodes in the network can learn about those services. There are a number of service discovery protocols that would work within an enterprise of reasonable size with quite robustness. As a matter fact, SSDP (UPnP) and SLP, both support fully distributed service discovery and do support a reasonable size network within an enterprise. So if you can use them for general service discovery, and believe they are robust enough, there is no reason they can't discover SIP URI and node-IP address mapping since that's all you need to enable p2p Sip within a "small" network. Let me clarify that I am not saying that one cannot build such a solution using DHT or use service discovery protocols to enable p2p sip, but only saying that DHT is not an absolute requirement, and there may be simpler approaches for people trying to enable p2p sip in a very "small" ad-hoc networks. cheers, --bk From huang-ming.pan at comcast.net Wed May 31 20:13:27 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 31 May 2006 17:13:27 -0700 Subject: [p2p-sip] What are we doing - question 1 References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com><447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> Message-ID: <024101c68510$355f3240$6400a8c0@comcast.net> The abstraction of GET/PUT seems ideal to wrap complex node interactions of different DHTs into a simple interface. Few questions: * Will there be some DHT "type tag" in the protocol so that a node in Kademlia DHT receiving a GET req from another node in Chord DHT will not dump irrelevant k closest nodes to the Chord node? * How will GET/PUT encapsulate difference of or convert distance "metric" information of different DHTs? (eg. Chord uses subtraction while Kademlia uses XOR to calculate node distance) * How will a node in DHT A locate the next-hop node in DHT B to send GET/PUT, which seems a precondition to interoperate DHTs on peer-to-peer basis? PP ----- Original Message ----- From: "Eunsoo Shim" To: "Cullen Jennings" Cc: "P2P-SIP" Sent: Wednesday, May 31, 2006 9:07 AM Subject: Re: [p2p-sip] What are we doing - question 1 > Cullen Jennings wrote: > > > > > On May 30, 2006, at 10:39 AM, Alan Johnston wrote: > > > >> Cullen Jennings wrote: > >> > >>> Ok, I'm glad to hear that at least some people think we have some > >>> consensus on this. It's been hard to tell following the list so I > >>> appreciate people speaking up about it. > >>> > >>> I'll be very blunt about doing both proposal. It is not clear to > >>> me if people think we should do both because > >>> 1) this is the technical long term solution we want, or > >>> 2) this would make it so at some level everyone agreed. > >>> > >>> Doing both will no doubt slow down finishing either. It is not > >>> clear to the that the GET/PUT only protocol would be used if the > >>> other GET/ PUT/JOIN/LEAVE exists - it seems like you would just > >>> want the later of the two. So if we look at our end goal, is there > >>> a need for GET/ PUT only. > >>> > >> Yes. Real DHT nodes typically interact with 100s if not 1000s of > >> peer nodes at any given instant. Will every SIP UA be capable of > >> doing this? > > > > > > I'll use chord as an example here not because I think chord is the > > right DHT but only as a concrete example. A node that knew a few > > other chord nodes but was not storing any data could easily interact > > with the DHT and only have very few connections. > > > Please let me try to clarify the issure a little bit more. > > A node in Chord must maintain a finger table and data with keys of a > certain range or locations of such data. > Chord requires each node (in the Chord network) to have around log N > fingers (where N is the total number of nodes in the Chord network and > the base is 2). So if the network size is around 64,000, the number of > fingers for each node is around 16. For a network of around a million > nodes, the number becomes around 20. > > There is a cost for maintaining the finger table when the network is > dynamic (nodes join and leave). Furthermore, each node should provide > routing for various Chord messages such as GET/PUT/JOIN/LEAVE. > > When a node has limited bandwidth or battery power, the above > requirements may be too much. If the node is behind NAT, it is not > simple maintaining connections with fingers and other nodes for which > the node is a finger. > > What I said kind of justifies the distinction between devices (SIP UAs) > that participate in the DHT (Chord) and devices (SIP UAs) that do not. > The devices that do not participate in the DHT don't need to support > JOIN and LEAVE but need to do just GET/PUT. > > So now we have two interfaces. > > Node in DHT Node in > DHT Node not in DHT > > > |<---------------------------------------->|<------------------------------- ----------------------->| > (a) GET/PUT (b) GET/PUT > JOIN/LEAVE > > Now the question has a few angles. > - Will (a) GET/PUT be dependent of the underling DHT algorithm? > - Will (a) GET/PUT and (b) GET/PUT have any difference in the syntax and > semantics? > - Will it be difficult to separate (a) GET/PUT from JOIN/LEAVE? > > If an answer for any of the above question is 'yes', I think we'd be > better off by defining (b) GET/PUT as a separate protocol. And I think > it is a safe assumption. > If we find out none of the answers is 'yes', then we would not need a > separate protocol for (b) GET/PUT. > Nodes not in DHT can safely just implement and support GET/PUT but not > JOIN/LEAVE. > > Hope I added some clarity, not confusion. > > >> Think wireless, low bandwidth, and embedded UAs. > >> There is a very clear layering and architectural choices here that > >> if we only somehow choose one single DHT and standardize it that we > >> will loose. > > > > > > So I take it you are saying we should NOT do the GET/PUT/JOIN/LEAVE > > protocol. This is the part that I am failing to understand. I think > > it would be great if we could have no central servers and not > > standardized a P2P protocol but I don't see how we can have our cake > > and eat it too. > > > >> > >> Also, I think we need to first decide what information should be > >> pushed and pulled from the DHT, what format it is, and how it will > >> be retrieved. Then, and only then do we have the requirements for > >> our DHT layer. > > > > I agree here but I don't see how this has to do with making a > > protocol for the GET/PUT. > > > > > >> To do both of these efforts them at the same time makes no sense to me. > > > > Agree here too. > > > Thanks. > > Eunsoo > > From fluffy at cisco.com Wed May 31 22:32:12 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Wed, 31 May 2006 19:32:12 -0700 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <00ee01c684ca$6b5e7310$110aa8c0@Shikky> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com><44761920.7030403@research.panasonic.com><4476D80E.7070100@telecomitalia.it><4477341C.5000107@research.panasonic.com><447C2532.7010805@telecomitalia.it><447C76DE.8070303@research.panasonic.com> <447DAE93.1090205@telecomitalia.it> <00ee01c684ca$6b5e7310$110aa8c0@Shikky> Message-ID: <62E2736B-5C96-4556-84C9-83433487B824@cisco.com> On May 31, 2006, at 8:53 AM, Brijesh Kumar wrote: > For a small network, a DHT is not needed - one can create a simple > table of > SIP URIs and node mapping, or learn such a mapping through a > simple service > discovery protocol (use SLP, UPnP (SSDP) or other networking means > (Dynamic DNS, > DHCP, Radius Extension etc.)). I probably misspoke in my use of the word DHT. What I really meant was the placeholder for whatever it was that formed the distributed database. I did not mean to rule out something like broadcast of all the data to all the nodes being one of the approaches to this (or others that you mentioned). From fluffy at cisco.com Wed May 31 22:33:55 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Wed, 31 May 2006 19:33:55 -0700 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <447DBF51.8030803@research.panasonic.com> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> Message-ID: One trivial comment and one important comment inline... On May 31, 2006, at 9:07 AM, Eunsoo Shim wrote: > Cullen Jennings wrote: > >> >> On May 30, 2006, at 10:39 AM, Alan Johnston wrote: >> >>> Cullen Jennings wrote: >>> >>>> Ok, I'm glad to hear that at least some people think we have some >>>> consensus on this. It's been hard to tell following the list so I >>>> appreciate people speaking up about it. >>>> >>>> I'll be very blunt about doing both proposal. It is not clear to >>>> me if people think we should do both because >>>> 1) this is the technical long term solution we want, or >>>> 2) this would make it so at some level everyone agreed. >>>> >>>> Doing both will no doubt slow down finishing either. It is not >>>> clear to the that the GET/PUT only protocol would be used if the >>>> other GET/ PUT/JOIN/LEAVE exists - it seems like you would just >>>> want the later of the two. So if we look at our end goal, is >>>> there >>>> a need for GET/ PUT only. >>>> >>> Yes. Real DHT nodes typically interact with 100s if not 1000s of >>> peer nodes at any given instant. Will every SIP UA be capable of >>> doing this? >> >> >> I'll use chord as an example here not because I think chord is the >> right DHT but only as a concrete example. A node that knew a few >> other chord nodes but was not storing any data could easily interact >> with the DHT and only have very few connections. >> > Please let me try to clarify the issure a little bit more. > > A node in Chord must maintain a finger table and data with keys of a > certain range or locations of such data. > Chord requires each node (in the Chord network) to have around log N > fingers (where N is the total number of nodes in the Chord network and > the base is 2). So if the network size is around 64,000, the > number of > fingers for each node is around 16. For a network of around a million > nodes, the number becomes around 20. the trivial comment - A trivial modification to the Chord algo would say that if a node wanted less finger tables, it dropped half the current ones and kept every other finger entry - things would still work. I'm not arguing this is a good idea but I am pointing out there are many ways to modify a DHT to meet this somewhat requirement of low connection count. The problem with most low power devices is not keeping up 20 connection but instead how often they have to wake up for traffic. It may be that P2P is a real bad idea for mobile devices because you need to keep updating data. All this really does is worry me that selecting a DHT for use in mobile environments is a research problem. > > There is a cost for maintaining the finger table when the network is > dynamic (nodes join and leave). Furthermore, each node should provide > routing for various Chord messages such as GET/PUT/JOIN/LEAVE. > > When a node has limited bandwidth or battery power, the above > requirements may be too much. If the node is behind NAT, it is not > simple maintaining connections with fingers and other nodes for which > the node is a finger. True that it is not easy but it's not clear that it is any harder than setting up RTP between two devices behind NAT which I believe to be a requirement of this work. > > What I said kind of justifies the distinction between devices (SIP > UAs) > that participate in the DHT (Chord) and devices (SIP UAs) that do not. > The devices that do not participate in the DHT don't need to support > JOIN and LEAVE but need to do just GET/PUT. > > So now we have two interfaces. > > Node in DHT Node in > DHT Node not in DHT > > > |<---------------------------------------->| > <------------------------------------------------------>| > (a) GET/PUT (b) > GET/PUT > JOIN/LEAVE > > Now the question has a few angles. > - Will (a) GET/PUT be dependent of the underling DHT algorithm? > - Will (a) GET/PUT and (b) GET/PUT have any difference in the > syntax and > semantics? > - Will it be difficult to separate (a) GET/PUT from JOIN/LEAVE? > > If an answer for any of the above question is 'yes', I think we'd be > better off by defining (b) GET/PUT as a separate protocol. And I think > it is a safe assumption. > If we find out none of the answers is 'yes', then we would not need a > separate protocol for (b) GET/PUT. > Nodes not in DHT can safely just implement and support GET/PUT but not > JOIN/LEAVE. > > Hope I added some clarity, not confusion. Yes sort of. I think what you are saying is that if any of the answers are yes, then we will not be able to build an interoperable protocol to do the (a) side so we will need the (b) protocol. Do I have this right? From ekr at networkresonance.com Wed May 31 11:54:32 2006 From: ekr at networkresonance.com (EKR) Date: Wed, 31 May 2006 08:54:32 -0700 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: (Cullen Jennings's message of "Mon, 29 May 2006 22:44:53 -0700") References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> Message-ID: <86k682i407.fsf@delta.rtfm.com> Cullen Jennings writes: > An alternative path is that more than one vendor can build the things > that participate in the DHT or store the location database > information and that in some cases they same devices or computer that > is the end UA will also have participate in this way. Certainly, the question of whether the protocol is interoperable is important one, but I think there's another important one you're missing: are the various participants inside the same trust domain? -Ekr