Hi Bruce, > > Two comments I have after reading through this draft: > > - a minor comment on 1.1.a, I think the BCP for failed node > recovery > would be to re-add "recovered" neighbor/leaf set peers on a > periodic > basis (if you have no other choice), but not to re-add recovered > routing > table peers
What you said may be true. But this issues may depend on the specific p2p algorithm. If it is a bamboo algorithm with candidate peer for each entry, then we can say "re-add recovered routing table peers" also. Thanks for pointing this out. > > - I think the "traceroute" idea is interesting, but I have mixed > feelings about it. On the one hand, it offers the capability of > giving > a rather quick diagnostic answer to which hop is failing. On the > other > hand, it seems like it's in danger of being a "please DoS me" bit. > Effectively, the overlay is going to have to route and the > requesting > peer receive Echo Response messages at 1/3 the sending rate of the > peers. Especially given the load this might impose on the > overlay, I > think it's safer to implement traceroute the conventional way > starting > with the ttl set to 1 and receiving a response from each peer as > the > message exceeds its ttl, then increasing ttl by one. It takes > longer, > but it has the virtue of not being an amplification attack. Bruce, what you propose is interesting an works. Now suppose in a Chord overlay with one million peers, if the successor list length is 32, then if my memory is correct, the average hops for a message is 1/2 * (20-5) = 7.5. There are not so many messages to the source peer. Additionally, the traceroute message is not initiated so often. It is only initiated when a peer wants to diagnose where the problem happens for its failed routing, or t o collect some information of the overlay for other purposes. So traceroute message works. The traceroute will not amplify attacks itself. In p2p overlay, each peer can reply to the source node when it receives a message unless you can have a mechanism to only allow the destination peer to repond. However, for diagnostics and error report reasons, you can't do that limit. Do you satisfy with my clarification? Best Regards -Song Haibin > > Bruce > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
