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

From: Greg Daley <[email-masked]>
Date: Wed, 09 Jun 2004 00:58:28 +1000

Hi Pekka, 

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

----- Original Message -----
From: Pekka Savola <[email-masked]>
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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 11 Jun 2004 14:24:28 +0100

Interestingly, part of this pain comes from the decision to provide
Ethernet emulation for 802.11, while some practical use cases do not
actually require a broadcast medium.

In particular, in the case of public access points, the desired effect
is a point to point connectivity with the access point; seems that a PPP
support over the Wireless MAC layer would have done the trick perfectly.
For MIPv6, though, there's also the pain that IPv6CP would not provide
an IPv6 address to the mobile device anyway.

But all this can be worked out :)

Pascal 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jari Arkko
> Sent: jeudi 10 juin 2004 12:15
> To: Masataka Ohta; Greg Daley; Pekka Savola
> Cc: IPv6 WG
Server)
> 
> Hi Masataka, Greg, and Pekka,
> 
> Masataka Ohta wrote:
> 
> > Because of its bloated set of features, I think ND hopeless.
> 
> and Pekka Savola wrote:
> 
> and elsewhere Greg Daley wrote:
> 
> I tend to agree with Greg and Pekka here. I do agree that
> we have performance and other issues with wireless
> link layers. Many of these issues are known and
> currently being dealt with somewhere, and for the
> rest we should carefully define the problems and discuss
> how they should be solved. Some issues can be solved
> using IPv6 over Foo documents, while others are
> best suited for a general solution.
> 
> --Jari
>

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 11 Jun 2004 14:57:01 +0100

> Hi,
> 	unreliable flooding of control/routing packets is a long
standing
> problem in the MANET working group [1]. Recently the MANET working
group
> formed a design team that will tackle this problem among others that
arise
> when extending OSPF for wireless media.  AFAIK, their design will be
> IP-v4/IP-v6 agnostic.
> 
> There have been several reliable multicast mechanisms discussed on
MANET,
> but none have been written up as an Internet Draft yet. If the IP-v6
ND
> requirements were well defined, one could pick one of them as the
reliable
> IP-v6 link-local multicast mechanism.
> -----

My understanding is that this discussion has a lot to do with the fact
that the radio medium provides a many-to-many connectivity as opposed to
any-to-any. So neither NBMA nor P2MP really applies for OSPF, and there
comes for instance the need for repeaters in order to cover the shadow
areas. So this is not really about making multicast work for the radios,
but the somewhat different problem of how to model the radio interface
from the OSPF perspective. And there's not necessarily a .11's
infrastructure mode behind. So I'm not sure what you exactly expect from
there.

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 17 Jun 2004 08:29:30 +0100

> 
> I think that the Point-to-Point idea has some merits,
> but the applicability is not general.
> 
> I think that if we're going to keep the ethernet-like
> nature of WLAN (it is a deployed base) then the
> hosts which are aware of their performance issues
> need to respond to them.
> 
> I'll see if I can come up with a reasoned description
> of my idea in a draft.
> 
> (reasoned may be the difficult part for me).
> 
It's not necessarily about deprecating ethernet emulation but maybe
about adding additional possible abstraction for L3 to use over the same
MAC. This could be negotiated on a per association basis, defaulting to
ethernet. 

Anyway the initial problem stands, even if the solution that came with
it is debatable. There needs to be an adaptation to the Neighbour
Discovery mechanism when used over WLAN because the nature of the
network makes it inefficient.

Even when using ethernet emulation, there is still some knowledge
somewhere that there is a hub and spoke behind. I believe that the
proposal must use that and give a specific role to the AP in order to
avoid the use of multicast. 

I'm not sure it means piggybacking with the beacons at all. But I think
it's asymmetrical. An AP based range as I succinctly described has some
merits, but then we have to look at the interaction with movements. Like
if you get your address from AP1 and then move to AP2, AP2 may want to
check with AP1 that the MAC/IP address is a correct match.

Pascal