Subject: [homenet] Mesh networks in the homenet

From: David Lamparter <[email-masked]>
Date: Tue, 24 Mar 2015 23:19:14 +0100

Hi Homenet chairs & list,

Before we lose this, let it be noted that we seemed to have arrived at
"no" for an answer to whether we want to deal with non-transitive
networks, *as part of this particular routing protocol discussion*.

If I'm misrepresenting the outcome from today's meeting, someone please
correct me.

(As a nail in the coffin for this:  IPv6 isn't even implemented for NBMA
networks, which a mesh falls under.  Without special ND handling, Hidden
nodes will fail DAD, and you can't expect to get a mac address for a
node you don't get multicast to.  Before anyone reminds me of RFC 2491,
please point to an implementation / a wifi mesh that runs MARS.)

(The big community meshes usually don't have stupid clients in the
ad-hoc cloud.  If you're in ad-hoc, you speak the mesh protocol.  Stupid
clients go to a separate AP/BSS on a mesh router of their choosing.)

I *don't* think meshes are out of scope for homenet.  I do think meshes
need a mesh routing protocol.  But pulling this into the current
discussion seems to generate nothing but waste heat.

As a consequence, when we talk about 802.11, we would be talking about
AP / BSS, not ad-hoc / IBSS.  No hidden node problem.  No intransitive
reachability.  Massively reduced marginal links (because when you start
losing beacons between AP and Client, you'll be deassociated.)

Cheers,

-David

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Mar 2015 17:28:05 -0500

Le 24/03/2015 17:19, David Lamparter a écrit :
> Before we lose this, let it be noted that we seemed to have arrived
> at "no" for an answer to whether we want to deal with non-transitive
> If I'm misrepresenting the outcome from today's meeting, someone
> please correct me.

That transitiveness issue is from the fact that their routers only have
1 interface.

Are there 1-interface routers in homenet?

> (As a nail in the coffin for this:  IPv6 isn't even implemented for
> NBMA networks, which a mesh falls under.  Without special ND
> handling, Hidden nodes will fail DAD, and you can't expect to get a
> mac address for a node you don't get multicast to.  Before anyone
> reminds me of RFC 2491, please point to an implementation / a wifi
> mesh that runs MARS.)
>
> ad-hoc cloud.  If you're in ad-hoc, you speak the mesh protocol.
> Stupid clients go to a separate AP/BSS on a mesh router of their
> choosing.)
>
>
> I *don't* think meshes are out of scope for homenet.  I do think
> meshes need a mesh routing protocol.  But pulling this into the
> current discussion seems to generate nothing but waste heat.

We dont have a definition of what a mesh is.  Saying mesh is inviting
people from RoLL and MANET WGs to argue.

However, I'd doubt a homenet is a mesh in their sense.

> As a consequence, when we talk about 802.11, we would be talking
> about AP / BSS, not ad-hoc / IBSS.

Yes and no.

Yes, at home most deployments are in AP mode.

But no in that still at home the WiFi landscape has recently become
reacher than the old dichotomy AP-mode vs adhoc-mode.  E.g. the 802.11ac
and ad products feature direct AP to AP communication for range
extension, or streaming from a tablet to a TV set, or a LED projector
switching between being an AP itself or being a Client to another AP.

> No hidden node problem.  No intransitive reachability.  Massively
> reduced marginal links (because when you start losing beacons
> between AP and Client, you'll be deassociated.)

Tinkering about this.

Alex

>
>
> Cheers,
>
> -David
>
> _______________________________________________ homenet mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/homenet
>
>

---

From: David Lamparter <[email-masked]>
Date: Tue, 24 Mar 2015 23:49:43 +0100

> That transitiveness issue is from the fact that their routers only have

I don't follow. If each of the routers in the A-B-C situation has a
wired segment attached to them, it's still A-C intransitive, but they
each have 2 interfaces?

> Are there 1-interface routers in homenet?

In an 802.11 IBSS, I would assume yes.

> However, I'd doubt a homenet is a mesh in their sense.

Sorry - replace "mesh" with "network segment with intransitive
reachability" in my mail.

(And I'm not applying the concept to a homenet as a whole, I see it as
an attribute of a particular set of links / interface types.)

> switching between being an AP itself or being a Client to another AP.

I'll have to look at these in detail, but they sound like individual
links that would be treated as P2P in the routing protocol.

(In the tablet to TV set case, I guess routing wouldn't be involved at
all?  Strays into the "is everything a router?" question, though.)

> > between AP and Client, you'll be deassociated.)

Tinker loudly, into your keyboard, onto a mail ;)

-David

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 25 Mar 2015 01:01:17 +0100

> networks, *as part of this particular routing protocol discussion*.

This is what the protocol comparison draft has to say on the subject:

   We believe that IBSS may be out of scope for Homenet, but we expect
   that people will attempt to use the Homenet protocols in IBSS mode,
   whether we like it or not.

> Without special ND handling, Hidden nodes will fail DAD, and you can't
> expect to get a mac address for a node you don't get multicast to.

