Thoughts: Canadian Regions Strategy

Canada Regional Discussions Inter-regional
1

Regions are a MeshCore feature that lets you scope traffic and keep it contained. It works by assigning region scopes to messages and then setting rules on repeaters. For example:

Alice, in Toronto, sends a message with the scope “ca-yyz”. Her message will only be repeated by nodes with the “ca-yyz” region set. If a repeater only has, e.g, “ca” set, Alice’s message will not be repeated.

This is important: regions do not have a hierarchy! If a repeater wants to carry both Canada-wide and Toronto-only messages in this example, it needs both “ca” and “ca-yyz” set.

Another very important note is that region IDs should ideally be unique within the connected mesh. As our meshes increasingly interconnect, avoiding conflicting region IDs is important.

With that, here’s some thoughts on what we need to settle for a region scoping plan in Canada:

  1. What broad naming scheme do we use? The PNW mesh has gone with a flat naming scheme, but we could also go with a hyphenated one.
  2. How granular do we get?
  3. Who decides how regions are split up, and how do we coordinate it to avoid region conflicts?

Here’s my personal take on the matter: I think the PNW scheme makes a lot of sense, but the Canadian meshes have two characteristics that make a hyphenated scheme fit better. (i) is that our meshes are currently not as interconnected in both technical and governance terms, and (ii) they might be more connected in future.

Which leads me to think that we should prioritize a scheme that lets individual regions make as many sub-assignments as they want without risk of conflicting with other ones in future (and thus making us revise the whole scheme after we roll it out!). Here’s how a hyphenated system might look:

  • meshcore.ca assigns broad scopes: a ca scope for all Canada, and subscopes by province, iata, metro area, something (e.g, ca-yyz for the GTHA).
  • after that, we let individual meshes assign subregions under that broader one: the GTHA is free to make as many ca-yyz-[whatever] regions as they want without any risk of conflicting with other meshes’ assignments, or requiring us to globally micromanage it.

An important problem to consider is that repeaters only have 172 bytes to respond with region names. This is okay for hyphenation imo, as long as we keep individual elements short. The Swiss mesh, for example, uses ch-fr, ch-it and ch-de as their broad scopes, which is almost as concise as the PNW scheme!

2 Likes
Ottawa and Montreal (temporarily) connected
2

With the comment that, IMHO, that is not final yet.

Honestly, I would love to get more discussions going. Because as it stands, (though administrative) the super-region convention makes it even harder for regions to fall under different super-regions, or even to make it shareable.

E.g. in west→pnw→bc, bc cannot also be a sub-region of ca, and `ca-yvr` cannot be shared as west-pnw-bc-swbc-yvr within the same region scheme. ca-yvr and west-pnw-bc-swbc-yvr are immutably different.

A chat scoped as one will not transport to the other despite intending to be the same region.

The only real solution that I personally see is that we have fixed IDs for regions that can be mapped to custom names.

(And obviously that regions don’t solve RF congestion.)

Good points though!

3

Isn’t this why they picked a flat scheme there?

Because simpler is better, I think I’d go with a flat scheme as well. Here, I think we’d have:

eastern
  qc
    yul (montreal)
    yqb (quebec)
    yhu (st-hubert / south shore)
    ymx (mirabel / north shore)
    ysc (sherbrooke)
  on
    yow (ottawa)
    yyz (toronto)
    ygk (kingston)
    ylk (barrie)

etc. This would be compatible with the west coast naming scheme (so, say, a traveller wouldn’t need to change that much when coming here) and would allow for some flexibility at the local level as well.

One concern i have is that i worry that for large regions like Montreal, we’re going to saturate even with a yul-specific region, which is one reason why i introduce those other IATA codes above for regions outside the city. Obviously, those are likely not going to be the cause of congestion - there’s more people in the center - but it might help them isolate from our congestion.

The question of how you scale places like YYZ and YUL is still open, for me. But perhaps that’s a problem we can solve later. In my mind, I could easily imagine a local region for my neighbourhood for example (villeray-rosemont), but it gets really tricky because we don’t have good names for the coverage LoRa provides here (we reach multiple neighbourhoods, even with a small repeater!).

2 Likes
4

It wouldn’t be fully compatible though, “ca” would be used for California. It wouldn’t be a big issue as there won’t be a direct connection between them and Canada, but it might still create some confusion.

