Subject: [P2PSIP] Merge of ASP and RELOAD - Version Notification for draft-bryan-p2psip-reload-02

From: Cullen Jennings <[email-masked]>
Date: Sun, 18 Nov 2007 21:17:04 -0800

The various authors of ASP and RELOAD have managed to get these two  
proposal merged together into one and we are pretty happy with the  
result.

You can find it at
http://www.ietf.org/internet-drafts/draft-bryan-p2psip-reload-02.txt

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: November 18, 2007 8:57:03 PM PST
> To: [email-masked]
> Cc: [email-masked], [email-masked],  
> [email-masked]
> Subject: New Version Notification for draft-bryan-p2psip-reload-02
>
>
> A new version of I-D, draft-bryan-p2psip-reload-02.txt has been  
> successfuly submitted by Cullen Jennings and posted to the IETF  
> repository.
>
> Filename:	 draft-bryan-p2psip-reload
> Revision:	 02
> Title:		 REsource LOcation And Discovery (RELOAD)
> Creation_date:	 2007-11-18
> WG ID:		 Independent Submission
> Number_of_pages: 96
>
> Abstract:
> This document defines REsource LOcation And Discovery (RELOAD), a
> peer-to-peer (P2P) binary signaling protocol for usage on the
> Internet.  A P2P signaling protocol provides its clients with an
> abstract hash table service between a set of cooperating peers that
> form the overlay network.  RELOAD is designed to support a P2P
> Session Initiation Protocol (P2PSIP) network, but it can be utilized
> by other applications with similar requirements by defining new
> usages that specify the data types that must be stored for a
> particular application, such as location for SIP.  RELOAD defines a
> security model based on a certificate enrollment service that
> provides unique identities.  NAT traversal is a fundamental service
> of the protocol.
>
> This draft represents a concrete proposal for the P2PSIP Peer
> Protocol.  The protocol described here builds on the lessons and
> experiences from designing and implementing the dSIP, ASP, and RELOAD
> protocols and is a merge of features from RELOAD-01 and ASP.
>
>
>
> The IETF Secretariat.

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Michael Chen <[email-masked]>
Date: Mon, 19 Nov 2007 20:00:44 -0800

Hi,

Compared to the classic Chord, the modified Chord algorithm mentioned in 
this draft advocates an inverted finger table in which n.finger[1] is 
the successor of n + (2^(m-1)), where m is the size of the ID address 
space. Is there a formal paper presenting this modified algorithm?

Thank you

--Michael

