Follow-up from SalishMesh/SWBC experiences: How to deal with large, saturated, congested meshes?

MeshCore Futures
1

Picking this up from the SalishMesh mesh Signal chat as this is a discussion that’s bigger than all of us.

Problem history, to the best of my knowledge:

  • Using the default frequency across a large area, like the Pacific North West, has shown to create a lot of (non-advert) flooding traffic, which saturates the whole mesh, increasing with node density, and ultimately causes congestion in both RF and MeshCore traffic.
  • The Vancouver Island Radio Club decided to test with a different frequency, which perceived by some as suddenly and not clearly communicated.
  • Another aspect of this test was that due to mesh density in BC, this caused parts of the what was thought as an agreement to create a shared mesh, to disappear from the ether.
  • On top of that, there were nodes on the mainland that also switched to test the other frequency, causing more parts of the mesh to “disappear”.
  • Beyond that, the lack of communication in general and expectations were detrimental to solving issues that folks had without a clearly defined path to information and resolution. (Mesh users were left in the dark and did not have clear direction.)
  • After the test was over, the Vancouver Island Radio Club to remain on their chosen frequency.
  • In parallel MERCS.ca was also running tests, which also caused large groups of repeaters on the default frequency to “disappear”.
  • All of this caused a broken mesh within southwest BC.
  • Mismatched expectations about the role of the SalishMesh Signal chat and attitudes about governance of more local meshes created extra challenges in interpersonal communication.

Personal observations:

  • There is a lot of simple advert traffic to begin with. Is there a reason why I should see an advert from a repeater in south Oregon?
  • A lot of traffic seems to be flooded channel messages.

Problem statement:

How do we solve the issue that even with current US settings there is a lot of congestion due to both RF congestion and absolute traffic?

Closing thoughts:

Because of the large amount of LoS connections through mountain/hill-tops if not otherwise through the large swaths of open water RF propagation, having different frequencies that cover various “micro regions” seems inevitable.

Large public chats, like the one current spanning the entire PNW (and then some), also seem to contribute to far more widely ranging traffic. This type of traffic behaviour also seems inherent to having a widely used default ‘Public’ channel.

Even with a nested region system, if a flood message is carried through the entire top-level super-region, then any and all repeaters within that super-region will receive that message.

Would an IGMP type of system help here? Where end-nodes (companions/sensors/room servers) can subscribe to specific channels?

If the solution is to prevent the repeating the super-region from being flooded, does that negate the usefulness of that super-region?

Would a system that divides regions with different frequencies into smaller regions and that bridges through bridge regions that run on different frequencies help here?

Are regions ultimately pointless and should MeshCore move to a roaming model that allows for temporary residence in local meshes that run on different frequencies and that are actively interconnecting, and where a location is a combination of the mesh and the end-node id (public key) and relevant nodes are actively discovered instead of relying on floods and are routed based on the mesh that they are currently connected to?

I know which way I am personally leaning… BUT!

I am just one and I don’t know what I don’t know.

So I figured I would start this forum with this post and open the floor.

Because with many, we can figure this out.

4 Likes
The community/governance challenge!
2

Here’s my simple, and scope limited explanation for review. You may agreed or disagree and YMMV.

To Whit
particularly looking for feedback/comments from folks in Class2

So we have 2.5 user classes here on BC West Coast and a 3rd class in USA as part of Cascadia mesh.

Class1 - general users, until a few month back I’d say that was a large part of the net on this side of the border, people doing community stuff together for one reason or another

Class2 - Emcomm/Ham radio focus groups

2.5 - a mix of class 1 and 2

Class 3 - USA based, Large number of users and repeaters, lots of general users and lots of control level folks like Jade somewhere between Class1 and 2

The overall problem is heavy load from USA repeaters causing congestion and reduced capability on our side of the border. It’s a reason sometimes it takes 2 or 3 attempts to get a group or direct message to be successfully delivered, or be able to reliably access the admin or telemetry page for a remote repeater.

For the general community, that’s an irritation, but crux of the problem for both Abbottsford and Vancouver Island are they are clearly Class 2 folks. For them operational functionality comes before general community functionality.

