Subject: Solving the right problems ...

From: "Tony Hain" <[email-masked]>
Date: Sun, 24 Aug 2003 13:08:40 -0700

In the ongoing saga about topology reality vs. application perception of
stability, it occurs to me we are not working on the right problem. In short
we have established a sacred invariant in the application / transport
interface, and the demands on either side of that interface are the root of
conflict.

Mobile IP, and the multi6 DHT work are attempts to mitigate it through
slight of hand at the IP layer, while SCTP attempts to mask the topology
reality in the transport layer. (These are probably not the only examples,
but they are the ones that come to mind this morning.) Yet none of these
really do the job in all cases.

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. There are arguments that the IP address is overloaded
as an endpoint name. I don't particularly buy that, because the real
endpoint is either a protocol, or a specific port of a protocol. From one
perspective, when applications use addresses in referrals, they are
specifying that routing through a particular point in the topology will
reach the desired endpoint named 'transport/port-id'. But that is a
semantics and perception discussion which doesn't help reach the goal.

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. This could be due to
technology issues of the underlying links, or simple policy. 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.

Such a layer would be responsible for managing intermittent connectivity
states and varying attachment points of the transport layers below.
Applications that interact with this layer would be insulated from the
inconsistencies being experienced by the transport layer. It would also be
reasonable for this layer to manage multiple simultaneous transport
interactions so that the application perceived a single data path to its
peer. With appropriate trust between the stack and the network policy, this
would even simplify the process of QoS markings for parallel related data
sets. 

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. The protocols
are not so much the issue as the deployment and operation model that is
focused on a limited number of nodes operated by a small community of
guru's, where the expectation is that any changes occur on the order of
several days or longer. What we ultimately need in a name service to support
the suggested layer is the capability for every consumer device with
electrons in it to automatically and dynamically register its current
attachment information with rapid (that doesn't mean sub-second, more along
the lines of a cell phone that powers up away from its home) global
convergence. As there are multiple trust boundary issues involved (because
not every device will be subscribed to a service), making this scale will
require pushing the database distribution out to smaller pockets. Making it
reliable for Joe-sixpack will probably require that part of the
infrastructure exists on his side of the interconnect & trust boundary from
any other networks. Automating the attachment of a massive number of small
dataset servers will probably require something with better scaling
characteristics than the current DNSsec deployment model.

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.

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.

Tony

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Sun, 24 Aug 2003 17:42:08 -0400

[trying to keep this as brief as possible]

> stability, it occurs to me we are not working on the right problem. 

agree.

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

> that topology is not stable, or consistently reachable. 

agree.

> Either way, the

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.

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

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

> potentially different places, it needs to have an intermediate stabilization

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

---

From: Robert Honore <[email-masked]>
Date: Tue, 26 Aug 2003 13:40:24 -0400

Dear Tony Hain,

Perhaps this proposal really requires another working group or 
something.  I seem to remember someone making a similar proposal a 
several years ago on this list and it didn't seem to get a good 
reception then.  For what it is worth, though, I really do think it is 
an idea whose time has come.

It seems everyone has espoused the idea that the application *must* talk 
directly to the network transport in order to be efficient and/or 
resilient, but given the capabilities IPv6 is supposed to have, I wonder 
how much of a good idea it is to cling to that concept.

It is not worthwhile to suggest that the direct application/transport 
interface be eliminated, but it should be possible for an application to 
specify what kind of service it wants from the (transport, network) 
combination and something is there to handle that where the requested 
service is different from that natively provided by the 
(transport,network) combination.  Problem is that right now, every time 
an application needs such a service, the application programmer must 
code his own provisions for it, and none of the propositions I have seen 
discussed so far seems to deal with that.

Keith Moore's statement is quite correct, viz:
> Application developers need

Two questions arise out of that though, at least as far as Keith Moore's 
statement is concerned.  The first one is how stable is stable?  That 
is, how long is that identifier supposed to remain stable.  And the 
second question is what should be the context of that identifier's validity?

Also from Keith Moore:
> higher layers.

And
> It would also force routing decisions to be made by layers

Does Mr. Moore care to explain a little why he believes these two 
statements?  As far as I can tell it needs not necessarily be so.

Yours sincerely,
Robert Honore.

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 26 Aug 2003 11:11:45 -0700

Robert Honore wrote:
> something.  

To be clear, I was not recommending where the work get done, that is why it
was sent to the IETF list. I only cc'd the IPv6 list because it ties into
the recent discussion. In fact it is not clear to me where this work belongs
because the IETF area structure is very focused around the current layers.
It is also not clear that a new area is required to create a new layer, but
maybe that would help focus work in both defining how such a layer would
interact both up and down, as well as name space and interaction protocols
along the lines of HIP/DHT/... 

The only thing that was clear to me was that the efforts to change the
behavior of lower layers only makes them more complex while creating
unintended side effects. At the same time, an optional layer between app &
transport could provide the consistency that some apps require, without
changing the widely deployed and well refined lower layers.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 26 Aug 2003 11:11:45 -0700

Tony