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

Jouni Mäenpää <> Sun, 08 June 2014 09:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0F9461A030A; Sun, 8 Jun 2014 02:37:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jP-RREUM1wsT; Sun, 8 Jun 2014 02:37:28 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 498A61A02F7; Sun, 8 Jun 2014 02:37:27 -0700 (PDT)
X-AuditID: c1b4fb30-f79a56d000006536-e7-53942ece4b9b
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id E2.96.25910.ECE24935; Sun, 8 Jun 2014 11:37:18 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Sun, 8 Jun 2014 11:37:18 +0200
From: Jouni Mäenpää <>
To: Tobias Gondrom <>, "" <>
Thread-Topic: secdir review of draft-ietf-p2psip-self-tuning-11
Thread-Index: AQHPfM6P2ObWwRutakGSq/fTjwpe/Ztm+wVQ
Date: Sun, 08 Jun 2014 09:37:17 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM+Jvje45vSnBBp23tS2WfrnPajHjz0Rm iw8LH7JY3Fown9GBxePBnflMHkuW/GTy+HL5M1sAcxSXTUpqTmZZapG+XQJXxtPnK9gLFotX /Lw5l7GBsVm4i5GTQ0LAROL4tBeMELaYxIV769m6GLk4hASOMkps2NTNDOEsYpRo6elmB6li E3CXOHzzJytIQkRgFqPE9d4Gli5GDg5mAQ+J7if6IDXCAnYS136fZQGxRQTsJZ4/2cEIYRtJ TO3YyQxiswioSKybvAOshlfAV2L64jY2EFtIwFOiccZlsBpOAW2JC/u+s4LYjEDXfT+1hgnE ZhYQl7j1ZD4TxNUCEkv2nGeGsEUlXj7+xwphK0ksuv0Zql5P4sbUKWwQtrbEsoWvmSH2Ckqc nPmEZQKj2CwkY2chaZmFpGUWkpYFjCyrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQLj6+CW 3wY7GF8+dzzEKMDBqMTDm9A9OViINbGsuDL3EKM0B4uSOO9FjepgIYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYyShxNUc851zsl7PdPKx8jhut+BLK1p/7LXOB4tyjA9MnlKsMSMjluWLW9k VX+cUDlSMMHylsZDg6RdwSrxy7Ic96yYvdWMtW0ue+IK68WGmqnqTEwlqxRKg7xUvvlujJtY z+qw9kudeZL/sadn72ouD8z5nhO2KoG58fDxTQGZp4w2xOu0hSqxFGckGmoxFxUnAgC/KeR/ kAIAAA==
X-Mailman-Approved-At: Mon, 09 Jun 2014 08:18:36 -0700
Cc: "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-p2psip-self-tuning-11
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 08 Jun 2014 09:37:29 -0000


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.


From: Tobias Gondrom [] 
Sent: 31. toukokuuta 2014 15:46
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.