Re: [P2PSIP] Re: Design decisions

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

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

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