Hi Martin, please, see below.
On 20.08.22 at 08:18 Schanzenbach, Martin wrote:
Before we submit it to the Independent Stream (or go to dispatch), we wanted to touch ground with you if you or a WG you could point us to would be interested in our specification on R5N, a protocol for randomised recursive routing for restricted-route networks. [1] It is a distributed hash table protocol and we currently have two independent implementations. The document is not finished but in a readable state and feedback is very welcome either way.
I quickly browsed over it and from my point of view it's actually (and unfortunately) not in a readable state. I suggest to expand the introduction by a motivation that clearly states the requirements and assumptions. Furthermore, consider restructuring the document. Better explain the overall protocol on a higher level (maybe by giving an example) rather than doing a deep dive into the API first, e.g., it would be good to describe how a node chooses the next hop for a random walk instead of requiring to read the description of
SelectRandompeer. Another example is Section 7 that appears quite unmotivated at that point. Here is a list of potential points to consider for the next version: * The current draft misses much of the background and motivation, although in the referred paper the missing information is present. * What is the attacker/adversary model that you assume? There are lots of related works to mitigate certain attacks (e.g., S/Kademlia), why aren't they suitable? * What is a restricted route environment? * The first sentence of section 5 is broken. * In section 8 is written: "Given an estimated network size N, the peer selection for the first N hops is random. After the initial N hops, peer selection follows an XOR-based peer distance calculation." This would be really inefficient. I guess what is meant here is after the first T hops with T=log n, where n is the network size in number of nodes. So basically, it's a random walk for log n hops and afterwards you are using the XOR metric as in Kademlia * I don't understand why you actually need the bloom filter to prevent "routing loops". I would rather speak of cycles here. They are inefficient, but it's not like in IP routing where packets may cycle endlessly until the hop count is exceeded. The probability for getting cycles should be relatively small in larger topologies. When you switch from the random walk to the XOR metric based routing there will be no cycles anymore. * It is not clear how you could protect against targeted sybil attacks as the XOR metric is unique in determining the node that is responsible for a certain key. So the prior random walk phase is not a protection against this. It seems that you argue as in the original Kademlia paper in section 10. * What about state exhaustion attacks against the pending table? * It is unclear to me why the condition "Peers with a positive test against the peer Bloom filter |B| are not considered." in SelectClosestpeer is necessary or even useful. Routing according to the XOR metric is loop free. If the closest node, however, was already part of the prior random walk, how could a query ever reach its correct responsible node? * Network size estimation is obviously required. This could be integrated into the protocol itself as the deepest k-buckets allow for an estimation. Sometimes L2NSE is used and at another location NETWORK_SIZE_ESTIMATE is used. This should be made consistent. I also find it odd to let the underlay do it since the peer-to-peer overlay may be only a small fraction of all available underlay nodes. * What is the recommended size for k? Also k=20 as in Kademlia? k influences the number of potential next peers for the random walk. So if k is too small, the walk would be more predictable. * I find it quite useful to conceptually separate the functions of key-based routing and data replication. * For recursive Kademlia routing there is also prior work: R/Kademlia (https://ieeexplore.ieee.org/document/5680244) Cheers, Roland
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
