Subject: kernelizing the network resolver

From: V Guruprasad <[email-masked]>
Date: Wed, 30 Oct 2002 18:33:14 -0500

Hi everyone,

Please check out http://infs.sourceforge.net for a novel INternet
FileSystem (INFS) package which appears to be ideally suited to
cell phones and other small devices or appliances. By pushing the
DNS resolution to the kernel, INFS means to achieve the following:

- eliminates sockaddr_t handling in the user space, allowing
  application code to become free of IPv4/IPv6 (or for that matter
  raw Ethernet or ATM) dependencies;

- reduces the number of context switches going from application
  to resolver and back;

- provides robust kernel multitasking for the resolution process,
  avoiding buggy or unsafe multithreading in application-based
  resolvers (like in netscape);

- reduces the overall code footprint - the filesystem name tree
  cache is reused, sockaddr_t handling code in applications gone.

This is still a pre-alpha version, sufficient only to illustrate
the concept. A few system calls need to be added to completely
eliminate any need for handling sockaddr_t in user space. Also,
the dns response parsing can be improved - it currently gets
confused with CNAME records (e.g. from www.microsoft.com), tho'
it does tolerate multiple A records (e.g. from www.ibm.com).

To the anonymous referees of my sigcomm submission earlier this
year on the Namespace Addressing Principle: you might recognize
that I was proposing INFS - but it was untried till May. the
full thesis is not yet final (but the global Internet self-management
algorithms hinted at are now described in the draft Annals paper
at http://www.columbia.edu/~vg96/papers).

I look forward to comments, education*, help...

Sincerely,
-prasad.
------------------
* finally a true student: no longer at ibm or anywhere!

---

From: John Stracke <[email-masked]>
Date: Fri, 01 Nov 2002 11:01:45 -0500

>  raw Ethernet or ATM) dependencies;
Doesn't using a shared library for the resolver give you the same 
benefit? It's in user space, but it's not in the app.

>- reduces the number of context switches going from application
Do you have data showing these context switches are a problem? To me, it 
seems like you're optimizing something that doesn't take up that much 
time anyway--what apps spend that much CPU time on DNS lookups?

>  resolvers (like in netscape);
Again, the same thing can be done with a good shared lib.  Most current 
Unices include gethostbyname_r(), which is thread-safe.  Netscape just 
started too early, when threading support in the OS was still pretty uneven.

>  cache is reused, sockaddr_t handling code in applications gone.
Again, shared libs also reduce duplicate code (though not data; for that 
you do need the kernel, or a daemon).

-- 
/===============================================================\
|John Stracke      [email-masked]                      |
|Principal Engineer|http://www.centivinc.com                    |
|Centiv            |My opinions are my own.                     |
|===============================================================|
|If you're going to walk on thin ice, you might as well *dance*!|
\===============================================================/

---

From: Keith Moore <[email-masked]>
Date: Fri, 01 Nov 2002 11:25:10 -0500

>   raw Ethernet or ATM) dependencies;

so when the address changes out from under the app, or there are
multiple hosts bound to a single domain name, the app loses.
and the app is also forced to live with delays and lower reliability
of DNS whether or not it is appropriate for that app.

it seems useful for some apps, but it doesn't remove the need for
sockaddr support.   why are you trying to wean apps off of using
IP space when for many purposes DNS is even worse?  DNS is slower
and less reliable than IP, no more consistent than IP, and DNS names
are as overloaded as IP addresses.

Keith

---

From: "Perry E. Metzger" <[email-masked]>
Date: 01 Nov 2002 12:06:28 -0500

> DNS resolution to the kernel, INFS means to achieve the following:

This isn't really appropriate for the IETF mailing list.

Perry

---

From: V Guruprasad <[email-masked]>
Date: Mon, 4 Nov 2002 00:27:22 -0500

Dear John,

> benefit? It's in user space, but it's not in the app.

Yes, sockaddr_t can be eliminated using a shared library, but in order
to do that, we must replace the following steps:

	server side:
		1  hostent_t haddr = gethostbyname (char* namepath);
		2  sockaddr_t sockaddr := { haddr, int port };
		3  fd_t sock = socket (domain, type, protocol);
		4  listen (sock);	 /* optional */
		5  bind (sock, sockaddr, sizeof (sockaddr));

	client side:
	[1,2,3] and
		7  int addrlen = sizeof (sockaddr);
		8  fd_t sock = connect (sock, sockaddr, &addrlen);