Both made the decision to try out switching frequencies from 525 to 425 and that significantly reduced load and improved operational functionality for their operational environments. Since it was operationally better they’ve made the decision to stay on 425. On the flip side this created holes in the rest of the net for all areas on 525.

Some would say implement Region settings as the solution, maybe…, however Region settings on the repeaters getting hammered along the border doesn’t reduce the packet or RF load those repeaters have to deal with and leave the upstreams congestion issues still in place.

With all that background, I suggest our overall goal for all classes above is find a way to keep classes 1, 2 and 2.5 functionally operational AND intercommunication AND reduce the RF/packet load from the USA.

That’s my take, have at it.

5 Likes
The community/governance challenge!
3

Canada frequency
USA frequency.
On the APP in the drop down preset list. That way every person who builds something going forward will be on the local frequency by default. That is what is the problem right now. A lot of switched to 425, all of those people happened to be on the group chat or part of another local mesh group…not everyone is part of a group. They had / have no idea about the frequency debate or reasons behind it.
Those are the repeaters that messed up the frequency switch initiative, leaving massive holes in the network.

Going forward imagine if someone built a repeater and just went to presets and selected “canada” and it was (lets say) 910.425. The problem of holes in the mesh starts fixing itself with each repeater being deployed. Trying to get frequencies changed after they are programed and deployed, lands you sort of where we currently are.

It’s easy to say all of this but would require change at the developer level, and that is after contacting the local mesh’s and getting their feedback. Would be a lot of nodes to reprogram hah

I believe this would be a good start in strengthening our local networks
No idea how to go about this, just an idea, somewhat unpopular idea…

1 Like
4

I’m far to the east but i think that, broadly, we have a governance problem in the mesh community. It’s a lot of do-ocracy, informal stuff, and it leads to communication problems, and will lead to the rise of a technocracy if we don’t start organising correctly.

Fundamentally, there are technical issues here, and those are huge challenges that shouldn’t be underestimated, but it seems to me the crucial issue in this case, completely from an outside perspective, is more of a social, coordination, and communication failure than fundamentally a technical one.

I would suggest focusing on that problem first, otherwise you’ll never be able to solve the technical problems, even if there are actual technical solutions.

4 Likes
5

more of a social, coordination, and communication failure than fundamentally a technical one

I spent decades in IT and it was always this.

2 Likes
6

Just for context, I’m on Orcas island in Washington, but I’ve been following this discussion for a while on the Signal group because the future of a LoRa BC mesh is the best - and in some cases only - way parts of the San Juan islands could get connected to a wider regional mesh network. (Imagine deep coves on the North and West sides of our islands.)

There’s a lot of ideas here already, but maybe I can suggest a way to organize the discussion a bit…

@djkranic has described some of the problems and some potential solutions. @VA7MCZ described some “classes” of users that might have different goals and how the experimentation with different frequencies has gone so far.

Perhaps it would make sense to step even further back and write out some user stories, then work backwards from those to the challenges satisfying them and potential technical solutions? (Both in the context of what’s possible today with MeshCore and an improved protocol.)

1 Like
7

From Ottawa, we’re nowhere near your scale, around 50-200 active users and ~130 repeaters on CAN/USA Default. The nearest mesh we might link to this summer is Montreal eventually extending to Quebec City, and that link will run through one or two key repeaters we’ll have control over, so scope enforcement at the boundary is going to be a much easier problem for us than what you’re dealing with along the BC/US border.

For what it’s worth, from running MeshMapper across mesh communities globally, you’re not alone. Australia already had this same debate, a few operators who controlled big chunks of the mesh split off, and there are now effectively two Australian meshes on different frequencies. The UK is constantly working through the same problem, and for that matter so are a lot of European countries that have accidentally connected. I’m not an RF expert and won’t pretend to be, but I do honestly wonder if we’re starting to see real-world limits of LoRa for the use case we’re putting it to.

