Hi Pekka, I'm not sure where this may lead, but...
----- Original Message ----- From: Pekka Savola <[EMAIL PROTECTED]> Date: Tuesday, June 8, 2004 11:05 pm Subject: Re: WLAN (was Re: IPv6 Host Configuration of Recursive DNS Server) > Tailed down mailing lists to just IPv6 WG list.. > > On Tue, 8 Jun 2004, Masataka Ohta wrote: > > Mohacsi Janos wrote: > > ND is wrong, because it was designed to be applicable to all the > > link types. > > > > ND deployed multicast only because some ATM guy said NBMA was > > capable of not broadcast but multicast, which is totaly denied > > by the current ND RFC stating that ND may not be applicable to > > NBMA. > > I agree that using multicast for ND was probably not one of the wisest > choices in the long run, and we're suffering from it today (e.g., as > many WLAN APs working as bridges don't forward IPv6 neighbor discovery > frames because they are multicast). There is only marginal value in > ND using multicast (compared to broadcast), as the typical number of > nodes per link is so low that broadcast storms are not a real problem. Actually, where there is a distinction able to be made between all-nodes multicast and specific small nodes, there is some advantage for the scalability of links to support many APs. This is because specific multicast packets will only be propagated out APs where there are interested hosts. For situtations where there are only a small number of nodes per cell (but many cells on the subnet), the advantage should be stark. The capabilities of the APs in this case may be partially the issue. The problem is unlikely to be 802.11 specifications though. (If APs are unable to bridge valid IEEE mcast frames that's a technical support issue). If the issue is that hosts aren't reporting their group membership in MLD reports (and the APs snoop), that's nothing to do with WLAN. > However, that doesn't change your original argument about CSMA/CA, > because broadcast suffers from the same issues as well. Indeed. > > The solution has been never bother to have standard way of > > address resolution. > > I have to disagree here. Just because broadcast/multicast (ND) isn't > optimized for WLAN (or CSMA/CA in general, I guess), that doesn't > nullify the usefulness of ND for all the other media for which > this is > not a problem. :) > The right fix appears to be specifying an IPv6 over WLAN document > (or > the like) which specifies a possible way to optimize the situation > for > WLAN media. I think that what Masataka may have been hinting at about MIPv6 performance is that loss of the first NS from the router upon reception of a binding Ack causes retransmission of the MIPv6 BU, after 1 second. The retransmission of the NS caused by the original BAck occurring just after this. This issue only really matters when there's a data channel with time-delay requirements, and no existing Neighbour cache entry (i.e. MIPv6). (This is a well-known problem with MIPv6 and ND, and doesn't typically affect fixed hosts, since it would be only the start of a fixed host's session delayed) This isn't an 802.11 specific issue though. It happens whereever the NS is not received by the MN or the NA gets lost. It would be perfectly reasonable for a router with MIPv6 related flags for Router Advertisement to have a token bucket allowing fast retransmissions of NS's for new NC entries. Another alternative is to send an NS from the host to the router before the BAck arrives at the router. This will create an NC entry in the STALE state before the packet arrives (this NS gets acked from the AP, and so is reliable). This is a fair idea for non-802.11 networks since it removes the router to host ND from the critical path for BU recpetion. As you can see, neither of these behaviours is 802.11 specific. In this case, perhaps an IPv6 over <blah> may fix things, but the any 802.11 issues are most likely not under the control of IPv6 nodes. It's important to remember the issue is only on the downlink (packets from the AP to the STA). In most cases, hosts sending packets to WLAN connected IPv6 nodes will not be on WLAN, they will be bridged from ethernet. Defining behaviours for ethernet connected hosts because they may (possibly) be bridged to WLAN seems a bit odd... Determining what the actual problem is and solving that may be a better mechanism. > But while IPv6 over WLAN may not be fully optimal, as it requires > link-layer acknowledgements of multicast packets, I think many already > deem it to work to a *sufficient* degree .. and I'm not sure whether > there would be consensus for specifying e.g. the changes you > suggested. Data (simulations, measurements, etc.) about the > performance, latency, etc. increases might help. Indeed. WLAN works fine, so long as you receive all the multicast frames from the AP first time. While WLAN downlink multicast loses frames at a greater rate, it's no different from any other unacknowledged MAC (Of which there are plenty). If there are issues in creating new NC entries (particularly for mobile nodes) then they should be tackled in IRTF MobOpts or fed to the MIP6/MIPSHOP WGs. All of these groups may require some quantification of the problems and the proposed solutions before they take on work though (rather than dire 'ND is broken' statements). Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
