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

["Medhavi Bhatia" <[e-mail]>]

 I don't think the DHT is something which gets negotiated between two nodes.
So I don't think we need to look at the mandatory DHT in the same way as we
look as at a mandatory codec. The requirement here is to prevent a situation
where all vendors implement their own DHT to gain commercial advantage. If
we don't pick a mandatory DHT, someone else outside this group will end up
doing that anyway - maybe Skype ;)

On 7/13/07, Henning Schulzrinne <[e-mail]> wrote:
>
> Lack of a common DHT does not necessarily interfere with
> interoperability. The client protocol, at least in our thinking, is
> independent of the DHT, so a node that doesn't implement the DHT
> algorithm of the overlay it wants to talk to can still reach others,
> it just can't be a full peer. Since typically only a small fraction
> of nodes need to act as peers at any given time, this may not be much
> of a problem.
>
> You could design a system that essentially replicated the key-data
> mappings across two DHT algorithm, a baseline universal one and the
> "fancy"/"better" one less universally spoken. This incurs
> significantly more overhead and probably yields some strange partial
> reachability cases particularly as new nodes are added, but it could
> be done.
>
> Henning
>
> On Jul 13, 2007, at 6:16 PM, David A. Bryan wrote:
>
> > 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
>
>
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip
>



-- 
Medhavi Bhatia

CTO, 3CLogic
www.3clogic.com

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