Re: [DNA-BOF] Attachment Detection charter text for discussion

[Jari Arkko <jari.arkko@kolumbus.fi>]

Brett Pentland wrote:

>> In the face of such schemes, having an IP address and a default router is
>> not sufficient to say you have complete Internet connectivity. 
>> Technically,
>> you are still not connected, you are "pending authorization." If your 
>> Mobile
>> IP module could learn this detailed state, so much better. Otherwise, it
>> will keep trying and failing, and all of a sudden it will work.... 
>> Ugly and
>> slow, but not catastrophic.
>>
> And if you have to stop and type in a password, your chances of a 
> "smooth handover" are probably out the window ;)

True.

But there's actually a few interesting issues in this. First of all,
if you have to "stop and type a password", it is still very useful
if the IP stack knows this is the case. For instance, if it were to
attempt mobile IP registration while the user takes half a minute
to type in a password, the retransmission back-off procedure would
pretty far already when the connectivity really comes around. This
would make the user's delay long after the password was typed. Or
maybe the registration already timed out, and the user gets *no*
service. (Continued registration attempts in Mobile IPv6, for instance,
are optional once the back-off limit has been reached.)

Secondly, I would assume access authentication for most nomadic/mobile
users to be automatic, such as a password which you configure to be
given automatically. Or a SIM-like card which you have to enable
through a PIN, but which will then automatically authenticate yourself
to new networks. But even with an automatic scheme, it will take
some time. [If this time approaches the time you spend on this link,
you're hosed ;-) If you use mobility and IPv6 on authenticated links,
the minimum number of messages to get connected and ROed is around 16.
L2 fast handoff schemes improve this, though they typically work only
within the same provider's network.]

Nevertheless, even in the automatic case the IP stack benefits
from knowing when the connectivity really is there. For instance,
if authentication were to take 1050 ms, the default Mobile IPv6
binding update timeout (1000 ms) would already be gone, a second
binding update sent, and the current retransmission would be scheduled
to take place in 2000 ms, i.e. 1950 ms from now. So you'd be waiting
for two additional seconds before you can send the first real update.

The above indicates that knowledge of current authorization state
is a requirement for fast movements. Depending on the type of
mobility or other services run on top of the access link, it may
even be a requirement with slow movements to prevent an unrecoverable
(on this link) failure state.

--Jari