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

From: Greg Daley <[email-masked]>
Date: Sat, 12 Jun 2004 15:03:15 +1000

Hi Pascal, 

I think we're straying from the original topic...

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Friday, June 11, 2004 11:24 pm
Subject: RE: WLAN (was Re: IPv6 Host Configuration of Recursive DNS 
Server)

> 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 :)

Indeed, with a new 'prefix' configuration option for 
IPv6CP, would work OK.

This would result in an extra round trip for nodes
which didn't support it ( a configure reject/
configure request pair ), but it would be
backward compatible.

Nodes which didn't support it would just send an
RS anyway...

No more nasty multicast at the link-layer :)

Actally I like multicast, but for anything less common
than television, optimization of the wireless link for
single users per stream may take precedence.

Greg

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Greg Daley <[email-masked]>
Date: Mon, 14 Jun 2004 09:38:54 +1000

Hi Masakata-san,

Masataka Ohta wrote:
> Greg Daley wrote:
> I think that infrastructure WLAN is point (not all statsions but
> only the base station) to multipoint one.
> 
> Anyway, back to the original topic, how do you think IPv6 hosts
> should be configured with DNS server addresses?
> 
> I think you and Pascal are saying it's not ND but PPP. Right?

Actually, I think that DHCP is better (for recursive DNS
configuration).

PPP was previously used for an (in my opinion) inappropriate
number of  non-network oriented configurations.

I really think that the PPP configuration should concentrate
on what's needed to get packets traversing the L2 link.

Greg

---

From: Greg Daley <[email-masked]>
Date: Mon, 14 Jun 2004 10:51:01 +1000

Hi,

Masataka Ohta wrote:
> Hi Greg,
> Not so bad.
> Though PPP already invoves exchanges of so many packets, DHCP
> does not make it worse, at least not so much.
> 
> 
> Yup.
> However, with the current DHCPv6, it means that IP address should
> be configured by DHCP with four messages.

I'm not so clear on your intention here, but I'd guess
that Stateless Address Autoconfiguration is OK, if there
is sufficient robustness in the (re)transmission of
DAD NS's and NAs.

Since these procedures need to be done for DHCPv6
configured addresses, theres no need to mandate
DHCPv6 for address configuration in general (although
it may be a useful access-network policy).

The OtherConfigFlag from RFC2462 (learned from router
advertisement) provides another way of triggering DHCPv6
for (non-address) host configuration.
 From my reading of RFC3315 this will use Information-Request
packets.

Although someone who knows about DHCPv6 may know better.

Whether this is time critical or not depends on the
requirements on the subsystems in question.

I'd guess that a host could solicit for router advertisement
and get a response within a few seconds, DNS
service could be configured subsequently, after another
couple of seconds using DHCP, and it may not be a problem
(since it is new connections which typically need this service,
rather than existing ones).

In this case, it may not be on the critical path for a
configuring host.

> So, I think it's better to let DHCP directly use beacon capability
> of the link without PPP tax (on MTU, on packet exchanges and on
> politics to standardize PPP over WLAN (discovery mechanism of PPPoE
> is useless, here)).
>
Perhaps the overhead is higher, although the MTU needn't
be a burden if there's no switched ethernet behind
(or the switching and AP support jumbograms).
802.11's MTU is much greater than 1500 octets.

Since in 802.11b the phy/mac packet headers are at least 96us
(sometimes 192us) the addition of a few octets due to PPP
at 11mbps (since it is point-to-point) may not contribute
significantly to wireless link congestion.

If people are really interested in PPP over WLAN, they'll
make a case and provide experimental results...

Greg

> 	Base station                  Terminal
> 
>                   --> 1. DHCP Advertise (broadcast over Beacon)
> 
>                   <-- 2. DHCP Request (unicast)
> 
>                   --> 3. DHCP Reply (unicast)
> 
> 							Masataka Ohta
>

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 14 Jun 2004 07:12:04 +0900

Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 14 Jun 2004 09:33:25 +0900

Hi Greg,

Not so bad.

Yup.

	Base station                  Terminal

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 14 Jun 2004 15:34:08 +0900

Hi,

> is sufficient robustness in the (re)transmission of

DAD?

Address resolution of ND gives up after three NSes and
is not robust.

Note that hand over means new routers are involded and
everything must be tried again.

> requirements on the subsystems in question.

which is why it is a broken idea to have ND with fixed timing,
which makes ND inappropriate for most subsystems.

> and get a response within a few seconds,

If RS were successfully received AND corresponding RA were
successfully received, which are not likely the case over
congested WLAN.

					Masataka Ohta

---

From: Greg Daley <[email-masked]>
Date: Mon, 14 Jun 2004 17:45:45 +1000

Hi,

>>is sufficient robustness in the (re)transmission of

Duplicate Address Detection (from rfc2462).

> everything must be tried again.

Actually, Address resolution doesn't give up after 3 retransmissions
(as defined in RFC 2461).

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.

Indeed, the address has been unreachable during the probe
period, so this may be interpreted as correct behaviour.

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.

I think that the issue is what needs to be done on:

* wireless hosts
* base-station/routers
* fixed devices which bridge to the WLAN.

I'd guess that the first two classes are easier to
handle, since they have direct knowledge of
Wireless LAN requirements.

We really can't rely upon deployed ipv6 hosts and
routers being implemented with WLAN specific changes
(unless these are good in every network).

If we can come up with some options (or generally useful
mechanisms) that may be OK, but it's probably
better to concentrate on the wireless hosts first.

Base-station/routers may be fixable, although there's
no reason for a host to believe that their particular
AP is a combined AP/Router as opposed to a bridge.

