Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion

["Wei Gengyu" <[e-mail]>]

Hi, 

I agree that there is a default DHT algorithm. 
And for flexibility, there may be an option for selecting other DHTs in Peer protocols.  

Some problem will occur:
1. How can a joining peer get what is the default DHT?
,It probably could get the configuation data by exchange messages during joining phase.

2. And whether the default DHT can be changed or reconfigured?
If yes, it needs to define mechanisms in Peer Protocol.

In practice, the default is required. 
Even we have the fault configurations, there are often interoperability problems due to different understanding or development choices.
And I can not image the result if there is no default DHT.

Regards, 

Gengyu

----- Original Message ----- 
From: "David A. Bryan" <[e-mail]>
To: "Krishna Sankar (ksankar)" <[e-mail]>
Cc: "P2PSIP WG" <[e-mail]>
Sent: Saturday, July 14, 2007 11:03 PM
Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion


>I think there is some confusion here. See inline.
> 
> On 7/13/07, Krishna Sankar (ksankar) <[e-mail]> wrote:
>> David,
>>         I assume by "pluggable DHTs" you mean common interface and
>> protocols.
>>
>>         Supporting your line of thought, as I understand them, basically
>> if we have a model which says a DHT should do this thing, that thing and
>> all those (well defined) things; plus a way of interacting with DHT
>> instances (via well established and crisp protocols), do we care how the
>> DHTs are implemented ? In fact, isn't this how routing works ?
> 
> You won't be able to have various different DHTs share the same
> overlay. I don't think anyone believes that will work. The protocol
> will define how messages are transported, and the syntax to get/put
> etc., but the particular DHT will decide specifics, such as where
> something is stored, which areas a particular peer is responsible for,
> and possibly some details of the routing. (For example the DHT
> EpiChord improves chord performance by routing on request forward
> around the ring and the other backward)
> 
> This flexability is great -- and why I think we want pluggable DHTs.
> The field is still evolving, and new, better DHTs will be developed.
> Once someone who is deploying a system chooses the one to use, only
> those that can support it will be able to join, and I think that is
> fine for the reasons you mention below (they may have picked a good
> one for power saving, or optimized for an enterprise, or a global
> deployment with many NATs...), but if their goal is "I want to be able
> to use endpoints from any vendor", and we have no standard, it may not
> be possible. Say vendor A implements DHTs 1 and 2, Vendor B 2 and 3,
> and vendor C only 4. If I want to build an overlay and have devices
> from all vendors, my choices are:
> 
> * Run a network on 2, A and B devices participate, but C devices run
> only in client mode, which less efficient (especially if I have about
> even numbers of A/B and C devices) It would be even worse if A, B and
> C had no common DHT and perhaps I only get to spread the work among
> 1/3 of the devices.
> 
> * Run multiple overlays and connect via inter-overlay operations, but
> this is also ugly, and likely to be less efficient since multiple
> calls are made. To me the proposal that this is satisfactory would be
> akin to saying when the IETF was looking at SIP that we shouldn't
> bother, and that different vendors could just build VoIP systems with
> their own protocols and we can define how to use the PSTN to
> interconnect them. This seems destined to lead to a network where the
> large vendors get to define an industry standard of "their" DHT,
> patent it, license it, and control the market.
> 
> I'd prefer another option, where all could run 0. It might not be the
> best DHT, but I can leverage the fact that all peers are sharing the
> load now, which is the whole point of P2P. In my experience with DHTs
> (and much of my Ph.D. thesis revolves around details of them, so I've
> studied them rather intently), The improvement between DHT A from the
> 90s and new super DHT Z are relatively minor in comparison the the
> performance gain of spreading the work among the various peers. That
> is really what P2P is trying to do -- spread the work over as many
> devices as possible to ensure each does little work, while
> collectively they get the work done.
> 
> If we spread it over "just a few peers" and use client protocol
> between the rest, this looks kind of like a degenerate case of a proxy
> farm (or perhaps redirect farm) to me, where we aren't really
> spreading the load. Spreading work among 1000 peers with a fairly
> simply DHT seems preferable to having it spread across 400 marginally
> more efficient ones that must serve another 600.
> 
> As Johnathan pointed out, there are a couple of models in the
> requirements document, because it is the result of many authors. The
> proxy model (which I personally don't like) and a true end to end
> where as many devices are in the overlay as possible (which I have
> always preferred and proposed) I want this to be as end to end as
> possible, and want to ensure that someone setting up a network of
> these can choose from any vendor. I'm also not sure there is a ton of
> value in each vendor sending messages that are the same format over
> the wire, but not being able to combine those devices together anyway
> except as islands interconnected by SIP or as dumb clients where only
> one vendor's device provide the smarts and stores the data.
> 
> So far, at least, I'm not convinced we can do that without a mandatory
> DHT, although maybe in this discussion we'll figure it out.
> 
> David
> 
>>
>> > to implement, there may be many devices from different
>> > vendors that don't even implement a common DHT. Each will
>> > pick and choose which DHTs to implement, and in the end,
>> > there won't be a common DHT all can even run if they want to.
>> <KS>
>>         Wouldn't a device implement only the protocols and interfaces ?
>> In fact, depending on the domain, we might need different types of DHTs
>> anyway. I am not sure one size will fit all domains for various reasons
>> - for example there might be a need for power saving; in which case that
>> domain might choose a lightweight DHT implementation; Apple definitely
>> will want to have an iDHT for no reason ;o),...
>> </KS>
>>
>> Also, I keep on seeing interoperability thrown around; interoperability
>> has different forms in different domains - as Medhavi mentions, in the
>> codec world what it means is different than in the routing world which
>> is different than in the SAML world, for example. In short what exactly
>> is interoperability in the world of P2PSIP ? I think if we have a clear
>> & common understanding of the definition of interoperability, that would
>> be a good start; we all have it in our heads, may be it is written down
>> somewhere.
>>
>> Cheers
>> <k/>
>> > -----Original Message-----
>> > From: David A. Bryan [mailto:[e-mail]]
>> > Sent: Friday, July 13, 2007 3:16 PM
>> > To: Jonathan Rosenberg (jdrosen)
>> > Cc: P2PSIP WG
>> > Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a
>> > dissenting opinion
>> >
>> > I think this likely to be a source of serious discussion. At
>> > least for now (maybe Jonathan can convince me), I'm inclined
>> > to disagree.
>> >
>> > I think the problem is that if we don't specify a mandatory
>> > to implement, there may be many devices from different
>> > vendors that don't even implement a common DHT. Each will
>> > pick and choose which DHTs to implement, and in the end,
>> > there won't be a common DHT all can even run if they want to.
>> >
>> > I think looking at it from the perspective of "once the DHT
>> > chosen it is locked" is the wrong way to look at it. The idea
>> > isn't that any device can join any already established
>> > overlay, but that if I deploy a system of heterogeneous
>> > devices, there is at least one that I can select when I start
>> > and know that all "P2PSIP endpoints" (assuming that term
>> > means anything) will at least support that and I can form an
>> > overlay with them. Maybe not the ideal DHT for my overlay,
>> > but something I know all devices can support, and if I run it
>> > in that mode, it works.
>> >
>> > Personally, I think if we don't do that, many DHTs will be
>> > standardized for different environments (good) but each
>> > vendor will implement a (potentially disjoint) subset, and
>> > there may be no way to use two endpoints from different
>> > vendors together at all.
>> >
>> > I agree that if a user selects a non-mandatory DHT, they may
>> > risk not being fully interoperable, but I think if we don't
>> > pick one at all, we almost guarantee things won't be interoperable.
>> >
>> > And I (and I think nearly everyone) is 100% in the camp of
>> > "we should allow pluggable DHTs". I think it is safe to say
>> > that one is a done deal, but I would personally have thought
>> > a mandatory was as well. In any case, my vote is definitely
>> > for pluggable DHTs.
>> >
>> > David
>> >
>> > On 7/13/07, Jonathan Rosenberg <[e-mail]> wrote:
>> > > I've read draft-bryan-p2psip-requirements-00, and have a bunch of
>> > > comments. But a few items came to mind I wanted to discuss
>> > which merit
>> > > their own threads.
>> > >
>> > > First, is the concept of mandatory-to-implement DHT. The
>> > requirements
>> > > document talks a lot about requirements around selecting a
>> > mandatory
>> > > to implement DHT. Its something we've discussed in the
>> > meeting and on
>> > > the list. I think everyone agrees also that we need to allow for
>> > > multiple DHT and all of the recent protocol proposals support it.
>> > >
>> > > However, I do not think we should have a
>> > mandatory-to-implement DHT at all.
>> > >
>> > > There are several reasons for this. First of all, its important to
>> > > understand the reason why IETF has mandatory-to-implement
>> > > functionality in its protocols. The one and only reason is that it
>> > > ensures interoperability. It ensures that, independent of
>> > the optional
>> > > features selected by a pair of entities, when you connect them
>> > > together, they can still interoperate.
>> > >
>> > > This property will NOT be retained with a
>> > mandatory-to-implement DHT.
>> > > Once the ring forms, the DHT protocol is chosen and locked.
>> > Thus, if any
>> > >   DHT besides the 'mandatory-to-implement' one has been
>> > selected for
>> > > the DHT, a new node not supporting that DHT will not be
>> > able to join
>> > > the ring even if it implements the mandatory-to-implement
>> > one. Thus,
>> > > the entire purpose of mandatory-to-implement is eliminated
>> > - we don't
>> > > actually get interoperability.
>> > >
>> > > Indeed, to get this kind of interoperability, we'd need to pick one
>> > > and only one DHT that ever gets used with p2psip. I think
>> > that is a mistake.
>> > > This is an evolving area and is one where agility is important.
>> > >
>> > > Instead, what I think happens is that a 'provider' that
>> > deploys a p2p
>> > > network will need to pick a DHT, and make sure that the clients all
>> > > support that DHT. This is something the market should drive, not us.
>> > >
>> > > Secondly, I think its important to realize that we are
>> > picking up work
>> > > in an area that is well trod. There are lots and lots of papers and
>> > > protocols and software written around P2P networks. I don't think
>> > > anyone looks at an IETF protocol and says, "IETF are the
>> > guys who know
>> > > about DHTs, lets go with their recommendation". What IETF is really
>> > > good at, and what this group has expertise in, is SIP, and on
>> > > designing good, scalable protocols in general - things that have
>> > > security, extensibility, good performance, and so on. So I
>> > think the
>> > > greatest value we can bring to the table is to create a
>> > protocol that
>> > > allows others to take DHTs and easily turn them into a real wire
>> > > protocol that you can actually deploy, on the Internet, to
>> > support SIP
>> > > and ideally other things too. Interestingly, this is
>> > exactly what all
>> > > of the protocol proposals do. That kind of focus goes hand-in-hand
>> > > with saying, let someone else figure out which DHT to use.
>> > I think its
>> > > perfectly reasonable for us, and for others, to write
>> > documents on how
>> > > to use our protocol with various DHTs. But I think we
>> > should be out of
>> > > the business of picking one or recommending one (or ones)
>> > to be used.
>> > >
>> > > -Jonathan R.
>> > > --
>> > > Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>> > > Cisco Fellow                                   Parsippany,
>> > NJ 07054-2711
>> > > Cisco Systems
>> > > [e-mail]                              FAX:   [phone]
>> > > http://www.jdrosen.net                         PHONE: [phone]
>> > > http://www.cisco.com
>> > >
>> > > _______________________________________________
>> > > 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
>> >
>>
> 
> 
> -- 
> 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