Splitting frequencies feels like a pretty drastic first step. Before going there I’d try cranking adverts out to 7-day intervals, configuring scopes on the key repeaters that connect the two meshes, and moving everything to 3-byte path hashes to limit advert spread. We run 3-byte (21 hop) for adverts in Ottawa and honestly even that feels like more than enough for any flood traffic, I don’t need to know about repeaters from other cities. The default of 64 hops is unrealistic, anyone who thinks the mesh should allow that should look at the attached graphic, the flood amplification math gets out of control long before you hit that limit. I honestly feel like flood messages should have much more conservative hop limits and direct messages could be higher.

image
image1920×2120 511 KB

I’d also like to see is something like an edge repeater flag so I know a message came from out of town. In fact when the whole multi-byte discussion was going on I asked if we could have reserved repeater IDs that couldn’t be generated automatically for this reason. It would let meshes deploy backbone repeaters with dedicated IDs like FFXX, so if I saw FFFF in a path I’d know it came from out of city (in fact before multi-byte, this was my proposal: Repeaters Interlink - Greater Ottawa Mesh Enthusiasts ).

I think part of what’s making the problem worse is that multi-byte and scopes are both implemented now, but they’re confusing to users and not really in their face. I’d like to see a default multi-byte set to 2 or 3 and a default scope set to the value “unconfigured,” at least that forces users into a bucket until they understand enough to change the settings.

I agree with VA7MCZ that region settings alone don’t really fix the border-repeater problem, the RF and decode load is happening on the receiving repeater whether the packet gets dropped after or not. However in Ottawa I again feel like we’re not impacted as much by this, since it’ll be the edge repeaters that have to process these. That may make inter-city messages less reliable, but at the end of the day I feel like MeshCore should be city-wide, not spamming 100s of km, and while it’s cool to see I don’t think it’s practical as we keep seeing.

On the Canada/USA preset idea, honestly that’s the last thing I’d want to see. We’re happy on the current frequency, it works really well for us, and a Canadian-only default diverging from the US would actively hurt the Ottawa, GTA, Montreal, and Quebec City meshes and just confuse new users. If presets are the lever, regional makes more sense than national, something like “Canada West Coast” rather than a country-level split.

On the bigger architectural questions in the OP (IGMP-style subscriptions, bridge regions, the roaming model), I don’t have strong takes yet and would rather see what the smaller knobs can do first. Splitting this early feels backwards to me, you’re jumping to the biggest, hardest-to-reverse lever before pulling any of the smaller ones. My gut is that someone is eventually going to bridge the frequencies anyway, and if it’s not done well you just end up right back in the same spot with more complexity bolted on, which seems to be exactly what happened in Australia. Once split, getting back to one mesh is a much harder coordination problem than staying on one and finding ways to reduce load.

3 Likes
8

Just responding in general and not towards anyone in particular, but definitely echoing a lot of the sentiments:

The issues are absolutely two fold:

  • Meatspace issues. (I.e. communication issues)
  • Technical issues.

And as I mentioned on Signal, in my not so humble opinion, focusing on solving issues as if we’ll still have MeshCore in 5-10 years, is the way to go.

All the scaling issues, both in terms of communication AND technical scaling, is IME pertinent long term. (Which is by I created this post in this exact category. Yes, we can test things short term, but long term thinking is also what we need.)

How do we support scaling long term while making on-boarding for new users easy?
How can we (collectively across the community) lay the ground work in both technical solutions and human/user experience to make it scale?

Because non-communication will always be an issue. It just needs a few people who aren’t connected to be like… I don’t see anything and start a new mesh on default frequencies and again extend/expand broadcast domains.

If there’s a big regional chat, then that might still cause big flood storms across super-regions.

As we know in the network world (before we got STP and PVST), all it takes is one rogue access point or one person looping back a network port to another or someone putting in a rogue switch with two uplinks, to make a mess out of the network.

All of the above (in every reply) is exactly why I think it’s good to have this discussion open to all.

Get ideas out and open to poke holes in.

