Subject: RE: [mobile-ip] MIPv6 v20/21 inconsistencies wrt CN binding (life) and home binding (life) [11.7.2]

From: "Greg O'Shea" <[email-masked]>
Date: Tue, 18 Feb 2003 17:57:52 -0000

>This looks like a bug. I think we want it to be the lifetime
>of the home binding.
Agree.

>MAY sounds appropriate.
Agree.

>>So, you want to make it slightly more optimistic, i.e. allow even 
>>sending the BU to the CN before the home registration >>is assured to
be complete?

Yes, unless there's a good technical reason for banning it; it seems a
bit arbitrary that we should always impose a strict ordering
(receive-home-ack, send-CN-BU) when a strict ordering is not always
necessary. HoTi rexmit and BA=ExpiredHomeCookie will take care of the
cases where the ordering matters. But this is not critical to the basic
protocol, so you might want to put it on that list of future work.

Meanwhile I think I'll ignore the constraint.

Greg
>-----Original Message-----
>From: Jari Arkko [mailto:[email-masked]]
>Sent: 17 February 2003 15:19
>To: Greg O'Shea
>Cc: [email-masked]
>Subject: Re: [mobile-ip] MIPv6 v20/21 inconsistencies wrt CN 
>binding (life) and home binding (life) [11.7.2]
>
>
>Thanks again Greg for your detailed comments... some responses
>inline:
>
>> 1 = "After the mobile node has sent a Binding Update to its
>home agent
>> ? the mobile node SHOULD initiate a correspondent binding
>procedure for
>> each node that already appears in the mobile node's Binding Update
>> List."
>
>So, you can start RR at this time.
>
>> 2 = "Upon successfully completing the return routability procedure,
>> and
>> after receiving a successful Binding Acknowledgement from the Home 
>> Agent, a Binding Update can be sent to the correspondent node."
>
>Sending a BU to a CN requires the completion of both the RR
>procedure and the home registration (including getting an answer).
>
>> Sending a home binding update (1) is not the same thing, and does not

>> occur at the same time as, receiving a home binding ack (2).
>I suspect
>> the BA provision of (2) should be removed.
>
>Perhaps, but they are not in conflict as such. (1) talks about
>the condition for starting RR, and (2) talks about the 
>condition to send the BU to the CN. It is true that the RR 
>might be a no-op if the necessary tokens are already avaiable.
>
>> I think the MN can send CoTi (and HoTi if it does not think it
>> possesses
>> a valid Home Cookie) concurrently with sending the BU to its 
>HA per (1).
>> This is optimistic, but not excessively so. If HA is temporarily
>
>I agree with this.
>
>> unreachable during handoff and MN has a Home Cookie for CN
>then the CN
>> binding may sometimes be renewed without reference to HA and in the
>> interim CN will not keep sending traffic to the old CoA.
>> 
>> The difference between (1) and (2) will be one or a few seconds when
>> the
>> HA is running DAD for the HoA, but this is a rare case.
>
>So, you want to make it slightly more optimistic, i.e. allow
>even sending the BU to the CN before the home registration is 
>assured to be complete?
>
>> I notice also that 11.7.2 and 11.7.4 say different things
>about max CN
>> binding life: 11.7.2 says max = life of HoA and 11.7.4 says
>max = life
>> of home binding. Is that deliberate?
>
>This looks like a bug. I think we want it to be the lifetime
>of the home binding.
>
>> There might be a slim case for (2) when the MN is changing
>between two
>> different HA on the home net, so initial (HoTi, HoT) may be
>dropped then
>> prolonged by the exponential backoff on HoTi rexmit. Was
>that the concern?
>
>I don't think so. I think the protocol first required home
>registration to be fully completed before you started any 
>corresponding binding procedures. But then we added some 
>parallelism -- and now you want some more...
>
>> Should the "can" in (2) be "MAY" | "SHOULD" | "MUST" ?
>
>MAY sounds appropriate.
>
>Jari
>
>

---

From: "Greg O'Shea" <[email-masked]>
Date: Tue, 18 Feb 2003 18:15:09 -0000

Sorry - overlapping email. 

>From: Greg O'Shea [mailto:[email-masked]] 
>Sent: 18 February 2003 17:58
>To: Jari Arkko
>Subject: RE: [mobile-ip] MIPv6 v20/21 inconsistencies wrt CN 
>>This looks like a bug. I think we want it to be the lifetime of the 
>>home binding.
>Agree.
>
>>MAY sounds appropriate.
>Agree.
>

---

From: "Greg O'Shea" <[email-masked]>
Date: Tue, 18 Feb 2003 18:21:16 -0000

That looks good to me. I would not hold things up for it though. (I had
not seen the Basavaraj email when I started this item.)

>Sent: 18 February 2003 10:16
>To: Greg O'Shea
>I have thought some more about this. Here's a few observations:
>
>*  In the usual case -- not first registration, packets not reordered
>    or dropped -- the behaviour is the same whether the current
>    or Greg's even more optimistic scheme is used. The order of
>    packets in the MN is likely to be the following:
>
>       ---> Home BU
>       ---> Hoti (optional)
>       <--- Home BA
>       <--- Hot (optional)
>       ---> Correspondent BU
>
>   Why is the order like this? Its Home Test and -Init messages
>   have to take a longer route, whereas the BU is answered from
>   the home agent directly. Secondly, if the order was different,
>   the tunneled hoti would not satisfy checks required from the
>   home agent, and the hot would be tunneled to the wrong place.
>
>* In the first registration where DAD has to be invoked it is
>   likely that we have to wait for the BA. However, in this case
>   the tunnel is not set up yet, and the hoti and/or hot messages
>   may be lost, and have to be retransmitted after the BA arrives.
>
>   On the other hand, as Greg notes, this is a rare case and probably
>   not worth optimizing.
>
>* If the home cookie has been cached the correspondent, the
>   BU could be sent sooner. If we allowed it. This has an
>   impact for fast movements.
>
>* If the home address has somehow gotten deprecated, removed
>   etc. the current rule about waiting for the BA ensures that
>   bad home addresses are not entered to the CNs. On the other
>   hand, this can only happen for a short period of time, assuming
>   the MN had an existing binding at the previous location.
>
>So what should we do about this issue? I think it is clear
>that we will fix the nits that Greg complained about. Change 
>"home address" to "home registration" in Section 11.7.2 at 
>"... Lifetime field sent in the Binding Update SHOULD be less 
>than or equal to the remaining lifetime of the home address 
>and ..." Also, in 11.7.2 change "can" to a "MAY" in "... a 
>Binding Update can be sent to the correspondent node".
>
>I'm undecided about what to do about the wait-for-the-BA rule. 
>Its pretty late in the process to add optimizations... on the 
>other hand a clarification of this rule would make fast 
>handovers significantly better. Here's one potential text 
>suggestion if we want to do the change. This text tries to 
>ensure that we don't inject bad information to the correspondent nodes.
>
>    Upon successfully completing the return routability procedure, and
>    Agent, a Binding Update MAY be sent to the correspondent node.
>    Alternatively, the Binding Update MAY be sent immediately, if the
>    following conditions are fulfilled:
>
>      o  The mobile node already has a registration for the
>         given home address at a previous care-of address.
>
>      o  The mobile node can reuse recently received keygen
>         tokens as described in Section 11.6.1.
>
>      o  The lifetime in the Binding Update sent to the correspondent
>         node does not exceed the lifetime of the previous
>         home registration the mobile node had.
>
>Jari
>
>