[HamWAN PSDR] Mesh backbone

Sat Mar 16 13:34:21 PDT 2013

KY9K de AE7SJ

Awaiting your response, but I'll address Gerard's comments here since 
he's waited quite a while.

On 3/14/2013 12:01 AM, Gerard Hickey wrote:
>
> First of all, (Bart I am not trying to start a fight, just making an 
> observation)

No one is trying to start a fight, but we do have inherently contentious 
issues to discuss.  So let's keep a cool head and keep the communication 
going for the good of the community.

> HamWAN is not a mesh network. It is an architected network with links 
> (both real and planned) spread out throughout the region.

This is where we hit the inevitable confusion over the phrase "mesh 
network" which I addressed at the top of my first response so there 
wouldn't be any such confusion.  Let me find it ...

-=[ QUOTE ]=-
First, let's speak the same language.

There's a lot of confusion around the word "MESH".  I'm also not sure 
why it's always capitalized.  It's not an acronym as far as I know.  The 
term "mesh network" describes nothing more than the logical topology of 
a network.  There's a really good write-up on this at the wikipedia page 
<http://en.wikipedia.org/wiki/Mesh_networking>.  I'm pretty sure that 
when you (and others on this email) use the phrase "mesh network" it is 
not the wikipedia definition you're intending.  It means something 
different, including:

1) Using a common RF channel
2) Promiscuous neighbor discovery + association
3) Automatic IP configuration based on MAC
4) Nearly open node authentication
5) Omnidirectional operation
6) WDS <http://en.wikipedia.org/wiki/Wireless_distribution_system>-style 
operation

These are the typical traits of a SeattleWireless 
<http://seattlewireless.net/>style mesh network (which, BTW, has been 
attempting to bootstrap itself for the last 13 years).  This type of 
definition of "mesh network" is quite a different animal from the 
canonical mesh network definition (wikipedia's, derived from network 
theory).

The reason I want to make the distinction clear is that nearly all large 
networks in the world are indeed mesh networks, but nearly none of them 
possess the qualities of 1-6.  So when I say something like "HamWAN 
<https://www.hamwan.org/t/tiki-index.php>is a mesh network", I want it 
to be clear that I'm referring to the network topology only (the 
wikipedia definition).  I'm not sure what is the right word to describe 
the other type of network; perhaps capitalizing all the letters is a 
good differentiator after all.  :)
-=[ /QUOTE ]=-

> Two of the qualities of a mesh network is self-healing and zero 
> configuration.

So, admittedly I did pull the list of the above 6 properties out of my 
butt.  It's my best guess.  Is there actually a formal list somewhere?  
Please provide it.  I don't think there's actually any clear divide 
between MESH or not, it's more like a spectrum of features that are 
there or not.

I would argue the "zero configuration" claim is not actually true. 
There's configuration in MESH nodes, it's just stored in the node 
router, much as it will be in HamWAN client routers.  You set things 
like frequency, bandwidth, SSID.  In fact, as I understand it, there's 
usually a custom firmware that's uploaded which comes with I don't know 
how many settings that I'm guessing are set "just right" so that things 
work nicely.  So here, we're not so different, as both client router 
devices will have a config set.

The other way I can interpret this is that once you get your fully 
configured client router device, you simply attach it to an antenna and 
it finds and connects to the wireless network.  This is exactly the 
scenario we're enabling for HamWAN as well, it's not unique to NW-MESH.  
OK, maybe one slight difference: in the HamWAN case there will be user 
credentials you enter into the router for it to authenticate onto the 
network.  But isn't there some OLSR key in NW-MESH?  I'm really not up 
to speed on that as much as I should be.

> Yes, HamWAN does have self-healing properties but it is an engineered 
> healing mechanism rather than a intrinsic part of the technology.

I'm failing to understand the difference between "engineered" and 
"intrinsic" here.  If we require that HamWAN run OSPF, this becomes an 
intrinsic property of HamWAN.  OLSR is REALLY close to OSPF.  I would 
say in the self-healing aspects, the networks are not very different at all.

> I also can not just by the same hardware that HamWAN is using, turn it 
> on and point it to a HamWAN point of presence and have it work. There 
> are specific network and routing parameters that need to be set in 
> order to come up on the network.

