I'm trying to summarize the discussion about the constants. First
I'd like to agree with Hesham: We need to treat the constants,
optimistic DAD, collision detection all as separate items. What I
see is that on most of the issues we are close to consensus, e.g.
I don't think anyone is against moving all optimistic DAD
ideas to a separate work item.
For the constants: It seems like there's agreement that optimizations
are needed. There is some disagreement about the type of most efficient
optimizations. There's a big disagreement about where the optimizations
should be done and when.
The practical effect of these constants is that they affect the
efficiency of movements. In particular:
- If there are no indications from lower layers, it becomes
slower to detect movement; from few tenths of a second to
a second or several seconds. This has an impact to user
perception, as well as TCP behaviour etc.
- When there is an indication from lower layers, RA rate
limitation may prevent sending RAs to all-nodes multicast
address for many simultaneously moving mobiles. The net effect
of this is slower establishment of communications for the
mobile on the new link.
As a result, most folks feel that we need new constant values
that support mobility better. So: the issue isn't really about
doing the optimizations or not, but where it is done. We have
the following alternatives for moving forward on this issue:
1. Specify new constant values in Mipv6 spec. End of story.
This is the approach taken in draft-mobileip-ipv6-19.txt.
2. Specify new constant values in Mipv6 spec, but start
also an activity to come up with a separate constant
adjustement document (either in MIP or IPv6 WGs). The
document could specify just new constants, or it could
also be a more general RA optimizations document, including
other speed-up mechanisms.
3. Remove constant modifications from Mipv6 specification,
and start an activity to come up with a separate constant
adjustment document. This is the suggestion from the ADs.
The following issues should be taken in account when deciding
which alternative to pick:
- Agreeing on the constant changes in draft 19 might delay
Mipv6 specification. This includes the need to agree with
the ADs that the constants belong to this document.
- The creation of a separate document will take in account additional
viewpoints and may thus consume some amount of time.
- Some implementers have announced that they want solutions now
for their products.
- It is possible to use indications from lower layer to speed
up movements, and this is in general more efficient than IP
layer frequent multicast messages.
- On the other hand, not all link layers and driver firmware
support indications from lower layers.
- Also, lower-layer information does not help the effect of
the RA rate limitation rules.
- The constant modifications are really needed for all routers,
not just MNs and HAs. A separate document may speed up adoption
of these changes.
- A separate specification makes it easier to update the
constants as we learn new optimizations.
- There are existing concerns about the suggested constants
(such as token-bucket proposal) which would be easier to
discuss if it wouldn't be holding up the Mipv6 specification.
Jari
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