with one function call
	9  fd_t sock = sockaddressless_socket_open (
				char* namepath,
				int type,
				int protocol,
				int port
				);
This is only one step removed from the INFS version
	10  fd_t sock = open (char* namepath, int flags, [int omode]);
if the port, type and protocol parameters are included in the namepath as
	e.g. /com/ibm/research/www/rtsptoolkit/tcp:80.

The real motivation for going this extra step was the thesis that
emerged in the incomplete sigcomm02 submission, for which we (my
immediate ex-colleagues and I) had two important ingredients begging
for a top-down architectural story:

A) an alternative namespace-based "addressless networking" algorithm
   presented at ECUMN'00, together with a prototype implementation
   (as MS project) demo'd at INET'01; and

B) an address/route auto-aggregation algorithm comprising a Huffman-like
   recursive address assignment scheme applied to Dijkstra routing trees.

(A) says that a distributed network namespace is sufficient as a
primary addressing mechanism (the proof involves a basic property of
an unshared distributed tree as a self-defining network address space),
i.e. not depending on a manually managed/coordinated numeric address
space like IP. Thus, (A) facilitates (B) and (B) motivates (A).

However, this also means that the end-to-end-ness or long term stationarity
of the numeric (IP) addresses should no longer be taken for granted, and
that names should be used instead as the primary reference. This makes
it imperative to consider an alternative networking API that uses names
as addresses. Since the ordinary notion of what constitutes "system"
and what "application/user" concerns the operating system boundary, a
system calls interface of this form merited consideration. The fact that
the open(2) already has almost the desired form, and caters to a hierarchical
(filesystem) namespaces as well, made the INFS approach all the more
interesting to try out.

Yes, a shared library is still the way to go on many platforms, especially
on Windows where the socket implementation itself comes from dll's. The
filesystem interface is more restrictive, however, and provides a stronger
test of the sufficiency of the filesystem/file operations paradigm.

> time anyway--what apps spend that much CPU time on DNS lookups?

The context switching reduction was intended only to point out
that performance is likely to improve rather than worsen. However,
yes, it is one of the things on the to-do list, but I don't know
how soon I can get around to it given my current resources (being
out of job!).

> you do need the kernel, or a daemon).

The code reduction is *slightly* more than with just shared library:
with an slib, duplications between apps is avoided, but there is at
least one slib implementation of parsing and name caching code. With
the infs approach, even this much of the slib would be eliminated
as the vfs already contains similar code and would be reused.

I wholeheartedly agree that this much of code reduction is not all
that big a diff today, as memory and cpu cycles are quite cheap and
becoming even cheaper by the minute, but if a reduction is possible,
it's always educational to try it out. However, the sockaddr_t and
VFS integration were the main motivations.

thanks,
-prasad.

---

From: V Guruprasad <[email-masked]>
Date: Mon, 4 Nov 2002 00:58:38 -0500

> multiple hosts bound to a single domain name, the app loses.

I don't see why name-address caching within the kernel cannot be as
good or as bad as caching in the user space. I believe this would be
an important area that the current Linux implementation of INFS allows.

> of DNS whether or not it is appropriate for that app.

Programs which more directly concern the IP infrastructure, e.g. like
traceroute or tcpdump, should naturally continue using IP addresses
as arguments. It is only for "true apps", for which use of DNS names
as command arguments is as such recommended, that INFS use is envisaged.
I like to think that while this distinction isn't black and white,
it is not altogether grey either. Again, this is precisely the kind
of issue a working implementation is needed to answer, hence INFS.

> are as overloaded as IP addresses.

The previous paragraph answers this to the extent INFS supplements
the current status quo and the limitations of the DNS.

There is a sounder philosophical/physics argument, given in my thesis
(section 1.3/1.4), for the idea of weaning apps off IP or similar
numeric address spaces. Very briefly, the two main reasons are (a)
that any fixed-length numeric address space automatically sets a
hard limit and resists expansion, as we are finding from the IPv6
migration, and (b) not depending on fixed-length numeric addresses
as primary (user & application level) addresses would enable the
network to auto-aggregate its addresses and routes. A more consistent
and less overloaded namespace is naturally required, and is at least
partly addressed by the alternative namespace (ANS) described in the
thesis. (The driver for ANS would be simply another INFS kernel module
like the dns driver in INFS.)

