Shim6, was: Re: filtering /48 is going to be necessary

Thu Mar 15 07:40:30 UTC 2012

2012/3/15 Masataka Ohta <mohta at 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 at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004