Subject: [MEXT] [mext] #9: Simultaneous Mobility [Ashutosh Dutta <[email-masked]>]

From: "mext" <[email-masked]>
Date: Tue, 08 Jul 2008 18:27:32 -0000

Ticket #9: Simultaneous Mobility  [Ashutosh Dutta <[email-masked]>]

 Ashutosh Dutta <[email-masked]>

         I have not seen anywhere about
         the fall back option if the mobile is already operating in RO
 mode.
         Section 11.8 in RFC 3775 discusses about the re-transmission of
         Care-of Test Init messages and Binding Update that may go on
         indefinitely.

         "The retransmissions by the mobile node MUST use an exponential
 back-
         off process in which the timeout period is doubled upon each
         retransmission, until either the node receives a response or the
         timeout period reaches the value MAX_BINDACK_TIMEOUT.  The mobile
         node MAY continue to send these messages at this slower rate
         indefinitely."

         However, if the retransmission goes on for indefinitely due to
         simultaneous mobility and there is no fall back option, it might
         affect the real-time communication because of the delayed RO.
 Thus, we
         will probably need to find some solution either by specifying it
 as
         part of RFC 3775bis or some other solution.

         It would be good to have some discussion on how to take care of
 this
         specific problem.

 Proposal:

 add the following text in section 11.8 after second paragraph in page 137.

    In certain scenarios such as in case of simultaneous mobility where
    both correspondent host and mobile host move at the same time, route
    optimization may not complete because of failed return routability
    procedures or failed binding updates. In such cases, the mobile node
    SHOULD fall back to resume normal bidirectional tunneling in order
    to avoid long delays in communication. The mobile node may run the
    bidirectional tunneling in parallel with the route optimization
 procedure
    until the RO procedure is successful. Bidirectional tunneling will
 start
    after RO procedure is not successful within a timeout period of
    MAX_RO_FAILURE (needs to be defined) and may continue to be the
    dafault option for that session if the RO procedure does not complete
    within the specified final timeout value of MAX_BINDACK_TIMEOUT.

 ---------------------------------------------------------------------

 Daniel Wong <[email-masked]>:

 ... Continuing to retry RO while falling back on reverse
 tunneling in parallel might be faster, but might have some new tricky
 protocol and timing issues that need to be carefully thought through.
 We would need to specify the correspondent host, home agent and mobile
 host behaviors carefully.

 If it is not done in parallel (say, it stops trying RO after one
 retry, and just falls back to reverse tunneling), then it may or may
 not have to use reverse tunneling for the rest of the session. maybe
 it could try RO again the next time it moves or something.

 ---------------------------------------------------------------------

 Hesham Soliman <[email-masked]> wrote:

 I think the text is not clear enough for specification language. Comments
 inline

 >> In certain scenarios such as in case of simultaneous mobility where
 >> both correspondent host and mobile host move at the same time, route
 >> optimization may not complete because of failed return routability
 >> procedures or failed binding updates. In such cases, the mobile SHOULD
 =>                                                               ^^ node
 >> have the fall back option to resume bidirectional tunneling in order

 => Need to reword this, perhaps remove "have the" and "option"

 >> to avoid long delays in communication. Such an option could occur
 >> after a suitable timeout period. new/

 => What's the timeout period? Do you retry RO in parallel? Or retry RO
 once
 before falling back to bidirectional tunnelling? There are several
 variations that can be done. I think falling back permanently to
 bidirectional tunnelling should be the last resort.

 Hesham

 ---------------------------------------------------------------------

 Jari Arkko  <[email-masked]>:

 There are a couple of issues that interact:

 1) Mobile nodes cannot send traffic from their new care-of address
 directly to a correspondent node before they have sent the RO BU to the
 it (Section 11.3.1). This cannot happen before they have executed the
 full return routability procedure. From this we can conclude that if
 there is any data traffic to the correspondent node, it will have to go
 through the correspondent node's home address and home agent.

 2) What is the reaction of the correspondent node when it receives
 tunneled traffic? See Section 11.7.2. But return routability packets are
 exempt from this rule.

 3) Whether the usual RO rules for the destination apply to RR packets or
 not; as far as I know there are no special rules for them.

 Did I miss anything? Based on the above, I have a few questions:

 - If we need to specify something new action on this, should this action
 be triggered by (a) data traffic or (b) lack of response to RR packets?

 - Or is it simply wrong to attempt to do the signaling to the peer's
 care-of address, maybe we should require doing it via the home address
 instead?

 - Why is this issue specific to simultaneous movement? Wouldn't it
 happen also if the peer rebooted and got a new address, as well?

 ---------------------------------------------------------------------

 Charles E. Perkins wrote:

 [>>       == Jari Arkko <[email-masked]>] [[BR]]
 [> Ans>   == Ashutosh Dutta <[email-masked]>] [[BR]]

 >> - If we need to specify something new action on this,
 >>   should this action be triggered by (a) data traffic or
 >>   (b) lack of response to RR packets?

 > Ans> It should be triggered by lack of response to RR packets.

 What if the mobile node used some perceived loss of data traffic as
 a trigger to retry the return routability signaling?

 >> - Or is it simply wrong to attempt to do the signaling
 >>   to the peer's care-of address, maybe we should require
 >>   doing it via the home address instead?

 > Ans> Yes, it is better to do it via the home address.

 Maybe it would be better to go by way of the home
 address only after signaling to the correspondent's care-of
 address fails once.

 I think it is agreed that this is a rare scenario, and so
 we should not penalize the overwhelming preponderance of
 cases when there is a simple remedy for errors in the
 rare case.

 >> - Why is this issue specific to simultaneous movement? Wouldn't it
 >>   happen also if the peer rebooted and got a new address, as well?
 >>
 >
 > Ans> I think this problem could be applied to other scenarios
 >      that you have described as well. Also, it is a matter of timing.

 In the case of reboots, there isn't much hope for
 continuity of real time communications.  So I would
 expect all binding cache entries and so on to be
 lost and/or invalidated in this situation.  So I do not
 think the same solution would be applicable.

 ---------------------------------------------------------------------

 Reference:
 http://www.ietf.org/internet-drafts/draft-wong-mext-simultaneous-ps-00.txt
 http://argreenhouse.com/IETF/draft-wong-mext-simultaneous-ps-00e.txt
 http://argreenhouse.com/IETF/wong-dutta-mext-ietf71.ppt

----------------------------------------+-----------------------------------
 Reporter:  [email-masked]       |       Owner:  [email-masked]
     Type:  defect                      |      Status:  new                  
 Priority:  minor                       |   Milestone:                       
Component:  draft-ietf-mext-rfc3775bis  |     Version:                       
 Severity:  Active WG Document          |    Keywords:                       
----------------------------------------+-----------------------------------
-- 
Ticket URL: <http://www3.tools.ietf.org/wg/mext/trac/ticket/9>
mext <http://tools.ietf.org/wg/mext/>
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext