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

---

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: "Tony Hain" <[email-masked]>
Date: Tue, 26 Aug 2003 11:11:45 -0700

Robert Honore wrote:
> Perhaps this proposal really requires another working group or 
> 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: Keith Moore <[email-masked]>
Date: Tue, 26 Aug 2003 15:26:55 -0400

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

why you keep insisting that this layer belongs between apps and
transport, when doing so would clearly require considerable complexity
to restore functionality that already exists at layer 4, completely
eludes me.

---

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.

Tony Hain wrote:
> --------------------------------------------------------------------
> 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: Thu, 28 Aug 2003 17:07:03 -0400

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

These "capabilities" should be regarded as bugs which are being fixed.

In particular, the fact that IPv6 hosts can, in ordinary circumstances,
have multiple addresses has led people to believe that it's reasonable
to expect IPv6 apps to deal with an arbitrary number of addresses per
host, some of which work to send traffic to the destination and some of
which don't, and to have this behavior vary from one source location to
another.  First, nobody has ever explained how these hosts can reliably
determine which addresses will work.  Neither source address
selection nor multi-faced DNS are satisfactory answers.  Second, this
robs apps of the best endpoint identifier they have.

> interface be eliminated, but it should be possible for an application
> to specify what kind of service it wants from the (transport, network)
> (transport,network) combination. 

No, it's not worthwhile.  Any kind of routing needs to happen below the
transport layer rather than above it.  That's not to say that you can't
make something work above the transport layer, but that to do so you
have to re-implement routing, acknowledgements, buffering and
retransmissions, duplicate suppression, and windowing in this new layer
when transport protocols already provide it.

> > reasonably stable and reliable endpoint identifiers.  At present,
> > the IP address is the closest available approximation to such an
> > identifier.
> 
> 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. 

Good question.  My best answer so far is: stable enough so that the
vast majority of applications don't have to implement additional logic
to allow them to survive broken TCP/SCTP/etc. connections, or (to put it
another way) stable enough so that failures due to address/prefix
changes are not a significant source of failure for most applications
(as compared to, say, uncorrectable network failures and host failures).

IMHO, apps should be able to assume that an advertised address-host
binding is valid for a minimum of a week.  This is a minimum - it
should be longer whenever possible.  (however there's no requirement to
maintain addresses longer than the nets will be accessible anyway -
i.e., you don't expect the addresses for the ietf conference net to
remain valid after the net is unplugged...but they shouldn't be reused
within a week either.)

> And the second question is what should be the context of that
> identifier's validity?

The identifier should be unique within the entire Internet.  In some
cases (e.g. small networks without connectivity to the Internet core)
"very likely to be unique within the Internet" would probably
suffice.  That doesn't mean that you can send to any point from any
other point, because there will still be access controls.  But if an
address is advertised for a host, and you have permission to send to
that host, you should be able to use that address to send to that host.

> Also from Keith Moore:
> > 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.
> 
> And
> > much more distant from the network layer that maintains reachability
> > and state information than the transport layer.
> 

The first one I explained above in slightly more detail.  The second one
should be obvious.  If an address becomes invalid because of a topology
change somewhere distant in the network, how is a layer above layer 4
going to know about it?  It doesn't have access to routing protocol
updates - those happen at layer 3 and aren't normally propagated to
hosts anyway.  When you think about it, you probably don't want hosts to
have to listen for information about distant state changes in the
network - that would place a tremendous burden on small hosts and nets
with low-bandwidth connections.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 28 Aug 2003 17:27:33 -0700

Keith Moore wrote:
> Second, this robs apps of the best endpoint 
> identifier they have.

Rather than being so locked into topology locators as endpoint identifiers,
we need to be specifying an infrastructure for endpoint identifiers and any
mapping protocol that might be needed. To some degree this is where the
multi6 design team is headed, but they appear to have a goal of
'transparently' stuffing the result in the lower layers. The one thing that
is obvious from that approach is that it will end up breaking something.

> No, it's not worthwhile.  Any kind of routing needs to happen 
> below the transport layer rather than above it.  That's not 
> to say that you can't make something work above the transport 
> layer, but that to do so you have to re-implement routing, 
> acknowledgements, buffering and retransmissions, duplicate 
> suppression, and windowing in this new layer when transport 
> protocols already provide it.

