Subject: [DNA] New I-D: draft-vogt-dna-relocation-00.txt

From: Christian Vogt <[email-masked]>
Date: Mon, 27 Jun 2005 07:14:00 +0200

Hi everybody,

there was recently a discussion [1] on the IPv6 mailing list about 
recommmended backoff delays for MLD Report messages sent by a MN upon 
link (re-) attachment.  These delays are according to RFC 2462bis.

The consent was to move any such mobility-related discussion to DNA.

We did a brief analysis on IPv6 relocation delays...
- identifying problematic situations, and
- proposing delay relaxations for MLD Reports or use of optimistic 
addresses prior to the initial NS to improve such situations.

You find this work here:
http://www.ietf.org/internet-drafts/draft-vogt-dna-relocation-00.txt

Kind regards,
- Christian

[1] http://www1.ietf.org/mail-archive/web/ipv6/current/msg05084.html

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

---

From: Jari Arkko <[email-masked]>
Date: Mon, 27 Jun 2005 12:53:17 +0300

Hi Christian,

and thanks for writing this draft. Some comments:

Technical:

>    o  MN sends a RS with a TSLLAO from the unspecified address.
>    o  MN receives an IPv6-multicast RA by link-layer unicast.
>    o  MN sends a MLD Report for an optimistic address.
>    o  MN send a NS for the optimistic address, initiating ODAD.
>
>    The RS (step 1) may be sent immediately, even though this is the
>    first message transmitted after (re-) enabling the interface RFC
>    2461bis.
>
>    From a standard's perspective, it is debatable whether or not the MLD
>    Report must be delayed.  RFC 2462bis says in section 5.4.2:

My belief is that the original delays in IPv6 specifications were
written in order to avoid broadcast storms and other similar
problems that might occur when, for instance, the electricity
is turned on for a large set of nodes after a power failure. Similarly,
this can address (in some cases) the wireless movement patterns
such as a bus load of people coming to the range of a cell at the
same time.

But I get worried if its followed blindly, such as in the above
scenario where other messages precede MLD signaling anyway.
Basically, I believe we need to look at the problem as a whole,
and build in safeguards that prevent packet storms. But once they
exist in a given situation, that should be sufficient and neither
ND nor MLD delays should be needed. Here's what RFC 3775 said
about the matter:

   The Mobile
   Node SHOULD delay according to the mechanisms specified in RFC 2462
   unless the implementation has a behavior that desynchronizes the
   steps that happen before the DAD in the case that multiple nodes
   experience handover at the same time.  Such desynchronizing behaviors
   might be due to random delays in the L2 protocols or device drivers,
   or due to the movement detection mechanism that is used.

>    It hence seems feasible to eliminate the backoff for MLD Reports when
>    applied after IPv6 relocation.  In particular, both of the following
>    two conditions would have to be met:
>
>    1.  The mobile node has received a trigger from its local link layer
>        indicating that interface reattachment has taken place.
>    2.  The MLD Report is either the first message transmitted on the new
>        link or it is sent in response to a unicast RA indicating IPv6
>        relocation.

What does "reattachment" mean, exactly? I believe you mean that
an interface which was previously operational has gone down and has
now come up again. But the text should be clear about this, to
avoid confusion with re-attaching to the same link that you have
previously visited.

Also, I find it curious that your conditions above don't call for
the same de-sync knowledge as the RFC 3775 text did. I'm not sure
if it is needed, just pointing out the difference...

Editorial:

>    Mobile nodes require fast IPv6 relocation.  Yet, router discovery,
>    address auto-configuration, and support for TSLLAOs depend on delayed
>    MLD signaling, defeating existing optimizations in many situations.
>
>    This document identifies problematic situations.  It proposes delay
>    relaxations for MLD Reports or use of optimistic addresses prior to
>    the initial Neighbor Solicitation to improve them.

Remove acronyms from the abstract (TSLLAO, MLD). What's
"relocation"? Maybe write the abstract as

  As mobile nodes move to new links, they need to resume their
  communications in a timely fashion. To communicate, IPv6 nodes need
  to complete router discovery, address auto-configuration, and
  other tasks. Unfortunately, many of these tasks depend on prior
  completion of the Multicast Listener Discovery (MLD) protocol,
  which introduces a mandatory delay of up to a second. This
  document discusses where this can be problematic and proposes
  some solutions that can alleviate the problem.

>    relocation delays indentified in section 2.

s/indentified/identified/

>    IPv6 Neighbor Discovery [1] accellerates router discovery in that it

My speller doesn't like the fourth word. Maybe "IPv6 ND [1]
allows mobile nodes to forego ..."

>    accelleration for this, defeating the benefits of the afore-mentioned

Same here. Maybe write it simpler as "... can currently not be optimized
away, defeating ..."

