[MVMA] Curtice Response to Recent Posts

[William Curtice]

To:  The MVMA

 

The following attempts to address some of Chuck's comments made in response
to my post last Tuesday.  I agree with a lot of what Chuck had to say over
the last few days.  Chucks comments are reprinted below in Black.  My
comments are shown below in the blue comic script font. 

 

Bill Curtice

937-287-0871

 

Chuck wrote:

IMHO, the AREDNMESH routing protocol works just fine. It fails when a
network fails to provide stable links.
OLSR will not fix an unstable network.

 

Curtice Response:  That is correct.  If we are talking about an RF Mesh.. In
Ohio. many of the links formed will, by nature, be "unstable links".  If
OLSR can't handle routing in the presence of "unstable links". what good is
it?  If the only thing OLSR can handle is routing through 100% LQ backbone
links, then it is really not suited to support an RF Mesh network. at least
not here.




Assuming the same number of node devices; in my view the trade-off is:

(1) a group of nodes with resiliency, but with reduced speed and capacity
.vs.
(2) a group of nodes with speed and capacity, but with reduced redundancy.

 

 

Curtice Response:  Generally agree.  However, it really comes down to the
question of how many of those natural, RF-mesh links you can replace with
point-to-point 3.4 or 5.8 high speed backbone links.  If we can replace them
all. then happy day, joy has arrived!  If the answer is "one".. I think you
must reword your second option above to (2) a group of nodes with speed and
capacity, but with reduced resiliency.    Our answer, should be somewhere
in-between.  

 

A couple cases in point:  It has been suggested that we eliminate the omni
on the 2nd Street Tank, and replace it with a sector radiator covering part
of Xenia on 2.4, and connect that node to points west by a single 5.8 (or
3.4) high speed link.  Undoubtedly. performance of connections to the tank
will improve.  But what you will have done.is to allow the whole Xenia mesh
to hang by a single thread, connected to the rest of the mesh by a single
high speed link.  You have also made it impossible for anyone outside of the
120 degree field of the panel, to connect.  I believe this is a bad idea!
When that high speed link goes down. we lose Xenia. From my view, that is
not just "reduced redundancy".  That's "fragile".   Not a great EmComm
solution.  Better. to have several, poor performing, resilient RF links that
can "hold the mesh together", when  your best shot goes down.  Now. if we
could install multiple high speed links from the tank going west (and east
for that matter). that would be ideal!  I don't think that will happen.
More likely. we will lose that site.    

 

A similar example would be the nodes in Huber.  Sawing off all 2.4 links
from DARA to the world south, and installing a high speed link to MVHS or
other, will dramatically improve the performance of DARA as a neighborhood
node.  It will also make all of the north nodes dependent on a single high
speed thread to the south.  However, in THIS case, we can likely install
multiple high speed links from DARA to points south.  My  personal
preference, would be to install some high speed links from the Vandalia Tank
going south, with a single high speed link to DARA.

 


(1) Adding more single node sites on 2397 MHz reduces speed and capacity
throughout the entire network.
     Previously, it was shown that reducing the number of nodes increased
speed and capacity while reducing redundancy.
     It is shown that a 'work around' can return some measure of speed and
capacity while reducing redundancy.

(2) Adding DtD'ed multi-node sites increases speed and capacity. 
     This may increase redundancy if omni-directional or sector antenna
patterns are used.
     Example: Adding channel 182 nodes increased redundancy, speed, and
capacity of Beavercreek<>Xenia.



Curtice Response:  Agree!!   Very likely. the more we can move to using
high-gain narrow-beam nodes for point-to-point connections the better, and
the more connections like that that we can make. the better.  However, most
of our primary sites will not support/permit many additional point-to-point
nodes.  We have to live with that.  Generally, I believe that using a single
sector antenna to replace an omni as a neighborhood flooding node. is a bad
idea.  When you consider your customer base, it is not just the single
mesher in an area (or perhaps no meshers in an area) that you are serving;
from an EmComm perspective, coverage of the entire area is a noble virtue.
Yes, it will cost you in terms of performance.  It IS a trade-off, that
should be looked at carefully.

 

 

Chuck Wrote:  

I see no manually configured nor hardwired backbone links...well, except the
tunnels. :-|

 

Curtice Response:  Yes, technically, you are correct.  All of our nodes, to
this point, are AREDN nodes, which do automatically configure.  My use of
the term "hardwired backbone links" was perhaps a misnomer.  However. what
we DO have, are point-to-point links that ARE configured such that they talk
ONLY to each other; they are isolated from the rest of the RF world as much
as  possible, and are generally prevented from making mesh connections to
any other station except for the designed receiver at the other end.  When
we connect them to the mesh with a dtd connection through a switch. OLSR can
route traffic across these links.  However.. If OLSR finds another path,
with lesser hops (or radio transmissions) and lesser performance, it will
select THAT path rather than use our high speed link paths. I sometimes
think we are using generic WiFi Access point hardware with mesh firmware to
do a task that would be better performed using a pair of Ubiquity devices
running AirOS.  

 