This is simply wrong. Decisions about topology need to happen below the
application, but that does not equate to below the transport API, unless you
hold to the position that the app/transport interface is a sacred invariant.

> ...
> The first one I explained above in slightly more detail.  The 
> second one should be obvious.  If an address becomes invalid 
> because of a topology change somewhere distant in the 
> network, how is a layer above layer 4 going to know about it? 
>  It doesn't have access to routing protocol updates - those 
> happen at layer 3 and aren't normally propagated to hosts 
> anyway.  When you think about it, you probably don't want 
> hosts to have to listen for information about distant state 
> changes in the network - that would place a tremendous burden 
> on small hosts and nets with low-bandwidth connections.

Yet you advocate propagating L3 changes to all host stacks so that some yet
to be defined glue can magically make the change transparent to the app.
Rather than relying on 'sometimes wanted, sometimes not' magic in the lower
layers, it makes much more sense to put an optional layer above L4 to reopen
a path using alternate topology information. This still allows the app to
choose a direct L4 interface, and removes the need to have the app say 'give
me mapping, or turn it off' in the API. That would be implicit in its choice
of the stabilization layer vs. direct L4.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Aug 2003 21:49:08 -0400

> Keith Moore wrote:
> > Second, this robs apps of the best endpoint identifier they have.
> 
> Rather than being so locked into topology locators as endpoint
> identifiers, we need to be specifying an infrastructure for endpoint
> identifiers and any mapping protocol that might be needed. 

I don't disagree, but the devil is in the details, and you also have to
pay careful attention to transitions.

> To some
> degree this is where the multi6 design team is headed, but they appear
> to have a goal of'transparently' stuffing the result in the lower
> layers. The one thing that is obvious from that approach is that it
> will end up breaking something.

I can't comment on multi6 since I'm not up to date on what they are
doing.

> >  Any kind of routing needs to happen 
> This is simply wrong. Decisions about topology need to happen below
> the application, but that does not equate to below the transport API,
> unless you hold to the position that the app/transport interface is a
> sacred invariant.