Cullen Jennings wrote:
>> Cc: [email-masked], [email-masked], [email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Nov 2007 21:01:42 -0800

So classic cord has the finger table entries set as

(all math is mod 2^m here so I will omit the mod 2^m parts)

finger[k] =  n+2^(k-1) for 1 <= k <= m

we have the same entries but in the reverse order in the finger  
table. The chord algorithm is still the same in that the same peer is  
still the one used next - i.e. we search the array in the opposite  
order as chord did so as to keep the algorithm the same as chord. The  
only thing that really changed is the layout of bits in memory not  
the algorithm.

The reason this was done is that when you want to truncate the finger  
table and have less finger table entries than the value of m, then  
the original chord required you to remove entries from the beginning  
of the finger table while if with the reverse order removes entries  
from the end of the table. In implementing it, we found removing from  
the beginning with offset seemed fairly confusing and  reversing it  
made it easier to not have weird off by one bugs and such.

It's really not a big deal as it is only an implementation detail and  
not something that changes any of the over the wire behavior. If  
folks felt we should write up the other way we could easily do that -  
we were just trying to make it easy for implementations with  
truncated tables.

Cullen <with my individual hat on>

---

From: "Jan Seedorf" <[email-masked]>
Date: Tue, 20 Nov 2007 14:57:28 +0100

Dear authors of the new RELOAD draft (02),

I have some comments on the security section:

- In section 7.3. it is specified that the root-node of some resource ID (i.e., the node responsible for storing the resource) is responsible for replication. In section 10.5.4. "residual attacks" you mention that a query node can check at replica roots for some resource if the root-node does not respond. I see the following security problem: if the root-node is originally faulty at storage time (e.g., compromised), it will likely store invalid (though detectable) or no resources at all at the replica roots. As you well describe the only issue here is availability. However, I think that any countermeasure involving replication must involve distributed storage done by the query node itself (for reasons described above). Replication should not be the responsibility of the root-node.

- Section 10.6.1.: You assume a central authority and indeed this solves many security problems. It limits Sybil attacks and Eclipse attacks. This is well-described in the draft. However, there are other attacks on DHT routing. Join-leave attacks can be used by the attacker to chose its location in the DHT despite a central node-ID assignment authority (see C. Scheideler, "How to Spread Adversarial Nodes?: Rotate!," Proc. 37th Annual ACM Symp. Theory of Comp., Baltimore, MD,pp. 704-13, for a formal analysis of the node-ID assignment problem in DHTs and join-leave attacks). Additionally, even if there are no Sybil or Eclipse attacks, adversary nodes (though well certified through the admission authority, e.g., because they have been compromised) can simply drop messages. This severely degrades the lookup success rate in a DHT. Countermeasures against these attacks may well be out-of-scope for P2PSIP standardisation, I just feel the section is misleading in the sense that it suggests that a central authority protects against all threats on DHT routing.

 - Jan

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: Monday, November 19, 2007 6:17 AM
> To: P2PSIP WG
> Subject: [P2PSIP] Merge of ASP and RELOAD - Version 
> Notification fordraft-bryan-p2psip-reload-02 
> 
> 
> The various authors of ASP and RELOAD have managed to get 
> these two proposal merged together into one and we are pretty 
> happy with the result.
> 
> You can find it at
> > form the overlay network.  RELOAD is designed to support a 
> P2P Session 
> > Initiation Protocol (P2PSIP) network, but it can be 
> utilized by other 
> > applications with similar requirements by defining new usages that 
> > specify the data types that must be stored for a particular 
> > application, such as location for SIP.  RELOAD defines a security 
> > model based on a certificate enrollment service that 
> provides unique 
> > identities.  NAT traversal is a fundamental service of the protocol.
> >

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 20 Nov 2007 09:07:25 -0600

I agree with Jan's first point below, and it's broader than RELOAD-02 - I 
don't see how replication works if the root node is responsible for all 
aspects of replication, and if the query node has to understand replication 
in order to locate replica roots, I'm not sure what problem is being solved 
by making the root node responsible for replication in the first place.

Thanks,

Spencer

From: "Jan Seedorf" <[email-masked]>

- In section 7.3. it is specified that the root-node of some resource ID 
(i.e., the node responsible for storing the resource) is responsible for 
replication. In section 10.5.4. "residual attacks" you mention that a query 
node can check at replica roots for some resource if the root-node does not 
respond. I see the following security problem: if the root-node is 
originally faulty at storage time (e.g., compromised), it will likely store 
invalid (though detectable) or no resources at all at the replica roots. As 
you well describe the only issue here is availability. However, I think that 
any countermeasure involving replication must involve distributed storage 
done by the query node itself (for reasons described above). Replication 
should not be the responsibility of the root-node.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Nov 2007 07:16:20 -0800

At Tue, 20 Nov 2007 14:57:28 +0100,
Jan Seedorf wrote:
>  section 7.3. it is specified that the root-node of some resource ID
>  (i.e., the node responsible for storing the resource) is
>  responsible for replication. In section 10.5.4. "residual attacks"
>  you mention that a query node can check at replica roots for some
>  resource if the root-node does not respond. I see the following
>  security problem: if the root-node is originally faulty at storage
>  time (e.g., compromised), it will likely store invalid (though
>  detectable) or no resources at all at the replica roots. As you
>  well describe the only issue here is availability. However, I think
>  that any countermeasure involving replication must involve
>  distributed storage done by the query node itself (for reasons
>  described above). Replication should not be the responsibility of
>  the root-node.

Yeah, this is sort of a thinko in our writeup. We intend to
move to explicit writes to each replica by the storing
node and just ran out of pre-draft time :)

