Subject: RE: Fwd: Minutes / Notes

From: "Christian Huitema" <[email-masked]>
Date: Thu, 24 Jul 2003 16:31:20 -0700

> > iii) Use multiple addresses, one of which is a "virtual address"
that is
> > guaranteed to be reachable all the time, albeit slowly. Use the
virtual
> > address to start connections. Use MIPv6 mechanisms to divert to an
> > actual address.
> 
> What do you do when the network hosting your HA drops dead?

That's why I was mentioning a virtual address rather than an HA. Are you
familiar with the distributed hash table algorithms? Basically, a DHT is
a reliable overlay on top of an arbitrary network. In a classic DHT
design, nodes have identifiers randomly spread in a large number space.
They maintain "routing tables" that allow them to forward a request for
a given number to the host most likely to know about it, etc. The common
trade-off is to have routing tables that scale as the logarithm of the
size of the network (O(log N)), while the number of relays required to
reach a specific destination also scales as O(log N). The routing table
would contain the current addresses/locators associated with the
identifier.

-- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Jul 2003 16:37:18 -0700

> would contain the current addresses/locators associated with the

Sounds cool.  Got draft?

Eliot

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jul 2003 08:40:21 +0859 ()

Christian;

> would contain the current addresses/locators associated with the

Feel free to call it IPv7.

						Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 25 Jul 2003 11:12:10 +0200

On vrijdag, jul 25, 2003, at 01:31 Europe/Amsterdam, Christian Huitema 

> design, nodes have identifiers randomly spread in a large number space.

If you can distribute your information over a set of reliable and 
trustworthy nodes, this could work very well. However, we can't assume 
any one node to be reliable, so we need to build in a good deal of 
redundancy and dynamic replication. This also means that a resolver may 
need to contact several nodes in sequence to find the required 
information. But it gets worse: a node that is supposed to hold a 
certain piece of information could, rather than hand over the requested 
information, claim that the information doesn't exist. The only way 
that I can see to get around this is distribute copies of the same 
piece of information over so many nodes that it becomes infeasible to 
corrupt them all. Which probably means there isn't a workable tradeoff 
between security/reliability and performance.

So essentially this has all the downsides of DNS and then some, with 
the only advantage that you now get to search in flat spaces too.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Jul 2003 13:57:55 +0200 (CEST)

> the only advantage that you now get to search in flat spaces too.

I guess we don't agree on the parameters of the problem we are trying to
solve yet.

One possible set of parameters is that the identifier space is hierarchically
structured with "sufficient" hierarchy. In such a case a hierarchical lookup
system like the DNS might be appropriate.

Another possible set of parameters is that the identifier space is flat
(for example, an ID is based on a hash of a public key) or with limited
hiearchy (e.g., N bits of flat site ID followed by 128-N bits of flat
"ID within site"). In that case a hierarchical lookup system like the DNS
doesn't seem like a good fit.

Figuring out how to use a DHT in the latter case has some issues that folks
need to look at. In addition to the ones you pointed out, one would also
need to be able to do DHT resolution for nodes belonging to the same site
when the site is cut off from the rest of the internet.

  Erik