> which makes ND inappropriate for most subsystems.

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).

* attempt to set neighbour cache entries before a neighbour
   solicitation from the peer is sent.

This second option also has the advantage that the uplink
packet queue is likely to be shorter than the downlink through the
Access Point (and so has better MAC contention properties).

For example, sending SLLAOs or TSLLAOs in an NS from the
a wireless host to the fixed network can be used to avoid
NS/NA exchanges when packets are expected on the downlink.

Both of the above strategies could be used with unmodified
nodes on the wired portion of the network (and would be suitable
for an IPv6 over WLAN type document).

> successfully received, which are not likely the case over

Indeed, any congested link may have a difficulty sending
packets.

For WLAN the RS and the RA (if the RA is unicast) can be
sent robustly (with retransmission) if the router is configured
to send unicast RAs.  Unicast RAs are likely to increase the load
in the case many devices configure simultaneously though.

Greg

---

From: Ignatios Souvatzis <[email-masked]>
Date: Mon, 14 Jun 2004 11:24:34 +0200

> only the base station) to multipoint one.

Radio, yes. Network, no. The base station creates the illusion of a
broadcast domain.

	-is

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Jun 2004 13:02:24 +0900

Greg;

Our goal is to let IP run over (almost) all the link types
as efficiently as possible.

Right?

> Duplicate Address Detection (from rfc2462).

I know. But, we are talking about address resolution, not DAD.

Yup.

Thus, ND gives up after three NSes and is not robust.

> 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.

> This may have a significant cost in time and packet

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.

> (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.

> If we can come up with some options (or generally useful

IP is generally useful. Forget to expect "generally useful"
for ND.

> but it's probably

ARP, for example, is better than ND, because it use
broadcast only for request and replies are unicast.

>   (not multicast downstream to WLAN hosts).

You can't send packets, unless address resolution succeed.

> to send unicast RAs. 

I'm afraid it's ARP and is not good enough.

> Unicast RAs are likely to increase the load

It's not a problem of modern networks, which has broad enough
bandwidth for small number of hosts.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Jun 2004 13:05:38 +0900

Ignatios Souvatzis;

> Radio, yes. Network, no. The base station creates the illusion of a

And the problem is that the illusion is not the reality.

Broadcast over the domain is a lot less reliable than unicast.

							Masataka Ohta

---

From: Greg Daley <[email-masked]>
Date: Wed, 16 Jun 2004 16:50:08 +1000

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.

> as efficiently as possible.

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.

> 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.

> 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?

> However, it does not deny the fact that ND is poor.

Indeed.  It is not irretrievable, though.

> 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.

> and we can't and must not expect such mechanisms are good in

Indeed.

Perhaps we are talking about the same idea
from different directions.

> IP is generally useful. Forget to expect "generally useful"

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.

> 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.

> 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).

> bandwidth for small number of hosts.

Indeed, it depends on the number of residents in the cell, in this
case.

Greg

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Jun 2004 21:55:56 +0900

Greg;

> point in the conversation.

Seems to be.

> I'm pretty sure that ND is critical for such devices

Why?

> in order

Why, do you think, it is a meaningful thing to use ND only
to reduce the efficiency of IP over the access medium?

Note also that, over WLAN, ARP, which works over various
access media, performs better than ND.

It is of course that new access medium needs its own hardware,
firmware, device driver and address resolution mechanism.

> as a debilitating factor for WLAN.

I'm not sure whether you understand the problem or not.

Do you understand why ND packets are lost so often?

> rely on peers being modified in order to guarantee our

It is of course that new access medium needs its own hardware,
firmware, device driver and address resolution mechanism.

Right?

> where many different media (Bluetooth, WLAN, Ethernet) may

Say CATENET. Never try to have large link.

It's you who said:

: 802.11's MTU is much greater than 1500 octets.

> configuration,

Wrong.

> Address Autoconfiguration and DAD for the link-local address.

Wrong.

DHCP without DAD works just fine over IPv4.

> I really don't see that there's an agreed way to handle

It's enough that you admit ND is not the agreed way.

> any discovery will require multicast at the MAC layer.

"Discovery" is a wrong terminology and avoided in our draft
on DNS configuration.

Advertisement is just what is required and is a lot easier.

> phase,

Yup.

> to work on a wide range of access technologies.

ND may be good for 3Mbps Ethernet shared by 1000 immobile
hosts, but not beyond.

> relying on optimizations on other devices.

As for address resolution, WLAN is not lossy media. ND over
WLAN is a lossy way of address resolution.

> Reliance upon such optimizations

Never bother to optimize ND.

> for messaging in any case

It is a lot better to use the existing ARP as the basis.

Note that DAD is useless.

> and _will_ respond if it receives a message.

ND does not assure that a host is "running a particular
service".

To detect a host is alive, ICMP echo is more than enough.

> Even if you don't receive it the first time.

DNS and URL is the way to know a host is "running a particular
service".

> retransmissions when packets are arriving.

You can do it only at the transport layer or above.

> Replies

That's the difference.

> retransmitted) to the peer.

You are merely saying ARP works over wired LAN or wired part
of the LAN, which has nothing to do with the current problem.

> neighbour discovery from the peer or router when it wishes to

Now, you are making ND link layer specific only to make ND
as good as ARP over wired part of the LAN.

Why do you bother?

> router discovery.

And router discovery is slow.

> Indeed, it depends on the number of residents in the cell, in this

As I said, ND timing is good for 3Mbps link shared by 1000 immobile
hosts, which has nothing to do with the current reality.

							Masataka Ohta