Please note that the thesis is not yet final, in that I need to rework
it a bit and add some results, but it is sufficient to the extent of
motivating and relating to INFS.

Thanks for your thoughtful comments. I should add that our previous
discussions re: addressless networking i-d last year substantially
educated me and influenced the arguments in the sigcomm'02 submission
and the thesis.

sincerely,
-prasad.

---

From: John Stracke <[email-masked]>
Date: Tue, 05 Nov 2002 11:14:45 -0500

>an important area that the current Linux implementation of INFS allows.
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.

>Very briefly, the two main reasons are (a)
>migration, 
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.

>and (b) not depending on fixed-length numeric addresses
>network to auto-aggregate its addresses and routes.
>
You're talking about permitting automatic renumbering.  How does that 
happen without disrupting established TCP connections?

---

From: Keith Moore <[email-masked]>
Date: Tue, 05 Nov 2002 14:57:15 -0500

> an important area that the current Linux implementation of INFS allows.

The issue I'm concerned about is not where DNS cacheing is done, nor 
is it whether there is an interface that allows apps to open sockets 
based on DNS names.  The issue is whether the app has the ability 
(without too much hair) to specify socket endpoints using IP addresses 
rather than DNS names.  Another issue is whether the app has the 
ability to perform DNS queries directly.

Basically and for a variety of reasons DNS is not suitable for all 
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.

> as command arguments is as such recommended, that INFS use is envisaged.

There are more apps that need to avoid using DNS than those "which more 
directly concern the IP infrastructure".  For instance, any app for 
which connection setup time is an issue, or for which performance can
be improved by careful selection from a variety of servers, is a 
candidate for not using DNS - at least not on every connection setup.

> the current status quo and the limitations of the DNS.

