[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt
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.
>>
>> 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.
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
>> 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.
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.
> Editorial:
> [...]
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
--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/
Jari Arkko wrote:
> 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
--------------enig1A549B5625A88040D58C3152
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCwFWjwstEk8gl2rURAjrhAJ99pMfV17YOtoo/+DVxK7BjYg+gKgCfeaa3
+tiok3XMBdDIiWUBc78j6R4=
=XQHd
-----END PGP SIGNATURE-----
--------------enig1A549B5625A88040D58C3152--