Dear Keith,
Sorry I couldn't respond earlier (if, that is, a response was expected).
On Thu 2002.11.07, Keith Moore wrote:
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.
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.
It's so frustrating to work alone and become unable to communicate, even
if it lightens the inertia to make great leaps quietly :(
agreed.
thanks ;-)
-prasad.