Subject: [p2p-sip] draft-bryan-sipping-p2p-03

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Sun, 22 Oct 2006 23:46:19 -0400

I've sent in draft-bryan-sipping-p2p-03.  Until it is officially
posted you can get a copy at

http://scm.sipfoundry.org/rep/ietf-drafts/bryan/draft-bryan-sipping-p2p-03.txt
or
http://scm.sipfoundry.org/rep/ietf-drafts/bryan/draft-bryan-sipping-p2p-03.html

major changes with this revision include:

- new terminology from the concepts draft
- many details have been fixed after implementation experience
- the initial formation explanation is clearer with inclusion of the
use of the null predecessor
- a security model based on sip-identity is now used and the security
section has been significantly revised
- a detailed example describing the formation of a 3-node system is included

Many thanks to everyone who sent us comments on the previous version.
We've tried to include as many suggestions and corrections as
possible.

As usual, we welcome feedback either directly or to the list.

Bruce

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Mon, 23 Oct 2006 10:11:06 +0200

> - a detailed example describing the formation of a 3-node system is included

Bruce:  I like the new flavour brought by the official terminology :-)

However I cannot still find a convincing description of the procedure
for dealing with node failures.  In our implementation, when a peer
performing periodic stabilization detects his first successor's failure,
it sends a third-party unregister to his second successor in behalf of
the dead peer, casing the receiving peer to update his predecessor.  In
the current version of the draft I cannot find an analogous mechanism
and I cannot understand how fault tolerance is achieved.

Is it just me, or is it really an open issue?

-- 
Ciao,
Enrico

Ahem.. Sorry, the notice below is not my fault :-(
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster at telecomitalia.it.

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Mon, 23 Oct 2006 07:21:56 -0400

Enrico,

I think one of the open issues is whether we should support a
third-party unregister; actually, I don't think we should support that
for security reasons, but we should support one peer telling another
to check on the status of one of its neighbors because it received a
302 to a node that timed out.

This winds up being intertwined with NAT/Firewall traversal---I think
they should be the same signal because a peer can't really know why
its message failed.   So right now when a communication fails you
resend your message to the node that timed out routed through the node
that redirected you to that node.  If you keep that node on the return
path, it will know whether the node is still there or not.  This is
currently described in 9.7 and 9.8, although you're right that I
didn't explain the link between them the way I should have.

Bruce

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Mon, 23 Oct 2006 17:10:13 +0200

> 302 to a node that timed out.

The advantage of a third-party unregistration mechanism is that it
allows peer to atomically update their successor's predecessors.  OTOH,
I agree that it has many security issues.

> didn't explain the link between them the way I should have.

It would be useful to have a section describing what happens when a peer
detects the failure of its successor and how its second successor
updates the predecessor field.  That is the most critical procedure,
because the consistency of the DHT heavily depends on it.

-- 
Ciao,
Enrico

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it