> Section 10.6.1.: You assume a central authority and indeed this
> solves many security problems. It limits Sybil attacks and Eclipse
> attacks. This is well-described in the draft. However, there are
> other attacks on DHT routing. Join-leave attacks can be used by
> the attacker to chose its location in the DHT despite a central
> node-ID assignment authority (see C. Scheideler, "How to Spread
> Adversarial Nodes?: Rotate!," Proc. 37th Annual ACM Symp. Theory
> of Comp., Baltimore, MD,pp. 704-13, for a formal analysis of the
> node-ID assignment problem in DHTs and join-leave
> attacks). Additionally, even if there are no Sybil or Eclipse
> attacks, adversary nodes (though well certified through the
> admission authority, e.g., because they have been compromised) can
> simply drop messages. This severely degrades the lookup success
> rate in a DHT. Countermeasures against these attacks may well be
> out-of-scope for P2PSIP standardisation, I just feel the section
> is misleading in the sense that it suggests that a central
> authority protects against all threats on DHT routing.

I agree  tha there are significant residual attacks. We'll see
whwat we can do to make this text clearer. IF you wanted to
suggest some text that would be great.

Thanks,
-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Nov 2007 07:17:38 -0800

At Tue, 20 Nov 2007 09:07:25 -0600,
> by making the root node responsible for replication in the first place.

Well, the replication strategy described in RELOAD-02 is very efficient
from the perspective of storing overhead. It's also transparent to
failures of the root node after replication is finished. It's just
not very secure.

-Ekr

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 20 Nov 2007 10:27:00 -0500

One problem with having the just the source place the replicas is what
happens when the source is offline.

For example, I am the source. I send out the data to the original and
the replica. Then log off.

If one peer fails, then that replica is gone for good unless I come
back up to refresh them, so over time, offline information could
"decay" in the presence of a slow peer failure rate.

Some sort of hybrid might make more sense...but there is (clearly) a
security point that needs to be considered here.

David (as individual)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 20 Nov 2007 10:27:27 -0500

> - In section 7.3. it is specified that the root-node of some resource ID (i.e., the node responsible for storing the resource) is responsible for replication. In section 10.5.4. "residual attacks"…

Jan and Spencer,

We agree.  7.3 has this note at the end:

This redundancy algorithm breaks if the storing node is malicious and
does not store the data in the replica set. Applications which wish to
have defenses against that must explicitly store multiple copies of
the data with separate peers. [[OPEN ISSUE: Where should a replication
algorithm of this type be described? The DHT? The storage layer? The
usage?]]

Basically, we're aware that this form of redundancy only solves the
problem where the responsible peer fails by ensuring that the new
responsible peer (once it realizes the failed peer is gone) has a copy
of the resource.  It doesn't protect against a wide variety of other
attacks, including routing.  We fully agree there is a need for
additional replication, and reload-01 specified to create random
replicas by appending a replica number to the resource name, but we
were unable to decide what layer should be responsible for that
service in the current architecture, so we left it listed as an open
issue.  It's certainly not an open issue implying there's a question
of whether it needs to be solved, it's just a question of what layer
should be responsible for solving it.

Bruce

> - Section 10.6.1.: You assume a central authority and indeed this solves many security problems. It limits Sybil attacks and Eclipse attacks. This is well-described in the draft. However, there are…

Certainly we don't want to imply that the central authority protects
against all routing attacks.  Better replication helps, among other
things.

Bruce

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 20 Nov 2007 18:43:44 -0500 (EST)

As pointed, the replication mechanisms can be classified as:

