Hi Roland, > On 22. Aug 2022, at 23:34, Bless, Roland (TM) <[email protected]> wrote: > > 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.
We know that it is in an early, unpolished state but we thought it makes sense to collect feedback and possibly generate interest as soon as possible. Thanks for reading it and your constructive comments below. We will start addressing them asap in the next version. BR Martin > 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 > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
