kgess-mirror/matrix-pinecone
1
0
Fork 0
mirror of https://github.com/matrix-org/pinecone.git synced 2026-01-16 23:00:32 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update docs with hybrid routing info. (#69)

Browse source
This commit is contained in:
devonh 2022-10-03 13:59:01 +00:00 • committed by GitHub
parent 2ce51dd4a4
commit d05e7fbb5d
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 13 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
docs/introduction/3_frame_forwarding.md
View file

@ -13,10 +13,22 @@ Pinecone separates frames into two types: **protocol frames** and **traffic fram
Protocol frames often have specific rules governing their behaviour, including inspecting and processing the protocol control messages at intermediate or destination hops, and which routing scheme should be used to forward them onwards.
Traffic frames, on the other hand, are always forwarded using SNEK routing or tree routing (typically the former) and are not required to be otherwise inspected by an intermediate node.
Traffic frames, on the other hand, are always forwarded using SNEK routing or tree routing and are not required to be otherwise inspected by an intermediate node.
If a suitable next-hop is identified, the frame will be forwarded to the chosen next-hop peer.
## Hybrid Traffic Routing
**Traffic frames** are forwarded using a combination of both SNEK routing and tree routing. This is done to reduce the overall network stretch while still providing a reliable transport mechanism during times of high network churn.
Traffic is initially routed using SNEK routing to the destination and the frame header is populated with the sending node's tree coordinates. Upon reaching the destination, the receiving node caches the sending node's tree coordinates.
When sending traffic, a node will check for matching cached tree coordinates and populate that information in the frame header if possible. The presence of destination coordinates in a traffic frame lets other nodes know to attempt forwarding using tree routing.
When forwarding traffic frames using tree routing, if any node along the path fails to find a suitable next-hop then the destination coordinates should be removed from the header and SNEK forwarding should be attempted to reach the destination.
To assist with adjusting to changing network conditions, individual cached coordinates should be removed if they ever become too old. Also, all cached coordinates should be removed if the tree root changes.
## Watermarks
In the case of **traffic frames** there is also a watermark used to help detect routing loops. Watermarks only factor into the equation when next-hops are selected from the SNEK routing table as these routes can become stale much more quickly than route information obtained through the global spanning tree. The watermark ensures that forward progress towards a given key is being made and that a packet will never be forwarded onto a path that is worse than the path selected at the last hop. If any node along the path does not know of either the same best destination node or a closer destination node, then the packet has reached a location where further forwarding could result in routing loops.