Add Next-Hop routing description

docs/about/overview/mesh-alg.mdx

@@ -4,14 +4,14 @@ title: Mesh Broadcast Algorithm
 slug: /overview/mesh-algo
 sidebar_label: Mesh Algorithm
 sidebar_position: 2
-description: "Discover the Meshtastic Mesh Broadcast Algorithm: a simple, yet effective routing protocol designed for off-grid communication using LoRa technology."
+description: "Discover the Meshtastic Mesh Broadcast Algorithm: an effective routing protocol designed for off-grid communication using LoRa technology."
 ---
 
 import ReactPlayer from "react-player";
 
 ## Current Algorithm
 
-The routing protocol for Meshtastic is really quite simple (and sub-optimal). If you want to test its theoretical performance, you can have a look at the [simulator](https://github.com/GUVWAF/Meshtasticator). The protocol is heavily influenced by the mesh routing algorithm used in [RadioHead](https://www.airspayce.com/mikem/arduino/RadioHead) (which was used in very early versions of this project). It has four conceptual layers.
+The routing protocol for Meshtastic is designed to support all kinds of different use-cases. Most importantly, it does not assume merely static nodes. If you want to test its theoretical performance, you can have a look at the [simulator](https://github.com/GUVWAF/Meshtasticator). The protocol is heavily influenced by the mesh routing algorithm used in [RadioHead](https://www.airspayce.com/mikem/arduino/RadioHead) (which was used in very early versions of this project). It has four conceptual layers and (since version 2.6) uses a different approach for broadcasts and direct messages.
 
 <div style={{ maxWidth: "800px", margin: "auto" }}>
   <ReactPlayer
@@ -46,7 +46,8 @@ This layer is conventional non-reliable LoRa packet transmission. A packet gener
 |  0x08  |                 4 bytes                  | Integer | Packet Header: The sending node's unique packet ID for this packet. Little Endian.                      |
 |  0x0C  |                  1 byte                  |  Bits   | Packet Header: Flags. See the [header flags](#packet-header-flags) for usage.                           |
 |  0x0D  |                  1 byte                  |  Bits   | Packet Header: Channel hash. Used as hint for decryption for the receiver.                              |
-|  0x0E  |                 2 bytes                  |  Bytes  | Packet Header: Reserved for future use.                                                                 |
+|  0x0E  |                  1 byte                  |  Bytes  | Packet Header: Next-hop used for relaying.                                                              |
+|  0x0F  |                  1 byte                  |  Bytes  | Packet Header: Relay node of the current transmission.                                                  |
 |  0x10  | Max. 237 bytes (excl. protobuf overhead) |  Bytes  | Actual packet data. Unused bytes are not transmitted.                                                   |
 
 #### Packet Header Flags
@@ -86,8 +87,9 @@ The default messaging provided by Layer 1 is extended by setting the `WantAck` f
 If a transmitting node does not receive an ACK (or NAK) packet after a certain expiration time, it will use Layer 1 to attempt a re-transmission of the sent packet. A reliable packet (at this 'zero hop' level) will be resent a maximum of three times. If no ACK or NAK has been received by then the local node will internally generate a NAK (either for local consumption or use by higher layers of the protocol). The re-transmission expiration time is based on the maximum time it would take to receive an (implicit) ACK, taking the airtime of the sent packet and any processing delay into account.
 For direct messages, the intended recipient will also send a real ACK all the way back to the original sender, but the device will only retransmit when it received no ACK at all.
 
-### Layer 3: Managed Flooding for Multi-Hop Messaging
+### Layer 3: Multi-Hop Messaging
 
+## Broadcasts using Managed Flooding
 Given the various use-cases and scenarios Meshtastic supports, most of our protocol is built around [flooding](<https://en.wikipedia.org/wiki/Flooding_(computer_networking)>), meaning that every node rebroadcasts a packet it receives, up till a certain hop limit. However, an important difference in Meshtastic is that before rebroadcasting, a node listens a short while to see if no other node already rebroadcasted it. If so, it will not rebroadcast. "Managed Flooding" is therefore a better term.
 
 The principle is as follows. If any mesh node sees a packet with a HopLimit other than zero, it will decrement that HopLimit and attempt to rebroadcast on behalf of the original sending node. In order to promote letting nodes that are further away flood the message, such that the message eventually reaches farther, the contention window (see Layer 1) for a flooding message depends on the Signal-to-Noise Ratio (SNR) of the received packet. The CW size is small for a low SNR, such that nodes that are further away are more likely to flood first and closer nodes that hear this will refrain from flooding. An exception to this rule is for the `ROUTER` and `REPEATER` roles, that have a higher priority to rebroadcast and will do so even if they hear another node rebroadcasting.
@@ -101,6 +103,13 @@ Since node 1 heard the rebroadcast by 2, it will not rebroadcast again. Node 3 h
 
 ![Mesh algorithm example](/img/SNR_based_flooding.webp)
 
+## Direct messages using Next-Hop routing
+
+Since version 2.6, Meshtastic uses a different approach for direct messages. Initially, the managed flooding approach as mentioned before is used to reach the destination.
+We'll then keep track of the node(s) that are trying to relay the packet for us. If upon a successful delivery, a response comes back (e.g., a NodeInfo response, acknowledgment or traceroute) and the node that relays this towards you was also (one of) the node(s) that relayed the original packet, it will be denoted as next-hop from now on. This means that instead of letting all nodes try to relay the packet, only the node for which the next-hop byte matches will. Note that this is determined per hop, so if there is an asymmetric link or a node on older firmware in between, managed flooding will be used on this hop. When a node moves, or RF conditions change, it might be the next-hop is not valid anymore. Therefore, a node will always fall back to managed flooding at the last retransmission attempt if it doesn't hear its next-hop relay.
+The procedure is visualized in the following diagram:
+![Next-Hop Routing procedure](/img/NextHopRouting.svg)
+
 ### Regular Broadcast Intervals
 
 Without additional modules configured, nodes will produce three different types of regularly intervaled traffic as part of the mesh: