Thanks for your thoughtful comments and look forward to more. Since I wrote INFS back in May-Jun, I already have had discussion on some of these issues, as given below. -p. On Tue 2002.11.05, John Stracke wrote: > The problem is that only the app knows what kind of caching behavior it > needs. For a simple protocol like SMTP or HTTP, pure DNS-based caching > is fine; for a more sophisticated protocol (e.g., any sort of > videoconferencing app), it may be necessary to ensure that each > connection associated with a given session go to the same address. I see both as largely system calls API issues, permitting simple and elegant solutions, and as not fundamental networking constraints that would legitimately rule against the INFS approach. As Vahalia (Unix internals book) describes, different network filesystems involve very different caching behaviours, meaning that the VFS name tree cache already caters to a wide variety of desired behaviours. The Linux VFS, for example, provides for per-node ttl, and can be manipulated on a per- process basis by setting mode parameters specifying the cache control before "opening" the nodes. For the second requirement, a simple known approach is to pass the already open (socket) file descriptor as argument when opening the secondary connections, so that the fd serves as an abstract handle for the previously obtained address. This is one of the things I am hoping people will play with in the INFS and lead to a mature networking API. > The fixed-length numeric addresses still need to exist, and their nature > still needs to be coded into all hosts and routers. Hiding them from > the apps will not make it easier to upgrade the installed base. No, but it would avoid inertia from the apps, whose hardcoding for IPv4 sockaddr's does pose some problems for v6 migration and dual support in wireless devices and appliances. I don't have data first hand on the magnitude of the problems involved, but have been told that it is enough to make INFS attractive. One analogy that comes to mind is that having app code doesn't eliminate disk sector addresses and formatting. One cannot upgrade to a larger disk by simply dd'ing from the old disk. However, mercifully, we store files and directories today by name and not disk sectors, and copying name-by-name, i.e. at the filesystem level, simplifies the upgrade. To compare, it was not too long ago that this wasn't the case! > You're talking about permitting automatic renumbering. How does that > happen without disrupting established TCP connections? What I am talking about is not *just* automatic renumbering, but renumbering with aggregation, and on large scales eventually including the entire Internet. Internet-defrag, so to speak. The sub-problem of preserving TCP connections has been variously addressed in other scenarios, e.g. in Snoeren and Balakrishnan's Mobicom'00 paper. There are TCP protocol extension proposals to allow renumbering of end points within the connection. Given the relative infrequency of re-aggregation, say weekly, and the increasingly shorter lifespan of TCP connections on the external Internet, it might even be worthwhile in subnets to simply carry the old address till the existing TCP sessions terminate. It would have been neat if TCP already had the provisions to allow transparent renumbering, but the difficulties of developing and deploying this feature appear to be increasingly less significant, compared to the savings that would result from automatic renumbering and aggregation.
