Hi Charlie,
> 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.
>
It was not the intent of my note to deprecate opinions.
The opinion of a knowledgable person is always valuable.
> > 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.
>
Human nature being what it is, the hard task in front of of your nose
gets more attention than the vague threat somewhere in
the future, regrettably. Otherwise, we would have see strong measures
in place for solving global warming back in the mid 1990's.
> > 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.
>
We are talking about adding the tunnel header, right?
If so and if you mean the relative volume of the data traffic
will be increased by a factor of 2, that, of course, depends on the
packet size. If the packet is a 40 byte VoIP packet, then I agree
with you. If it is a 1500 byte HTTP packet (most common size
on the Internet today, I'm told) then the relative increase won't be
nearly as large. People are more likely to look at the latter than the
former when they consider route optimization because most of the traffic
now is of that nature. This may be shortsighted, but it is
how practical-minded people (which means most engineers)
tend to think
> 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.
>
My opinion is that, in the near future, again unfortunately,
most of these devices will likely be GPRS nodes (aside: this text
is coming to you courtesy of Docomo's wCDMA GPRS network).
And most of them won't be doing VoIP. So Mobile IP won't likely
play a big role immediately, though it will in the intermediate
term. VoIP (where, in my opinion, route optimization is
critical) probably will be important in the longer
term. But this is pretty crystal ball.
> 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 guess I don't follow your logic. RFC 2119 is fairly explicit about
what SHOULD and MUST mean, and, to me, the text on SHOULD
closely matches what route optimization provides. I think
we disagree here.
> 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...
>
I don't think your conclusion is entirely wrong (and that is my
opinion). As I mentioned in the original note, it is possible
that your opinion on the effect of lack of route optimization may
happen.
Where we disagree, I think, is in the difficulty of judging how likely
it is
and when it might occur. It is necssary to balance that uncertainty
against
the certainty of imposing additional requirements on people's
IPv6 stacks. Since we are trying to get people to implement and
deploy IPv6, we need to try to minimize the number of requirements.
Of course, this leaves it up to the implementor's and deployer's
judgement about when to implement and deploy route optimization.
The view I have is that standards can always be updated. 3GPP
is unfortuantely much better at realizing this than we are, which
is perhaps why they are able to get their standards completed
more quickly. Making route optimization SHOULD establishes a
pretty strong stake in the ground about what the WG thinks is desirable.
All things considered, I think that should be enough for now.
jak
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
