RE: [P2PSIP] Re: Design decisions

["Henry Sinnreich" <[e-mail]>]

David,

I believe we agree to large extent on the arguments (except A. and B. as below), and it is probably my fault of speaking of openDHT when the actual alternatives meant here are Bamboo, Chord, etc. for the DHT itself. As for using SIP for the DHT, this is another design choice.

So there are a number of design choices with their pros and cons.

What are missing before we make a commitment are experimental results:

- How effective (%) is NAT traversal (types of NAT, NAT configurations, etc.)?

- What are the numbers for the call setup time? See the delays on the openDHT before some fixes.

- How many calls fail because there is non-transitive connectivity (peers cannot see each other)?

- What proportion of evil peers make the DHT fail? 30% as measured for Bamboo?

- There may be more...

There are good reports with numbers for _all the above_ for Bamboo at openDHT (the source of the confusion), but zero numbers in the other proposals that have been submitted to the P2P SIP WG. 

A. Just because an I-D is well written is no substitute for hard numbers. Otherwise, we would simply work on faith instead based on experimental results and measured numbers. 

If reporting numbers as for Bamboo is too difficult, at least if we could first make some informal tests on an implemented system, before making a commitment for a standard would really help.

B. And sure, a document showing the design choices, Bamboo-Chord, etc., SIP for the DHT or HTTP, etc. and quite a few other design choices. Writing and discussing such a document is preferable to discussing all the issues by e-mail.

Henry

-----Original Message-----
From: David A. Bryan [mailto:[e-mail]] 
Sent: Monday, March 05, 2007 3:57 PM
To: Henry Sinnreich
Cc: Kundan Singh; P2PSIP Mailing List
Subject: Re: [P2PSIP] Re: Design decisions

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

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