[ppml] a modified proposal 2005-8

[Tony Hain]

Owen DeLong wrote:
> ...
> And if you go with a strictly positional model, then, you assume that
> all population density is equal.  The idea of a /128 per square foot
> sounds great until you consider the possibility of a 100 story
> office building with 10 floors of high-density colocation (45
> 1U servers per cabinet) and 90 floors of moderate to high density
> office.

draft-hain-ipv6-pi-addr shows how to map a /48 per sq meter (equatorial
approximation). There is a discussion about altitude because people kept
insisting it needed one, but it is currently broken as it doesn't account
for surface variations. In any case, high rise buildings are not mounted on
a pinnacle foundation, so there are a large number of /48 prefixes available
to work with.

> 
> >> In fact, this type of
> >> scheme is proven to work for interactive applications since
> >> this is how phone number portability works.
> >
> > While that model works for service provider controlled applications, it
> > would be more effort to implement for P2P application models. The
> > timeliness of global database updates would have to be better than dns,
> > and there is always the 'trust' issue about who has access and rights to
> > make the change. The problem of crossing the trust boundary should not
> be
> > minimized.
> >
> The timeliness of global updates only needs to be better than DNS if
> the churn rate is higher.  If instead of changing the addresses,
> we change indirect the addresses to one or more routing locators
> through the same database, then, the routing locator updates don't
> actually need to be all that timely since they will not change
> often (where often is defined as a given record changing more
> than once every 5 minutes or so).

No matter how you do it some part of a distributed database will need timely
updates. Shell games claiming to make the problem go away by moving them
somewhere else don't actually solve the problem. This is why the double nat
locator replacement approaches fail. You can always know enough locally to
do the front end part, but getting that propagated to the system that will
have to translate back (and even knowing where that is) will be a
non-trivial problem. 

> 
> 
> >>
> >> Given that such mapping schemes are almost certain to
> >> be based on a database, then there should be no scaling
> >> problems.
> >
> > Then why does it take so long for simple dns changes to propagate
> > globally? Wouldn't that be due to an operational requirement
> specifically
> > implemented to deal with scale? After all DNS is a distributed database.
> > Or are you assuming that this is a central database which has scaling
> > issues in another dimension? There are always scaling problems; it is
> > just a matter of finding the lowest cost trade-off.
> >
> DNS changes with short TTLs propogate quite rapidly.  If I sent the
> TTL on my DNS record to 60, then, generally speaking, (other than
> buggy clients), I can depend on everyone getting the new version
> within 120 seconds.

And the reason that all records are not set with short ttl's is that the
resulting query rate would cause the global system to roll over. The trick
is knowing at least the current ttl's setting in advance that you will need
to move so you can set it short soon enough to affect the move in a timely
manner; then setting it back to a long value after the move to reduce query
rates. 'Just set the ttl' is an easy generalization to make when it has
sufficient advanced notice. It also requires someone with the technical
understanding to know what to change and when. 

Tony