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