I don't see how INFS supplements the limitations of DNS at all.  The
best it can do is shrink the application footprint (which usually
isn't an issue as the DNS library is shared anyway) and slightly reduce
the amount of code in the app.  It certainly doesn't improve DNS 
reliability or performance.

> hard limit and resists expansion, as we are finding from the IPv6

Personally, I would prefer a variable length address space, and I think
the technical performance issues with this could have been addressed.
Having said that, it's not at all clear that 128 bits is a "hard limit" 
in the sense that 32 bits was.  This really depends on whether having so
many address bits causes addresses to be used for many more things than
they were previously used - i.e. far more than one address per host.

Even assuming that a variable-length IP address were better, that would
not argue for trying to overload DNS names to do that job.

> network to auto-aggregate its addresses and routes. 

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?
 
> A more consistent

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.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 05 Nov 2002 14:58:59 -0500

> that names should be used instead as the primary reference. 

No it doesn't, because your overloading of DNS names for this purpose
interferes with their utility for other purposes.  

Keith

---

From: John Stracke <[email-masked]>
Date: Tue, 05 Nov 2002 15:26:29 -0500

V Guruprasad wrote:

>On Tue 2002.11.05, John Stracke wrote:
>
>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.
>
I disagree.  The answers you give seem to say that you assume there are 
only a few possible variations on an application's needs, which is not 
the case.

>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.
>
(a) This requires that the kernel be able to support the cache logic 
that the app needs.  The only way to support apps with novel 
requirements is a minimalist API on which the app can build its own 
logic.  That's the lesson of Unix--and, for that matter, of IP.

(b) Per-process is not sufficient, because a given process may need 
several different styles of caching.  For example, consider a 
conferencing program with an embedded LDAP client.

>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.
>
That works only if the first connection is still open.

In addition, not all applications use connected sockets.  If you're 
using a UDP-based protocol, it may be more efficient to have a single 
unconnected socket, and specify the recipient address on each packet you 
send.  This is especially true for servers; if you've got lots of 
requests coming in, and they don't require a lot of user-space CPU, then 
the cost of creating a new socket for each request could add 
significantly to the cost of serving the requests.

>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.
>
And you think you won't encounter inertia trying to get people not to 
use sockaddrs at all?

>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.
>
Securely? And what about all the non-TCP-based protocols?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 5 Nov 2002 22:12:56 +0100 (CET)

> interferes with their utility for other purposes.

What other purposes do DNS names have other than identifying a host, or
possibly a service?

The multi6 wg is working on scalable multihoming in IPv6. It looks like
this will be done by separating identifiers from locators. One (radical)
way to do this would be to use the full host name as the identifier and
IP(v6) addresses as the locators. Other than the fact that it breaks
all known transport protocols, this makes a lot of sense IMO.

Unfortunately multi6 doesn't have anything on the official agenda for
Atlanta. If anyone who is going to Atlanta is interested in hearing
about what's happening in and around multi6, let me know.

Iljitsch van Beijnum

---

From: Keith Moore <[email-masked]>
Date: Tue, 05 Nov 2002 16:39:35 -0500

> What other purposes do DNS names have other than identifying a host, or

trying to make DNS names serve as connection endpoint identifiers dilutes 
their utility as host or service names.  

Keith

---

From: Bill Manning <[email-masked]>
Date: Tue, 5 Nov 2002 14:06:38 -0800 (PST)

% The multi6 wg is working on scalable multihoming in IPv6. It looks like
% this will be done by separating identifiers from locators. One (radical)
% way to do this would be to use the full host name as the identifier and
% IP(v6) addresses as the locators. Other than the fact that it breaks
% all known transport protocols, this makes a lot of sense IMO.
% 
% Iljitsch van Beijnum

	for those doomed to about to repeat history...
	check the archives for NIMROD.
	or current work in DCCP.

	this is not greenfield, its well plowed ground.
	have you done your homework?
-- 
--bill

---

From: V Guruprasad <[email-masked]>
Date: Tue, 5 Nov 2002 12:59:26 -0500

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.

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.

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!

> 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.

---

From: V Guruprasad <[email-masked]>
Date: Tue, 5 Nov 2002 15:50:56 -0500

> interferes with their utility for other purposes.

Imho, use of A records is not an overload.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 05 Nov 2002 18:24:54 -0800

Bill,

The field may have been well plowed by NIMROD, but the IETF forgot to 
water it.  This organization has never sufficiently answered the route 
scaling problem, and the ISPs are paying for it today.  The question is 
really whether IPv6 is properly deployable over the long term without a 
new multihoming paradigm (for `pick your definition of multihoming`).

The usual suspects (including Noel) are working through these scaling 
issues on multi6.

Eliot

---

From: Randy Bush <[email-masked]>
Date: Tue, 05 Nov 2002 18:59:16 -0800

> water it.

it needed to be planted too, i.e. a documented and finised design

randy

---

From: V Guruprasad <[email-masked]>
Date: Tue, 5 Nov 2002 17:47:37 -0500

> only a few possible variations on an application's needs, which is not

Au contraire, I am simply being more open to the idea that the OS interface
can be as simple and general as applications need it to be. But, that's
admittedly a matter of faith - in some cases, for example, with SysV's
streams modules, the generalization can become complex enough to limit
it from general adoption.

> logic.  That's the lesson of Unix--and, for that matter, of IP.

True, so aren't you assuming that use of INFS somehow prevents use of
the traditional socket system call for the special needs? The lesson
of Unix is also that while we provide a high level i/f that suffices for
most apps, we also provide a low level i/f - viz the /dev/hd0, /dev/hda
etc. interface available for special needs. It's in Windows that I don't
see a convenient low level access for the disk, the usb, etc. Unix is
a minimalist, not a restrictionist, philosophy, and this is in fact
reflected in my implementation - the kernel patch merely adds sock_morph()
and sock_demorph() to support INFS, it doesn't subtract anything.

All I'm saying here's another way, try this too, maybe in some cases,
like small wireless devices, you'll find it advantageous. It doesn't
have to be equally advantageous for large, wired servers.

> conferencing program with an embedded LDAP client.

I meant that as example. The source code is there so that people can try
more imaginative things out if they want to. (so please don't give me
*all* the ideas or the others will feel left out ;-)

> That works only if the first connection is still open.

True, but that's not the only trick up the kernel programmer's sleeve.

> significantly to the cost of serving the requests.

Of course.

The neat trick of INFS is that it reuses the open(2) system call for
connected sockets, since the filename argument can be used for the DNS
pathname. However, it's a trivial matter to arrange the code to return
an unconnected socket for a null filename argument, which is what you'd
generally want for server-side sockets.

With unconnected sockets, it is known that you can't use read()/write()
calls in any case, and must use the send()/recv() calls that take a
destination parameter.

For the INFS version of send/recv, we'd allow a DNS name as the destination
argument, but note, as already mentioned above, that the low level socket
API remains intact - the old send/recv calls will work.

> And you think you won't encounter inertia trying to get people not to

No more than Linus' world conquest, which gives me hope, imho!

> Securely? And what about all the non-TCP-based protocols?

Perhaps - why not check out the Snoeren-Balakrishnan paper?  I'll assume
that, for the purposes of my thesis, those problems are or will be solved
by people specialized in those areas.

Also, I'm tempted to add: And what about all the non IP-based protocols,
for good measure?  Are we absolutely sure that there is no good feature
in any of them that we have not already compromised by going to IP? [I
do allow for non IP protocols also in my thesis, since with names as primary
addresses, I can have that luxury. It is IP, IMHO, that appears to be more
biased and restrictive.]

-p.

---

From: V Guruprasad <[email-masked]>
Date: Tue, 5 Nov 2002 17:26:47 -0500

> 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.

> 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.

> 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.

> 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).

