Re: [P2PSIP] Re: Design decisions

["David A. Bryan" <[e-mail]>]

My last sentence got clipped to just "I'd argue this is". It should have read:

"I'd argue this is a good reason to see about getting together a
number of drafts we can implement and test or at least write to the
extent that we know we can do NAT traversal, security, etc."


On 3/5/07, David A. Bryan <[e-mail]> wrote:
> Changing the focus a bit here...
>
> I've read the drafts, including the one by Singh Henry references
> below, but I still don't understand what people mean when they talk
> about an "OpenDHT" proposal. OpenDHT is a service...it isn't a
> protocol, unless people are talking about just taking and
> standardizing what OpenDHT sends on the wire *as* the protocol.
> OpenDHT describes themselves as:
>
> "OpenDHT is a publicly accessible distributed hash table (DHT)
> service. In contrast to the usual DHT model, clients of OpenDHT do not
> need to run a DHT node in order to use the service. Instead, they can
> issue put and get operations to any DHT node, which processes the
> operations on their behalf. No credentials or accounts are required to
> use the service, and the available storage is fairly shared across all
> active clients."
>
> From my understanding, it is a group of machine which implement a DHT
> using Bamboo, and serve as a DHT on behalf of clients. I believe it is
> also the idea some people have in mind when they talk about a
> service-based architecture. OpenDHT encourages people to use it to
> store/retrieve information, so in some ways, the ultimate end systems
> don't participate in any way in the P2P aspects of the system.
> Currently OpenDHT runs on a few hundred nodes on a closed
> academic/industrial research system called planet lab which a general
> user cannot become a member of, although obviously that could be
> different in a different deployment. To me it looks like a way to play
> with a DHT but not really one that users can leverage or use.
>
> So a few things I want to discuss about this philosophy:
>
> * First, what do people think the WG would do in the event we went
> with a model like this? I would assume the model advocated here is
> that we use unmodified SIP entities (proxies, UAs or whatever) that
> contact OpenDHT nodes to store information for them. Since the actual
> SIP entities are not participating in the overlay in such a model,
> what is it we standardize here? Do we take the current protocol sent
> over the wire by OpenDHT, flesh it out more fully, and standardize
> that protocol (or perhaps two protocols -- between the peers and
> between the clients who just use the service and the peers)?
>
> (if the answer to the above is yes, how would we leverage it to deal
> with NATs? PlanetLab is NAT free. Also, how about security and
> identity? OpenDHT says they don't use credentials or accounts, which
> seems to imply we would need to build some infrastructure like this on
> top if this system can be used for a real system. Although we can
> obviously look since it is open source, does anyone know what OpenDHT
> is using as a protocol on the wire -- not the programming interface --
> since as a WG we need to standardize that? (XML? Something they
> created?) Is there a document that describes the protocol they use?)
>
> * How does this approach eliminate a service provider? I don't think
> it is scalable for us all to just use the few hundred planet lab
> servers as our data store servers, so the question is who would
> provide the servers (in the physical sense of that word -- the
> machines/electricity/bandwidth) that today are running the OpenDHT
> peers? People have always proven poor at providing free resources in
> the past, so if most people just choose to use the DHT "cloud", who
> provides that cloud and how do we ensure reliability for it?
>
> * Is there only one cloud? How can I create a (private) system in such
> an approach? What about an off-line cloud for ad-hoc or emergency
> responder cases? Does OpenDHT support this today?
>
> I also have a few specific questions/comments about Henry's points:
>
> > 1. P2P SIP requires a network of bootstrap servers as well.
> > So why not in the form of openDHT?
>
> What we need are some peers that can serve this role, but they don't
> really need to be servers, as long as they are semi-persistent. I
> think the approach of volunteer nodes such as OpenDHT takes could be a
> good model of a few people volunteering to be the "cloud" of
> bootstraps -- might be much easier to get volunteers to be a "Peer
> that will just quickly respond with a list of peers for you" then to
> get volunteers to be a "Peer that will store your stuff for you".
> Would that make some sense here?
>
> > 2. A P2P overlay may be used for more than just one type of service.
>
> True, but remember the first item explicitly excluded from scope in
> this WGs charter is creating or using DHTs for other services, so we
> need to stick to SIP.
>
> > 3. Clean separation of functions.
>
> This is sort of the heart of the OpenDHT question I think. What are we
> trying to separate? I guess I see 3 things that can be separated:
>
> 1 The logical layer of gets/put/search from SIP call setup (although
> could use SIP for both)
> 2 The protocols used
> 3 The nodes using it from the nodes providing the service
>
> My way of thinking is that 1 is clearly a good thing to separate, but
> I'm not as clear that 2 makes sense (I personally feel it does not)
> and I think in many or most cases separation 3 is a bad idea. What do
> we see as the separation that is valuable here, and how do we want to
> capture that separation in our work?
>
> > 4. Columbia University has researched several approaches, including the use of openDHT.
>
> True, although many others have done research or developed products in
> this area as well, many of which don't use OpenDHT. I think using
> OpenDHT is a great way to conduct research -- it is a "testbed", but
> that doesn't really make it well suited for a protocol to be defined
> and used for commercial and non-commercial development on the
> internet.
>
> > 5. Last and most important, Bamboo on openDHT has well published performance reports and fixes from what was learned in global implementations and lab simulations to cope with Internet impairments.
> > I have not seen any comparable numbers or graphics showing reported performance. See the top 4 bullets at http://opendht.org/pubs.html
>
> This might be an argument for Bamboo as a DHT, but choosing Bamboo
> doesn't force us to use an OpenDHT type architecture. We have proposed
> in a draft how to use Bamboo as one of many pluggable algorithms
> within a P2PSIP context where each UA is a peer and using SIP here:
>
> http://www.p2psip.org/drafts/draft-zangrilli-p2psip-dsip-dhtbamboo-00.html
>
> Also we need to keep in mind these numbers are for stable servers on
> University systems with no NATs and no security, so we need to factor
> that into the decision.
>
> I think there are a number of very big open questions here that I
> would like to discuss more fully.
>
> David
>
> > Just well written I-Ds are no substitute IMHO.
>
> I'd argue this is
>
>
> > Thanks, Henry
> >
> >
> >
> > ________________________________________
> > From: Victor Pascual Ávila [mailto:[e-mail]]
> > Sent: Monday, March 05, 2007 12:22 PM
> > To: EdPimentl
> > Cc: Henry Sinnreich; Kundan Singh; P2PSIP Mailing List
> > Subject: Re: [P2PSIP] Re: Design decisions
> >
> > Hello all,
> > 2007/3/5, EdPimentl <[e-mail]>:
> > Hello Henry,
> >
> > Thanks for addressing this concern.
> > Because of the previous work done at Columbia.edu and good documentation we have been leaning towards CHORD....
> > Have even applied at getting a slice at PlanetLAB to develop and test our work.
> >
> > As far as I know it relies on 'Internet connection'. From my point of view P2PSIP should has an AS philosphy, not relying on other 'external' services. What do you think?
> >
> > We actually will begin planning and coding in the next two weeks using the latest drafts from P2PSIP and Henning S.
> > I really do welcome comments and suggestions on which one to start with so we can be true to the letter and spirit of this WG.
> > Again, welcome feedback and recommendations.
> >
> > Thanks in advance and best regards,
> > -E
> >
> > Regards,
> > Victorp
> >
> > On 3/5/07, Henry Sinnreich < [e-mail]> wrote:
> >
> >
> > -----Original Message-----
> > From: Henry Sinnreich
> > Sent: Monday, March 05, 2007 10:30 AM
> > To: 'EdPimentl'; JiangXingFeng
> > Cc: P2PSIP Mailing List; Kundan Singh; 'Henning Schulzrinne'
> > Subject: RE: [P2PSIP] RE:
> >
> > Ed Pimentel wrote:
> >
> > >Why are we using OpenDHT as an example, when currently OpenDHT method of >putting bits on the wired is not compliant with the drafts being >discussed.
> >
> > This is a good and also important question that will require some work to answer properly. Please see one alternative:
> >
> > http://tools.ietf.org/wg/sip/draft-singh-p2p-sip-01.txt
> >
> > though I want to make it clear I am not married to this approach or any other submitted so far.
> >
> > Now that the P2P SIP WG has quite a number of proposals, including the above, I would like to see a paper on the design options and a comparison of the pros and cons of the various concepts.
> >
> > This is probably the most important decision this WG will make and such a decision deserves a formal comparison paper and thorough discussions.
> >
> > We may be attached (or even invested in) to one proposal or another, but do we want to fail by rushing into the wrong decision?
> >
> > What do you all think? Take a hum during the meeting?
> > (Paper on design choices)
> >
> > Thanks, Henry
> >
> > ________________________________________
> > From: EdPimentl [mailto: [e-mail]]
> > Sent: Monday, March 05, 2007 8:25 AM
> > To: JiangXingFeng
> > Cc: P2PSIP Mailing List
> > Subject: Re: [P2PSIP] RE:
> >
> > Why are we using OpenDHT as an example, when currently OpenDHT method of putting bits on the wired is not compliant with the drafts being discussed.
> > What is the group recommending for those planning on building/coding (line in the sand) to the emerging standards? CHORD, BAMBOO, KADEMLIA or OpenDHT?
> > We do understand that at some point in the future it will be DHT protocol agnostic... and today this is not the case.
> >
> > Looking for your comments.
> > Best,
> > -E
> > On 3/4/07, JiangXingFeng <[e-mail]> wrote:
> > Hi, Henry:
> > > Your understanding is correct, and I see no reason not to use
> > > openDHT-like networks (maybe even commercial as intended by its
> > > developers) either:
> > >
> > > 1. A multipurpose global "Internet at the application layer", and/or
> > > 2. A bootstrap mechanism for P2PSIP.
> > >
> > > A discussion would be very interesting and welcome indeed.
> >
> > Do you mean that the infrastructure like what OpenDHT provides to provide
> > service is used to organize P2PSIP overlay and help new nodes bootstrap?
> >
> > If my understanding is correct, the OpenDHT should run as stable as
> > possible, because there will a variety of applications or services will be
> > built on it. In this case, the quality of nodes making up of OpenDHT is very
> > different from peers which are discussed in the current P2PSIP mailing list,
> > so the design of Peer protocol should change accordingly.
> >
> > What about your opinions?
> >
> > --
> > Jiang XingFeng
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > P2PSIP mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/p2psip
> >
> >
> >
> > --
> > Thanks in advance and best regards,
> >
> > Ed Pimentel
> >
> >
> >
> > Mail: edpimentl[at]gmail.com
> > IM: edpimentl [AOL | Jabber | Yahoo | MSN ]
> > Voip: edpimentl [SKype | GoogleTalk ]
> >
> > Mobile Content Marketing/Management/Digital Delivery
> > http://mobilecentral.ws
> >
> > Mobile ( Relevant, Ambient, Location ) based Social Network
> > http://TagR.mobi (Alpha)
> >
> > Mobile Payment - P2P Payment
> > http://agilepay.ws
> >
> > Sponsor of P2PSIPopen source [viasip_ng] project
> > Creating a standards base P2PSIP dSIP infrastructure
> > https://sourceforge.net/projects/viasip/
> > Mailing List [e-mail]
> >
> >
> >
> > _______________________________________________
> > P2PSIP mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/p2psip
> >
> >
> >
> > --
> > Victor Pascual Ávila
> >
> > mail:[e-mail]
> > sip:[e-mail]
> > fon user: 223364
> >
> > _______________________________________________
> > P2PSIP mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/p2psip
> >
> >
>
>
> --
> David A. Bryan
> [e-mail]
> +1.757.565.0101 x101
> +1.757.565.0088 (fax)
> www.SIPeerior.com
>


-- 
David A. Bryan
[e-mail]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

_______________________________________________
P2PSIP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip