Subject: [netlmm] Solution for the Scenario C Race Condition

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 1 Oct 2008 13:43:27 -0400

Hello,

I saw at least a couple of claims about the solution for handling the
race condition in scenario C described in
draft-giaretta-netlmm-mip-interactions-02 being complex. The solution
was in the slides that were presented in the last IETF meeting. But
there wasn't enough time to actually describe the solution. Slides 9-11
at http://www.ietf.org/proceedings/08jul/slides/netlmm-3.pdf describe
the solution. 

It is a simple solution. If at any time, the LMA receives a PBU and BU
(or a BU and PBU) within a very short interval of time, the race
condition prevention mechanism (for lack of better words), gets
triggered. This basically involves the LMA checking with the entity from
which the last message was received, if it still wants to create the
binding. If the last message that was received was the PBU, then the LMA
checks with the MAG if it still wants to create the binding by sending a
binding revocation message. If the last message that was received was
the BU, then the LMA checks with the MN if it still wants to create the
binding by either sending a binding revocation message with a new code
or by sending a binding ack with a new failed status code.

Note that the race condition prevention mechanism does not get triggered
if the time interval between the PBU and the BU (or between the BU and
PBU) is larger than the RACE_CONDITION_PERIOD at the LMA. 

Vijay
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "BLUME, Oliver" <[email-masked]>
Date: Thu, 2 Oct 2008 14:12:18 +0200

Hello Vijay,

Your description of the race condition prevention mechanism doesn't seem to fit to the Dublin slides you referenced. As far as I can see, the slides suggest to give higher priority to the MN BU and to question the PBU in case of both orders of race conditions. I.e. the race condition check would be PMIP internal and transparent for the client MIP binding, while you now describe a symetric solution (always questioning the latest binding request). Did I miss something?

BTW, couldn't the Handoff Indicator give a valuable help in the race condition? In Scenario 2 this would suggest the following: 

If the  PMIP binding request that arrives second during the race condition  is a refresh (HI=5) this must have been delayed and should be rejected with POTENTIAL_RACE_CONDITION. On the other hand, if the PBU has a handoff indication and the previous BU of the MN was just refreshing the BCE timer, obviously the messages were received in due course and the handoff to PMIP is valid. In this case it would be non-optimal to reject the PBU and force the MAG to send another PBU later (after waiting for RACE_CONDITION_PERIOD of time).

Does that make sense?

Oliver

>-----Ursprüngliche Nachricht-----
>Von: [email-masked] [mailto:[email-masked]] 
>Im Auftrag von Vijay Devarapalli
>Gesendet: Mittwoch, 1. Oktober 2008 19:43
>An: [email-masked]
>Betreff: [netlmm] Solution for the Scenario C Race Condition
>
>Hello,
>
>I saw at least a couple of claims about the solution for 
>handling the race condition in scenario C described in
>draft-giaretta-netlmm-mip-interactions-02 being complex. The 
>solution was in the slides that were presented in the last 
>IETF meeting. But there wasn't enough time to actually 
>describe the solution. Slides 9-11 at 
>http://www.ietf.org/proceedings/08jul/slides/netlmm-3.pdf 
>describe the solution. 
>
>It is a simple solution. If at any time, the LMA receives a 
>PBU and BU (or a BU and PBU) within a very short interval of 
>time, the race condition prevention mechanism (for lack of 
>better words), gets triggered. This basically involves the LMA 
>checking with the entity from which the last message was 
>received, if it still wants to create the binding. If the last 
>message that was received was the PBU, then the LMA checks 
>with the MAG if it still wants to create the binding by 
>sending a binding revocation message. If the last message that 
>was received was the BU, then the LMA checks with the MN if it 
>still wants to create the binding by either sending a binding 
>revocation message with a new code or by sending a binding ack 
>with a new failed status code.
>
>Note that the race condition prevention mechanism does not get 
>triggered if the time interval between the PBU and the BU (or 
>between the BU and

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 2 Oct 2008 11:44:34 -0400

BLUME, Oliver wrote:
> Hello Vijay,
> 
> Your description of the race condition prevention mechanism
> doesn't seem to fit to the Dublin slides you referenced. As
> far as I can see, the slides suggest to give higher priority
> to the MN BU and to question the PBU in case of both orders
> of race conditions. I.e. the race condition check would be
> PMIP internal and transparent for the client MIP binding,
> while you now describe a symetric solution (always
> questioning the latest binding request). Did I miss something?

You are right. The one I sent in the email below was something that we were discussing offline recently. Basically the LMA would check with the entity that corresponds to the last received binding request.

In the slides I presented at the IETF, we tried to avoid any burden on the mobile node. So the LMA checks with the MAG all the time, if a race condition is detected.

Sorry for the confusion. Both would work, we have to pick one. 
 
> BTW, couldn't the Handoff Indicator give a valuable help in
> the race condition? In Scenario 2 this would suggest the following:
> 
> If the  PMIP binding request that arrives second during the
> race condition  is a refresh (HI=5) this must have been
> delayed and should be rejected with POTENTIAL_RACE_CONDITION.
> On the other hand, if the PBU has a handoff indication and
> the previous BU of the MN was just refreshing the BCE timer,
> obviously the messages were received in due course and the
> handoff to PMIP is valid. In this case it would be
> non-optimal to reject the PBU and force the MAG to send
> another PBU later (after waiting for RACE_CONDITION_PERIOD of time).

This wouldn't work if the mobile node for some reason attaches to the PMIPv6 domain briefly and goes back to the access router right away and the PBU from the MAG is received after the BU from the MN. 

Vijay

>> http://www.ietf.org/proceedings/08jul/slides/netlmm-3.pdf describe
>> the solution. 
>> 
>> between the BU and PBU) is larger than the RACE_CONDITION_PERIOD at
>> the LMA. 
>> 
>> Vijay

