Hi, Some comments on two responses to the WGLC comments I sent earlier:
Comment 1: ---------- "(2) The default time is about every ten minutes. This is not sufficient in large-scale networks experiencing churn. However, it may be sufficient in small-scale, low-churn overlays in which reactive recovery is used. Therefore, I would modify this as follows: If reactive recovery is used, the default time is about every ten minutes." "BBL: I have absolutely no idea what type of network would be able to successfully run this protocol at all that would be overloaded by one update every 10 minutes. Worry about STUN keepalive traffic first." The point I was trying to make wasn't that a "chord-reload-update-interval" of 10 minutes can overload the network. Of course it can't. The comment was simply that when only periodic recovery is used, it is more difficult to recommend a default interval. This is because the appropriate stabilization interval depends entirely on the current churn rate in the network. Therefore, I was simply proposing to modify the text so that a 10-minute default interval is only recommended for reactive stabilization (in many cases, periodic stabilization is likely to require more frequent updates). To set the stabilization interval for periodic recovery, one could use the mechanisms specified in draft-ietf-p2psip-self-tuning-01. Comment 2: ---------- "Page 104-105, Section 9.6.4.2. Refreshing finger table (1) A peer SHOULD NOT send Ping requests looking for new finger table entries more often than the configuration element chord-reload-ping-interval, which defaults to 3600 seconds (one per hour). This is not sufficient in large-scale networks experiencing churn. However, it may be sufficient in small-scale, low-churn overlays in which reactive recovery is used. Therefore, I would modify this as follows: A peer SHOULD NOT send Ping requests looking for new finger table entries more often than the configuration element chord-reload-ping-interval. If reactive recovery is used, this defaults to 3600 seconds (one per hour)." "BBL: I'm sorry, but if one ping an hour can take down a network, the network is already down. This is silly, and it's already configurable." Again, the comment wasn't that one ping in an hour can take down the network. Of course it can't. I was simply trying to say that perhaps an one-hour default interval should only be recommended for reactive stabilization. Periodic stabilization is likely to require more frequent Pings. Cheers, Jouni Bruce Lowekamp wrote: > An -08 revision of the base draft has been posted. This draft > primarily addresses more of the WGLC feedback and subsequent feedback > on the mailing list. We have again updated > http://svn.resiprocate.org/rep/ietf-drafts/p2psip/wglc1-comments.txt > with responses to specific email. In particular, the new revisions > reflect the discussion on list about the xml configuration document, > etc. > > To address WGLC feedback, there is a very rough proposal for a DRR > option header in Section 5.3.2.4, which essentially proposes allowed > an option header that encodes an AttachReqAns for DRR purposes. We > believe the proposal (fully speced out) is sufficient to provide DRR > functionality in the protocol, although further extensions would be > required to determine when it is safe to use, etc, if someone desires > to use it in any case where it is not known to work (i.e. public > servers). As indicated in the text, this is a proposal that we would > like list and f2f discussion of before proceeding further. > > Bruce > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
