2012/3/15 Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>:
William Herrin wrote:
I've been an IRTF RRG participant and in my day job I build backend systems for mobile messaging devices used in some very challenging and very global IP and non-IP environments.
I know non-IP mobile environment is heavily encumbered. So, I can understand why you insist on using DNS for mobility only to make IP mobility as encumbered as non-IP ones.
I don't understand your statement. None of the technologies I work with use the word "encumbered" in a comparable context. Perhaps you could rephrase?
Ignoring that DNS does not work so fast, TCP becomes "it wasn't sure what addresses it should be talking to" only after a long timeout.
Says who? Our hypothetical TCP can become "unsure" as soon as the first retransmission if we want it to. It can even become unsure when handed a packet to send after a long delay with no traffic. There's little delay kicking off the recheck either way.
That may be a encumbered way of doing things in non-IP, or bell headed, mobile systems, where 0.05 second of voice loss is acceptable but 0.2 second of voice loss is significant.
However, on the Internet, 0.05 second of packet losses can be significant and things work end to end.
Get real. Even EAPS takes 0.05 seconds to recover from an unexpected link failure and that's on a trivial Ethernet ring where knowledge propagation is far less complex than a mobile environment. For expected link failures, you can't get any fewer than zero packets lost, which is exactly what my add/drop approach delivers.
In this case, your peer, a mobile host, is the proper end, because it is sure when it has lost or are losing a link.
Correct, but...
Then, the end establishes a new link with a new IP and initiate update messages for triangle elimination at proper timing without unnecessary checking.
This is where the strategy falls apart every time. You know when your address set changes but you don't know the destination endpoint's instant address set unless either (1) he tells you or (2) he tells a 3rd party which you know to ask. Your set and his set are both in motion so there _will_ be times when your address set changes before he can tell you the changes for his set. Hence #1 alone is an _incomplete_ solution. It was incomplete in SCTP, it was incomplete in Shim6 and it'll be incomplete in MPTCP as well. And oh-by-the-way, if you want to avoid being chatty on every idle connection every time an address set changes and you want either endpoint to be able to reacquire the other when it next has data to send then the probability your destination endpoint has lost all the IP addresses you know about goes way up. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004