Hi Cullen,
On 18.06.2012 23:37, Cullen Jennings (fluffy) wrote:
> switched to your suggested text in next version - thanks
Ok, meanwhile I have some more comments, mostly clarification questions.
Two major comments though:
- The Connection Table is somewhat unclear.
* Is it correct that it contains all nodes that are directly connected
to a node, including those from the routing table?
* Does it belong more to the topology plugin or to the forwarding &
link management?
* In case one has to route a message towards a destination, should the
connection table be searched first (for an exact match), then the
neighbor set and then the finger table?
- It is unclear to me why (sec. 10.7.1, p.) the spec states:
"peer MUST remove the entry from its neighbor table and replace it
with the best match it has from the other peers in its routing table.
If using reactive recovery, it then sends an immediate Update to all
nodes in its Neighbor Table."
so the peer replaces the failed entry with one of its fingers,
which is maybe a poor choice, and sends this information to
its neighbors. IMHO it makes much more sense to request routing
information from the neighbors in order to get a better replacement
for the lost peer, instead of "confusing" the neighbors with more
inaccurate routing information.
Then some more clarifications/nits:
=====
Sec. 10.5 (p.110):
"The join process for a joining party (JP) with Node-ID n"
why joining _party_ if the terminology section mentions
Joining Peer and AP is the Admitting Peer?
=====
"1. JP MUST connect to its chosen bootstrap node."
it is unclear what "connect" exactly means. This is actually
described in Sec. 11.5:
"When contacting a bootstrap node, the joining node MUST first form
the DTLS or TLS connection to the bootstrap node and then sends an
Attach request over this connection with the destination Node-ID set
to the joining node's Node-ID."
So my suggestion is to explain it a little but more or to put a forward
reference to section 11.5.
=====
"2. JP SHOULD send an Attach request to the admitting peer (AP) for
Node-ID n. The "send_update" flag should be used to acquire the
routing table for AP."
Here, it is not clear how the JP finds the AP. This is explained in
Section 12:
"JP then sends an Attach through that
peer to a resource ID of itself (JP). It gets routed to the
admitting peer (AP) because JP is not yet part of the overlay."
I suggest to change it to:
"2. JP SHOULD send an Attach request to Node-ID n in order to contact
the admitting peer (AP). The "send_update" flag should be used to
acquire the routing table for AP, i.e., it gets an UpdateReq message
after connecting (via TLS) to AP."
Question: should it be "acquire the routing table of AP" or "acquire the
routing table from AP"?
=====
"3. JP SHOULD send Attach requests to initiate connections to each of
the peers in the neighbor table as well as to the desired finger
table entries. Note that this does not populate their routing
tables, but only their connection tables, so JP will not get
messages that it is expected to route to other nodes."
here it is unclear that the Attach requests are sent via the AP
and what "desired" finger table entries means, e.g., in contrast to all?
=====
Sec. 10.7.:
" A peer MUST maintain an association (via Attach) to every member of
its neighbor set. "
why only to the neighbor set and not the whole routing table?
=====
Sec. 10.7.1:
" Every time a connection to a peer in the neighbor table is lost (as
determined by connectivity pings or the failure of some request),"
I think that "connectivity pings" means periodically sent Pings to all
members of the Connection Table by the Link Management Layer as
mentioned in sec. 6.5. A reference may help here.
However, I couldn't find out how often such "connectivity pings" should
be sent (the chord-ping-interval is only related to pinging finger table
entries).
=====
"If the neighbor failure effects the peer's range of responsible IDs,
then the Update MUST be sent to all nodes in its Connection Table."
Why Connection Table? I think this must be Neighbor Table!
=====
Sec. 10.7.2.:
"If a finger table entry is found to have failed,"
how is it determined to have "failed"? 10.7.1 is only
related to neighbor failures...does the same definition
apply here?
=====
Sec. 10.7.3.:
"When a peer discovers that its range of responsible IDs have changed,
it MUST send an Update to all entries in its connection table."
Why connection table? Why not neighbor or routing table?
=====
Sec. 10.7.4.1.:
"A peer MUST periodically send an Update request to every peer in its
Connection Table."
Why connection table? Why not neighbor table?
=====
"A peer SHOULD randomly offset these Update requests so they do not
occur all at once."
This is a little bit too imprecise.
How should this be done? A typical mechanism
is using a randomly chosen offset from an interval [0.5*Tp,1.5*Tp]
where Tp is the target period, cf.
S. Floyd, V. Jacobson, „The Synchronization of Periodic Routing
Messages“, IEEE/ACM Transactions on Networking, Vol. 2, No. 2, April,
1994, http://portal.acm.org/citation.cfm?id=187045
=====
Sec: 10.7.4.2.:
"A peer SHOULD NOT send Ping requests looking for new finger table
entries more often than the configuration element "chord-ping-
interval", which defaults to 3600 seconds (one per hour)."
This paragraph should probably moved some paragraphs down as it
has been stated yet that a peer should actually send Ping requests
at all (this is explained in the subsequent paragraphs).
=====
Sec 12:
- throughout the figures: "Update" should be "UpdateReq"
and Attach should be AttachReq?
=====
Neighor Table and Connection Table are written sometimes
in lower case and sometimes in upper case style. I'm sure that
the RFC editor will ask for consistency in writing...
Regards,
Roland
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