Also, two three four five more comments:

  • I feel that the region look up algorithm is expensive (in computing cost) and that regions can be improved
  • I also think floods (broadcasts) with 64 hops don’t make sense or not across the board. An end-point discovery would make sense to blast, but while flooding Public channel messages to all nodes between Southern Oregon and YVR/New Westminster provided good birthday entertainment, one could question if that makes sense from a mesh perspective. Is there a way to optimize this?
  • Is there a good way to solve repeating in general? Are there protocols that have solved repeating packets? Is there something to learn from say AX.25? Can we optimize traffic beyond just checking how many times we’ve heard a packet?
  • I believe that depending on specific geography and mesh density, that mixed frequencies are inevitable. Especially we want to solve the hilltop problem that we have here.
  • Meshes are only as good as the communities that run them and make them available. Whether we like it or not, once we let other people start to use them, much like an ISP, we become part of “public” infrastructure and we carry that responsibility and I believe that accountability. Sure, FAFO while learning, but also remember to give back to the community that let you learn it in the first place. No one exists in a vacuum. If one had the privilege to put up dozens of repeaters, gifting RF density, and thus become a non-trivial part of a mesh, then I personally feel that one equally has that responsibility to make sure that the wider community that depends on that gift isn’t left out in the cold if one had to remove them from that mesh. And I feel similar about that in regard to testing.

Also as a general share:

@ded started the coreprotocol.org / Core Protocol project. We’ve been working on some things to get the community aspects started and I’d be really keen to get that rolling for community processes. Scott has been in the know about this.

Just my 2 cents. (CAD; circa 0.015 USD)

9

Yeah… And it’s a lot of do-ocracy of one.

(Which - side note - is also why I generally have an issue with the inherent privilege of do-ocracy. People with the most money can easily deploy and thus control the outcome.)

10

I am not sure what an RF expert is supposed to be, but I’m a amateur radio operator and of course we’re running into physical limits here.

LoRa is a shared, low bandwidth medium. Even if we had optimal routing conditions (which mesh networks definitely are not), we have only 62kHz of bandwidth essentially over the entire network. Yes, there might be multiple trunks. Yes, you might get your message through another route if one is congested.

But that’s essentially the ground rule.

It’s very little bandwidth.

… but that’s the thing: once we connect with Montreal, I bet we’ll hit that problem, pretty much as soon as the link is up. It’s a kind of a threshold failure mode that’s hard to deal with.

I also feel it’s a bit ambitious, if not pointless, to connect country-wide, especially in wide areas like ours.

And that, again, is the core of the problem.

I think it’s worth thinking about how this problem was addressed in the past. People really interested into fixing those issues are welcome to look at how IRC, Email, BGP and now Mastodon mesh networks (because that is, fundamentally, what all of those are) have developed (and collapsed, in most cases), because it can teach us a lot about how those problems really are not that technical, in the end, even though there are, again, huge technical challenges.

1 Like
11

I totally agree but our edge repeaters will ensure that all unscoped traffic is dropped which will help keep our flood domains separate. At least that’s how I envision it.

12

We’re in violent agreement. :slight_smile: That’s what i meant: we’ll necessarily have to implement region scopes once we link.

But I worry about the concern you raised here (original from VA7MCZ, which I hadn’t realized before, but it’s a real problem):

… but perhaps, yeah, that’s not really an issue because we’re much further away than the denser west coast.

