Subject: [apps-discuss] [APPS-REVIEW] review of draft-ietf-p2psip-self-tuning-09

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 22 Jan 2014 12:05:26 +0900

I have been selected as the Applications Area Review Team reviewer for 
this draft (for background on apps-review, please see 
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-ietf-p2psip-self-tuning
Title: Self-tuning Distributed Hash Table (DHT) for REsource LOcation 
And Discovery (RELOAD)
Reviewer: Martin J. Dürst
Review Date: December 27, 2013
IETF Last Call Date: not yet
IESG Telechat Date: not yet

Summary: From what I have read, this draft looks like it's almost ready 
for publication in IETF Standards Track but has a few issues that should 
be fixed before publication. However, I have to admit that I'm not a SIP 
expert, nor an expert in P2P systems.

Minor Issues:

Section 2, definitions of O(g(n)) and Omega(g(n)): The informal 
definitions are fine, but there should also be a reference to a more 
formal definition.

Definitions of "Predecessor List" and "Successor List": The former has 
"first predecessors", whereas the later has "first *r* successors" 
(emphasis by the reviewer). This may be an editorial issue, but it looks 
to me like the *r* should be present for predecessors, too.

Section 3.2, bottom of page 6 and top of page 7: First, the big-O and 
big-Omega notation makes the base of the logarithm irrelevant, so it 
should be O(log(N)) rather than O(log2(N)), and so on. But this shows 
that statements such as "a successor list of size O(log2(N)) makes it 
unlikely..." are actually flawed, because both a function 0.01*log2(N) 
and a function 100*log2(N) would be O(log2(N)) (the constant multiple is 
mentioned in the definitions of O() and Omega()), and I'm pretty sure 
that with the former, connectivity will be lost quite soon, whereas the 
later is most probably heavy overkill.

The notation log2^2(N) is quite difficult to read. It's a logical 
combination of the notations N^2 and log2(N), which are both not too 
difficult to read, but in combination, the mental gymnastics required to 
translate this to a 2D mathematical formula and then interpret are too 
much. I'd strongly prefer a more functional notation, e.g. 
square(log2(N)), which would be much more straightforward to read. This 
would also work better together with the fact that there are parentheses 
around the N, which wouldn't be needed in a 2D mathematical formula.

Section 6.2:
"the finger table MUST be set to max(log2(N), 16)": the finger table 
size obviously must be integral, but log2(N) will rarely be integral, 
and it is not clear what kind of rounding to apply. Same for the size of 
the successor list.

Section 6.4: In "Ages[rsize/2]", is the division an integer division 
(rounding down) or what?

Section 6.5, last paragraph: "75th percentile": This probably needs a 
better definition. See http://en.wikipedia.org/wiki/Percentile, where it 
says: "Definition: There is no standard definition of percentile, 
however all definitions yield similar results when the number of 
observations is very large.". In this draft, we will normally be in a 
situation with very *few* observations, so a careful definition seems 
required.

Section 7:
"This document extends the RELOAD overlay configuration document": It 
would be good to have a reference here. Actually, I was specifically 
asked to review this section, but I don't feel I'm able to do a good job 
here because while I found quite a few references to "RELOAD overlay 
configuration document *extensions*", I didn't easily find a good 
reference to the base document.

Section 8 (security):
"In addition, as long as the amount of
    malicious peers in the overlay remains modest, the statistical
    mechanisms applied in Section 6.5 (i.e., the use of 75th percentiles)
    to process the shared estimates a peer obtains help ensuring that
    estimates that are clearly different from (i.e., larger or smaller
    than) other received estimates will not significantly influence the
    process of adapting the stabilization interval and routing table
    size."
This seems good for the overall network, but it should be mentioned that 
this is not the case locally. If an attacker wants to e.g. isolate a 
specific node, it should not be too difficult to generate hashes to 
place nodes in "strategic" locations on the ring to in effect isolate 
and detach a specific node.

Regards,    Martin.