Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion
"Eunsoo Shim" <eunsooshim@gmail.com> Sun, 15 July 2007 03:54 UTC
Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9vC9-000705-Gs; Sat, 14 Jul 2007 23:54:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9vC8-0006xZ-A1 for p2psip@ietf.org; Sat, 14 Jul 2007 23:54:52 -0400
Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9vC4-00041v-7E for p2psip@ietf.org; Sat, 14 Jul 2007 23:54:52 -0400
Received: by nf-out-0910.google.com with SMTP id c10so61306nfd for <p2psip@ietf.org>; Sat, 14 Jul 2007 20:54:47 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mqfqNLrTntBhWCcpzflEiUWvTSkkwnhlountlj+wI+P26gyA8oOeLAlWYn4k6iEbUTqL8Sm64CPzBrEKE0sclHeXVidbKjUMWL0BEdLXDrbEnkJhXgFFOYgCkiXQPBEwd79Z5LNObRlF31I6VsX9l+mUOxVQF7Np7tWvSGfPAjo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=UXCfJ2wQlWtOeeG0FhFbYdaDGRR4zcZXNXQv1woxTmolIM9JbhWzhAepDwSGBzarB0cwep6mXAUtVBHu/X842OT8a57XAMDhaAtjLuge53vLZGqDP61fYz1s1xlwh6sHvTs4oOre/wZ4lyJiV60n55WEshMNLfHwUn6yKVQwQjc=
Received: by 10.78.165.16 with SMTP id n16mr847972hue.1184471686836; Sat, 14 Jul 2007 20:54:46 -0700 (PDT)
Received: by 10.78.53.20 with HTTP; Sat, 14 Jul 2007 20:54:46 -0700 (PDT)
Message-ID: <7b683f3f0707142054y66138c82hf5a39c30f9dd5fa9@mail.gmail.com>
Date: Sat, 14 Jul 2007 23:54:46 -0400
From: Eunsoo Shim <eunsooshim@gmail.com>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion
In-Reply-To: <563F8B51-9F14-400C-9274-220672F8AD40@cs.columbia.edu>
MIME-Version: 1.0
References: <4697F02B.4030506@cisco.com> <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> <563F8B51-9F14-400C-9274-220672F8AD40@cs.columbia.edu>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ed68cc91cc637fea89623888898579ba
Cc: P2PSIP WG <p2psip@ietf.org>
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0614086879=="
Errors-To: p2psip-bounces@ietf.org
On 7/13/07, Henning Schulzrinne <hgs@cs.columbia.edu> 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. I am not sure whether this is a desirable approach. Having a commond DHT and thus being able to use more devices as full peers seems to be more desirable to me. 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. I am not sure whether it is always the case that, given two DHT algorithms, one can be considered as a baseline universal one and the other a fancier/better one. This incurs > significantly more overhead and probably yields some strange partial > reachability cases particularly as new nodes are added, but it could > be done. I am not convinced why we would want to pursue this complex approach instead of choosing/recommending one common DHT. We can change the common DHT or add one more later. Thanks. Eunsoo 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 <jdrosen@cisco.com> 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 > >> jdrosen@cisco.com FAX: (973) 952-5050 > >> http://www.jdrosen.net PHONE: (973) 952-5000 > >> http://www.cisco.com > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > >> > > > > > > -- > > David A. Bryan > > dbryan@SIPeerior.com > > +1.757.565.0101 x101 > > +1.757.565.0088 (fax) > > www.SIPeerior.com > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >
_______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip
- [P2PSIP] Mandatory-to-implement DHTs - a dissenti… Jonathan Rosenberg
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… Henry Sinnreich
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… David A. Bryan
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Ted Hardie
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Emil Ivov
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Henning Schulzrinne
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Ted Hardie
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Medhavi Bhatia
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… Krishna Sankar (ksankar)
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… David A. Bryan
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… David A. Bryan
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Wei Gengyu
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… Kundan Singh
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… David Barrett
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… Kundan Singh
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… David Barrett
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Henning Schulzrinne
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Bruce Lowekamp
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… David Barrett
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Henning Schulzrinne
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… David Barrett
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… Roy, Radhika R.
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Eunsoo Shim
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Eunsoo Shim
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Eunsoo Shim
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… Roy, Radhika R.
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… Roy, Radhika R.
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… Henry Sinnreich
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Henning Schulzrinne
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… David A. Bryan
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… David Barrett
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… David A. Bryan
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Henning Schulzrinne
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… David Barrett
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Bruce Lowekamp
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… David Barrett
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Ted Hardie
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Ted Hardie
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… He, Jingtong
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Henning Schulzrinne
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… David Barrett
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… Henry Sinnreich
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… David Barrett
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Jonathan Rosenberg
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Jonathan Rosenberg
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Jonathan Rosenberg
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Henning Schulzrinne
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Bruce Lowekamp
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… Roy, Radhika R.
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… Roy, Radhika R.
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… Brian Rosen
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… Ted Hardie
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… Brian Rosen
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… Ted Hardie
- RE: [P2PSIP] Mandatory-to-implement DHTs - a diss… Brian Rosen
- Re: [P2PSIP] Mandatory-to-implement DHTs - a diss… Bill Mccormick