Subject: [mobile-ip] Text proposal for Mobile IPv6 issue 154 ND Constants (Removing RS/DAD optimizations).

From: Greg Daley <[email-masked]>
Date: Fri, 13 Dec 2002 14:31:37 +1100

Hi,

I've been looking at the RS issue, and based on feedback
received from the list (regarding removing RS optimizations
from MIPv6 draft), this is the tactic I (now) propose:

* Remove all Text from Section 7.6 (Changes to Sending Router
   Solicitations)

This may be specified later in another draft, once we know
if the new settings are required.

* Remove all text regarding DAD Optimizations using
   the MAX_RTR_SOLICITATION_DELAY from sections 10.3.1 and 11.5.2

The 'Don't delay before sending DAD' optimization, has an
equivalent issue to the RS Bombing issue on the local link
as discussed in an earlier post, for MN's performing DAD
on link-locals and care-of addresses.

The other use of this optimization is when the MN sends
a BU to the home agent with the 'D' bit set.  In this case,
the BAck cannot be sent until DAD has completed, which is
the sum of the DAD delay(RetransTimer * DupAddrDetectTransmits)
and any delays prior to sending the first NS for DAD.

If the MN sent a BU with the DAD (D) bit set, it expects
that there's at least a full second delay on the BU.
(1,000 ms RetransTimer * 1 DupAddrDetectTransmits).  An
expected delay of another half a second (expected) only
affects retransmission timers on the MN.

