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.