Subject: Re: [MEXT] Text to close issue #9 (Simultaneous Mobility)]

From: "Dr. Daniel Wong" <[email-masked]>
Date: Fri, 6 Mar 2009 14:12:07 +0800

Hesham, Raj, Ashutosh

the typo pointed out by Ashutosh could perhaps be fixed as follows:

from:

"The return routability procedure may be triggered but movement or
sustained loss of end-to-end communication with the correspondent node
(e.g. based onindications from upper-layers). If such indications are
received, the mobile node may revert to bi-directional tunnelling while
re-starting the return routability procedure."

to:

"The return routability procedure may be triggered by movement or
sustained loss of end-to-end communication with the correspondent node
(e.g. based on indications from upper layers). If such indications are
received, the mobile node may revert to bi-directional tunnelling while
re-starting the return routability procedure."

Also, I suggest the following change to the fixed paragraph, in the
last sentence:
"The return routability procedure may be triggered by movement or
sustained loss of end-to-end communication with the correspondent node
(e.g. based on indications from upper layers). If such indications are
received, the mobile node may revert to bi-directional tunnelling while
re-starting or starting the return routability procedure."

reason: this allows the option that the mobile node can revert to
bi-directional tunneling in parallel with return routability
immediately when there is a need for the return routability procedure,
rather than waiting for a time-out indicating failure of the first
attempt of return routability. this option may provide for fewer
dropped packets (at the cost of possible wasted resources in the event
that the return routability succeeds the first time).

thanks
Daniel

-------- Original Message --------
Subject: Re: [MEXT] Text to close issue #9  (Simultaneous Mobility)
Date: Thu, 05 Mar 2009 14:19:07 -0500
From: Ashutosh Dutta <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
References: <[email-masked]>

Hesham, Raj,

I am Ok with the suggested text, and I also think it is probably good to
have this text in 3775bis version to cover the simultaneous mobility
scenario.

Also, the following paragraph (first sentence) does not read well, there
is perhaps a typo.

"The return routability procedure may be triggered but movement or
sustained loss of end-to-end communication with the correspondent node
(e.g. based onindications from upper-layers). If such indications are
received, the mobile node may revert to bi-directional tunnelling while
re-starting the return routability procedure."

Thanks
Ashutosh

[email-masked] wrote:
>
> Hi Hesham,
>
> While your text does propose some corrective actions that the MN could take
> in the scenario where the MN and CN are mobile, I do not believe it is going
> to make the RO feature in the base spec any more usable. I am fine with
> having this text included in the 377bis version of the I-D if there is
> consensus that it covers a missing scenario and is useful to do so. I would
> also be okay if nothing is changed with the route optimization feature in
> the base spec and instead the WG decides to work on specifying this feature
> in a separate spec and address all scenarios.
>
> -Raj
>
>
> On 3/5/09 5:00 AM, "ext Hesham Soliman" <[email-masked]> wrote:
>
>> Hi Charlie,
>>
>> Please find a suggestion below.
>>
>> <text> In some scenarios, such as simultaneous mobility, where both
>> correspondent host and mobile host move at the same time, or in the case
>> where the correspondent node reboots and loses data, route optimization may
>> not complete, or its data in the binding cache might be lost.
>>
>> To provide graceful recovery from those cases, the following should be done:
>>
>> - Return Routability signalling MUST be sent to the correspondent node's
>> home address if it has one (i.e. If the correspondent node is also mobile)
>>
>> - If Return Routability signalling timed out after MAX_RO_FAILURE attempts,
>> the mobile node MUST fallback to sending packets through its home agent, to
>> the correspondent node's home address.
>>
>> The mobile node may run the bidirectional tunnelling in parallel with the
>> return routability procedure until it is successful. Exponential backoff
>> SHOULD be used for retransmission of return routability messages.
>>
>> The return routability procedure may be triggered but movement or sustained
>> loss of end-to-end communication with the correspondent node (e.g. based on
>> indications from upper-layers). If such indications are received, the mobile
>> node may revert to bi-directional tunnelling while re-starting the return
>> routability procedure.
>>
>>
>> </text>
>>
>> MAX_RO_FAILURE = 3
>>
>>
>> I hope this is a good start. I tried to account for both simultaneous
>> mobility and loss of the BC entry.
>>
>> Hesham
>>
>>
>> On 28/02/09 4:50 AM, "Charles E. Perkins" <[email-masked]>
>> wrote:
>>
>>> Hello Hesham,
>>>
>>> You are on the hook for some text to close issue #9.
>>> According to the minutes:
>>>>
>>>> - issue #9, simultaneous mobility (defect)
>>>>  Nobody has observed this in practice, it may be a rare case that doesn't
>>>>  require a solution.  There are multiple proposals and possibilities, but
>>>>  none are clearly winners.
>>>>  Raj Patil thinks we should pull RO out and publish separately, fixing
>>>>    this problem there.
>>>>  Julien proposes to leave it as an implementation issue.
>>>>  Hesham says we can explain the tradeoffs.
>>>>  *HESHAM WILL SUPPLY CHARLIE WITH A ROUGH DRAFT OF DESCRIBING TRADEOFFS OF
>>>>    DIFFERENT METHODS TO DETECT WHEN TO FALL BACK TO REVERSE TUNNELLING*
>>>>
>>>
>>> I looked, and I don't think I ever received anything from
>>> you about this.  Could you supply some text in the next
>>> few days?
>>>
>>> Thanks in advance for your consideration of my request!
>>>
>>> Regards,
>>> Charlie P.
>>>
>>>
>>
>> _______________________________________________
>> MEXT mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mext
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

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

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 06 Mar 2009 17:39:41 +1100

