Hi, > 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.
Just wanted to point out that the Self-tuning DHT draft uses periodic repair: http://tools.ietf.org/html/draft-maenpaa-p2psip-self-tuning-00 -Jouni Das, Saumitra wrote: > 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 _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