You are missing something fundamental here - if a TCP connection breaks
(isn't closed cleanly) then the two endpoints can get out of sync
regarding how much data was delivered.  You can't fix this at higher
layers without an unacceptable amount of complexity and overhead.
This has nothing to do with the app/transport interface being a sacred
invariant - it happens any time you try to layer something on top of
transport that has to survive breakage of the transport layer.

(how many ways do I have to explain this?)

> > If an address becomes invalid 
> Yet you advocate propagating L3 changes to all host stacks so that
> some yet to be defined glue can magically make the change transparent
> to the app.

It's a lot less glue than the L4-L7 approach, and most of it has to deal
with authentication that would be needed for any kind of
remotely-originated routing update anyway, regardless of what layer it
lived at.

> Rather than relying on 'sometimes wanted, sometimes not'
> magic in the lower layers, it makes much more sense to put an optional
> layer above L4 to reopen a path using alternate topology information.

No, it doesn't make sense to add a considerable amount of overhead and
complexity that isn't needed and often won't be used.

> This still allows the app to choose a direct L4 interface, and removes
> the need to have the app say 'give me mapping, or turn it off' in the
> API. That would be implicit in its choice of the stabilization layer
> vs. direct L4.

Yes you can do that but it presumes that the host knows a priori whether
or not it needs the stabilization layer.  I would make the
mechanism used to provide stable addresses a property of the network-
either the network provides "reasonably" stable addresses (i.e. plenty
of prior notice before changing them) or it provides a stabilization
layer.  That way, networks that don't need it don't pay the overhead.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 28 Aug 2003 20:52:35 -0700

Keith Moore wrote:
> You are missing something fundamental here - if a TCP 
> connection breaks (isn't closed cleanly) then the two 
> endpoints can get out of sync regarding how much data was 
> delivered.  You can't fix this at higher layers without an 
> unacceptable amount of complexity and overhead. This has 
> nothing to do with the app/transport interface being a sacred 
> invariant - it happens any time you try to layer something on 
> top of transport that has to survive breakage of the transport layer.

And apps are in exactly that position today. This is still not a valid
reason to insist on adding complexity into the transport or IP layers. If a
connection breaks before closing, the notification up is 'broken', then
whatever is there has to decide if it wants to try something else. Today the
app has to have the complexity, but there is no reason we can't put that
into a stack layer once for any app that wants it.

> It's a lot less glue than the L4-L7 approach, 

That is a matter of speculation.

> and most of it 
> has to deal with authentication that would be needed for any 
> kind of remotely-originated routing update anyway, regardless 
> of what layer it lived at.

I agree, but the lower layers are not designed with that in mind, so to some
it would appear you want a substantial amount of change to something that is
already working well. Never mind the transition/deployment/interoperability
issues.

> No, it doesn't make sense to add a considerable amount of 
> overhead and complexity that isn't needed and often won't be used.

More speculation. In any case, if it is not used it is simply an idle module
at the top of the stack. 

> Yes you can do that but it presumes that the host knows a 
> priori whether or not it needs the stabilization layer.  I 
> would make the mechanism used to provide stable addresses a 
> property of the network- either the network provides 
> "reasonably" stable addresses (i.e. plenty of prior notice 
> before changing them) or it provides a stabilization layer.  
> That way, networks that don't need it don't pay the overhead.

Optimizing before the design is started only ensures that something will get
overlooked or dropped as 'too much overhead'. 

I raised the 'right problems' thread after the observation that we had
several embryonic efforts to separate endpoint identifiers from topology
locators, but all of them are focused on inserting complexity into the lower
layers. Those layers don't need complexity to do their job, and any changes
in behavior will break current operational assumptions about how those
layers work. Also everyone agrees that the place that needs the complexity
of the current & future unstable network masked is the application.
Therefore the place we should be focusing solutions is in the interface
between transport & app. 

--- Solve the right problem

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Aug 2003 01:22:26 -0400

> reason to insist on adding complexity into the transport or IP layers.

Okay, well you've just demonstrated that you're insane.

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Aug 2003 14:35:34 -0400

(regarding the complexity of putting a general-purpose layer to survive
address changes between L4 and L7)

>   But why do you assert that it will take lots of complexity and 
> overhead?  Can you point to some code where they tried this?  As far
> as I know, nobody has really given this an earnest try as yet.  At
> least not with any IP protocols.

I tried this in connection with a project called SNIPE that I worked on
several years ago.  SNIPE was an attempt to build a very
reliable distributed computing environment that supported, among other
things, the ability to access a computing resource via multiple
addresses (mostly in order to exploit high-bandwidth local networks
not necessarily using IP), and the ability of both hosts and processes
to migrate to other addresses.  It used a DNS-like service similar to
RESCAP (for those who remember that) to register the addresses at which
a process was accessible, and it attempted to provide TCP-like streams
on top of TCP and this registry that would survive changes in those
addresses.  Basically I found that you can get such a service to work
reasonably well and reasonably efficiently if endpoints don't move
without adequate notice.  OTOH if hosts or processes do move without
adequate notice then you end up needing to implement the mechanisms I
mentioned earlier, and that involves extra copies and extra overhead. 

The reason I am preposing that the two problems (changing addresses
with adequate notice and changing addresses without adequate notice) be
treated separately is that by trying to make a single mechanism serve
both purposes you end up with a lot of inefficiency and/or cost that
aren't needed in most cases.  And that's true (for different reasons)
regardless of whether you insert that single layer between L3 and L4 or
between L4 and L7.

> What specific glue do you believe it requires for the L4 to L7
> approach? 

Thought I'd said this already: buffering of data until acknowledged by
the peer, generation and processing of acknowledgements, retransmission
of lost messages due to broken connections, windowing (so you don't
degrade to stop-and-wait), duplicate suppression.  You also need to
multiplex control and data information over the same stream and to probe
for other addresses when you get a failure on the one you were using.

>   How does that compare to what is needed in an L3 solution?

If you work on the problem at (or just above) L3, transport protocols
already have the code needed to recover from lost messages, so you don't
have to reimplement that.  You basically need a mechanism by which the
layer can realize it needs to start routing packets differently, and do
so.  You probably need multiple ways that the layer can get that
information because the remote address can change for a variety of
reasons and in lots of different places in the network.   (That's
equally true for the L4-L7 layer as for the L3-L4 layer, but the L4-L7
layer isn't in a position to get some of that information.  The L3-L4
layer can potentially recover from address changes more quickly but to
do that safely it has to be able to authenticate and establish a basis
for trust in a wider variety of information sources.)

> > Yes you can do that but it presumes that the host knows a priori
> > whether or not it needs the stabilization layer.  I would make the
> > mechanism used to provide stable addresses a property of the
> > network- either the network provides "reasonably" stable addresses
> > (i.e. plenty of prior notice before changing them) or it provides a
> > stabilization layer.  That way, networks that don't need it don't
> > pay the overhead.
> 
> But I would argue that the host or at least the application's designer
> knows whether it will need the stabilisation layer. 

It can't know that reliably unless the network without the stabilization
layer has well-defined properties - e.g. the network won't change
addresses of a network without advertising those changes with a minimum
amount of advance notice.  If addresses can potentially change at
arbitrary times with no assurance of stability then every app needs the
stabilization layer (or provide its own means of recovery).

> Making the 
> mechanism that provides the stable network addresses a property of the
> network leaves the question of how.  Even if that were achieved
> though, that still does not completely or effectively address the
> problem of one application process identifying its peer across the
> network.

Well, there's no way I can supply all of the details in a few email
messages.  I've been trying to find time to write them up.  In the
meantime I want to discourage too much momentum behind trying to solve
all of the address changing problems in any one place - particularly
between L4 and L7, because I already know that that won't work well.

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 30 Aug 2003 05:07:45 +0859 ()

Keith;

> address changes between L4 and L7)

It is not merely complex but also useless to have such a layer.

The basic problem of the approach to have such a layer is that
only the application layer has proper knowledge on proper
timeout value to try other addresses.

So, the issue can be solved only involving application layer, though
most applications over TCP can be satisfied by a default timeout of
TCP. In either case, there is no room to have an additional layer.

I documented it long ago (April 2000) in draft-ohta-e2e-multihoming-*.txt

               The Architecture of End to End Multihoming

(current most version is 05) that:

   To support the end to end multihoming, no change is necessary on
   routing protocols. Instead, APIs and applications must be modified to
   detect and react against the loss of connection.  In case of TCP
   where there is a network wide defact agreement on the semantics
   (timeout period) of the loss of connectivity, most of the work can be
   done by the kernel code at the transport layer, though some timing
   may be adjusted for some application. However, in general, the
   condition of "loss of connectivity" varies application by application
   that the multihoming must directly be controlled by application
   programs.

							Masataka Ohta

PS

Layering is abstraction and not indirection at all.

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Aug 2003 17:26:12 -0400

well, the reason I named a specific time interval was to provoke
discussion, so I suppose I shouldn't be disappointed...

I am not sure that one week is the best figure.  I imagine that figure
could reasonably be picked to be anywhere between several hours on the
low end to a few weeks on the high end.

However as I've written in other messages today I believe that trying to
use a single mechanism to handle all cases where addresses change is
probably too expensive (either in money or reduced performance or both),
and to me it makes sense to handle two cases separately - those for
which the change is known about well in advance, and those for which it
is not.  The idea is for l3 or l4 to handle the unanticipated changes
and for l7 (or a layer between l4 and l7) to handle those that are
anticipated and announced.

For the anticipated changes, one week notice/stability does not seem
like an onerous requirement.   For unanticipated changes of wired
networks, I don't think providing redirection for one week is too
expensive either.  And for mobile networks I think it's reasonable to
expect them to pay for redirection services.  In this way the costs of
providing the infrastructure necessary to compensate for the lack of
natural address stability (i.e. the ability to move without one week's
notice) can be borne by those who need that service; others need not pay
for it.  Finally, one week is long enough that most apps (i.e.
those whose connections never have to last that long) won't have to
worry about it or pay for the extra overhead.  You could pick a shorter
time interval but it would eventually start to impact a significant
number of apps.

Of course, there will still be apps that need to worry about user
mobility rather than host mobility.  Since the network doesn't know
anything about users, those apps will still need to provide their own
facilities to keep track of users' network locations.

Keith

p.s. and yes, AOL's IM tracking is quite dynamic, but it's also highly
centralized.  based on the experience with ICANN I think it would be
very difficult to manage the political issues associated with a central
Internet prefix mapping service - though the experience with the ongoing
ENUM work seems, at least from my distant vantage point, to be somewhat
more promising.

> as one thinks about VPNs, tunneling, mobility and the like, assuming a
> week is probably a bad idea. Think a bit about the way AOL's IM tracks
> the binding of an IM handle to an IP address - it is quite dynamic.