Subject: [P2PSIP] Are we settled on a DHT approach? (was: Term for the peer who is responsible for a specific key)

From: Dean Willis <[email-masked]>
Date: Sun, 2 Sep 2007 16:31:12 -0500

On Aug 29, 2007, at 8:24 PM, Zheng Hewen wrote:

> Hi,
>
> I suggest that the concept draft would adopt those terms - "P2PSIP  
> root peer" and "P2PSIP replica root peer", they are clear
> and useful for contributors to P2PSIP WG.
>

I believe I agree with this, and I also wouldn't object to a "root  
beer" as as also suggested.

Those of us who grew up drinking it know that the best root beer is  
draft root beer, so why not internet draft root beer? ;-) For those  
who don't know, root beer is a sweet carbonated drink flavored with  
assorted plant roots, sometimes including birch (you may also see  
"birch beer" and "sarsaparilla"). It is related to ginger ale and  
ginger beer. Many mass-market varieties are are just flavored corn  
syrup and carbonated water, but real home-style draft root beer  
carbonated naturally with yeast is a true delicacy. For even better  
results, combine with vanilla ice cream for a "root beer float". In  
my experience, all varieties of root beer are almost universally  
despised by people who grew up on east-Asian diets, so don't blame  
me, I warned you. Now back to p2psip . . .

Use of DHT terms like root and replica root does point at one thing  
that we've tried to dodge so far in the concepts draft, and that is  
"Is the distributed database built on a DHT or something else?"

I think I'm detecting a general consensus emergence that the  
distributed database is either built on a DHT, or on something so  
much like a DHT that we could reasonably apply DHT terminology to it  
without confusing too many people.

Do we agree to this? If so, I believe we can start shaping the  
concepts document toward this consensus, and inclusion of P2PSIP root  
peer and P2PSIP replica root peer seems like a reasonable place to  
start. But since we're supposedly documenting P2PSIP and not soft- 
drink concepts, I propose we leave the "root beer" out of the  
document for now.

--
Dean

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

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 2 Sep 2007 21:11:42 -0400

I enjoyed the information about root beer. Thanks for that, Dean.
And I agree to applying DHT terminology.
Thanks.

Eunsoo

---

From: Zheng Hewen <[email-masked]>
Date: Mon, 03 Sep 2007 09:44:17 +0800

Dean,

    Thanks for your share about "root bear" and other drinks.
    Support to apply DHT terminology again ^_^

--Hewen

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: 2007?9?3? 5:31
To: P2PSIP Mailing List
Subject: [P2PSIP] Are we settled on a DHT approach? (was: Term for the peer who is responsible for a specific key)

On Aug 29, 2007, at 8:24 PM, Zheng Hewen wrote:

> root peer" and "P2PSIP replica root peer", they are clear and useful
> for contributors to P2PSIP WG.
>

I believe I agree with this, and I also wouldn't object to a "root beer" as as also suggested.

Those of us who grew up drinking it know that the best root beer is draft root beer, so why not internet draft root beer?
;-) For those who don't know, root beer is a sweet carbonated drink flavored with assorted plant roots, sometimes including
birch (you may also see "birch beer" and "sarsaparilla"). It is related to ginger ale and ginger beer. Many mass-market
varieties are are just flavored corn syrup and carbonated water, but real home-style draft root beer carbonated naturally
with yeast is a true delicacy. For even better results, combine with vanilla ice cream for a "root beer float". In my
experience, all varieties of root beer are almost universally despised by people who grew up on east-Asian diets, so don't
blame me, I warned you. Now back to p2psip . . .

Use of DHT terms like root and replica root does point at one thing that we've tried to dodge so far in the concepts draft,
and that is "Is the distributed database built on a DHT or something else?"

I think I'm detecting a general consensus emergence that the distributed database is either built on a DHT, or on something
so much like a DHT that we could reasonably apply DHT terminology to it without confusing too many people.

Do we agree to this? If so, I believe we can start shaping the concepts document toward this consensus, and inclusion of
P2PSIP root peer and P2PSIP replica root peer seems like a reasonable place to start. But since we're supposedly documenting
P2PSIP and not soft- drink concepts, I propose we leave the "root beer" out of the document for now.

--
Dean

---

From: "Peter Pan" <[email-masked]>
Date: Sun, 2 Sep 2007 20:21:30 -0700

why warned us? what's wrong with east-asian diets???

