[HamWAN PSDR] Mesh backbone

Tue Mar 12 22:15:09 PDT 2013

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.

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?

On Tue, Mar 12, 2013 at 9:35 PM, ZPO <geekdownrange at gmail.com> wrote:

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

-- 
Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20130312/6e992972/attachment.html>