I addressed this "zero config" claim above, but do correct me if I'm wrong.

> Just the same as if I have a configured HamWAN installation, I could 
> not move it to another part of the region, point it to another point 
> of presence and be back on the network (actually there is one or two 
> ways, but it makes the routing butt ugly).

This is actually one of the scenarios we're definitely enabling.  If you 
have a static IP or subnet, it will follow you around on the network no 
matter what sector you connect to.  In one of my previous replies I also 
described how that static (and publicly routable!) address(es) can 
follow you to partner networks as well through use of VPN peering.  
Nice, ya? :)  This is why we're using beefy routers, cuz we expect the 
routing tables to be large.

>
> With these statements, I am just trying to provide a clearer 
> distinction that Bart started in the second or third email of this 
> thread. By no means am I trying to elevate one technology or the other 
> as a superior technology. I think that there is plenty of room for 
> every one to experiment and play with the various technologies.

I whole-heartedly encourage any activity which gets hams playing with 
more modern digital stuff.  The whole concept of "superior" or "best" is 
relative to your goals.  That's why I'm trying to get some sense out of 
the NW-MESH crowd of what the goals really are.  A mission statement or 
something.  Like I've said, I think our goals are actually pretty close 
in most areas, and it's the differences I'd like to explore to see if we 
can minimize them or respect them and work on a peering model.  If we 
develop a clear understanding of each others' goals, only then we can 
begin the technical work necessary to align the networks together.

>
> I have stated since I first heard Bart speak about the HamWAN project 
> last year at Summer Gathering that it works very well as a backbone 
> technology. I think it compliments the NW-MESH work very well in the 
> sense that it can tie together various NW-MESH networks and provide 
> the backbone between them. And NW-MESH provides an economical way for 
> hams to participate in a community network.

The economics of onboarding to HamWAN (~$200) vs. NW-MESH (~$30) is a 
fair point.  I can envision a neighborhood cluster of $30 nodes sharing 
a $200 uplink.  But for this to become reality, we must agree on how to 
align.  I'm starting to sound like a broken record. :)  The initial 
thinking of "just give us a tunnel" is a raw deal for HamWAN, so we must 
work harder to strike a better balance.  I'd like HamWAN clients and 
MESH clients to be mutually directly addressable, for one.  I have other 
concerns about route injection into HamWAN, client authentication on 
NW-MESH and potential collisions with people's RFC1918 space networks 
since HamWAN does intend to announce routes into people's home 
networks.  I'd also like to understand the QoS, default gateway, DNS, 
IPsec and IPv6 stories.  There's a LOT of work to sort out.  Let's not 
waste time in jumping to it.

>
>>  Do you have a favorite low-noise public meeting location with power 
>> + wifi?  Starbucks is sounding likely.
>
> I have never seen a Starbucks be low-noise. Anyone of them I have ever 
> been is has always been fairly loud with all the sound reverberating 
> of every flat surface (I swear that every Starbucks employee is taught 
> to bang pots on every surface behind the counter). I am sure that I 
> can be proven wrong as I am not a coffee drinker and do not visit 
> Starbucks that often.
>
> What I will offer is conference rooms at ebay in Redmond. We have 
> plenty of white boards and projectors / 60 monitors for presenting so 
> that everyone does not have to crowd around one laptop. We can meet 
> pretty much most nights or weekends except for Tuesdays and the 2nd 
> and 4th Monday of the month. This Friday and Saturday is also out 
> since I will be at the Cascadia IT conference. I will also be in 
> California the week of 3/25. Beyond that I think I can pretty much 
> make anything else work.

I'm game.  Since I work in Redmond, I can be available there any weekday 
(after work), and am willing to make weekend trips whenever others can 
do likewise.  Let's get the ball rolling here.  During the first 
meeting(s) whoever is attending should be prepared to discuss their 
goals and philosophy about these networks.

--Bart

>
> 73.
> --
> Gerard Hickey / WTØF   IRLP:3067/Echolink:529661
> hickey at kinetic-compute.com <mailto:hickey at kinetic-compute.com>
> 425-395-4554
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20130316/aeb51002/attachment.html>