1) Publisher (source) oriented
2) Responsible peer (root node) oriented

Both publisher and responsible nodes can determine the node replica set, 
i.e., the list of nodes on which to replicate. In addition to security, 
factors such as churn rate, uptime and load of a node also impact the 
choice of replica set.

An artifact of using DHTs is that the publisher and responsible peers are 
generally different. Since nodes churn, the responsible peer may change. 
In an unstructured (non-DHT) overlay, the publisher node will likely be 
responsible for determining the replica set.

The question of how many replicas to maintain is best left to the overlay 
operator. As mentioned above, the number of replicas depends on the 
churn rate, availability guarantees, and security among others.

The question whether to maintain replicas after source node fails is best 
left to the overlay operator.

-salman

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 21 Nov 2007 09:49:32 -0500

Sort of related to this discussion is the open question of what layer
does replication occur? There are several alternatives:

* Do it on a per-pluggable DHT level. In otherwords, each DHT that is
defined specifies a replication mechanism. This may be very desirable
if someone has a very clever DHT design with a specific replication
scheme, but might remove operator flexibility and make it difficult
for specific applications to have alternate schemes (although they
could layer it on top of the DHT provided scheme)

* Do it at the application level instead. Each usage specifies what
replication it would like (how many, where, do you do source node
replication if the source node fails, etc.) The advantage to this is
that it can be much more tailored for the use of the application, but
if one overlay is supporting multiple usages, then things stored in
common to each usage (maybe the user's public key, for example, which
different applications may want) could conceivably be replicated in
more places than really needed. It also means a clever DHT replication
idea isn't as useful, since there would still be replication above it
at the app level anyway (although I guess you could just turn off the
application level replication in that case anyway)

* There might be other options...

This is definitely a good open issue...I'd love to see a bit of
discussion about what others think the pros and cons are here...

--David (as individual)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: Michael Chen <[email-masked]>
Date: Wed, 21 Nov 2007 07:59:09 -0800

Hi,

I have a practical suggestion for the forwarding header. The last two 
paragraphs of section 4.1 of the draft describe how the Route-List 
shrinks while Via-List grow as the Reload message passes through 
intermediate peers.  If you flip the order of these two lists such that 
Via-List comes first followed by the Route-list:

   24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Via       |    Route      |                               |
      |     List      |      List     |            Flags              |
      |     Length    |     Length    |                               |
   28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                          Via List                           //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                          Route List                         //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                          Route Log                          //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Then as the message passes the pre-selected list of peers in Route-list, 
intermediate peer can simply increment the via-list-length field and 
decrement the route-list-length field, in effect shrink the route-list 
by 1 while growing the via-list by 1 without touching the actual 
Via-List and Route-list that follows.

By the way, I do believe the header should indicate the size of the IDs.

Thanks

--Michael

---

From: "Jan Seedorf" <[email-masked]>
Date: Thu, 22 Nov 2007 14:58:09 +0100

Dear David,

you raise a very interesting point here.

Replication done by the root node serves the purpose of redundancy to protect against node failure (of the root node) but does not protect against the root node being adversary. Replication done by the storing node serves the purpose of having the resource-ID available even if the root is adversary but may fail to provide redundancy against node failures.

I agree: to have both, a hybrid solution is needed. The storing node selects the initial replica roots and these again replicate content to protect against node failure. How to do this in detail is very DHT-protocol specific and probably not trivial.

 - Jan