---

From: "Premec, Domagoj" <[email-masked]>
Date: Fri, 3 Oct 2008 14:22:55 +0200

Hi Vijay,

> The one I sent in the email below was 
> something that we were discussing offline recently. Basically 
> the LMA would check with the entity that corresponds to the 
> last received binding request.

Could you share with us the motivation for the change, what is the issue with the original proposal and how is the new proposal better?

> In the slides I presented at the IETF, we tried to avoid any 
> burden on the mobile node. So the LMA checks with the MAG all 
> the time, if a race condition is detected.

Agree, the MN should not be impacted. I'm not in favor of any proposal that requires changes to the MN. 

domagoj

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vijay Devarapalli
> Sent: 02. listopad 2008 17:45
> To: BLUME, Oliver; [email-masked]
> Subject: Re: [netlmm] Solution for the Scenario C Race Condition
> 
> BLUME, Oliver wrote:
> > Hello Vijay,
> > 
> > Your description of the race condition prevention mechanism doesn't 
> > seem to fit to the Dublin slides you referenced. As far as 
> I can see, 
> > the slides suggest to give higher priority to the MN BU and to 
> > question the PBU in case of both orders of race conditions. 
> I.e. the 
> > race condition check would be PMIP internal and transparent for the 
> > client MIP binding, while you now describe a symetric 
> solution (always 
> You are right. The one I sent in the email below was 
> something that we were discussing offline recently. Basically 
> the LMA would check with the entity that corresponds to the 
> last received binding request.
> 
> In the slides I presented at the IETF, we tried to avoid any 
> burden on the mobile node. So the LMA checks with the MAG all 
> the time, if a race condition is detected.
> 
> the race 
> > condition? In Scenario 2 this would suggest the following:
> > 
> > If the  PMIP binding request that arrives second during the race 
> > condition  is a refresh (HI=5) this must have been delayed 
> and should 
> > be rejected with POTENTIAL_RACE_CONDITION.
> > On the other hand, if the PBU has a handoff indication and the 
> > previous BU of the MN was just refreshing the BCE timer, 
> obviously the 
> > messages were received in due course and the handoff to 
> PMIP is valid. 
> > In this case it would be non-optimal to reject the PBU and 
> force the 
> > MAG to send another PBU later (after waiting for 
> RACE_CONDITION_PERIOD 
> > of time).
> 
> This wouldn't work if the mobile node for some reason 
> attaches to the PMIPv6 domain briefly and goes back to the 
> access router right away and the PBU from the MAG is received 
> after the BU from the MN. 
> 
> Vijay
> 
> > 
> > Does that make sense?
> > 
> > 
> > Oliver
> > 
> >> Von: [email-masked] [mailto:[email-masked]] Im 
> >> Auftrag von Vijay Devarapalli
> handling the 
> >> there wasn't enough time to actually describe the solution. Slides 
> >> 9-11 at http://www.ietf.org/proceedings/08jul/slides/netlmm-3.pdf 
> >> describe the solution.
> >> 
> >> It is a simple solution. If at any time, the LMA receives 
> a PBU and 
> >> BU (or a BU and PBU) within a very short interval of time, 
> the race 
> >> triggered. This basically involves the LMA checking with 
> the entity 
> >> from which the last message was received, if it still 
> wants to create 
> >> the binding. If the last message that was received was the 
> PBU, then 
> >> the LMA checks with the MAG if it still wants to create 
> the binding 
> >> by sending a binding revocation message. If the last 
> message that was 
> >> received was the BU, then the LMA checks with the MN if it still 
> >> wants to create the binding by either sending a binding revocation 
> >> message with a new code or by sending a binding ack with a 
> new failed 
> >> status code.
> >> 
> >> triggered if the time interval between the PBU and the BU 
> (or between 
> >> the BU and PBU) is larger than the RACE_CONDITION_PERIOD 
> at the LMA.
> >> 
> >> Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 03 Oct 2008 07:34:29 -0700

In the original proposal at the IETF meeting, we wanted to avoid any impacts
to the mobile node. So the LMA+HA was always checking with the MAG if it
detects a potential race condition.

But later on we realized that the LMA+HA could send a binding revocation
message, with a new reason code to the MN also. Also, we are already
standardizing binding revocation for Mobile IPv6. One of the 3GPP specs
already has some text on the LMA+HA sending a binding revocation message to
the mobile node in case the binding created by the mobile node is ever
over-written by PBU. So I no longer consider it a big impact on the mobile
node. 

Either of the solution would work.

Vijay

On 10/3/08 5:22 AM, "Premec, Domagoj" <[email-masked]> wrote:

> Could you share with us the motivation for the change, what is the issue with
> the original proposal and how is the new proposal better?
>