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