Subject: [P2PSIP] new base-08 draft posted, more revisions, DRR proposal

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 8 Mar 2010 17:02:42 -0800

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

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 8 Mar 2010 22:29:07 -0500

So it looks like you went with not having the type flag in the
bootstrap node option, but I also don't see anything in the
configuration listing the security mechanism.

How does a peer know which security mechanism is being used (i.e., how
does one indicate a mechanism other than TLS, and thus a non-TLS
connection?) I expected to see either the flag or something lower in
the XML indicating what security protocol the network used.

It might have missed something somewhere that specifies how to do it.
If so, can you explain how to do a system that chooses to use another
mechanism? We can't just ignore this -- many folks on the list have
raised several reasons for TLS to me mandatory to imp but allow other
security mechanisms. We need to be able to do that somehow in the
bootstrap file.

Thanks,

David (as individual)

On Mon, Mar 8, 2010 at 8:02 PM, Bruce Lowekamp <[email-masked]> wrote:
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>

---

From: Jouni Mäenpää <[email-masked]>
Date: Tue, 23 Mar 2010 07:41:39 -0700

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