Anyways, I feel we’re drifting away from the west coast here, we can talk about those plans elsewhere.. :wink: (in https://forum.meshcore.ca/c/canada-regional-discussions/inter-regional/31 perhaps?)

1 Like
13

While this originated from the we(s)tcoast, it’s certainly not intended to be limited to just here.

These are general issues that in some shape or form will likely pop up elsewhere!

Plus, if folks make chats in super-regions like the proposed “west,pnw,bc,(swbc|vanisle)” convention, that traffic would still be carried through a lot of RF space, and it would also depend on what the default region would be for a device. With the caveat that I haven’t looked at the region code too closely, I’m guessing it could theoretically make management of a repeater in a different region impossible.

1 Like
14

A few bits here:

Would an IGMP type of system help here? Where end-nodes (companions/sensors/room servers) can subscribe to specific channels?

My sense is that something “IGMP-like,” especially at the channel level, would change the routing fairly significantly and change the resource requirements on repeaters. Perhaps that’s fine, but my read is that the routing design currently focuses on keeping the repeaters as simple and stateless as possible, whereas something subscription based increases the level of knowledge repeaters require and also increases the amount of state in the network / on repeaters.

If a companion “subscribes” to a channel, that subscription needs to be known to the network. In order to be able to reduce unnecessary repeats (no “subscriptions” for a given channel), repeaters would need to maintain an awareness of whether they have local subscribers dependent on them. Repeaters are also “blind” to channels at this point, per the objective of keeping repeaters simple and relatively stateless.

To deliver a multicast type delivery system with subscriptions, repeaters would both have to start keeping track of channels and associated keys etc and then also manage a subscription table.

This starts to get more challenging in a larger mesh. If I subscribe to something like #myneighbourhood somewhere in BC, that can be reasonably contained. But could a companion in California join #myneighbourhood? Would that result in a subscription where we’d basically plumb a chain of repeaters from My Neighbourhood all the way down to California that all need to now maintain a subscription table for #myneighbourhood? What impact does that have on resource requirements and suitable hardware for repeaters if I have to keep track of a large number of channels and subscriptions? What happens if I “top out”?

Maybe something like MVRP is a bit of a closer analogy, but then at the level of regions rather than channels? You still would have an administration problem with that, though. If we’re disseminating region information through the mesh, how do we “contain”#bc scope to its intended geography? Maybe that dissemination has a hop limit assigned to each advertised scope/region, e.g. if I advertise #bc I might tag it with a hop limit of 8, but for a #pnw region I tag a hop limit of 15 or 20?

Some of the same concerns apply to that “MVRP-like” system for region dissemination as applies to the “IGMP-like” system for channels wrt additional state/registration information maintained in the network, but perhaps with a slightly lower level of risk or maintained state given that regions are going to be fewer in number than channels, and targeting the region level doesn’t introduce a requirement for repeaters to start “understanding” channels.

Even with a nested region system, if a flood message is carried through the entire top-level super-region, then any and all repeaters within that super-region will receive that message.

…

If the solution is to prevent the repeating the super-region from being flooded, does that negate the usefulness of that super-region?

To be clear, you’re talking here about some theoretical nested region mechanism, right? As it stands, there is no actual linkage of region hierarchy in transport or repeat decisions. Any hierarchy in region config on a repeater is purely locally significant and for organizational purposes only. Getting to a place where established region hierarchy can impact transport decisions, e.g. that repeater B is configured only for parent-region and will then forward on a message scoped to child-region, would require either (a) repeater B has a full region hierarchy where it knows about the relationship between child-region and parent-region, which kind of defeats the purpose, or (b) the full region “chain” is transmitted along with the message, such that repeater B is only configured with parent-region, the sender uses child-region for the message, but the message itself conveys that child-region is “under” parent-region. Where the latter then increases the amount of overhead to transmit (the full region chain, somehow).

Would a system that divides regions with different frequencies into smaller regions and that bridges through bridge regions that run on different frequencies help here?

That can, yes, and perhaps to @VA7MCZ’s point about different classes of users, perhaps you end up with multiple meshes on different frequencies in the same geographical area, to serve those different purposes.

If you bridge frequencies, though, it would be critical to apply region filtering and e.g. dropping unscoped flood at the bridge boundary. And if someone just starts bridging two frequencies “wide open” then you’re right back where you started.

Splitting frequencies feels like a pretty drastic first step.

It is a pretty drastic step, yes, but also not a first one. This has popped up in other venues, but the folks that tried using 910.425 absolutely did try those other levers first. The problem is exactly the coordination one, as folks have laid out in previous messages. There is also an element where toggling frequencies is a pretty easy operation that can be done over the mesh (doesn’t require close physical proximity), whereas tests with regions and dropping unscoped flood ran into problems of repeaters on firmware lacking the needed support, where those repeaters where in hard-to-reach areas and not getting upgrades any time soon.

That more drastic step is the one that is the least subject to the coordination challenges of the others. I still maintain that a sound region strategy, well implemented, with unscoped flood dropped, could alleviate the issues, with the caveat of course that to make a dent the controls have to be implemented at the tx side of the conversation rather than at the rx side. However, if I’m in a pocket where the RF is crowded, I need buy-in from all the folks doing the talking in order for that to be effective. But I can organize an experiment on a spot of “clear air” fairly easily.

To be clear: I am not saying that we should not still work on that coordinated effort; just pointing out that the reason it’s a possible or more feasible lever to pull for an experiment is exactly because it can be done with less coordination, and that it was done after other experiments.

Sorry, I’m somewhat short on any proposed solutions here. But overall I’m encouraged that we have a common discussion space now to try to hash through these issues. Perhaps we end up with parallel meshes for discrete functions (general use, emmcom, etc.). Perhaps this is the “push” we need for the required firmware upgrades plus a community push for region adoption cutting down unscoped flood.

2 Likes
15

this is only a solution if canada agrees to use a different frequency. this is not an immediate solution to the issue of a pocket or two deciding to change frequency.

16

I mean, yes and no?

I can see how my comment could be interpreted like that, but that was not the message that I tried to convey. My apologies for the confusion.

There is a concrete community proposal right now, the Pacific Northwest MeshCore Region Strategy, that lays out a strategy that would create an organizational hierarchy for local meshes.

From the document’s Proposed Region Hierarchy:

image
image738×902 65.6 KB

By using that convention, it is implied that if all nodes have these super-regions configured, that an end-point connected to one of the descendant regions could start say a PNW chat tagged with the pnw region, which could then be carried around.

As Adam’s document points out, it IS pertinent to choose one’s chat channel’s region scope intentionally, but a busy chat with 1 msg/sec would still add a 1 msg/sec flood to the entire range of that scope. Say there are various NTP nodes that add 1 msg/sec across various regions. Adding a busy metro region scoped chat with 2-3 msgs/sec, then that’s a 4-5 flood msgs/sec baseline for a scoped region.

Though that could very likely be improved by properly implementing flood protection.

Now that I’ve had a few moments to read up, I also apologize to everyone for the simple IGMP reference, because that was a half-thought and I forgot that IGMP isn’t simple. Yes, M(V)RP is probably a better metaphor. I was more thinking about IGMP Snooping and PIM Sparse Mode/SSM. Constructing shorter forwarding paths based on actual presence/use. But that might also require more resources? It was a random fleeting thought on something we could take inspiration from!

Just to state it explicitly, I do not see super-regions as implied in tree-traversing forwarding. They just are, but similar to VLANs or IGMP groups (that get configured by default and are explicitly configured to broadcast on all their egress ports), carrying a VLAN across your campus network, can also spread a broadcast storm across your entire campus.

True. Forwarding could be disabled for super-regions. But then again… Without the ability to more concisely control what gets flooded across those super-regions, what would be the use of these super-regions in the first place?

That right there would also require everyone to communicate about and agree on what gets transported to what extent.

Ultimately, I think having more/different frequencies is a long-term inevitability. It’s inherent to the technology.

Everyone could just put up their own network of repeaters so that at least they themselves have coverage… But eventually we’d run into that issue on whatever frequency people would be using. We all share this RF, so we should figure out all of this and play nice together!

Just to be clear: I also REALLY appreciate everyone chiming in!
If I come across as assertive/emphatic/passionate, it’s just that. I don’t hate or dislike anyone here. Please don’t infer anything from my tone. (This is the internet… That’s what smileys and emoji were invented for! :sweat_smile:) I know that I don’t know what I don’t know and that we’re all here to try and make this thing work and there’s plenty of you all who have a ton of experience that I don’t have and I do value your opinions! And I really appreciate all of that!

Side note: I think I’ll spawn-off a separate thread about how can we fix the operator communications challenges.

1 Like
17

By using that convention, it is implied that if all nodes have these super-regions configured, that an end-point connected to one of the descendant regions could start say a PNW chat tagged with the pnw region, which could then be carried around.

As Adam’s document points out, it IS pertinent to choose one’s chat channel’s region scope intentionally…

Gotcha. Right, so:

If I’m understanding correctly, the reference to super regions was not meaning anything like that a companion could set the region for a message to a child region, and then a repeater configured for a higher level / parent region would still forward it. But rather it was a reference to the fact that we would have overlapping sets of regions, and the amount of flooded messages in a given physical location would be the sum of messages of that full stack of regions.

For instance if, for a given location, we could have all of something like a municipality, metro region, county, one or more additional geographical or cultural regions, province/state, country, etc., and flood message traffic for that physical location would then be the combination of traffic for all of those. IOW if we have higher level regions, and end users can still select those higher level regions when transmitting messages, while the overall flood traffic level could be reduced, that would be contingent on how often users opt to use smaller region scopes vs. the larger ones. Is that broadly what you were meaning?

I can see how my comment could be interpreted like that, but that was not the message that I tried to convey. My apologies for the confusion.

Oh, largely on my end for working through my reading on it; thanks for your patience with me in clarifying.

I was more thinking about IGMP Snooping and PIM Sparse Mode/SSM. Constructing shorter forwarding paths based on actual presence/use. But that might also require more resources? It was a random fleeting thought on something we could take inspiration from!

For sure, yea. There’s often the tradeoff of more intelligence in the routing/system for optimization, but agreed it’s good for us to explore the possibilities.

That right there would also require everyone to communicate about and agree on what gets transported to what extent.

Aye. If however we roll out regions and e.g. dropping unscoped flood results in users getting a fragmented and inconsistent experience, we always risk folks falling through to the biggest scope as the default to make things Just Work :trade_mark: ; the veritable chmod 777 or permit ip any any, as it were.

If I come across as assertive/emphatic/passionate, it’s just that. I don’t hate or dislike anyone here. Please don’t infer anything from my tone.

Not at all; everything you wrote here seemed reasoned I didn’t get any “harsh vibes”.

On other tech bits, I only read this later:

…and it would also depend on what the default region would be for a device. With the caveat that I haven’t looked at the region code too closely, I’m guessing it could theoretically make management of a repeater in a different region impossible.

I think that the [repeater default region config in v1.15.0](Default Scope Region - MeshCore Blog) somewhat helps here? By that I mean this logic:

From v1.15.0 there is a new rule for responses. These originate from repeater/room server, but have this rule:

  • If request packet scope can be resolved (ie. Region is in its list) then same scope is used for reply

  • Otherwise, reply is sent un-scoped.

So, say, for example:

  1. I have a repeater in Vancouver Island somewhere
  2. The default region for that repeater is bc
  3. I try to manage that repeater from Seattle

I should still be able to manage that repeater if:

  1. I set the scope on my management request to that repeater to a wider scope, e.g. pnw
  2. The repeater is aware of / is configured to permit that wider scope (pnw)
  3. There is a valid forwarding path between myself and that target repeater where the repeaters in the path also are aware of / are configured to permit that wider scope (pnw)

So, cross-region management of repeaters would not be impossible, but the management request would need to satisfy those relevant conditions.

18

A followup comment based on some of the discussions that haven’t made it onto the forums here yet

I’m going to agree with ***** since I came to mesh from an Emcomm point of view, back in my Meshtastic days with a grand ambition to flood the lower mainland with cheap mesh radios to work as failover if we lose our ham and public service repeaters in event of earthquakes, floods like the Sumas basin etc. That’s one of the reasons we (VECTOR) started talking with the other clubs to resurrect the LMERC (Lower Mainland Emergency Radio Council), one of those early conversations was talking with one of the Abby board members, she and the Abby team were pretty keen on getting meshtastic up and running did some good stuff before switching over to MeshCore.

To be clear as I mentioned previous, this is an Emcomm based operational decision, sand on the Island and at UBC. If VECTOR was already using MeshCore operationally i suspect we’d make the same decision at this point.

With that said… we also have general community usage which we have to take into consideration, I’m starting to outfit family members with companions for emergency comms planning, so coming up with an overall plan that covers both use cases, for now, for me that means running repeaters on both frequencies and building any new repeaters with 2 radios to cover both use cases.

YMMV

As in this interview where they cover public service, ham and grms and frs usage, i think something across/among shared, mixed usage lines are likely our collective future.