> 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.

> 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.

---

From: John Stracke <[email-masked]>
Date: Wed, 06 Nov 2002 10:38:42 -0500

V Guruprasad wrote:

>In short,
This is misleading.  You say that your main motivation here is to move
the identification role out of IP up to DNS, and moving the resolver
into the kernel is a necessary first step for that.  But it's not a
sufficient first step; to eliminate IP addresses as identifiers, you
have to remove the socket API.

>IP, and that's what my thesis is about. ]
You can't strip the ID role from IP, either, unless you provide a new
form of ID for transport protocols to use.

---

From: V Guruprasad <[email-masked]>
Date: Wed, 6 Nov 2002 11:13:02 -0500

> have to remove the socket API.

No more than you need to disable the socket API for MAC layer or
ATM AAL5 access.

> form of ID for transport protocols to use.

Read my thesis.

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Nov 2002 10:14:11 -0500

> form of ID for transport protocols to use.

Not just transport protocols, but applications also.  DNS is neither
reliable enough nor fast enough nor fine-grained enough for all purposes.  
And those shortcomings are more-or-less inherent in DNS - you really
can't fix it and still have a namespace with the characteristics we
want in DNS - e.g. federated assignment, federated lookup, and ability
to assign names to groups of hosts or services.

(some people think DNS should have only been used for host names, but 
we're long since past the time when that was a reasonable assumption)

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Nov 2002 11:52:44 -0500

> That's why we need a different namespace approach, which looks close
> enough to the dns at the user/application level, so that the same API(s)
> will work, but is architected differently.

problem is, if you keep the same API, then apps that depend on that API
will expect that the name space has the same characteristics as DNS,
(benefits and shortcomings and everything else).  so for instance they
will still try to bypass DNS when DNS would have been a poor choice for
them.

even if the resulting architecture makes more sense than the old one,
you can't expect to be compatible with existing apps if you significantly 
change how the services that were accessed by those APIs work.

> It's so frustrating to work alone and become unable to communicate, even 
> if it lightens the inertia to make great leaps quietly :(

agreed.

Keith

---

From: V Guruprasad <[email-masked]>
Date: Thu, 7 Nov 2002 10:49:46 -0500

Carpenter had remarked back in '01  that maybe what I had could be better
described as a more successful namespace. However, getting that published
as a networking paper seems as hard as the classical derivation of Planck's
law and the missing thermodynamic details they don't want to learn. It's
so frustrating to work alone and become unable to communicate, even if it
lightens the inertia to make great leaps quietly :(

-p

---

From: V Guruprasad <[email-masked]>
Date: Sat, 9 Nov 2002 09:01:05 -0500

Dear Keith,

Sorry I couldn't respond earlier (if, that is, a response was expected).

> change how the services that were accessed by those APIs work.

The essence of my thesis is as follows:

- A namespace suffices as the end to end primary/effective address space in
  itself - no lower level or manually set up destination labels are necessary
  to define names. A distributed name tree is itself an effective addressing
  mechanism, and provides default end to end routes by up-and-down treewalk.

  (Of course it wouldn't be optimal, hold your horses. Let's start with a
  Pascal-like simplification at the high level for once, and treat the
  practical/optimal/efficient/whatever routing as
  a separate implementational/compiler/route-translation problem.)

- Fixed length numeric addresses (FLNA) for routing, as in IP, can be
  automatically assigned and reassigned to the names for
  non-triangular/efficient/etc. routing, so long as

  	* an end to end primary EA space remains available
		for datagrams and new connections;

	* ongoing connected sessions are switched over transparently,
	  but this, as in Snoeren/Balakrishnan's paper for TCP,
	  should be treated as an individual protocol level issue
	  rather than an address space and management issue.

  Note: I prefer the terms 'allocation' and 'assignment' for FLNA because
  these terms are already used broadly in automated software like OS's and
  device drivers for things like real memory/IO/bus addresses and interrupts.

  'Renumbering' appears to be special to IP and connotes two things:
  (a) that a human agent must be involved in deciding and effecting it, and
  (b) that the connected universe constitutes a single numeric label space.

  This is undue baggage that would limit reconsideration of the assumptions
  currently made for IP, as will be clear from the next bullet. (In fact,
  (b) is not even physically sound on the unlimited scale that I allow for.)

- Notice that:
	* Routing with FLNA can and would be done using automatic route
	  discovery, within each FLNA space, which ensures *independence*
	  of the FLNA-based actual routes from the namespace structure.

	* Since every FLNA space involves management and FLNA are reflected in
	  routing tables, each FLNA represents *networking state*.

	* We do not need, and in fact do not use a single FLNA today.
	  VPNs are FLNAs stacked vertically because of the end to end
	  paradigm we have been following philosophically. NAT gateways
	  illustrate horizontal tiling of FLNA spaces, although in
	  conventional NAT, the FLNA spaces overlap (over 192.168 etc.
	  private network ranges) and are not disjoint.

	  Using virtual path style state representation in the gateways
	  can yield the same level of connectivity for the same state volume,
	  with the essential difference that the address will now be faked
	  both ways making the client space disjoint. Secondary issues
	  like how the traffic will distribute across gateways concerns
	  distribution of the state across gateways. This has been in effect
	  shown for IP-like FLNAs in IPNL, and primary difference in going
	  to 2-way NAT or virtual paths is the signalling/initialization
	  mechanism for the state set up, not its resulting volume.

	  In other words, virtual path/circuit state represents horizontal
	  tiling form of network state - there's no getting away from state
	  altogether, only how much we keep horizontal and how much vertical.
	  To compare, IPNL describes a limited form of tiling.

	* Given the state equivalence and the availability of an end to end
	  EA in the form of names, which applications already have to consult
	  every so often (from what I seem to recall reading, netscape caps
	  the ttl to 15 mins regardless of what the dns said), there is no
	  reason to continue mandating end-to-endness of an FLNA, which means
	  vertical stacking only as in VPNs.

- Within an FLNA space, the route translation problem
	from	namespace
	to	non-triangular/efficient/optimal/
		best-effort-but-better-than-Prasad's-namespace/
		whatever-you-want-to-do routes
  	reduces to
		the name->FLNA problem
	which is
		the DNS.

  This essentially answers your comment above.  However, the treatment is now
  more general than the current IETF/IRTF/IP vision:

  Section 2 of my thesis describes linkage of the local DNS-equivalent
  namespaces across FLNA spaces, provide the default "Prasad's stupid routes"
  (PSR) defined by the namespace treewalks.

  Section 3.2 describes IP-like datagram routing across FLNA spaces and
  Section 3.3 describes route discovery and connection state setup across
  FLNAs.

  The latter routes need to partially dependent on PSRs, but only on the
  unlimited scale allowed by horizontal tiling, because of very basic rules
  of logic and physics, as explained in Section 1.1. On any finite scale,
  however, the routing would reduce to being independent and IP-like.

- Lastly, I haven't considered variable length numeric addresses (VLNA) other
  than referring to the Nimrod. The only practical application that I can
  recall is the worm routing in IBM's SP switch fabric, and the scarcity
  of examples makes me a bit wary.

  In any case, the namespace is in principle of variable length (ignoring the
  pragmatic limits set in the dns), and the combination of namespace EA and
  horizontal tiling of FLNA transports like IP seem to achieve the same thing.
  There seems to be little motivation for an VLNA solely as transport, and
  none, imho, as EA other than as textual names.

> > if it lightens the inertia to make great leaps quietly :(

thanks ;-)

-prasad.