In this case, it is likely that the address is being configured
for the first time (and sessions do not exist with the MN's HoA),
or that the BU is part of a rebinding procedure, where the CoA is
already bound to the HoA.  BAck latency doesn't matter in either
of these cases, since there is no disruption to existing traffic.

A summary of the changes are:

** Remove Section 7.6 'Changes to Sending Router Solicitations'

** In section 10.3.1 Replace the following paragraph,
       with the one shown directly below it.

Original Paragraph:

    "Normal processing for Duplicate Address Detection specifies that, in
    certain cases, the node SHOULD delay sending the initial Neighbor
    Solicitation of Duplicate Address Detection by a random delay
    between 0 and MAX_RTR_SOLICITATION_DELAY [12, 13].  However, when
    the Duplicate Address Detection (D) bit instructs the home agent
    to perform Duplicate Address Detection, the home agent SHOULD NOT
    perform such a delay.  If this Duplicate Address Detection fails,
    then the home agent MUST reject the Binding Update and MUST return a
    Binding Acknowledgement to the mobile node, in which the Status field
    is set to 134 (Duplicate Address Detection failed).  When the home
    agent sends a successful Binding Acknowledgement to the mobile node,
    the home agent assures to the mobile node that its home address will
    continue to be kept unique by the home agent at least as long as the
    lifetime granted for that home address binding is not over."

Replacement Prargraph:

    "The 'D' bit in a Binding Update instructs the home agent to
    perform Duplicate Address Detection for the MN's HoA on the
    home network. If the Home Agent detects a duplicate address, then
    the home agent MUST reject the Binding Update and MUST return a
    Binding Acknowledgement to the mobile node, in which the Status field
    is set to 134 (Duplicate Address Detection failed).  When the home
    agent sends a successful Binding Acknowledgement to the mobile node,
    the home agent assures to the mobile node that its home address will
    continue to be kept unique by the home agent at least as long as the
    lifetime granted for that home address binding is not over."

** In section 11.5.2 (Forming New Care-of Addresses) Remove all of
       the last paragraph. The text to remove is shown below:

    "In addition, normal processing for Duplicate Address Detection
    specifies that, in certain cases, the node SHOULD delay sending the
    initial Neighbor Solicitation message of Duplicate Address Detection
    by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY [12, 13];
    however, in this case, the mobile node SHOULD NOT perform such a
    delay in its use of Duplicate Address Detection, unless the mobile
    node is initializing after rebooting."

---

From: Greg Daley <[email-masked]>
Date: Fri, 13 Dec 2002 15:09:24 +1100

Hi,

Having read issue 159 more closely, it looks like there's
no need to specify the modifications to section 10.3.1
(since there will be no text regarding the 'D' bit in Draft20).

Adopting the text in issue 159 should be sufficient, for that
section, although removing 7.6 and the last paragraph in
section 11.5.2 are still necessary.

We apologise for the inconvenience

Greg

---

From: "James Kempf" <[email-masked]>
Date: Fri, 13 Dec 2002 08:50:26 -0800

Agree.

            jak

----- Original Message -----
From: "Greg Daley" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 12, 2002 7:31 PM
Subject: [mobile-ip] Text proposal for Mobile IPv6 issue 154 ND Constants
(Removing RS/DAD optimizations).

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 13 Dec 2002 14:38:55 -0800

> * Remove all Text from Section 7.6 (Changes to Sending Router

this is fine.

>    node is initializing after rebooting."

strongly disagree. whats the harm in sending DAD NS immediately? do
you know why RFC 2462 recommends the random delay? heres why.

Section 5.4.2 RFC 2462

    If the Neighbor Solicitation is the first message to be sent from an
    interface after interface (re)initialization, the node should delay
    sending the message by a random delay between 0 and
    MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY].  This serves
    to alleviate congestion when many nodes start up on the link at the
    same time, such as after a power failure, and may help to avoid race
    conditions when more than one node is trying to solicit for the same
    address at the same time.

notice "interface (re)initialization" and "when many nodes start up
on the link at the same time".

this is not the case when the MN moves to another link and configures
a new CoA.

the last paragraph of section 11.5.2 has to stay (IMO).

regards
Vijay

---

From: Greg Daley <[email-masked]>
Date: Mon, 16 Dec 2002 09:38:55 +1100

Hi Vijay,

I'll try to explain the thinking led me to
this conclusion:

priority 1: Get a useful MIPv6 draft out the door

priority 2: Get optimizations going.

Any optimizations would have to have known
worst case effects (such as RA beaconing)
to make it into MIPv6 (and get consensus
either in mobile-ip or IETF stage).

The delay provided by rfc2462 is intended as a safeguard
for the situation when many nodes configure on a network.
This is equivalent to the situation where many nodes
move at the same time (train,bus, base station failure).

The issue is that the configuration in each case is tied
to the router advertisement, with no randomness or
serialization in the operations of the mobile nodes.
This means that without RFC2462 delay on the DAD, the
N MNs would send N Multicast Neighbor Solicitations
on the wireless link (possibly simultaneously).

This is exactly the sort of issue the 2462 stanza is
trying to avoid.  We need to determine what the effect
of multicast packets will be (RS or NS) in the case
that they are all sent simultaneously, and find an
acceptable solution (maybe the current one) which doesn't
cruel the link layers and lose DAD NS packets.

Currently, the 2462 recommendation only applied on
multicast RA reception, when the DAD NS is the first
packet sent by the MN.  This means that if the MN is
currently sending packets it need not follow this
recommendation. Also, the delay is a SHOULD, which
means that people who need to (experimentally, for
example) remove this delay are not breaking RFC2462's
rules, rather its recommendations.

I don't think we should advertise this in the MIPv6
base spec until we know the parameters of the multicast
bombing on wireless access links.

Greg

---

From: "JinHyeock Choi" <[email-masked]>
Date: Mon, 16 Dec 2002 14:46:40 +0900

Hi Vijay

> this is not the case when the MN moves to another link and configures

I can't be sure 'this is not the case when the MN moves to another link.' 
As Greg pointed, there may be a problem when many nodes move at 
the same time (for example in a train). There may be NS congestion. 

Even though there will be no congestion, we can't be sure of it because 
there is no evidence or experimental result yet. (If there is, kindly let me
know.)

At current stage, it's not certain that 'Omitting NS Random Delay' is O.K.
in this case. It still is controversial. 
 
IMHO, it's reasonable to remove controversial part to a separate draft 
to speed up MIPv6 base draft. 

Best Regards

Jin

---

From: "James Kempf" <[email-masked]>
Date: Mon, 16 Dec 2002 09:57:06 -0800

I think it makes sense to remove it. My own feeling is that it should only be
required if the link doesn't provide protection. Most wireless links will
provide protection, but by removing it for now, we can discuss that at our
leisure and not have it hold up the draft.

            jak

----- Original Message -----
From: "JinHyeock Choi" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, December 15, 2002 9:46 PM
Subject: Re: [mobile-ip] Text proposal for Mobile IPv6 issue 154 ND
Constants(Removing RS/DAD optimizations).

---

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Dec 2002 15:11:42 +0200

Looks like we have an agreement on the modified text for 7.5, removal
of 7.6 and the other things. Very good...

Except that we still are debating the delay before initiating DAD.
Following the RFCs to the letter, I think Vijay is technically
right: if we are not initializing or re-initializing then we don't
have to delay... just that noone has defined initialization in any
exact sense. Clearly, if you turn off and on your interface then
thats reinitialization. What if you WLAN card starts to hear another
base station, is that reinitialization?

On the other hand, I also think Greg and others are right in the
sense that there is a possibility of simultaneous movements which
could cause a storm of DAD requests. I talked to some radio experts
about this and they didn't have any papers that would tell us how
bad the problem is. They did say, however, that ten years ago there
was a concern that fast trains etc would cause a similar problem
for cellular systems but that in practise this hasn't happened. And
yes, James, there's probably some safety features in lower layers
to deal with these things. WLANs have exponential back-off for
collisions, for instance, and I suspect many wireless techniques
have some inherently random delays before they can switch to
another base station.

There's also the question of how does the IP stack *know* that it
has re-initialized an interface? Remember that many current
drivers in Linux etc do not tell the IP stack that there's been a
switch to a new base station. So, the IP stack learns that
there's a new router and prefix, and it probably also sees that
the flow of packets from the previous router has stopped...
is this interface re-initialization or did someone turn off
the router and installed a new one? And the initialization delay
comes then at a time when we have received at least one RA and
sent perhaps many NUD-related messages.

So what can we do here? I guess the possibilities are the following:

1) Remove the delay from the spec.

