<div dir="ltr">I think you're glossing over some pretty significant issues, and hyper-focusing on specific technical ideas. The proposal to kick back, have some beer, and hash everything out in the future is appreciated, but I wonder if you're assuming that HamWAN can sit around waiting for this. We already have hardware specified, timelines for initial deployments set, a great deal of groundwork laid out, and some rather pressing organizational and regulatory issues we're contending with. Please don't take this the wrong way, but we've got quite a bit of personal investment in what's going on. Certainly you can see how another group coming in and saying "Oh yeah, hey, that work you're doing? Yeah, postpone for a while so we can have beer and throw in our own two cents" might be contentious.<br>
<br>The peering model is less about commercialism, and more about fairness. It would be terribly unfair for the members of HamWAN to fund and build a solid network only to later have other networks come in and simply use it as a network pipe to serve their own needs without adding any value. Are you suggesting that members of NW-MESH are interested in becoming members of or otherwise funding HamWAN?<br>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 12, 2013 at 9:35 PM, ZPO <span dir="ltr"><<a href="mailto:geekdownrange@gmail.com" target="_blank">geekdownrange@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Replying to the earlier message (fixed Steve's email) to keep things in-line....<br>
<div class="im"><br>
On Tue, Mar 12, 2013 at 4:29 PM, Bart Kus <<a href="mailto:me@bartk.us">me@bartk.us</a>> wrote:<br>
> Everyone take a deep breath before reading the thread. There is conflict<br>
> ahead, but we knew that. Read it only if you're willing to take the view<br>
> that what is written is done so under the best possible intentions.<br>
><br>
><br>
><br>
> On 03/12/2013 03:04 PM, ZPO wrote:<br>
><br>
> Quick note before I get dragged back into work....<br>
><br>
> Bart is correct that MESH has been overloaded as both a name for a<br>
> topology and a proper noun for a specific implementation of a MANET.<br>
> As long as we know what we're talking about, we can use either term.<br>
> We can call it MANET which is technically accurate, or MESH since that<br>
> is commonly used and understood.<br>
><br>
><br>
> I'm glad we agree on at least that. :) Let's stick with MESH in all caps<br>
> when referring to NW-MESH type stuff, since MANET can also mean a network<br>
> like HamWAN and we'd once again be ambiguous.<br>
><br>
<br>
</div>MESH it is.<br>
<div class="im"><br>
><br>
> I view the NW-MESH and HamWAN projects as complimentary. HamWAN in<br>
> general and the PSDR component in particular makes an excellent<br>
> backbone transport network to move data around the wider area.<br>
> NW-MESH works well to cover the last mile.<br>
><br>
><br>
> This is where I think HamWAN is being sold short, since it also works great<br>
> on the last mile. Reason being is HamWAN sites are all planned to be<br>
> non-ground-level, so LoS probability increases which makes last mile happy.<br>
> Your trip may be physically longer by a few miles, but the latency and speed<br>
> will still be good, if not better when compared to multiple ground hops for<br>
> the same distance. In close-proximity situations, the end-user-site to<br>
> end-user-site direct connectivity of NW-MESH I believe provides an<br>
> optimization. A COUPLE hops of MeSh might indeed be superior to traversing<br>
> a busy sector.<br>
><br>
<br>
</div>I don't think I'm selling HamWAN short, just looking at the likely<br>
timelines to have those cell-type sectors densely deployed and seeing<br>
it stretch into years if ever. It is good to have multiple things in<br>
the network gene pool. Let the use cases shake themselves out. My<br>
thought process is that a few clubs with advantaged sites can form the<br>
initial connections from MESHland to the PSDR. I'm being brief, this<br>
makes a lot more sense with a whiteboard.<br>
<div class="im"><br>
><br>
> Full bidirectional<br>
> interconnection of the networks has some significant challenges as<br>
> Bart states. They are surmountable, but there are some issues to<br>
> address.<br>
><br>
><br>
> I'm glad we both recognize this fact.<br>
><br>
<br>
</div>Maybe we can grab a cold beer at SEAPAC and I'll tell you the joys of<br>
trying to tie together US and NATO networks in Astan. All kinds of<br>
messiness.<br>
<div class="im"><br>
><br>
> On the other hand, using the PSDR as a transport means for<br>
> interconnecting pockets of NW-MESH is not terribly difficult and can<br>
> be done rather simply.<br>
><br>
><br>
> It sure can! But read on to the last point.<br>
><br>
><br>
><br>
> I greatly prefer to keep the projects separate and have a<br>
> collaboration on the interface between the two efforts outside the<br>
> mainline work of either. The projects have differing goals, differing<br>
> timelines, and differing concepts.<br>
><br>
><br>
> And I'd greatly prefer to merge the projects, because I'm not convinced that<br>
> we do have differing goals. If our goals can be communally stated as<br>
> "provide the amateur radio community with a fast wide-area multi-megabit<br>
> IP-based digital network that can scale and out-last either of us", then I<br>
> think we have a chance at merging, because that's pretty much the HamWAN<br>
> mission statement. For the more detailed version, see the official HamWAN<br>
> mission statement, which is the first article of our constitution.<br>
><br>
<br>
</div>Breaking between these two paragraphs as this is one of the first<br>
spots where the ethos of HamWAN and the MESH programs (the one here<br>
and others) tends to differ. There is no "constitution" in MESHland.<br>
That is by design. There are sets of interoperability recommendations<br>
that can be thought of as barebones versions of the RFCs underpinning<br>
the global Internet. I don't particularly care what hardware somebody<br>
brings to the party as long as it has the right interfaces and can<br>
speak the right protocols. This allows the network to grow<br>
organically with each node extending the network a bit more. It also<br>
tends to make things very resilient.<br>
<div class="im"><br>
<br>
> This is where I think you, Rob, and the rest of the NW-MESH team need to get<br>
> together with the HamWAN people to spell out exactly what it is that each of<br>
> us is trying to accomplish. Do you have a mission statement you can share?<br>
> Do you have a favorite low-noise public meeting location with power + wifi?<br>
> Starbucks is sounding likely.<br>
><br>
><br>
> I'd like to see some more detail<br>
> from Bart on what he sees as the large issues with bidirectional<br>
> interconnection (I think I know most of them) or simply using the PSDR<br>
> as transport via tunneling between access nodes.<br>
><br>
><br>
> So even though it's possible for HamWAN to act as a dumb pipe for NW-MESH,<br>
> this is not a fair arrangement for HamWAN. If this were a peering agreement<br>
> at an Internet exchange, it would be considered a violation of the terms of<br>
> service set out in every Internet exchange I'm aware of. A fair peering<br>
> agreement is where each network moves equal amounts of data to and from a<br>
> peer, where said traffic is between clients of each network. This means not<br>
> via a peer network, and the traffic is from/to clients of the same<br>
> originating network.<br>
><br>
<br>
</div>This concept probably needs to be fleshed out a bit. I didn't<br>
adequately define it in my initial post. Better with a dry erase<br>
board.. My goal would be to have every node in MESHland offering<br>
services to the wider network do so via a 44-net address which will be<br>
advertised as an HNA4 on the network. This is easy to link into<br>
HamWAN at interconnection points via BGP. That completely isolates<br>
the internal 10.x.y.z/8 2.4GHz addressing (which isn't a viable<br>
long-term solution for lots of reasons) from HamWAN. This is a good<br>
thing. On the other hand, there are some functions and features which<br>
add value to MESHland that require direct communication with OLSR ETX<br>
values intact, and routing staying on <a href="http://10.0.0.0/8" target="_blank">10.0.0.0/8</a>. Some folks may<br>
choose to not go with 44-net addresses and advertise their services to<br>
the wider world. Someone traveling out of area may want their MESH<br>
devices to transparently link up with other networks.<br>
<br>
The statement " If this were a peering agreement at an Internet<br>
<div class="im">exchange, it would be considered a violation of the terms of service<br>
</div>set out in every Internet exchange I'm aware of" reflects a commercial<br>
service provider mindset. This is not such an environment. If the<br>
ham community as a whole contributes to fund, build, and support<br>
HamWAN then HamWAN needs to accept uses that may not fit its model. I<br>
don't expect there will be huge amounts of traffic flowing via<br>
tunneled connections, but it is an important feature. What I don't<br>
want to see happen is money, site availability, and goodwill expended<br>
needlessly operating two parallel networks. There will be compromise<br>
and adaptation on both sides.<br>
<br>
The most important thing in such an interconnection is harmonizing<br>
DSCP marking for QoS. If we want to get very granular and complex,<br>
DISA UCR 2013 (<br>
<a href="http://www.disa.mil/Services/Network-Services/UCCO/UCR-2013-Draft" target="_blank">http://www.disa.mil/Services/Network-Services/UCCO/UCR-2013-Draft</a> )<br>
provides a detailed setup (section6 -<br>
<a href="http://www.disa.mil/Services/Network-Services/UCCO/~/media/Files/DISA/Services/UCCO/UCR2013-Draft/06UCR2013Section6.pdf" target="_blank">http://www.disa.mil/Services/Network-Services/UCCO/~/media/Files/DISA/Services/UCCO/UCR2013-Draft/06UCR2013Section6.pdf</a><br>
). In the long run, as long as both domains use the same QoS, things<br>
are manageable. I've played the game where DSCP tags are remarked on<br>
traffic ingress/egress. It isn't fun and generally ends up breaking.<br>
<br>
<br>
--snipping the BCWARN stuff since it isn't germane --<br>
<div class="im">><br>
> Hell, I don't even know if NW-MESH is running part 97 or part 15 rules.<br>
> What say you? :)<br>
<br>
</div>In most cases, the difference between Part97 and Part15 is a state of<br>
mind. It is only when you start using frequencies outside the<br>
ISM/UNII bands or running higher EIRPs on point-to-multipoint links<br>
that things become definitely Part97. For example, a 5.8GHz PtP link<br>
between two sites running 500mW radios and 26dBi antennas could be<br>
considered Part15 or Part97. There may be value in considering it<br>
Part15 as we may want to run the link with encryption or perhaps run<br>
an encrypted tunnel for a served agency through the link. In such an<br>
arrangement, we might get the served agency to fund the link, we<br>
install/maintain it, and they get a portion of the available bandwidth<br>
as a backup communications channel. That isn't a bad deal for any of<br>
the involved parties. Such a setup is being mulled now for one<br>
group/area in particular.<br>
<br>
Probably the best idea is to continue discussions at an exploratory<br>
level and then spend some time with a couple dry-erase boards at<br>
SEAPAC. I will be there Friday-Monday (driving back Monday). We can<br>
enjoy some frosty beverages and dry-erase our way through most of the<br>
challenges.<br>
<br>
73-KY9K/Brian<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
PSDR mailing list<br>
<a href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</a><br>
<a href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Benjamin<br></div>
</div></div>