I had some small comments on Section 9. 1. Why do we wait for replies from the replicas to send back STORE Response. This will increase the amount of state on originating nodes from waiting around for all this to get done. A STORE should be deemed complete when the owning node has received and stored the data itself
2. Are there further thoughts on defining reactive versus proactive repair for the base topology plugin? As Rhea2004 showed, it may be useful to have a periodic repair in stead of reactive. This could be set statically and configurable through the overlay configuration document based on the overlay deployment scale and expected churn. 3. The section says that every time a connection is lost, the peer should remove the entry from the neighbor table and replace with best match from the routing table. Shouldn't we try to re-establish connection or give some guidelines on when to remove an entry after some number of re-establishes don't work? Thanks Saumitra _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