2) Remove the delay from the spec, but observe that the 2462 spec uses
    SHOULD, consider your link layer in your implementation, and
    take appropriate action if you KNOW that there are lower layer
    safeguards or other delays already in place.

    (Unfortunately, an implementation on top of sloppy drivers
    could also just be blissfully unaware that the interface has
    been re-initialized and wouldn't know it has to use a delay...)

3) Require the delay, unless the IP layer is aware that the
    link layer has safeguards. That is, the above approach
    but written to the spec and not just something done
    by implementers.

4) Keep the delay in the spec.

But we need to move forward and close this issue. It looks like
#1 (might become #2 in reality) is the only viable option at this
stage. Or could you James propose some text for #3? I'm hoping
you could but if I don't hear from you I'll just go with #1.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Dec 2002 20:33:10 +0200

It was pointed out to me that my list of alternatives was confusingly
formulated. This has now been corrected below.

> 1) Remove the optimization from the spec. That is, keep the current 2462 delay.
> 
> 2) Remove the optimization from the spec, but observe that the 2462 spec uses
> 3) Keep the optimization unless the IP layer is aware that the
> 4) Keep the optimization in the spec.
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 20 Dec 2002 10:52:23 -0800

> > you could but if I don't hear from you I'll just go with #1.

FWIW, I am in favor of (4). if the WG concensus is (1), I will still
go with (2). I am going to ignore the SHOULD in RFC 2462 becuase (IMO)
we are clearly not (re)initializing the interface when the MN switches
links. most link layers are decently good at handling a storm of 
packets. and FWIW again, I think it is not bright idea recommending 
a random delay on top of the DAD delay everytime the MN moves.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Dec 2002 13:23:44 -0800

> base station, is that reinitialization?

No, that's handover. There is no equivalent in the wired case. The link layer
operations involved in handover are usually different than for reinitialization
(Reassociate v.s. Associate in the WLAN case). But, as you point out below, it
is hard for the IP stack to differentiate.

> have some inherently random delays before they can switch to

Right, I think why it didn't happen is because the radio layer takes care of it.

> sent perhaps many NUD-related messages.

So this really is something the Mobile IP would need to add above and beyond
what the IP stack itself has.

> 4) Keep the delay in the spec.

How about this (Section 11.5.2, paragraphs 5 & 6) for choice 3 above:

   RFC 2462 [ref] specifies that in normal processing for Duplicate
  Address Detection, the node SHOULD delay sending the
   initial Neighbor Solicitation message by a random delay between
   0 and MAX_RTR_SOLICITATION_DELAY.  Since delaying
   DAD can result in significant delays in configuring a new care
   of address when the Mobile Node moves to a new link, the
   Mobile Node preferably SHOULD NOT delay DAD when
   configuring a new care of address. The Mobile Node SHOULD
   delay according to the mechanisms specified in RFC 2462
    if the Mobile IP stack cannot distinguish between the normal
   process of moving to a new link and reinitializing the interface, or
   if the link layer does not include adequate local collision and
   congestion control mechanisms.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Sat, 21 Dec 2002 00:12:02 +0200

> No, that's handover. There is no equivalent in the wired case. The link layer

Right. I guess one of the root causes for this discussion is that the
events specified in current RFCs for IPv6 cover the wired case well,
but there are additional events for wireless media. It is true that there
are similarities in these events, such as the fear of packet storms.
But it might be helpful to agree upfront that we are adding some new
events rather than redefining existing ones.

>    congestion control mechanisms.

Works for me.

Jari