Re: [secdir] secdir review of draft-ietf-p2psip-self-tuning-11

[Tobias Gondrom <[e-mail]>]

Hi Jouni,

thanks a lot for the explanation.
That answers my question.

Best wishes, Tobias


On 08/06/14 10:37, Jouni Mäenpää wrote:
> Hi,
>
> Thanks for the comments!
>
>> How did you determine the value of 75th percentile? Is this based on research
>> or experience or derived from some other estimates? 
> We implemented the mechanisms specified in draft-p2psip-self-tuning in our P2PSIP prototype and ran an extensive set of simulations and PlanetLab experiments to determine appropriate values for the parameters. We found that the 75th percentile was a slightly better choice than for instance using the median. This is because if the received estimates happen to vary greatly, it is safer to pick a value that is higher than the median to ensure that the stabilization rate that will be used will be sufficiently high. Using the 75th percentile also enables faster reaction to increasing churn rate.
>
>> Is this choice influenced by number of peers or churn in certain environments.
> The choice of using the 75th percentile is not influenced by the number of peers or the churn rate - we have found the 75th percentile to perform well regardless of the size of the overlay network and the churn rate.
>
> Regards,
> Jouni
>
> From: Tobias Gondrom [mailto:[e-mail]] 
> Sent: 31. toukokuuta 2014 15:46
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: secdir review of draft-ietf-p2psip-self-tuning-11
>
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.
>
> The draft is standards track and describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size. It extends the mandatory-to-implement chord-reload algorithm by making it self-tuning.
>
> The document appears ready for publication.
>
> With one note for the IESG: This security review did only consider this specification, but did not verify the scientific data and research that lead to this algorithm.
>
> The Security Consideration Section 8 seems appropriate for the draft. It also refers to the security considerations of RFC6940 (RELOAD Base).  
>
> One personal question to the authors: 
> In section 8 and 6.5, you introduce the concept of "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..."
> How did you determine the value of 75th percentile? Is this based on research or experience or derived from some other estimates? Is this choice influenced by number of peers or churn in certain environments. 
> Thank you and best regards. 
>
> Tobias 
>