switched to your suggested text in next version - thanks
On Apr 13, 2012, at 4:44 PM, Roland Bless wrote:
> Hi Cullen,
>
> On 13.04.2012 22:49, Cullen Jennings wrote:
>> There is one comment inline in the email that I'd really appreciate
>> it if you could look at the change I made and see if it looks right
>> to you.
>
> See comments below and inline.
>
>> The places N was being used for a specific peer, I moved the N to X
>> to help clarify this.
>
> looks ok.
>
>>> p. 108: " o RELOAD uses a 128 bit hash instead of a 160 bit
>>> hash, as RELOAD is not designed to be used in networks with close
>>> to or more than 2^128 nodes (and it is hard to see how one would
>>> assemble such a network)."
>>>
>>> The reasoning here is a little bit odd since the address space size
>>> is more related to how many objects one can store and the number of
>>> objects can very much larger than the number of actually existing
>>> nodes.
>>
>> clarified. this is a bit complicated in Reload as the size the
>> Node-ID does not need to the be the same size as Resource-ID.
>
> Change is ok, but for section 10 they actually have the same size (as
> probably for all structured KBR schemes).
> "For this Chord based topology plugin, the size of the Resource-ID is
> 128 bits."
>
>>> sec. 9.1:
>>>
>>> minor: It would be helpful to describe that neighbor table and
>>> finger table only contain Node-IDs and that the mapping to locators
>>> is done by using the Attach procedure via the overlay (such entries
>>> will be kept in the Connection Table then?!).
>> added
>
> "The neighbor and finger tables have a logical Node-ID but the
> actually mapping of a IP level addressing information to reach that
> Node-ID is kept in the connection table."
> I'm not a native speaker, but I'd rather propose:
> "The neighbor and finger table entries contain logical Node-IDs as
> values but the actual mapping of an IP level addressing information
> to reach that Node-ID is kept in the connection table."
>
>>> " Fundamentally, the chord data structure ": this is somewhat
>>> confusing since it is not clear what you mean by "the chord data
>>> structure", because it was not defined. In this context it seems to
>>> mean the logical data structure across all nodes and not a
>>> particular data structure inside a single node. This may confuse
>>> readers since "the chord data structure" is nothing that actually
>>> needs to be implemented.
>>
>> fixed
>
> ok.
>
>>> May 9.1 is also the section where you could state that N=2^128?
>> fixed
>
> ok.
>
>>> It should be clarified that this is only meant conceptually (one
>>> shouldn't implement it that way). "The routing table is
>>> conceptually the union of the neighbor table and the finger
>>> table."
>>
>> fixed
>
> ok.
>
>>> sec. 9.4: typo old: " success response. It MUST then sends a
>>> Store request to its" new: " success response. It MUST then send
>>> a Store request to its"
>>>
>>
>> fixed
>
> ok.
>
>>> 9.5: (p.110) " 4. JP MUST enter all the peers it has contacted
>>> into its routing table." presumably only successfully contacted
>>> peers should be entered into the routing table, so maybe better: "
>>> 4. JP MUST enter all the peers it has successfully contacted into
>>> its routing table."
>>
>> fixed
>
> ok.
>
>>> p.111: " 7. ... AP can now forget any data which is assigned to JP
>>> and not AP." I think that this should be kept as long as AP is in
>>> the replica set (cf. 9.7.3)
>>
>> fixed
>
> ok.
>
>
>>> Major: "In order to set up its finger table entry for peer i, JP
>>> simply sends an Attach to peer (n+2^(128-i)." should be changed
>>> to: "In order to set up its finger table entry for peer at finger
>>> index i (i.e., finger[i]), JP simply sends an Attach to peer
>>> n+2^(127-i)." as finger[0] should point to node n+2^127, i.e.
>>> halfway round the ring, otherwise n+2^128-0 would point to n
>>> itself.
>>
>> This is ( and related stuff in 9.7.4.2) is the change I really want
>> you to check.
>
> New formulation with i'th finger is much better (though still a bit
> confusing since the finger[i] notation is mentioned in the overview and
> also the original Chord paper), but the particular sentence is not
> quite correct.
> "In order to set up its i'th finger table entry for peer i, JP simply
> sends an Attach to peer (n+2^(128-i)."
> The i'th finger this is usually not for peer i and there is a
> superfluous "(".
> So better correct to:
> "In order to set up its i'th finger table entry, JP simply
> sends an Attach to peer n+2^(128-i)."
>
>> Look at how I clarified this and check you think I got it right. The
>> arrays start at 0 or 1 and been a point of confusion several times in
>> the past on this and it does not matter as long as it is clear. Check
>> with respect to section 9.7.4.2 too.
>
> Yep. Clearer now.
>
>>> sec. 9.7.1: p. 113, typo? old: " If the neighbor failure effects
>>> the peer's range of responsible IDs," new: " If the neighbor
>>> failure affects the peer's range of responsible IDs,"
>>
>> fixed
>
> ok.
>
>>> sec. 9.7.3: change throughout the section N to n
>>
>> Look at how I clarified this too.
>
> looks good.
>
>>> Major: sec. 9.7.4.2: " entries in the finger table. A finger
>>> table entry i is valid if it is in the range [ n+2^( 128-i ) ,
>>> n+2^( 128-(i-1) )-1 ]. Invalid" new: " entries in the finger
>>> table. A finger table entry at index i (finger[i]) is valid if it
>>> is in the range [ n+2^( 127-i ) , n+2^( 127-(i-1) )-1 ]. Invalid"
>>>
>>> So finger[127] will be the successor.
>>
>> check fix here too
>
> That's ok now.
>
> Regards,
> Roland
>
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