i didn't see that melamine-tainted dogfood, lead-coated toys or other
east-asian-made products has ever retarded progress of p2psip wg. ~ho~~ho~~~

great job!!

----- Original Message -----
From: "Dean Willis" <[email-masked]>
To: "P2PSIP Mailing List" <[email-masked]>
Sent: Sunday, September 02, 2007 2:31 PM
Subject: [P2PSIP] Are we settled on a DHT approach? (was: Term for the
peerwho is responsible for a specific key)

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 3 Sep 2007 07:28:12 -0700

Adopting DHT terminology in the P2PSIP WG has a precedent right from the
emergence of SIP where most initial concepts from HTTP and the web: 
The SIP proxy, the SIP message syntax and many other if you think of it.

This web root (no pun intended) is probably at the root of the success
of SIP.

Henry

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Sunday, September 02, 2007 4:31 PM
To: P2PSIP Mailing List
Subject: [P2PSIP] Are we settled on a DHT approach? (was: Term for the

--
Dean

---

From: Ted Hardie <[email-masked]>
Date: Tue, 4 Sep 2007 10:27:55 -0700

At 4:31 PM -0500 9/2/07, Dean Willis wrote:
>
>Use of DHT terms like root and replica root does point at one thing that we've tried to dodge so far in the concepts draft, and that is "Is the distributed database built on a DHT or something else?"

I believe this goes back to a question we've discussed and did not come to a
consensus on.  That was, basically, how well do we want this to support
new technologies plugged-in as substrates here?  My personal opinion
is that we need to select a candidate technology to demonstrate
interoperability here, but that we don't need to specify a full-on, long-term
mandatory-to-implement technology.  I think the candidate technology
should be based on one of the existing DHT solutions. 

But I think the plug-in architecture should support any mechanism
that supports the same primitives, and that it should not be limited
to distributed hash tables.  If some function other than hashing is used
to create the overlay topology, why does it matter?

That said, I don't see a problem in describing the primitives in terms
derived from those used by DHTs.  We can always add text like:

	The terms below are derived from X,  selected as
	the common choice for those intending to demonstrate
	interoperability with the initial version of this standard.
	X is based on Distributed Hash Tables, and the working
	group believes that other DHTs or other peer-to-peer
	overlay mechanisms may be used  where they provide
	similar capabilities.   Because peer to peer technologies
	are an area of active research and the working group
	expects significant progress, it encourages developers
	to code with the expectation that other technologies
	may eventually replace or augment X as a substrate.

That lets us pick up the existing technology's terminology, but leave
open the possibility of change.
				Ted

>I think I'm detecting a general consensus emergence that the distributed database is either built on a DHT, or on something so much like a DHT that we could reasonably apply DHT terminology to it without confusing too many people.
>
>Do we agree to this? If so, I believe we can start shaping the concepts document toward this consensus, and inclusion of P2PSIP root peer and P2PSIP replica root peer seems like a reasonable place to start. But since we're supposedly documenting P2PSIP and not soft-drink concepts, I propose we leave the "root beer" out of the document for now.
>
>--
>Dean
>

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Tue, 4 Sep 2007 20:07:03 +0200

Hello,

On 04/09/07, Ted Hardie <[email-masked]> wrote:
> My personal opinion

I completely agree with Ted. The new architecture should support any
mechanism that supports the same primitives, and that it should be not
limited to DHTs.

Victor Pascual

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 4 Sep 2007 12:02:07 -0700

> But I think the plug-in architecture should support any mechanism that

> supports the same primitives, and that it should not be limited to 
> distributed hash tables.

Yes, this is exactly what the I-D on the P2PP describes and it is based
on a real implementation:

http://ietf.org/internet-drafts/draft-baset-p2psip-p2pp-00.txt  

Henry

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Tuesday, September 04, 2007 12:28 PM
To: Dean Willis; P2PSIP Mailing List
Subject: Re: [P2PSIP] Are we settled on a DHT approach? (was: Term for
thepeer who is responsible for a specific key)

>Use of DHT terms like root and replica root does point at one thing
that we've tried to dodge so far in the concepts draft, and that is "Is
the distributed database built on a DHT or something else?"

I believe this goes back to a question we've discussed and did not come
to a
consensus on.  That was, basically, how well do we want this to support
new technologies plugged-in as substrates here?  My personal opinion
is that we need to select a candidate technology to demonstrate
interoperability here, but that we don't need to specify a full-on,
long-term
mandatory-to-implement technology.  I think the candidate technology
should be based on one of the existing DHT solutions. 

>I think I'm detecting a general consensus emergence that the
distributed database is either built on a DHT, or on something so much
like a DHT that we could reasonably apply DHT terminology to it without
confusing too many people.
>
>Do we agree to this? If so, I believe we can start shaping the concepts
document toward this consensus, and inclusion of P2PSIP root peer and
P2PSIP replica root peer seems like a reasonable place to start. But
since we're supposedly documenting P2PSIP and not soft-drink concepts, I
propose we leave the "root beer" out of the document for now.

---

From: Dean Willis <[email-masked]>
Date: Tue, 4 Sep 2007 14:08:11 -0500

> why warned us? what's wrong with east-asian diets???

Apparently, root beer itself may be wrong with east Asian diets. I  
suspect there's a similarity between its flavoring and something that  
is used in an entirely different context across the region (but I  
haven't figured out what) so it just "tastes wrong". But I'd  
appreciate hearing if your experience deviates from my prior sample  
set. Next IETF in Dallas, remind me to bring a keg. ;-)

Meanwhile, I think I like Ted's proposal to selectively use the  
proposed DHT terminology where appropriate, and to potentially caveat  
it with a note to the effect that we've borrowed this terminology  
from the DHT literature, but that we're applying it to a distributed  
database that may not actually be based on distributed hash tables.

--
Dean

---

From: "Peter Pan" <[email-masked]>
Date: Tue, 4 Sep 2007 14:18:07 -0700

as i learned from wiki
(http://zh.wikipedia.org/wiki/%E9%BB%91%E6%9D%BE%E6%B2%99%E5%A3%AB), the
only prevailing root beer in taiwan uses similar formula of the root beer
that mexican natives drink to reduce heat. a taiwan merchant obtained the
formula by paying to learn the prescription of an american-imported
carbonated beverage sold at a shanghai pharmacy in 1945. added with little
salt the root beer does reduce heat, i experienced.

i feel so sad that no one sponsors a flight to dallas for me to appreciate
your naturally-brewed root beer :(

at least, however, i can appreciate any technology you know other than dht
that can be applied to serverless distributed database for p2psip
applications.

thank you.

----- Original Message -----
From: "Dean Willis" <[email-masked]>
To: "Peter Pan" <[email-masked]>; "P2PSIP Mailing List"
<[email-masked]>
Sent: Tuesday, September 04, 2007 12:08 PM
Subject: Re: [P2PSIP] Are we settled on a DHT approach? (was: Term for the
peerwho is responsible for a specific key)

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 05 Sep 2007 11:58:43 +0800

I am not disagreeing with what Ted is saying below, but it seems to be part 
of a conversation we haven't finished, which is why we don't have working 
group consensus yet.

Without actually trying to figure out who the original players were (and I'm 
remembering that we've been around the block a couple of times), I thought 
where we are is

while (waiting_for_additional_clue) {
    someone like Ted says what Ted says below;
    someone like Spencer agrees with what Ted says BUT;
    someone like Spencer also asks "how do I know
        my mobile device will work in a new overlay?" or
        "what technology do I use if I'm the first node in an overlay?";
    catch (timeout);
}

I'm not saying that we haven't made any progress on this particular point, 
I'm saying that we seem to be using different definitions for 
"interoperability", so we're caught between saying that, for our 
standards-track protocol specifications, either

"interoperability is for nodes with applications that use a common interface 
to some compliant distributed database"

OR

"interoperability is for nodes that may join any arbitrary overlay, as long 
as credentials would allow the node to join"

I have some opinions about my preference, but am I framing the right points 
here?

Thanks,

Spencer

From: "Ted Hardie" <[email-masked]>

>>Use of DHT terms like root and replica root does point at one thing that 
>>we've tried to dodge so far in the concepts draft, and that is "Is the 
>>distributed database built on a DHT or something else?"
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 5 Sep 2007 08:07:36 -0400

<as individual>
Yeah, and I'm often the "someone like Spencer".

I don't understand how you get any kind of interoperability with what Ted
proposes.  I also don't understand quite how you achieve "pluggable" in a
protocol definition; seems like more of an implementation thing.

Brian

> From: Spencer Dawkins [mailto:[email-masked]]
> Sent: Tuesday, September 04, 2007 11:59 PM
> To: P2PSIP Mailing List
> thepeerwho is responsible for a specific key)
> 
> to
> > a

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 Sep 2007 08:47:41 -0700

>protocol definition; seems like more of an implementation thing.

Probably the best way to describe this is by way of example.  If you
go back and read RFC 1035, you'll see an early definition of the DNS.
Some of the elements that are there have remained very fundamental
to the DNS:  the wire protocol that describes how different elements
query each other; the roles like authoritative name server and local resolver;
the extensibility mechanism with the introduction of new resource
records.  Change those and you lose interoperability.  The DNS allows
you to arrange them in many different ways (broad, flat zones like .com;
zones with unusual delegation like in-addr.arpa; and many mixes
in between), but retains a core interoperability without regard to
the deployment of the data within the zones.

1035 also defines a master file format (what we would commonly
call a zone file now).  Though versions of this are still used, you can
deploy the DNS using multiple different back-ends.  You can use an
SQL database in lieu of a master file quite easily and many do.  The
master file format is a plug-in, in my view, which could be changed
without disturbing over-much the overall operation.  If you have
a common one, some things get easier (you can rsynch the zone
file from a master, for example), but it doesn't break the fundamental
operation if you change it.

As we look at a peer to peer mechanism for distributed information
storage and retrieval, we should define the primitives
(the roles and wire protocols) so that the underlying DHT is not
the key driver.  If it is, I believe we will end up with the system
limited, in essence, by its zone file format; since current DHTs are
good at some things and not others, I worry that will, in turn,
make it difficult to arrange the data in all the different ways
which might eventually benefit from the peer-to-peer mechanism
(only able to deploy broad, flat zones, to carry the analogy out
a bit further).

Defining a DHT which will be used for initial demonstrations of
interoperability is necessary at this stage, much as defining a
master file format was needed 20 years ago.  It helps kick
start development and helps get things rolling.  But we should
be doing so with an eye to the replacements which might come
along in the next twenty years, so that its limitations do not have
too strong an impact on the capabilities of the system as a whole.

Hope that helps,
			regards,
					Ted

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 06 Sep 2007 02:29:56 +0800

Warning ... jet lag alert ...

Unlike most cycling mailing list topics in the IETF, we're actually learn 
something on each cycle about other people's positions. Ted, thanks for you 
turning the crank again.

If I'm getting what you're saying, you're NOT talking about what we do when 
a node that speaks Chord finds an overlay of nodes that speak Chord and 
Bamboo, but are currently speaking Bamboo.

What you ARE talking about is system evolution, so when someone invents the 
better-than-DHT-grommet, we're not looking at a lot of code, and a lot of 
nodes, that only understand DHTs, and has to be reworked at, say, the level 
of rework required to go from 1992 TCP/IPv4 to 2008 SCTP/IPv6.

You're NOT saying that the first doesn't matter, you're saying that the 
second is going to hurt a lot if we ignore it.

Am I getting this right?

Spencer

>>> >>that

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 Sep 2007 12:16:48 -0700

At 2:29 AM +0800 9/6/07, Spencer Dawkins wrote:
>Unlike most cycling mailing list topics in the IETF, we're actually learn something on each cycle about other people's positions. Ted, thanks for you turning the crank again.
>
>If I'm getting what you're saying, you're NOT talking about what we do when a node that speaks Chord finds an overlay of nodes that speak Chord and Bamboo, but are currently speaking Bamboo.
>
>What you ARE talking about is system evolution, so when someone invents the better-than-DHT-grommet, we're not looking at a lot of code, and a lot of nodes, that only understand DHTs, and has to be reworked at, say, the level of rework required to go from 1992 TCP/IPv4 to 2008 SCTP/IPv6.
>
>You're NOT saying that the first doesn't matter, you're saying that the second is going to hurt a lot if we ignore it.
>
>Am I getting this right?
>
>Spencer

Maybe it's anticipatory jet-lag on my part (I'm going to be on planes a lot, real
soon now), but your rendition confused me.  Let me try again.

We should be designing this so that the protocol has certain functions that
work the same way no matter what the underlying peer to peer layer.  Imagine
that as an abstraction layer if you like, that says a participant speaks "op2p"
(overlay peer to peer) to other nodes when it wants to find a resource or send
traffic to another participant (or whatever the key semantics turn out to be).  
The *syntax* of how it speaks "op2p" is equivalent in the analogy below to the DNS
wire protocol; the *semantics* of what roles are available (e.g. registration server,
participating node, "leach" node), in contrast,  correspond to things like the querier,
authoritative name server,  and caching resolver in the DNS example. 

That level of syntax and semantics shouldn't change as you change out the
DHT/peer-to-peer mechanism, any more than the DNS wire protocol should
change when the back-end shifts from a zone file to a sql database.  We don't
ask DNS clients to construct SQL queries when the backend is Oracle; they use
the abstraction to ask and the database uses the abstraction to respond.

We could select a winner and say "the choice is Chord".  If we do that,
I'll bet you a donut (glazed Krispy Kreme) that we will later have
at least some deployments that want to use new technologies as the
underlying peer to peer layer.  They will treat Chord's syntax as the
abstraction layer, and the roles in Chord will become the constraining
semantics.  I'd rather we start from the presumption that there will
more than one technology deployed and use a "speaks p2p" approach
rather than a "speaks Chord" approach.

I'd say that I hoped that turned your crank, but I fear it might be misconstrued.
So let me just say that I hope your jet lag improves,

					Ted

>>>>>>Use of DHT terms like root and replica root does point at one thing >>that
>>>>> I believe this goes back to a question we've discussed and did not > come
>>>>to
>>>>> a
>>>>> consensus on.  That was, basically, how well do we want this to > support
>>>>> to distributed hash tables.  If some function other than hashing is > used

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 06 Sep 2007 05:16:32 +0800

Hi, Ted,

Good luck with YOUR jet lag.

I keep finding things in every paragraph that you type to agree with. You 
have turned my crank in the best possible sense of the word. I am still 
somewhat out of sync with the conclusion. Let me back up and try again.

I'm totally down with not having to redo DNS every time somebody changes a 
back-end storage technology. It would be great if we could do something 
similar for P2PSIP.

I'm comfortable with the semantics in P2PSIP not changing when we change 
DHT-or-whatevers (I'm not sure how much they COULD change - if we're 
fundamentally joining an overlay, finding peers in that overlay and routing 
messages that set up sessions with out-of-channel media, that seems pretty 
future-proof already).

I don't understand how the syntax doesn't change if we move from Chord to 
Bamboo. I can understand how that would be a good thing, I just don't have 
any idea how that happens...

... unless you're talking about a DHT-independent layer between the 
DHT-or-whatever and applications? ...

... which could very well be a good thing, but doesn't get my Chord node 
into an overlay unless the overlay speaks Chord ...

... so, since you aren't worried about this and I am, I'm sure I'm missing 
something.

To thicken the plot, I'm now thinking that "maintaining the overlay" may be 
difficult to abstract so well that we don't care what the underlying 
DHT-or-whatever is. But you don't have to worry about that now - the plot 
was thick enough without that thought.

I hope you can reply before you get on a plane, because it would take every 
brain cell *I've* got to solve this one.

Travel safely, and have a great week,

Spencer

>>something on each cycle about other people's positions. Ted, thanks for 
>>you turning the crank again.
>>
>>If I'm getting what you're saying, you're NOT talking about what we do 
>>when a node that speaks Chord finds an overlay of nodes that speak Chord 
>>and Bamboo, but are currently speaking Bamboo.
>>
>>What you ARE talking about is system evolution, so when someone invents 
>>the better-than-DHT-grommet, we're not looking at a lot of code, and a lot 
>>of nodes, that only understand DHTs, and has to be reworked at, say, the 
>>level of rework required to go from 1992 TCP/IPv4 to 2008 SCTP/IPv6.
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 5 Sep 2007 19:36:28 -0400

I admit that I find the debate a bit theoretical. There are several  
proposals, one of which I'm co-authoring, that indeed have the  
property that the DHT can be replaced without changing the underlying  
protocol. We even have an implementation to show that this works.  
This turns out to be relatively straightforward; we can even run  
several different DHT on one node, as "ships in the night". This  
isn't magic - DHTs are essentially graphs that need to be maintained.  
The protocol just builds and tears down the edges and doesn't really  
care as to why node A and node B are connected with each other and  
whether node A is logically connected to one node or a dozen. This  
isn't fundamentally different from saying that pointers in a  
programming language can be used to construct any data structure. As  
with pointers, you don't have to worry about some new data structure  
that suddenly can't be mapped.

Clearly, all nodes in an overlay have to (more or less) agree on the  
graph construction, as otherwise you won't get convergence. (They can  
disagree on the number of successor nodes and other details that  
primarily deal with reliability and speeding up search rather than  
correctness.) Thus, this doesn't address the "need for single DHT"  
question.

Henning

On Sep 5, 2007, at 5:16 PM, Spencer Dawkins wrote:

> I keep finding things in every paragraph that you type to agree  
> with. You have turned my crank in the best possible sense of the  
> word. I am still somewhat out of sync with the conclusion. Let me  
> back up and try again.
>
> I'm totally down with not having to redo DNS every time somebody  
> changes a back-end storage technology. It would be great if we  
> could do something similar for P2PSIP.
>
> I'm comfortable with the semantics in P2PSIP not changing when we  
> change DHT-or-whatevers (I'm not sure how much they COULD change -  
> if we're fundamentally joining an overlay, finding peers in that  
> overlay and routing messages that set up sessions with out-of- 
> channel media, that seems pretty future-proof already).
>
> I don't understand how the syntax doesn't change if we move from  
> Chord to Bamboo. I can understand how that would be a good thing, I  
> just don't have any idea how that happens...
>
> ... which could very well be a good thing, but doesn't get my Chord  
> node into an overlay unless the overlay speaks Chord ...
>
> ... so, since you aren't worried about this and I am, I'm sure I'm  
> missing something.
>
> To thicken the plot, I'm now thinking that "maintaining the  
> overlay" may be difficult to abstract so well that we don't care  
> what the underlying DHT-or-whatever is. But you don't have to worry  
> about that now - the plot was thick enough without that thought.
>
> I hope you can reply before you get on a plane, because it would  
> take every brain cell *I've* got to solve this one.
>

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 06 Sep 2007 08:07:19 +0800

Hi, Henning,

I agree that this isn't magic - you guys have been talking about reasonable 
solutions for a while.

I'm not arguing that the problem cannot be solved, I'm arguing that I'm not 
sure what problem we're solving.

Your choice of the phrase "ships in the night" is helpful, because it frames 
the question. We often see this phrase in routing, where (for example) we 
run OSPFv2 for IPv4 and OSPFv3 for IPv6 on the same network, but the two 
graphs being maintained are independent, and the routing exhanges for one 
graph don't affect the other graph at all.

Is that the way we want P2PSIP to work?

I am not expressing an opinion, I'm trying to figure out if I'm 
understanding what you're proposing.

Thanks,
]
Spencer