I agree.  If we assume unmodified clients, then IBSS is only suitable for
router-to-router links.  However, I think that Homenet needs a killer
feature, and almost-zeroconf router-to-router wireless links might be it.

(Now I happen to believe that if Homenet is successful, we will get
modified clients -- think Android -- but I realise that this opinion does
not necessarily reflect the consensus of this group.)

> need a mesh routing protocol.

I disagree.  If you accept that a small mesh is a cheap and convenient way
to establish a router-to-router link, then you'll want to avoid the tricky
issues that come with running multiple routing protocols (bidirectional
redistribution at two distinct points within the network, oh boy).

(But then, I'm pretty much bound to disagree.  The desire to have a single
routing protocol that you let loose on a highly heterogeneous network and
it just works is the main driver behind Babel.)

> we would be talking about AP / BSS, not ad-hoc / IBSS [...]  Massively
> reduced marginal links (because when you start losing beacons between AP
> and Client, you'll be deassociated.)

I strongly disagree.  By default, the Linux Intel driver will perform
recalibration after it misses 5 beacons in a row.  You can have
a perfectly functional yet clearly marginal link in AP/STA mode.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Mar 2015 08:16:20 -0500

> losing beacons between AP and Client, you'll be deassociated.)

To put it in a single sentence, I think what you are saying is that in a homenet, a mesh is treated as a single link, and whatever magic is required to make it work is invisible to the routing protocol.

Of course, I should point out that if this is the case, then we have to make sure that the routing protocol will be able to use this "link" as transit.   :)

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Mar 2015 11:15:40 -0500

Le 24/03/2015 17:49, David Lamparter a écrit :
>>> Before we lose this, let it be noted that we seemed to have
>>> arrived at "no" for an answer to whether we want to deal with
>>> non-transitive networks, *as part of this particular routing
>>> protocol discussion*.
>>>
>> That transitiveness issue is from the fact that their routers only
>> have 1 interface.
>
> wired segment attached to them, it's still A-C intransitive, but
> they each have 2 interfaces?

Err, no.  It's an A-B-C situation where each (even B) has 1 interface,
and all are in an IBSS.  This is the situation described in that draft.

> In an 802.11 IBSS, I would assume yes.

Well IBSS is not made to have 1-interface routers on them, so this
(1-interface routers) is not really good to do, in my personal oppinion.

IBSS is made to have 1-interface Hosts on it, not routers.

Remark this is my IMHO and a number of other people disagree with this.

I know.

I just tell that you can build a very good ad-hoc network without an AP
and with 2-interface routers.  At that point there is no hidden-terminal
problem.

>> We dont have a definition of what a mesh is.  Saying mesh is
>> inviting people from RoLL and MANET WGs to argue.
>>

Ok.  I'd substitute network for mesh altogether.

> (And I'm not applying the concept to a homenet as a whole, I see it
> as an attribute of a particular set of links / interface types.)

Well, I dont.

A mesh is a network and vice-versa.

>> But no in that still at home the WiFi landscape has recently
>> become reacher than the old dichotomy AP-mode vs adhoc-mode.  E.g.
>> the 802.11ac and ad products feature direct AP to AP communication
>> for range extension, or streaming from a tablet to a TV set, or a
>> LED projector switching between being an AP itself or being a
>> Client to another AP.
>

I agree, although I dont understand what you mean by P2P.

Peer-to-peer networks is a great term used by DSL boxes and enhanced
Blueray players to download content from P2P platforms.

Peer-to-peer is also a great term used by the RPL protocol to tell a
node talks directly to another RPL node, instead of up-and-down a
Directed Acyclic Graph.

Point-to-point links are those which only have two IP ends on them, like
a cellular link of a smartphone, or the uplink of a DSL box.

A AP to AP wireless link could be a point-to-point link, but I dont
think point-to-point protocols are used on these links.  The netgear
802.11ac AP to AP communication (see its user manual) is not necessarily
a point-to-point link.  I _suppose_ that link is a WiFi link like any
other (i.e. not point-to-point link).

>
> (In the tablet to TV set case, I guess routing wouldn't be involved
> at all?  Strays into the "is everything a router?" question,
> though.)

Sure it should.

In a typical homenet you have a growing number of these apparently
specialized links.  You have this tablet-to-TV but also 802.15.4 smart
light control, and remotely controlled window shades, alarms, smartbody 
to smartphones, smartgrid control, and more.  Each of these works ok 
isolated in itself.  When you want to link them together only IP works 
for each.  And only a notion of IP routing can find paths through such a 
maze.  Actually it's such complex that I gave up completely considering 
it, it's craziness.