It is the 'mesh' in AREDNMESH that separates our network from commercial
wireless communication networks.
The virtue of AREDN MESH is in the removal of the need to configure routing.
OLSR is a layer 3 (routing) service. 
This is what the AREDN MESH firmware provides.

 

Curtice Response:  Agree!


If we provide stable links (level 2), then OLSR automagically configures the
routing.
If we provide stable links (level 2), then our network will function.
If too many stations are on the same channel, neither AREDN MESH nor
'ordinary 801.11 commercial wireless communications networks' will work'.
If too many stations are on the same channel, layer 2 will be unstable.

 It is our burden to provide the layer 1 and stable layer 2 circuits.
Then OLSR will take care of the layer 3 (routing).

===Break====

 IMHO, the 'mesh' in AREDN mesh is in the routing, not in the RF.
It is the onus of the network builders to provide resilient, redundant,
quality RF links.
If this is achieved, OLSR will handle the routing. OLSR will create the
'mesh'.
OLSR cannot 'mesh' poor RF links.

 OLSR seems to work fine when presented with 100% LQ links.
In the past I have watched the '/cgi-bin/mesh' screen of various 2397 MHz
nodes,
which in 'auto' mode updates about every 13 seconds, and
noticed the LQ of various links fluctuate widely. These 'LQ' 
values are used to determine OLSR linking choices. If 'LQ' values vary
widely,
OLSR choices will vary widely. Thus, OLSR performance will vary widely. 
======Break=======
IMHO, links create a network. A network does not create links.
Providing best quality links will let OLSR create the crucial "best quality
route paths".



 

Curtice Response:  Your comments above echo some of what I read on the AREDN
forum history for OLSR.  Generally, AREDN has encouraged us to work to make
all of our links 100% LQ.  That's easy to do if you have a mountain in your
back yard, or access to commercial towers.  Chuck indicates we need to
provide a "Stable Link", that is, a link that does not have too many
stations on the same frequency.  I would guess, that a stable link also
implies a link that is not affected by trees, or other environmental
factors.  Therefore, "Stable" implies LQ=100% all the time.  I do not
believe that is a reality in Ohio!  Mesh, by it's very nature, is inherently
unstable.. (At least the RF side of Mesh is inherently unstable).  

 

Case in Point.is the link we had between an AGM5 at MVHS, and an NSM5 at
N8NQH.  When initially installed, we had S/N of over 45db.  However, it too,
was not stable. Even though there were no trees in the path, the S/N dips to
far lower levels (more when someone climbs on the dish mounting frame).  

 

In my opinion, to say that we must assure that all of our links are stable,
and kill off all links that are not in order for OLSR to work properly, is
to say that OLSR is failing us. and desperately needs to be upgraded.   The
very fact that each nodes checks, multiple times a second, to see if it is
using the optimum modulation scheme for current conditions, implies that the
Ubiquiti designers KNEW that RF connections are inherently unstable, and
they allowed for it.  The fact that OLSR can't deal with that. is an
indictment of OLSR.  

 

Regardless of our best efforts, we still have a system where, given the
choice, OLSR will pick a one-hop direct connection with an LQ of 25%, over a
two-hop path where the LQ is 100%.   Only the duct-tape and bailing-wire
work-around (SSID Node/Link Trimming) prevents that from happening.
Something .. About OLSR.. Is not where it needs to be!

 

To the steering committee:

Please consider purchasing items no faster than they can be deployed.
It seems to me that the MVMA may have an inventory of never deployed
and/or inactive 32 MB SISO devices. 

 

Curtice Response:  In most cases, we purchased items only as they were
required.  The exception was the purchase of Bullet/L-Com units to support
Hamvention and planned installs, where  a sale price enabled us to purchase
four more than we needed at the time (for about the same price as the six we
did need). I believe all Bullets save three. have been expended or used, and
all antennas have been expended.  I will have inventory for you tomorrow.

 

 The MVMA roll-out of nine (9) user accessible 2397 MHz sites has/had 
one (1) site providing access to two (2) meshers.



Curtice Response:  I might disagree with the people served, but even that
would miss the point.  If our only objective is to serve ourselves. the
active meshers that are in the club. then I think we miss the point of
service to the community, and support of EmComm applications.  

 

In the future, shall MVMA continue the roll-out or repair or
maintenance of 2397 MHz or 32 MB or SISO node sites? 

 

Curtice Response:  THAT.. Is a decision you will have to make, functioning
as part of the steering committee.  Everything is a trade-off.  Count the
beans in the pot, and decide how you wish to use them.  As the cost of MIMO
systems comes down, and as SISO devices become unavailable, it may be a moot
point. 

 

I will not stand in the way of the MVMA making choices they think are
important, even when I disagree.  I will encourage you to look at the
choices you make, particularly concerning network expansion, and consider
the needs of all of the stake holders.  Hence my questions:  What are we
doing, why are we doing it, and who will it affect?  Compromise is sometimes
a good thing.

 

Bill WA8APB  

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qth.net/pipermail/mvma/attachments/20181109/ae452f62/attachment-0001.html>