>proposals, one of which I'm co-authoring, that indeed have the  property 
>that the DHT can be replaced without changing the underlying  protocol. We 
>even have an implementation to show that this works.  This turns out to be 
>relatively straightforward; we can even run  several different DHT on one 
>node, as "ships in the night". This  isn't magic - DHTs are essentially 
>graphs that need to be maintained.  The protocol just builds and tears down 
>the edges and doesn't really  care as to why node A and node B are 
>connected with each other and  whether node A is logically connected to one 
>node or a dozen. This  isn't fundamentally different from saying that 
>pointers in a  programming language can be used to construct any data 
>structure. As  with pointers, you don't have to worry about some new data 
>structure  that suddenly can't be mapped.
>

---

From: "Peter Pan" <[email-masked]>
Date: Wed, 5 Sep 2007 19:19:03 -0700

you: "We even have an implementation to show that this works."

    me: "which dhts are in your implementation?"
    me: "is it exhaustive enough?"

you: "we can even run several different DHT on one node."

    me: "what's the advantage of this capability?"
    me: "who will adapt this capability?"

thank you.

pp
----- Original Message -----
From: "Henning Schulzrinne" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: "'P2PSIP Mailing List'" <[email-masked]>
Sent: Wednesday, September 05, 2007 4:36 PM
Subject: Re: [P2PSIP] Are we settled on a DHT approach? (was: Term
forthepeerwho is responsible for a specific key)

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 5 Sep 2007 23:10:47 -0400

>     me: "is it exhaustive enough?"

I suspect we'll never satisfy some people, even if we implemented a  
dozen DHTs. So far, none of the standard DHTs (CAN, Chord, Kademlia)  
seemed to raise particular issues.

>     me: "who will adapt this capability?"

It's very helpful for testing and allows to run multiple applications  
on the same system, without worrying about port allocation, for  
example. It imposes no significant cost except for an identifier.