Subject: Re: [P2PSIP] Remove StoreReq.resource, FetchReq.resource, etc.

From: Cullen Jennings <[email-masked]>
Date: Wed, 17 Feb 2010 15:33:53 -0700

I got lost on this one. Are there any changes we need to make to the draft based on this email thread?

On Dec 27, 2009, at 10:10 AM, Eric Rescorla wrote:

> On Sun, Dec 27, 2009 at 8:48 AM, Michael Chen <[email-masked]> wrote:
>> Eric,
>> 
>> Thanks for pointing out the replica StoreReq paragraph in 6.4.1.1, but I
>> still have 2 questions:
>> 
>> 1. What is the via and destination list look like for a replica StoreReq?
>> 
>> I believe StoreReq (replica or not) should not be routed, thus the via list
>> should be empty and the destination list should contain a lone entry of the
>> receiving peer (i.e. the successor of the responsible peer). If this is
>> true, the draft should enforce it.
> 
> I had assumed that this question was implementation and overlay
> dependent. Say for the sake of argument that a node can't establish
> direct connections with all the replica set, then it would have to
> route replica stores, no? What do you think would be the advantage
> of adding this restriction?
> 
>> 2. What are the use cases for the other 3 requests where the resource ID in
>> the message differ from the destination list?
>> 
>>   FetchReq.resource
>>   StatReq.resource
> 
> Both of these can be used by the storing node to explicitly address replica
> nodes; see 6.4.1.2:
> 
>      The list of other peers at which the data was/will be replicated.
>      In overlays and applications where the responsible peer is
>      intended to store redundant copies, this allows the storing peer
>      to independently verify that the replicas have in fact been
>      stored.  It does this verification by using the Stat method.  Note
>      that the storing peer is not require to perform this verification.
> 
> The text probably should say "Stat or Fetch" methods.
> 
> 
>>   FindReq.resource
>> 
>> Replica is not involved in these cases. These messages are only meant to be
>> answered by the responsible peer. If this is true, these resource IDs should
>> be removed from the message.
> 
> Well, the idea with Find is to allow you to ask a specific node a question, so
> it's expected to be addressed to a node directly, not a resourceid, thus
> requiring the resourceid in the request.
> 
> -Ekr
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html