>>> No hidden node problem.  No intransitive reachability.
>>> Massively reduced marginal links (because when you start losing
>>> beacons between AP and Client, you'll be deassociated.)
>>
>> Tinkering about this.
>

Overall it may boil down to have IP running on each of these links, a
routing protocol and an address and prefix assignment functionality.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Mar 2015 11:26:15 -0500

Le 24/03/2015 19:01, Juliusz Chroboczek a écrit :
>> at "no" for an answer to whether we want to deal with

Well, you can put IBSS out of scope for homenet WG, but nobody can stop
one to set an IBSS mode in a home network.

This is a confusion about the use of the term 'home networking and
homenet WG'.

>> Without special ND handling, Hidden nodes will fail DAD, and you
>> can't expect to get a mac address for a node you don't get
>> multicast to.
>
> I agree.  If we assume unmodified clients, then IBSS is only suitable
> for router-to-router links.  However, I think that Homenet needs a
> killer feature, and almost-zeroconf router-to-router wireless links
> might be it.

There are a few such killer features but they dont seem to be considered
in homenet WG.

To find one it is very easy: express a problem you have encountered.

Buy a modern home device bring it home and tell what was the difficulty
in setting it up.  There are many simple problems immediately exposed:
how is IPv6 running (is it NAT? is it PD? is it ULA?  is it running DHCP?).

Ask your DSL operator what IPv6 and how.  In France there are now two
IPv6-enabled DSL operators for the user lambda (not professional) and
you'll see how they need some feature.  For example Free IPv6 DSL only
allows setting routes manually by filling in forms in a webpage -
automate that.  Orange IPv6 DSL is nascent yesterday - what are the
problems there?

> modified clients -- think Android -- but I realise that this opinion
> does not necessarily reflect the consensus of this group.)
>
>> meshes need a mesh routing protocol.
>
> I disagree.  If you accept that a small mesh is a cheap and
> convenient way to establish a router-to-router link, then you'll want
> to avoid the tricky issues that come with running multiple routing
> protocols (bidirectional redistribution at two distinct points within
> the network, oh boy).

Multiple routing protocols is inevitable IMHO.  To deal with it is like
dealing with OSPF and BGP - make them talk to each other.

> (But then, I'm pretty much bound to disagree.  The desire to have a
> single routing protocol that you let loose on a highly heterogeneous
> network and it just works is the main driver behind Babel.)

A single routing protocol is a good goal to state at WG meeting decision
time.  But it often leads to actually new protocol which will be the
one.  We've seen that recently with RPL - that's the one.  There is even
a set of requirements for it in the home networks (RFC).

Should we enumerate all routing protocols which are 'the one'?

>> we would be talking about AP / BSS, not ad-hoc / IBSS [...]
> I strongly disagree.  By default, the Linux Intel driver will
> perform recalibration after it misses 5 beacons in a row.  You can
> have a perfectly functional yet clearly marginal link in AP/STA
> mode.

Maybe yes, with that particular driver.

Alex

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Mar 2015 08:35:14 +0100

> IBSS is made to have 1-interface Hosts on it, not routers.

one of the typical use-cases of IBSS mode was to connect larger amount
of routers for a mesh network.

> and with 2-interface routers.  At that point there is no hidden-terminal

Unfortunately this is wrong.

The number of interfaces is totally irrelevant to the hidden station
problem. The only question is if you have one wireless radio interface
(among many on a router) connecting to two other routers (with maybe
many more interfaces) that cannot hear each other on this interface.

It can even happen on AP/client networks if you use them to connect
multiple routers. There is no guarantee that the clients can see each
other.

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Mar 2015 11:45:34 -0500

Le 26/03/2015 02:35, Henning Rogge a écrit :
>> Err, no.  It's an A-B-C situation where each (even B) has 1
>> interface, and all are in an IBSS.  This is the situation
>> described in that draft.
>>
> one of the typical use-cases of IBSS mode was to connect larger
> amount of routers for a mesh network.

I doubt that.  IEEE specs of IBSS tell 'STA' (station).  They never say
Router.

A mesh network may be a nonsense in itself; it's as if IP networks were
not meshed, or as if there were meshes somewhere which were not networks.

One has to look at the latin origins of the words mesh and network.
They mean practically the same thing, no need to double.

>> I just tell that you can build a very good ad-hoc network without
>> an AP and with 2-interface routers.  At that point there is no
>> hidden-terminal problem.
>

Well no.

In the ABC problem if B had two interfaces each on a different channel,
and it were a real IP router then there were no hidden station problem.

Insisting to deploy 1-interface routers and say there are unsolvable
problems, and that meshes are different than other networks, is leading
to frustration.

Please do not get me wrong: I do support IBSS mode and large wireless
neworks; except that they should be done otherwise than currently
recommended.

> The only question is if you have one wireless radio interface (among
> many on a router) connecting to two other routers (with maybe many
> more interfaces) that cannot hear each other on this interface.

So you should not have only wireless interface on a router.  You should
have at least two distinct wireless interfaces on a router, each on a
different channel.  This is what some deployments do.

> multiple routers. There is no guarantee that the clients can see each

The guarantee to see each other comes from careful network planning,
careful field analysis.  Once the field is understood the deployment is
very easy.

A guarantee that everything will be unstable stems from lack of analysis
of the field and promotion of technology that is designed on paper by
using a God view.

Alex