Hi Masakata,
I think there is an issue of mis-communication here which prevents us from moving beyond a certain point in the conversation.
I understand what you're saying about different links having different properties, and that individual hosts (on different media) should take advantage of them.
I'm pretty sure that ND is critical for such devices (neighbours, but connected by different media), in order to create a common link-layer address resolution mechanism regardless of the access medium of a particular host.
Please tell me if you're in agreement here.
I think that where we're getting stuck is that the assumptions we're making are different with regard to the priorities.
I believe that you see the issue with regard to packet loss as a debilitating factor for WLAN.
I think that using existing messages from ND, some of these issues may be overcome, if we can introduce new behaviours on wireless hosts when sending and receiving these messages.
Given each of these points, perhaps it is best for me to disclose some of my assumptions, and as we become aware of further assumptions we can contribute these to the discussion.
Masataka Ohta wrote:
Greg;
Our goal is to let IP run over (almost) all the link types as efficiently as possible.
Right?
Yes, but I think it is also a goal to ensure that we don't rely on peers being modified in order to guarantee our own good performance.
This is especially the case for switched access networks, where many different media (Bluetooth, WLAN, Ethernet) may be present.
DAD?
Duplicate Address Detection (from rfc2462).
I know. But, we are talking about address resolution, not DAD.
Indeed, some of the arguments regarding ND apply to DAD, since its transmission and reception mechanisms are based on multicast (and ND messaging is used).
I was also indicating that DAD is required for address configuration, while DHCPv6 isn't, which you (seemed to have) asserted in a previous e-mail.
DHCPv6 today relies upon link-local unicast packet transfer. Therefore it relies upon ND and Stateless Address Autoconfiguration and DAD for the link-local address.
Address resolution of ND gives up after three NSes and is not robust.
As indicated in the State transition table in appendix C, The address unreachable message is sent in response to each of the queued packets and then the NC entry is deleted.
Yup.
Thus, ND gives up after three NSes and is not robust.
I really don't see that there's an agreed way to handle this issue in 802.11.
If multiple hosts can receive a packet, it will go out multicast or broadcast at the link-layer. If going from the AP to the STAs, there will be no ACK.
This is an essential property of the MAC, where the packets do not have a unique (or known) destination.
In any discovery this is going to be a problem, since any discovery will require multicast at the MAC layer.
What is needed is either to do away with the discovery phase, or to increase the robustness of the probing.
Do you agree?
Indeed, the address has been unreachable during the probe period, so this may be interpreted as correct behaviour.
It is correct to send a message that ND is performing poorly, when ND is performing poorly.
However, it does not deny the fact that ND is poor.
Indeed. It is not irretrievable, though.
Newly arriving packets will cause a new NC entry to be created, and this may establish connectivity.
This may have a significant cost in time and packet loss, though.
And, our goal is to let IP run over (almost) all the link types as efficiently as possible.
It involves to make mechanisms of IP over some link type actively make use of properties specific to the link type, which means ND approach to ignore the diffeence of link types was wrong and failed.
Indeed, we may need to make some allowance for the link types.
ND itself is not failed. It does a very good job of allowing a single message format (and single implementation) to work on a wide range of access technologies.
I think the issue here is where the allowance is made.
I think that only hosts which are directly connected to the WLAN should be expected to make adjustments.
The fixed network hosts talking to them have a mechanism (ND) which should provide a predictable fallback behaviour.
In my opinion, it is the duty of hosts which connect over lossy media to improve their own performance without relying on optimizations on other devices. Reliance upon such optimizations will make it difficult to communicate when they aren't available.
We really can't rely upon deployed ipv6 hosts and routers being implemented with WLAN specific changes (unless these are good in every network).
We can and we must implement IP with lin specific mechanisms and we can't and must not expect such mechanisms are good in every network.
Indeed.
Perhaps we are talking about the same idea from different directions.
If we can come up with some options (or generally useful
IP is generally useful. Forget to expect "generally useful" for ND.
I think that the existing ND can be used as a basis for messaging in any case (even when some modification to signalling or retransmission procedures is required)
With regards to its usefulness: It's certainly useful to be able to guarantee that a host is running a particular service and _will_ respond if it receives a message. Even if you don't receive it the first time.
If we can rely upon this form unoptimized hosts then I guess that we can utilize cleverer polling techniques, or install state on peers in order to remove the need for retransmissions when packets are arriving.
but it's probably better to concentrate on the wireless hosts first.
ARP, for example, is better than ND, because it use broadcast only for request and replies are unicast.
The only difference here is that packets are multicast for Neighbour Solicitations (Request). Replies are unicast except for in the case of DAD (which has its own retransmission mechanisms), and router advertisement (which is repeated at intervals).
Since the packets are only within a single hop, the only issue with multicast transmission (compared to broadcast) is multicast-signaling snooping devices.
Indeed, WLAN doesn't treat multicast differently to broadcast on the wireless link.
Really I can't see your point here.
It's possible that devices which know that they're using WLAN could adopt a better ND strategy. For example:
* Send packets which are likely to be robustly transmitted (not multicast downstream to WLAN hosts).
You can't send packets, unless address resolution succeed.
Actually, if your peer or router is on the fixed network, the multicast router or neighbour solicitation will go from the Wireless Host (STA) through the AP (getting Acked or retransmitted) to the peer.
This will have as good performance as unicast.
If you sent a Source Link-Layer Address Option (i.e. a MAC address) in the solicitation, it will set a neighbour cache entry in the peer or router, in which case there will not be a multicast neighbour discovery from the peer or router when it wishes to send data.
This also works if the peer is on a similar wireless link bridged by the fixed infrastructure.
If the wireless host has sent a neighbour solicitation in this case, it is aware of whether the peer has received the packet, since it will get a unicast response. If there is no response, the wireless host can continue retransmitting a number of times associated with the robustness of the media (>3?), before dropping the Neighbour Cache entry.
These mechanisms require the wireless host to be modified, but not their peer.
In most cases, the wireless host will want packet delivery from a router, which it will have discovered using router discovery. In this case, it just needs to ensure that there is a REACHABLE or STALE neighbour cache entry on the router (which it can once again check with reachability tests).
Unicast RAs are likely to increase the load in the case many devices configure simultaneously though.
It's not a problem of modern networks, which has broad enough bandwidth for small number of hosts.
Indeed, it depends on the number of residents in the cell, in this case.
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