>    Both of the following two approaches can eliminate the high IPv6
>    relocation delays indentified in section 2.

There's three subsections following this.

--Jari

---

From: Christian Vogt <[email-masked]>
Date: Mon, 27 Jun 2005 21:38:07 +0200

Hi Jari,

thanks for your review and comments.  Some responses are inline.

 > Technical:
 >
 >> o  MN sends a RS with a TSLLAO from the unspecified address. o  MN
 >> receives an IPv6-multicast RA by link-layer unicast. o  MN sends a
 >> MLD Report for an optimistic address. o  MN send a NS for the
 >> optimistic address, initiating ODAD.
 >>
 >> From a standard's perspective, it is debatable whether or not the
 >> MLD Report must be delayed.  RFC 2462bis says in section 5.4.2:
 >
 >
 > written in order to avoid broadcast storms and other similar problems
 >  that might occur when, for instance, the electricity is turned on
 > for a large set of nodes after a power failure. Similarly, this can
 > address (in some cases) the wireless movement patterns such as a bus
 > load of people coming to the range of a cell at the same time.
 >
 > Basically, I believe we need to look at the problem as a whole, and
 > build in safeguards that prevent packet storms. But once they exist
 > in a given situation, that should be sufficient and neither ND nor
 > MLD delays should be needed. Here's what RFC 3775 said about the
 > matter:
 >
 >> The Mobile Node SHOULD delay according to the mechanisms specified in
 >> RFC 2462 unless the implementation has a behavior that
 >> desynchronizes the steps that happen before the DAD in the case that
 >> multiple nodes experience handover at the same time.  Such
 >> desynchronizing behaviors might be due to random delays in the L2
 >> protocols or device drivers, or due to the movement detection
 >> mechanism that is used.

I do agree that the extent to which desynchonization should be performed
is application- and environment-specific.  RFC246[12][bis] is tailored
towards stationary nodes, so the delays of up to 1s
(MAX_RTR_SOLICITATION_DELAY) are acceptable and make sense.  But we
can't do VoIP for mobile nodes with such delays.

The problem is that we cannot necessarily hard-code application- and
environment-specific behavior into the nodes simply because we don't
know a priori what the applications and environments will be.

But maybe there may be a resort:

I see a difference between messages for which collision is recoverable
and messages for which it is not.  E.g., loss of a RS would simply be
detected by the mobile node by lack of a responding RA.  So in the
(unlikely) case that there was a collision, the mobile node loses some
time, but will eventually retransmit the RS.  OTOH, loss of a MLD Report
or NS sent during (O)DAD cannot be detected---because there is no
expected response---and might lead to an address duplicate, which is NOT
recoverable (in the case of RFC2462[bis]).

But MLD Reports and NSs for (O)DAD can be retransmitted in background
mode.  So an optimistic address would be considered unique only after
two, three, or more transmissions of the MLD Report and NS resulted in
no response.  In addition, there may be plenty of desynchronization
delay because we are doing all this in background mode.  BTW, this is
what draft-vogt-dna-relocation-00 mentions in section 4.3.

 >> It hence seems feasible to eliminate the backoff for MLD Reports
 >> when applied after IPv6 relocation.  In particular, both of the
 >> following two conditions would have to be met:
 >>
 >> 1.  The mobile node has received a trigger from its local link
 >> layer indicating that interface reattachment has taken place. 2.
 >> The MLD Report is either the first message transmitted on the new
 > What does "reattachment" mean, exactly? I believe you mean that an
 > interface which was previously operational has gone down and has now
 > come up again. But the text should be clear about this, to avoid
 > confusion with re-attaching to the same link that you have previously
 > visited.

I agree; the text is unclear.

 > Also, I find it curious that your conditions above don't call for the
 > same de-sync knowledge as the RFC 3775 text did. I'm not sure if it
 > is needed, just pointing out the difference...

See above.  Maybe it makes sense to send non-critical messages (those
for which collision is recoverable) immediately where possible, and to
desynchronize and retransmit critical messages in background mode.

 > [...]

Thanks for the additional comments and suggested text passages.  I guess
there is going to be a 01 version of this draft before Paris.

- Christian

---

From: Jari Arkko <[email-masked]>
Date: Tue, 28 Jun 2005 07:34:53 +0300

> can't do VoIP for mobile nodes with such delays.

Right.

> know a priori what the applications and environments will be.

Well, we could have (bad) default behavior and better, optimized
behaviour when the stack knows more about what's happening
underneath. But I agree that this is not the best possible solution.
What you describe below seems to work more universally.

> recoverable (in the case of RFC2462[bis]).

Right.

> delay because we are doing all this in background mode.

Ok, it makes a lot of sense. Thanks for explaining it.

> desynchronize and retransmit critical messages in background mode.

Ok.

--Jari