Did anyone actually tried with hyphens to see whether that will be an issue on the packet that contains regions? I got a feeling it would still fit fine.

I believe cities would be a good addition too. It might not be for congestion purpose (though it might help), but simply as a convenience. You might not want to send a message outside of a city boundary.

2 Likes
5

yeah, if we want to stick with the PNW scheme, it would actually be east, not ca. :slight_smile: I’ll amend my comment above.

maybe the grouping is timezones? e.g. eastern, central, pacific, then also atlantic and newfoundland? :wink:

1 Like
6

We have 172 bytes to play with! So hyphens would fit fine, as long as we keep it short.

7

I think those would really easily conflict unless they’re scoped with hyphens, though :confused: e.g, the american folks might pick up eastern as a region with different markers than we would have it, and our meshes are increasingly interconnected in the GTA

8

This is another reason why I like hyphens, tbh! Because then we can scale as much as we want under the broad YUL umbrella with little coordination. This would also be fine if we all got under the IATA standard as the base, but I don’t know if folks are all behind that.

9

Just for context on the packket sizing issue, we have 172 bytes to play with for the regions packet. So assuming every region code is 17-characters long, each repeater can have a full 10 regions set (which is more than we’d probably want!), and some regions will be usually shorter.

So imo, the big point in favour of flat naming schemes is significantly more about UX than it is about technical limitations - in terms of packet sizes, hyphens or a flat naming scheme are fairly equivalent.

10

I’ve honestly been mostly assuming that the vancouver folks will mostly stick with the existing CascadiaMesh scheme for this reason, to be honest. I think trying to get an intentional overlap with their IDs would likely be messy unless we share some central assignment mechanism, which is gonna be tricky with how many potential US<–>CAN interconnects there are.

11

but that’s the thing: you want some overlap with the americans no, so you can talk with each other? so having a “eastern” zone, isn’t that precisely what you want?

then you segment on cities?

1 Like
12

could someone link to that scheme here? i don’t recall seeing it fly by yet.

13

it’s the PNW one, sorry for the confusion!

14

one of our american co-operators wanted us to namespace on NA- instead of CA- at the top level, which i think might be the solution there. i guess the issue i’m trying to get at is uncontrolled/non-standardized overlap - e.g, the WNY folks do not want to get lumped into an eastern region that assumes they’ll necessarily want to overlap with other east-coast meshes.

15

I really wish regions were actually a hierarchy in the routing system, it’d make this so much easier haha

16

Now that I understand better the lack of heirarchy, then its ok to go with east or eastern or whatever. Our plan is to use whatever you all assign as your top level, as a unique name on our repeaters, and then we will create a Canada/USA channel scoped to your top level, or your GTA level if thats more appropriate. I reached out to the Boston mesh, and it seems their top level is us.

17

My Vote is East. Any plan should assume that the US is involved, as this expands we’ll have more and more connection with them. Its nearly a given that Buffalo picks up our public messages now in the GTA.

Where I am torn, is the lack of granulary with YYZ. YYZ is MASSIVE population. When this takes off, might have to segment Hamilton and Niagara, Maybe even brampton, but Brampton doesn’t have IATA code, Unless we did Subsets.

East-YYZ-Tor
East-YYZ-Ham
East-YYZ-Peel
East-YYZ-Niag
East-YYZ-KW (or their own IATA code, whichever, but a stable link to them is inevitable, and they might want the YYZ traffic…
(At which point YYZ basically means ~75% of the population of Southern Ontario.)

18

The subsetting/hyphenation proposal was me very much thinking about our situation in the GTA, lol. Because yeah, we have a lot of possible subregions

19

This whole discussion reminds me of: https://what3words.com/

20

I think we’ll have the same problem in Montreal. In my mind, we’ll have to separate by neighborhood, but only eventually.

And it’s one of the things I like about the flat system: i don’t need to think right now “oh, is this East-YYZ-Peel or plain East-YYZ?” Right now I just think “This is East and YYZ, and maybe something else later”.

I’d love to understand better how regions work, but in my mind, each packet is bound to a single region, and repeaters are configured to relay all or only some of those regions.

Then, yeah, maybe I can see a space where a specific subset (say, “Peel” in your case) conflicts between the two cities, but then why would a long-range repeater even retransmit that in the first place?

1 Like