On Tue 2002.11.05, Keith Moore wrote:
purposes, or for all apps. My concern is that an API that "encouraged"
apps to use DNS (by making it difficult or infeasible to use IP addresses)
would cripple that's platform ability to support some kinds of apps.
INFS is simply a VFS wrapper around the existing socket implementation.
Check it out - the kernel patch is not for disabling the socket() call,
but rather, to add two new hooks, sock_morph() and sock_demorph() to
the existing sock_create() and sock_destroy() entry points. In short,
you continue to have the full socket API with no impediment to its use.
INFS is meant to be a high level addendum to the socket API. This is
in keeping with the spirit of Unix that there be high as well as low
level APIs, like /dev/hd0 and /proc, etc.
The previous paragraph answers this to the extent INFS supplements
the current status quo and the limitations of the DNS.
I don't see how INFS supplements the limitations of DNS at all. The
INFS is a general VFS wrapper. My thesis talks about an alternative namespace
that goes beyond DNS in many respects. As I'm still working on filling in
some details, it's probably better to hold off discussion on that for a
couple of months.
Personally, I would prefer a variable length address space, and I think
the technical performance issues with this could have been addressed.
This was discussed in the Nimrod proposal in the early 90s. However, it
would still be low level and impose manual end to end coordination effort
like IP. The advantage with going to a name-based primary addressing scheme
is that the address space in many senses defines itself.
Even assuming that a variable-length IP address were better, that would
not argue for trying to overload DNS names to do that job.
Not at all, and the DNS is indeed not what I had in mind. On the other hand,
both Nimrod and the more recent Francis and Gummadi's IPNL schemes, as well
as Cheriton's Triad at one time, depend on the DNS for linking routes between
route map regions (in Nimrod) or realms (Triad, IPNL).
So you'd prefer that the network advertise routes to DNS suffixes
to having it advertise routes to IP prefixes, and forcing DNS
to reflect network topology?
Not really. I'd prefer (a) a different kind of namespace that's
designed for this purpose and (b) a two level approach in which
this other namespace reflects topology only between realms, leaving
the intra-realm routing to IP and DNS. This is somewhat like IPNL,
but avoids protocol shims and the 48-bit limit, among other differences.
Forgive me if I don't read your whole thesis right now. If you have
a 10 or 20 page summary I'd be willing to look at that.
The first 17 pages pretty much cover the philosophy and the principles
of architecture and operation, with tons of figures. The remaining
sections are mostly algorithms that can be skipped.
I'm working on condensing it somewhat for the Annals special issue,
but it would probably mean throwing out many figures. Sigh.
If you recall, we had a good bit of discussion on this mailing list
last year, following a very premature I-D I'd put out in Nov'00.
I learnt many things from that discussion, such as the notion and the
importance of orthogonality between the DNS and IP-level routing.
[ Speaking of orthogonality, I made the observation, in my INET'01 poster,
that DNS and IP are not really orthogonal because of the overlap of
identification role - the right word should be independent. To have
orthogonality, one must have only identification and other, only location.
Since you can't strip the id role from names, it must be stripped from
IP, and that's what my thesis is about. ]
sincerely,
-prasad.