> re-starting the return routability procedure."

=> Please see the last correspondence on this. I think the text in the last
message is clearer than the above text.

> re-starting or starting the return routability procedure."

=> Not "starting" we're talking about the scenario where RO already exists.

> that the return routability succeeds the first time).

=> I'm not sure I understand what you want to do here. You don't restart RO
after the current one expires, you refresh it before it expires.

Hesham

---

From: "Dr. Daniel Wong" <[email-masked]>
Date: Fri, 6 Mar 2009 14:53:03 +0800

> => Not "starting" we're talking about the scenario where RO already exists.

I know, RO already exists. and we are adding a reverting to
bi-directional tunneling in the event of certain failures in the
return routability procedure, e.g., in some cases of simultaneous
mobility. the question is, what does "re-starting" mean? It seems from
your text that you mean when there is a time-out, and then you re-try
(re-starting means re-try)?

> after the current one expires, you refresh it before it expires.

I was using the word "re-starting" that was in the suggested text. In
particular, the sentence "If such indications are received, the mobile
node may revert to bi-directional tunnelling while re-starting the
return routability procedure." does this re-starting here refer to
retrying after the timeout?

Daniel

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 06 Mar 2009 16:24:58 -0800

Hello folks,

I have reviewed the submitted text and the following discussion on this
issue.  I made the suggested changes in a new section.  If this is
satisfactory, I expect to submit the result some time on Monday.

Here is the new section:

> 5.2.9.  Handling Interruptions to Return Routability
>
>    In some scenarios, such as simultaneous mobility, where both
>    correspondent host and mobile host move at the same time, or in the
>    case where the correspondent node reboots and loses data, route
>    optimization may not complete, or relevant data in the binding cache
>    might be lost.
>
>    o  Return Routability signalling MUST be sent to the correspondent
>       node's home address if it has one (i.e. not to the correspondent
>       nodes care-of address if the correspondent node is also mobile).
>
>    o  If Return Routability signalling timed out after MAX_RO_FAILURE
>       attempts, the mobile node MUST revert to sending packets to the
>       correspondent node's home address through its home agent.
>
>    The mobile node may run the bidirectional tunnelling in parallel with
>    the return routability procedure until it is successful.  Exponential
>    backoff SHOULD be used for retransmission of return routability
>    messages.
>
>    The return routability procedure may be triggered by movement of the
>    mobile node or by sustained loss of end-to-end communication with a
>    correspondent node (e.g. based on indications from upper-layers) that
>    has been using a route optimised connection to the mobile node.  If
>    such indications are received, the mobile node MAY revert to bi-
>    directional tunnelling while re-starting the return routability
>    procedure.
>   

Regards,
Charlie P.

---

From: Ashutosh Dutta <[email-masked]>
Date: Sun, 08 Mar 2009 21:48:05 -0400

Charles, it sounds reasonable addition to take care of issue #9.

You may want to change "optimised" to "optimized" in the last para to 
maintain the consistency with the first para.

Regards
Ashutosh