Subject: [MEXT] Text for Binding Update Race condition issue

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 25 Mar 2009 18:30:09 -0400

Hi Charlie,

Here is some text that you could perhaps use for the issue you pointed
out on slide 7 at
http://www3.ietf.org/proceedings/09mar/slides/mext-0.ppt  

  When a mobile node sends a binding update to refresh the binding 
  from the visited link and soon after moves to the home link and 
  sends a de-registration binding update, a race condition can 
  happen if the first binding update gets delayed. The delayed 
  binding update can cause the home agent to create a new binding 
  cache entry for a mobile node that had just attached to the home 
  link and successfully deleted the binding. This would prevent the 
  mobile node from using its home address from the home link.

  In order to prevent this, the home agent SHOULD NOT remove the
  binding cache entry immediately after receiving the deregistration
  binding update from the mobile node. It SHOULD mark the binding 
  cache entry as invalid, and stop proxying for the mobile node's 
  home address. The home agent should wait for MAX_DELETE_BCE_TIMEOUT 
  seconds before removing the binding cache entry completely. In the
  scenario described above, if the home agent receives the delayed 
  binding update that the mobile node sent from the visited link, it
  would reject the message since the sequence number would be less 
  than the last received deregistration binding update from the home
  link. The home agent would then send a Binding Acknowledgment with
  status '135' (Sequence number out of window) to the care of address
  on the visited link. The mobile node can continue using the home 
  address from the home link.

  MAX_DELETE_BCE_TIMEOUT           120 seconds

I didn't try to figure out which section this text would go into.

Feel free to modify the text.

Vijay

---

From: "Genadi Velev" <[email-masked]>
Date: Thu, 26 Mar 2009 11:09:38 +0100

Hi Vijay,

thanks for providing the text for resolution of the issue. 
 
Just for information: the problem of race condition between BU and
BU-dereg. when the MN returns to the home link was recognized by 3GPP
CT1 WG in October 2008. The text that was agreed for TS24.303 (NOTE in
section 5.2.3.3) is inline with your proposed solution.

Regards,
Genadi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Vijay Devarapalli
> Sent: Wednesday, March 25, 2009 11:30 PM
> To: Charles E. Perkins
> Cc: mext
> Subject: [MEXT] Text for Binding Update Race condition issue
> 
> Hi Charlie,
> 
> Here is some text that you could perhaps use for the issue 
> you pointed out on slide 7 at 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
> 
> 

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: Julien Laganier <[email-masked]>
Date: Sun, 29 Mar 2009 04:53:32 +0200

Hello Vijay,

<chair hat off>

The text you're proposing looks good to me.

--julien

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 30 Mar 2009 12:01:32 +0000

Hi Vijay,

The logic of the text is fine with me, thanks.

I am not so sure about the 120sec timeout though...it sounds completly
over the top. This is supposed to catch packets that have been delayed
in reaching the HA. That should not  be much more than the max
half-RTT for the Internet. Typical values
 these days are usualy some hundreds of milliseconds, so a few seconds
would suffice as a MAX ... I would say no more than 10seconds.

Thoughts?
George

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 30 Mar 2009 09:21:40 -0700

> would suffice as a MAX ... I would say no more than 10seconds.

Agree. 10 seconds or less makes more sense for the default value.

Vijay