[HamWAN PSDR] Mesh backbone

[ZPO]

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