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@kinetic-compute.com <mailto:hickey@kinetic-compute.com> 425-395-4554