[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Text to close issue #9 (Simultaneous Mobility)]
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 <adutta at research.telcordia.com>
To: Basavaraj.Patil at nokia.com
CC: mext at ietf.org, dwong at gmail.com
References: <C5D57F5B.244A9%basavaraj.patil at nokia.com>
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
Basavaraj.Patil at nokia.com 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" <hesham at elevatemobile.com> 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" <charles.perkins at earthlink.net>
>> 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
>> MEXT at ietf.org
>> https://www.ietf.org/mailman/listinfo/mext
>
> _______________________________________________
> MEXT mailing list
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext