[dnssd] Re: Scalability of draft-ietf-dnssd-srp-replication in a mesh

[James Hanley <[e-mail]>]

Definitely not every node for all the services, would want opportunistic since the underlying mesh can easily miss frames due to a number of reasons like being off channel - in most deployments the mesh will be 4000 nodes of MCU constrained radios so for most services interested would be only a few hops away and is ideal for the memory footprint and limiting the traffic across the mesh, then for a handful set of services available to a large set of nodes, and for a rare few services to be available to all.

-Jim

On Sep 3, 2024, at 2:42 PM, Ted Lemon <[e-mail]> wrote:



The key insight in SRP replication is that each host is authoritative for its own data. So you aren't replicating a zone, as with a zone transfer, or you could say that each hunk of data you get from a host is a zone. You can use the key tag and received time to differentiate between stale and new data: if the names and tags match, and the date is newer, the data is newer.

Do you want every node to know about every other node, or do you want to be more opportunistic?

On Tue, Sep 3, 2024 at 12:31 PM James Hanley <[e-mail]> wrote:

I’ve been digging into rev 2 of draft-ietf-dnssd-srp-replication which for small networks with minimal multi-link cases would work, but I have concerns in a mesh where each node could act as a route to the next.  It a case where most nodes are outside of RF range of another and must route with an intermediary, if every node can act as a SRP replication server for all other nodes as chosen, there’s still a versioning and synchronization that occurs:


+---+         +---+           +---+         +---+       
|EP0| ------  |EP1|   ------  |EP2|  ------ |EP3|       
+---\         |---\           ----\         |---\       
     |       /     |         /     |       /     |     
     \      /      \       -/      \      /      \     
      \     |       \     /         \     |       \     
       |---/         |---/           |---/         |---+
       |EP4-----------EP5-------------EP6-----------EP7|
       /---|        /+----           /---|         |---+
      |     \      |      \         |     \       /     
      /      \     /       \-       /      \     /     
     /       |    |          \     /       |     |     
+---|         \---+           \---|         \---/       
|EP8-----------EP9-------------EPa-----------EPb|       
+---\         |---\           ----\         |---\       
     |       /     |         /     |       /     |     
     \      /      \       -/      \      /      \     
      \     |       \     /         \     |       \     
       |---/         |---/           |---/         |---+
       |EPc-----------EPd-------------EPe-----------EPf|
       +---+         +---+           +---+         +---+
For example, end-point node EPf could use EPe or EPb as its replication server, but it’s unclear which records should be replicated based on use-case, and based on my interpretation of the draft would replicate all records and bump the version.
For a small number of nodes, this may be acceptable, but for memory constrained MCU based radios and mesh networks on the order of 4096 endpoint nodes would prove unsalable.

Is there something writhin the application level of SRP to allow a network level concept akin to TTL so a service may indicate how “far” to throw a publication and/or conversly a query to throw a query for a number of hops? It could be done at the network level, but every service on an individual end-point node could be unique on how aggressive it needs to be to find a service which should be hated and controlled at the application level.
-Jim
_______________________________________________
dnssd mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]