[Feature Request]: CLIENT_BASE should not decrement hop count for favorites

[jschrempp]

Platform

Cross-Platform

Description

A CLIENT_BASE node will assist a favorite node by always rebroadcasting messages to or from a favorite node. The intent is that these favorite nodes are close by and in a disadvantaged radio location.

When CLIENT_BASE rebroadcasts these messages it decrements the hop count. I suggest that it does not decrement hop count for these messages. This would allow nodes to set a lower hop count for their messages, thus reducing congestion.

As an example: A friend and I are 3 hops away in the normal mesh but reception is very spotty. Now I have installed a CLIENT_BASE in the attic and changed my personal node to CLIENT_MUTE. My friend as done the same. For us to connect we have to set our default hop count to 5 because each of our CLIENT_BASE nodes swallow a hop. If my suggestion was implemented then we could leave our default hop count at 3 and still be connected.

I hope my suggestion is clear. Thanks for listening.

[korbinianbauer]

My understanding is that CLIENT_BASE is supposed to act as a sort of "remote antenna" for nearby nodes that can't be placed in advantageous positions themselves. Those nearby nodes basically become slaves to that CLIENT_BASE node, that talks to the mesh on their behalf.

--> Not eating hops makes sense, but only at the very beginning and the very end of the route.

---

So, not reducing the remaining hops when retransmitting packets from "their" fav'd slave clients seems reasonable to me, but only if the packet is received directly from such a slave client. "Received directly" means received with hop_limit == hop_start.

Packets to their fav'd slaves on the other hand should decrement hop_limit as usual unless received with no remaining hops (hop_limit == 0). In that case, the message should be retransmitted with hop_limit == 0 again.

Whenever CLIENT_BASE doesn't decrement hop_limit, it should increment(!) hop_start.

In your example, it would work this way:

1. The sending CLIENT_MUTE sends a message with hop_limit == 3.
2. CLIENT_BASE on the sending side retransmitts without decrementing hop_limit.
3. The packet reaches the public mesh still with hop_limit == 3, using all 3 hops there.
4. The CLIENT_BASE on the receiving side receives the packet with hop_limit == 0, but still retransmitts, again with hop_limit == 0.
5. The packet successfully reaches your CLIENT_MUTE.

Result:

• The message sent with a normal hop_limit == 3 initially made it to the recipient, even though the route includes 3 "normal" hops + 2 CLIENT_BASE hops.
• Everyone along the way can accurately see how many hops that packet has actually travelled.

---

Why rebroadcast packet with hop_limit == 0 instead of just not decrementing hop_limit?

Either way what could happen here is that a bunch of CLIENT_BASEs that hear each other and all fav'd the same bunch of Clients (e.g. operated by a group of friends) would keep retransmitting a packet that has already gone through more hops than usual.

These additional retransmissions would be relayed even further by other nodes, but shouldn't.

By decrementing hop_limit, but still retransmitting at hop_limit == 0, the artificial extension of retransmits is applied if necessary, but it will never produce packets with seemingly remaining hop-budget that actually went through many hops already.

So while this packet might still get retransmitted by all the CLIENT_BASE nodes of the friend group after using up the original hop_limit of 3, no other nodes would retransmit them beyond that.

What if both sender and receiver are fav'd`?

If the packet was received directly from a fav'd node (hop_limit == hop_start) do not decrement. Otherwise (hop_limit < hop_start) decrement, but retransmit even when receiving with hop_limit == 0.

Why increment hop_start?

• To keep the calculation of hops travelled accurate for each packet.
• To make sure another CLIENT_BASE knows this retransmission is not a direct reception (which would have hop_limit == hop_start) from a fav'd node

[jschrempp]

@korbinianbauer I agree with what you say. Makes good sense.

[ford-jones]

Was this behaviour not already added by https://github.com/meshtastic/firmware/pull/7992 ?

[korbinianbauer]

Was this behaviour not already added by #7992 ?

If I understand #7992 correctly, with this CLIENT_BASE decides to not decrement hops if the previous node is an infrastructure node and favorited.

In OPs scenario this saves at most 1 hop, and only if the route between the two involved CLIENT_BASEs starts and ends with known infrastructures nodes. If there's e.g. only CLIENTs relaying the packets between the two CLIENT_BASEs, they will decrement as per usual.

This request asks CLIENT_BASE to not decrement the hops when talking directly to a favorited node (which is CLIENT_MUTE, not an infrastructure role)

[jschrempp]

This request asks Client_Base to not decrement the hops when talking directly to a favorited node (which is Client_Mute, not an infrastructure role)

correct

[h3lix1]

In #7992 we left off the first hop since it went down various codepaths that included things like neighbor info if limit == start.

It wasn't really an issue with the client_base node itself, but the later nodes after it seeing the message as the first hop.

The challenge is if the packet never decrements and the packet 0-hops through the entire network. An interesting idea, but not one we wanted to test out :)

I guess we could explore the idea of removing hops altogether and lean heavily on next_hop routing and packet deduplication, but we need to add a couple more bytes to next_hop to avoid name collisions. That would be a v3.0 kind of change, and one that will get some push back.. especially for packets we want to die early like position and telemetry.

Maybe a hybrid where routed/message packets are 0-cost but telemetry and position packets always cost a hop.

I'm just a contributor, so take this all with a grain of salt.

[github-actions[bot]]

This issue has not had any comment or update in the last month. If it is still relevant, please post update comments. If no comments are made, this issue will be closed automagically in 7 days.