Hello Jim,

There are at least three kinds of inputs to this process:
        data, facts, and opinions.
I've lumped together "intuition" and "expertise" under
"opinions", and I point out that it is a mistake to
deprecate the latter in the way that some readers of
your note may tend to do.  With this in mind, I have
some comments on your message.

James Kempf wrote:
 
> TCP flow control was implemented in response to congestion collapse in
> the late '80s. If something like that happens as a result of widespread
> Mobile IP implementation, you can be sure that it will become a MUST.

Presumably, you are not suggesting that we have to get burned first
before taking action.  Instead, you probably mean to suggest that
the threat is not assuredly imminent.

>    But, for now, it is very easy to see the extra amount of work route
> optimization would add to implementing an IPv6 stack, but very hard to
> see what effect lack of route optimization would have on traffic flow in
> the Internet when mobile nodes are widespread

Here are some facts:

A. A mobile device transmitting data to a correspondent node will
   require forward and reverse tunneling through the home network
   unless it can establish a binding cache entry at the correspondent
   node.

B. This can increase the total capacity requirement for the
   communications by an arbitrary amount, depending on the
   layout with respect to the home network.  That could easily
   mean a factor of "thousands".

Opinion:

A typical multiplier for (B) will be about 2.  The actual
number depends on the relative placement of the nodes, and
the multiplier will be higher whenever a mobile device needs to
communicate with a local correspondent.

Thus, the scenario where people would expect the most
responsive communications will offer counterintuitive
behavior.

Solutions for this problem include:
- restricted mobility
- transient IP addresses
  = subcase: EIDs to replace IP addresses as identifiers
- reengineering human intuition
- proxy agents

These are good for more startups and full employment (like
NATs are), but most of them are bad for the Internet.

Opinion:

The probability is very high that the future Internet will
be predominately composed of mobile devices.  If you think
otherwise, try counting your mobile Internet nodes versus
your stationary ones, and then lump in 1 billion mobile
telephones into the overall mix.

Opinion:

We should expect to see new applications related to messaging
and multimedia and data mining.  These new applications should
not be encumbered with a legacy (created by us right now) that
assures long delay paths crossing the Internet multiple times.

>                                               (though, of course,
> everyone has an opinion). So making it a SHOULD seems like the best
> tradeoff.

I disagree with this.  It is about the same as saying that a device
can be IPv6 compliant even if the engineering budget and marketing
timetable for the vendor persuaded management to delete features
that did not harm the device itself, only other devices.

I believe this leads to the phenomenon called the "tragedy of
the commons".

Making it a SHOULD means you cannot fault any vendor for making
devices that continually cause extra work for numerous remote
Internet nodes.

> It is really too bad that there is not some kind of large scale,
> supercomputer simulation of the Internet that we could tweak when these
> kinds of questions come up. This would allow the IETF to base decisons
> on some kind of data (though people do argue about simulations) rather
> than just on intuition.

Well, I agree that it would be a lot better if we had this
information.  In the meantime, I guess the best we can do is
try to understand the problem, given the best factual basis
we have, and using the best expertise we can gather to improve
the future scalability of using mobile devices in the Internet --
that is, the scalability of almost the entire future Internet.

I'd be interested to find out which of my opinions (or facts!)
you think is leading me to the wrong conclusion...

Regards,
Charlie P.
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------

Reply via email to