> From: David A. Bryan [mailto:[email-masked]] 
> Sent: Tuesday, November 20, 2007 4:27 PM
> To: Eric Rescorla
> Cc: [email-masked]; Jan Seedorf
> Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version 
> Notificationfordraft-bryan-p2psip-reload-02
> 
> One problem with having the just the source place the 
> replicas is what happens when the source is offline.
> 
> For example, I am the source. I send out the data to the 
> original and the replica. Then log off.
> 
> If one peer fails, then that replica is gone for good unless 
> I come back up to refresh them, so over time, offline 
> information could "decay" in the presence of a slow peer failure rate.
> 
> Some sort of hybrid might make more sense...but there is 
> (clearly) a security point that needs to be considered here.
> 
> David (as individual)
> 
> 
> > > Dear authors of the new RELOAD draft (02), I have some 
> comments on 
> > > the security section:
> > >
> > Yeah, this is sort of a thinko in our writeup. We intend to move to 
> > explicit writes to each replica by the storing node and 
> just ran out 
> > of pre-draft time :)
> >
> >
> > > other attacks on DHT routing. Join-leave attacks can be 
> used by the 
> > > attacker to chose its location in the DHT despite a 
> central node-ID 
> > > assignment authority (see C. Scheideler, "How to Spread 
> Adversarial 
> > > Nodes?: Rotate!," Proc. 37th Annual ACM Symp. Theory of Comp., 
> > > Baltimore, MD,pp. 704-13, for a formal analysis of the node-ID 
> > > assignment problem in DHTs and join-leave attacks). Additionally, 
> > > even if there are no Sybil or Eclipse attacks, adversary nodes 
> > > (though well certified through the admission authority, e.g., 
> > > because they have been compromised) can simply drop 
> messages. This 
> > > severely degrades the lookup success rate in a DHT. 
> Countermeasures 
> > > against these attacks may well be out-of-scope for P2PSIP 
> > > standardisation, I just feel the section is misleading in 
> the sense 
> > > that it suggests that a central authority protects against all 
> > > threats on DHT routing.
> >
> > I agree  tha there are significant residual attacks. We'll 
> see whwat 
> > we can do to make this text clearer. IF you wanted to suggest some 
> > text that would be great.
> >
> > Thanks,
> > -Ekr
> >
> >
> >

---

From: "Jan Seedorf" <[email-masked]>
Date: Thu, 22 Nov 2007 16:15:22 +0100

Dear David, Bruce, and Salman,

a couple of thought on this:
-- any mechanism on the DHT layer would not prohibit the application layer to conduct additional replication (as David points out below)
-- it may also depend on what layer you have mechanisms to detect adversary nodes (to intentionally not replicate at adversary nodes). If this is done at the DHT layer (e.g., by using density checks of the successor list) this information could be passed on to the application layer. If you detect adversary nodes at the application layer (e.g., through timeouts or by cryptographic verification of the content they provide), only the application layer can use this information for replication.

I thought the WG had decided not to focus on a particular DHT but rather make P2PSIP use pluggable DHTs. Any mechanism on the DHT layer is very DHT-protocol specific. Does that not imply that replication on that layer is out of the scope of the WG?

