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.