[trying to keep this as brief as possible]
In the ongoing saga about topology reality vs. application perception of
stability, it occurs to me we are not working on the right problem.
agree.
We all agree that applications should not be aware of topology. At the same
time, application developers insist on the right to pass around incomplete
topology information.
Let's rephrase this in a less loaded way. Application developers need
reasonably stable and reliable endpoint identifiers. At present, the IP
address is the closest available approximation to such an identifier.
Therefore apps developers don't want to give up the ability to pass these
things around and expect them to work from other locations in the network,
until such time as a suitable replacement is available and widely deployed.
(Note that even after such a replacement exists, there will still be some apps
that need to pass around locators - network management tools in particular.
But they will have less need to insist that those locators be usable from
other network locations.)
In any case, what applications need is a stable reference to other
participants in the app. Yet we know that current and projected reality says
that topology is not stable, or consistently reachable.
agree.
Either way, the
network as seen by the transport layer is not, and will never be stable or
consistently reachable from everywhere. Given that, the direct interface
with the transport layer creates a failure mode for an application expecting
stability.
Where this leads us is to the sacred invariant, and the need to solve the
problem in the right place. I suggest it is time for the IETF to realize
that the protocols are no longer being used in the network of 1985, so it is
time to insert a formal stabilization layer between application & transport.
Disagree. The layer needs to be between the current network and transport
layers. If the layer were between transport and applications, many of the
services provided by transport would end up having to be re-implemented in
higher layers. It would also force routing decisions to be made by layers
much more distant from the network layer that maintains reachability and state
information than the transport layer.
The next place that leads us is to a name space. At this point I see no
reason to avoid using the FQDN structure, but acknowledge that the DNS as
currently deployed is not even close to being up to the task.
Disagree. A big part of the reason DNS is not up to the task is that its name
structure is a very poor fit for this purpose. There is no need to have these
names be human-meaningful or to have them delegated along the lines that DNS
is delegated. There is already a lot of semantic loading of DNS names (many
would say they're too overloaded already) which would strain their ability to
be used in this new layer. There is a large benefit to having these names be
terse and fixed-length (though perhaps not as important or useful as it is for
IP addresses, and having a variable length name for endpoints would provide
some additional flexibility). There is also a benefit to being able to reuse
existing transport protocols in terms of these new names, though that can be
finessed. Finally, using 128-bit identifiers that were API and protocol
compatible with IPv6 locators (but distinguishable from them) might be very
useful in smoothly transitioning existing stacks and apps.
Then there's the problem that DNS's protocol and replication models aren't
really a good fit either, and this hinders any effort to make it suitable
for identifier-to-locator mapping.
(Admittedly, if I thought that the new layer should go between transport and
apps then DNS-like names would make a tad more sense.)
Since many networks have usage policies established around the sacred
invariant, there will need to be some recommendations on how to apply those
policies to this new layer. We could even consider a protocol between this
layer and a policy entity that would aggregate applications into a policy
consistent with the what the network can deliver for various transport
protocols. This distribution of policy awareness would have much better
scaling characteristics than per app signaling, as well as the ability to
locally group unrelated transports that any given app might be using.
Lots of work is needed in the policy area. But being able to express policies
in terms of stable and reliable host identifers, instead of expressing them
exclusively in terms of attachment points or links, would help a great deal.
Bottom line is that we are spending lots of time and effort trying to force
fit solutions into spaces where they don't work well and end up creating
other problems. We are doing this simply to maintain the perception of
stability up to the application, over a sacred interface to a very unstable
network. Stability to the application is required, but forcing applications
to have direct interaction with the transport layer is not. Yes we should
continue to allow that direct interaction, but we should be clear that there
are no guarantees of stability on that interface. If the application does
not want to take care of connections coming and going to the same device at
potentially different places, it needs to have an intermediate stabilization
layer available.
It appears that we agree on much of the above, especially if you leave out
loaded words like "sacred". It needs to be understood that the needs of apps
are legitimate, even while admitting that these needs are stretching existing
network layer services beyond their capabilities.
This was a constructive post. Thanks.
Keith