Salman: I think the point raised by David in his other mail was not _whether_ an operator should ensure that replicas survive node failures but how this can be done if the source is responsible for replication (rather a research issue)

 - Jan

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David A. Bryan
> Sent: Wednesday, November 21, 2007 3:50 PM
> To: Salman Abdul Baset
> Cc: Eric Rescorla; [email-masked]; Jan Seedorf
> Sort of related to this discussion is the open question of 
> what layer does replication occur? There are several alternatives:
> 
> * Do it on a per-pluggable DHT level. In otherwords, each DHT 
> that is defined specifies a replication mechanism. This may 
> be very desirable if someone has a very clever DHT design 
> with a specific replication scheme, but might remove operator 
> flexibility and make it difficult for specific applications 
> to have alternate schemes (although they could layer it on 
> top of the DHT provided scheme)
> 
> * Do it at the application level instead. Each usage 
> specifies what replication it would like (how many, where, do 
> you do source node replication if the source node fails, 
> etc.) The advantage to this is that it can be much more 
> tailored for the use of the application, but if one overlay 
> is supporting multiple usages, then things stored in common 
> to each usage (maybe the user's public key, for example, 
> which different applications may want) could conceivably be 
> replicated in more places than really needed. It also means a 
> clever DHT replication idea isn't as useful, since there 
> would still be replication above it at the app level anyway 
> (although I guess you could just turn off the application 
> level replication in that case anyway)
> 
> This is definitely a good open issue...I'd love to see a bit 
> of discussion about what others think the pros and cons are here...
> 
> --David (as individual)
> 
> > Both publisher and responsible nodes can determine the node replica 
> > set, i.e., the list of nodes on which to replicate. In addition to 
> > security, factors such as churn rate, uptime and load of a 
> node also 
> > impact the choice of replica set.
> >
> > An artifact of using DHTs is that the publisher and 
> responsible peers 
> > are generally different. Since nodes churn, the responsible 
> peer may change.
> > In an unstructured (non-DHT) overlay, the publisher node 
> will likely 
> > be responsible for determining the replica set.
> >
> > The question of how many replicas to maintain is best left to the 
> > overlay operator. As mentioned above, the number of 
> replicas depends 
> > on the churn rate, availability guarantees, and security 
> among others.
> >
> > The question whether to maintain replicas after source node 
> fails is 
> > best left to the overlay operator.
> >
> > -salman
> >
> >
> > > One problem with having the just the source place the replicas is 
> > > what happens when the source is offline.
> > >
> > > For example, I am the source. I send out the data to the original 
> > > and the replica. Then log off.
> > >
> (clearly) a 
> > >> At Tue, 20 Nov 2007 14:57:28 +0100, Jan Seedorf wrote:
> > >>>  section 7.3. it is specified that the root-node of 
> some resource 
> > >>> ID  (i.e., the node responsible for storing the resource) is  
> > >>> well describe the only issue here is availability. However, I 
> > >>> think  that any countermeasure involving replication 
> must involve  
> > >> explicit writes to each replica by the storing node and just ran 
> > >> out of pre-draft time :)
> > >>
> > >>
> > >>> node-ID assignment problem in DHTs and join-leave attacks). 
> > >>> Additionally, even if there are no Sybil or Eclipse attacks, 
> > >>> adversary nodes (though well certified through the admission 
> > >>> authority, e.g., because they have been compromised) can simply 
> > >>> drop messages. This severely degrades the lookup 
> success rate in a 
> > >>> DHT. Countermeasures against these attacks may well be 
> > >> whwat we can do to make this text clearer. IF you wanted 
> to suggest 
> > >> some text that would be great.
> > >>
> > >> Thanks,
> > >> -Ekr
> > >>
> > >>
> > >>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 23 Nov 2007 11:17:53 -0800

Hi Jan,

I think you are getting at we need replication to be possible at both  
the DHT and Application layer. I probably agree with you. One of the  
reasons I think we need this  as the application layer is on only it  
can updated with a new signed copy that obsoletes any prior data  
because it is authoritative source for the information. On the other  
hand, we need it in the DHT because when the peer that runs the  
storing application is offline, we need the information to continue  
to persist in the DHT as peers storing the data churn.

On a side note, I think the WG agreed to have a plug-able type of DHT  
scheme but I still think we need to specify some. Unless we specify  
some, I don't see how we can build interoperable systems.

Cullen <with my individual contributor hat on>

On Nov 22, 2007, at 7:15 AM, Jan Seedorf wrote:

> -- any mechanism on the DHT layer would not prohibit the  
> application layer to conduct additional replication (as David  
> points out below)
> -- it may also depend on what layer you have mechanisms to detect  
> adversary nodes (to intentionally not replicate at adversary  
> nodes). If this is done at the DHT layer (e.g., by using density  
> checks of the successor list) this information could be passed on  
> to the application layer. If you detect adversary nodes at the  
> application layer (e.g., through timeouts or by cryptographic  
> verification of the content they provide), only the application  
> layer can use this information for replication.
>
> I thought the WG had decided not to focus on a particular DHT but  
> rather make P2PSIP use pluggable DHTs. Any mechanism on the DHT  
> layer is very DHT-protocol specific. Does that not imply that  
> replication on that layer is out of the scope of the WG?
>
> Salman: I think the point raised by David in his other mail was not  
> _whether_ an operator should ensure that replicas survive node  
> failures but how this can be done if the source is responsible for  
> replication (rather a research issue)
>
>  - Jan
>

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 23 Nov 2007 14:56:13 -0500

