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

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 15 Jun 2004 15:41:24 +0100

> 
> >>Broadcast over the domain is a lot less reliable than unicast.
> 
> > I'm not sure that the question is whether ND is good or poor, OSPFv3
is
> > good or poor, etc... All these protocols have proven their qualities
in
> > the context they were designed for.
> 
> Though OSPF has its own problems, let's not discuss them here.

I did not introduce OSPF to the discussion there's a common struggle to
adapt to the radio link. In MANET, they also want to make that faster
and ND delays are unwelcome. But there's more to it, there's the
ethernet abstraction that does not fit.

> 
> As for ND, what, do you think, is the context for which ND
> was designed?

If 802.11 was successfully emulating an Ethernet I would say yes. 

> I recognize that ND is fine for 3Mbps Ethernet segment
> containing 1000 immobile hosts, which will takes minutes
> to boot.

And so would you :)

> However, with 100Mbps Ethernet segment with 10 hosts which
> boot quickly and move frequently, which is a common context
> today, ND is already poor.

Agreed. There are improvements that should be done since the use cases
have changed. Fact of life... I believe that optimism can help a lot,
and not only O-DAD...

> Our goal is to run IP over various link types as efficiently
> as possible.

Note your contradiction: the problem you address here is to improve ND's
perf regardless of the link type. So it's about a new 'mobility' usage,
not about IPv6 over foo. I agree that this is a problem worth working
on. I guess that's part of DNA charter?

 > > On the other hand, radios open a new world of problems,
> 
> So, you are agreeing with me that radio is not a context for
> which ND was designed. Right?
Right. But then again, it's the usage we make of it, not the link type,
that seem to trouble you. I'm trying to say that also, the radio link
type has to be accounted for. I egree we can make that a separate
discussion, but then state your problem like "ND v.s. mobility" as
opposed to "ND over radio".

> 
> To me, WLAN happens to be a good example to show that ND is
> a bad idea.
Maybe because the ethernet abstraction is unfit in the first place :)

> > some of them
> > specific to the type of radio, which prevents them from being
> > efficiently abstracted as classical broadcast media. The link
> > availability is generally much poorer than classical links (even
WAN).
> > The bandwidth is changing rapidly, the error rate is several orders
of
> > magnitude worse then usual, the connectivity is at best of the
> > many-to-many type etc...
> 
> Most of your concerns are not an issue at all for best effort IP.
> 
These concerns impact the way you decide to model the radio link. It's
all advocating for serial. In which case your ND problems are very
different. You may need to look at it from a broader perspective. 

> > For MIPv6 and DNA, we have a set of problems addressed at 802.21
about
> > the visibility of the various potential peers and the control of the
> > radio by L3. There's a lot of activity around what's being called
the
> > radio layer 2.5;
> 
> No, thank you. There is no such thing as layer 2.5

Try "layer 2.5" under google. Cool tool that Internet stuff. There are a
lot of features at 2.5 including security, VPN, some forms of routing,
all of which changing the perception of the link from L3.

> 
> > Should we change all the upper layer protocols, all the
> > radios,
> 
> No. All we need are link specific mechanisms to run IP.
Obviously since you refuse to consider an higher perspective. This is
why I mentioned OSPF in the beginning of the mail. You'll discover
you're wrong on that. A new link type impacts everything at L3, because
it has to be abstracted everywhere.

> It is called "IP over XXX", not layer 2.5.
Layer 2.5 can help provide some necessary adaptation (part of it mesh
networking) that makes the layer 3 work easier. Yet I agree we need to
reconsider / adapt ND as well. But looking from the broader perspective
should help do the right thing at the right place.

> 
> > Another aspect of this problem is ethernet itself. ND over a
broadcast
> > medium is not at its best in terms of performance for DNA related
> > functionalities, such as getting an address.
> 
> "stateless autoconfiguration" is, of course, a wrong thing to do.

If it's pessimistic, yes, I agree. Another point for serial protocols
over radio MAC. We have a hub and spoke radio layer, let's have the hub
protect and distribute the addresses when a new link comes up. 

> 
> But, you are rather off topic.
> 
Depends how you consider the topic. You can narrow down and improve a
local problem or you can change your paradigm...

> > In many radio cases, the closest abstraction is to be found on
serial
> > links. .11 APs are a hub and spoke model,
> 
> 11 APs are 11 APs.
> 
.11 (for 802.11) It's hub and spoke at MAC level in enterprise mode.
Pleading for a P2MP mesh, one classical topology in Frame Relay.

> We don't need further abstractions to design IP over 11 APs.
Who's we? Maybe YOU do not. The job has already started, though.
OSPF/MANET is one example. But the radio problems are not limited to .11
. You also have problems such as those related to propagation, which
will be common across different radios; all changing the way L3 uses the
mediul - unless the problem is handled and hidden at L2.5 .  

> It's simply IP over XXX.
Is this that simple? It's not only IP address resolution and forwarding,
it's also IP routing.

Pascal

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

---

From: Greg Daley <[email-masked]>
Date: Wed, 16 Jun 2004 12:11:33 +1000

Hi Masakata

Masataka Ohta wrote:
> Broadcast over 802.11 is much less reliable than that over Ethernet.
> PERIOD.
>
Actually multicast isn't, if the multicast packet
is only going toward the AP.

Greg

---

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

Pascal;

> adapt to the radio link.

Let me explain the history.

Once upon a time, there was people believing that the world is
covered by an ATM network as a single link and the global
Internet can work only over it.

Thus, many protocol abandoned the CATENET model and assumed there
are a lot of hosts on a single link.

As it was advertised that, over ATM, broadcast does not but multicast
does work, many protocol used multicast.

IPv6 and OSPF are the examples.

There were common struggles to adapt to ATM link.

The reality is that there is no ATM and ATM does not support
multicast.

Assuming small link, the CATENET model, we can and should have
simply use point to point unicast connections (with TCP, if
reliability is required, and with modified timing if quick
response is required) instead of multicast.

> Agreed.

Thank you.

> perf regardless of the link type.

No. Even ARP is better than ND that there is no point to improve
ND. Just abandon it.

> I egree we can make that a separate

There is no point to say ND. It's simple "IP over radio" or,
more specifically, "IP over WLAN".

> Maybe because the ethernet abstraction is unfit in the first place :)

In the first place, ND strongly dependent on the ethernet
abstraction and can not be expected to be useful on all
the other link types.

> different. You may need to look at it from a broader perspective. 

With my broader perspective, there is no ND, thus, no ND problems.

> Try "layer 2.5" under google.

Try "abstract nonsense" under google.

> it has to be abstracted everywhere.

The new link type was ATM large clound.

> Who's we?

Anyone seriously considering to have IP over 11 APs.

> Is this that simple? It's not only IP address resolution and forwarding,

You should study the history on how IP over NBMA damaged the
routing architecture to develop NHRP.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Jun 2004 12:40:45 +0900

Hi, Greg;

> is only going toward the AP.

Apparently, you misunderstand that the problem were caused
by hidden terminals and were generic to radio.

It is not. The problem is caused by lack of ACK for
multicast/broadcast and is specific to CSMA/CA.

I explained it in initial messages.

						Masataka Ohta