[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WLAN (was Re: IPv6 Host Configuration of Recursive DNS Server)



Hi Pekka, 

I'm not sure where this may lead, but...

----- Original Message -----
From: Pekka Savola <pekkas@netcore.fi>
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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------