On Nov 23, 2007 2:17 PM, Cullen Jennings <[email-masked]> wrote:
> because it is authoritative source for the information.
I am fine with allowing replication in both layers - DHT and application.
Just let me clarify one thing.

There are two nodes that may initiate replication.
- Source Node (Peer or Client)
- Responsible Peer

Replication by the Responsible Peer must be done in the DHT layer.
Replication by the source node may be performed in the DHT layer or in
the application layer. The two cases will be (almost) identical from
the protocol perspective.

(In Pastry, the nodes on the path to the Responsible Peer make and
keep a copy of the data. I am not sure if we want to follow it.)

On the other

> some, I don't see how we can build interoperable systems.
Agreed.

Thanks.

Eunsoo

-- 
Eunsoo

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 23 Nov 2007 12:06:34 -0800

At Fri, 23 Nov 2007 11:17:53 -0800,
> some, I don't see how we can build interoperable systems.

AFAICT, both of these are required by our charter:

   2. A proposed standard defining a P2PSIP Peer Protocol. This protocol
   is used between P2PSIP overlay peers, some of which may be behind
   NATs. This protocol will define how the P2PSIP peers collectively
   provide for user and resource location in a SIP environment with no or
   minimal centralized servers. This protocol may or may not be
   syntactically based on SIP, a decision to be made by the WG. The group
   will identify and require one base P2P algorithm (likely a particular
   Distributed Hash Table (DHT) algorithm), while allowing for additional
   optional algorithms in the future.
   
-Ekr

---

From: Michael Chen <[email-masked]>
Date: Wed, 28 Nov 2007 18:57:15 -0800

Cullen,

I don't see where the protocol sends the originator's peer-ID. At the 
end of section 4.1, it says the via list starts out empty and the route 
list has the intermediate and destination peer IDs.  Say A wants to 
reach C through B, then in the forwarding header sent by A, the 
route-list contains [B, C], and the via list is empty.  Where does C or 
B for that matter know the peer ID of A when it's time to send the 
respond back?

Should the via-list in the forwarding header sent by A contains the peer 
ID of A?

Also, any comment of my earlier suggestion in this thread about swapping 
the position of the via list and route list?

Thanks

--Michael

---

From: "Jan Seedorf" <[email-masked]>
Date: Thu, 29 Nov 2007 19:12:22 +0100

Dear Cullen,

> I think you are getting at we need replication to be possible 
> at both the DHT and Application layer. I probably agree with 
> you. One of the reasons I think we need this  as the 
> application layer is on only it can updated with a new signed 
> copy that obsoletes any prior data because it is 
> authoritative source for the information. On the other hand, 
> we need it in the DHT because when the peer that runs the 
> storing application is offline, we need the information to 
> continue to persist in the DHT as peers storing the data churn.

Yes, that was my point. There are good reasons for either layer to have replication handled by it.

 - Jan

> Sent: Friday, November 23, 2007 8:18 PM
> To: Jan Seedorf
> Cc: P2PSIP WG
> Subject: Replication - Was Re: [P2PSIP] Merge of ASP and 
> RELOAD - Version Notification fordraft-bryan-p2psip-reload-02
> 
> 
> Hi Jan,
> 
> I think you are getting at we need replication to be possible 
> at both the DHT and Application layer. I probably agree with 
> you. One of the reasons I think we need this  as the 
> application layer is on only it can updated with a new signed 
> copy that obsoletes any prior data because it is 
> authoritative source for the information. On the other hand, 
> we need it in the DHT because when the peer that runs the 
> storing application is offline, we need the information to 
> continue to persist in the DHT as peers storing the data churn.
> 
> On a side note, I think the WG agreed to have a plug-able 
> type of DHT scheme but I still think we need to specify some. 
> Unless we specify some, I don't see how we can build 
> interoperable systems.
> 
> application 
> > layer to conduct additional replication (as David points out below)
> > adversary nodes (to intentionally not replicate at 
> adversary nodes). 
> > If this is done at the DHT layer (e.g., by using density 
> checks of the 
> > successor list) this information could be passed on to the 
> application 
> > layer. If you detect adversary nodes at the application 
> layer (e.g., 
> > through timeouts or by cryptographic verification of the 
> content they 
> > provide), only the application layer can use this information for 
> > replication.
> >
> > rather make P2PSIP use pluggable DHTs. Any mechanism on the 
> DHT layer 
> > is very DHT-protocol specific. Does that not imply that 
> replication on 
> > that layer is out of the scope of the WG?
> >
> Behalf Of 
> what layer 
> specifies what 
> >> replication if the source node fails,
> tailored for 
> >> the use of the application, but if one overlay is 
> supporting multiple 
> >> usages, then things stored in common to each usage (maybe 
> the user's 
> >> public key, for example, which different applications may 
> want) could 
> >> conceivably be replicated in more places than really 
> needed. It also 
> >> means a clever DHT replication idea isn't as useful, since there 
> >> would still be replication above it at the app level 
> anyway (although 
> >> I guess you could just turn off the application level 
> replication in 
> >> that case anyway)
> >>
> >> On Nov 20, 2007 6:43 PM, Salman Abdul Baset 
> <[email-masked]> 
> >> wrote:
> just ran

---

From: Song Yongchao <[email-masked]>
Date: Fri, 30 Nov 2007 14:47:47 +0800

> From: Jan Seedorf [mailto:[email-masked]]
> Sent: Friday, November 30, 2007 2:12 AM
> To: Cullen Jennings
> Dear Cullen,
> 

That was also my point. Replication handled by either layer, or either the
source peer or the responsible peer, has its pros and cons. 

However, for the peer protocol, should only take the replication handled by
distributed storage layer into account, either by the source peer or the
responsible peer. For the availability when the source peer is offline, I
prefer the responsible peer to do it.

Of course, whether or not to replicate in the overlay is left to the
decision of the overlay operator.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 30 Nov 2007 12:06:38 -0800

Hi, Cullen,

If I may disagree with your individual hat :-)

It IS tempting to provide replication at both levels, but if we can avoid 
that, I'd like to avoid that.

I'm concerned that we're headed for the situation where applications that 
care handle their own replication because they may end up running on 
overlays that don't provide replication, so the overlay replication only 
"adds value" for applications that don't handle replication because they 
don't care.

I'm also concerned about debugging, especially with race conditions, but 
expect you are already thinking about that.

Thanks,

Spencer

p.s. I'm also remembering a fairly funny conversation with Jonathan Sadler 
about how pleased he was with the high uptime he was seeing from an immature 
MPLS fast recovery implementation ...

... until he got suspicious and asked the SONET guys if they had disabled 
SONET-layer protection. They hadn't ("who would want SONET without 
protection?"), so the MPLS implementation had never seen a link failure in 
testing. No wonder it was so "reliable" ...

> Hi Jan,
>
> I think you are getting at we need replication to be possible at both  the 
> DHT and Application layer. I probably agree with you. One of the  reasons 
> I think we need this  as the application layer is on only it  can updated 
> with a new signed copy that obsoletes any prior data  because it is 
> authoritative source for the information. On the other  hand, we need it 
> in the DHT because when the peer that runs the  storing application is 
> offline, we need the information to continue  to persist in the DHT as 
> peers storing the data churn.
>
> scheme but I still think we need to specify some. Unless we specify  some, 
> I don't see how we can build interoperable systems.
>