[Din] draft-mazieres-dinrg-scp-05 nomination, reasons for peer selection process
Piers Powlesland <pierspowlesland@gmail.com> Mon, 17 December 2018 15:10 UTC
Return-Path: <pierspowlesland@gmail.com>
X-Original-To: din@ietfa.amsl.com
Delivered-To: din@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1761200B3 for <din@ietfa.amsl.com>; Mon, 17 Dec 2018 07:10:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRJwx6cNvekx for <din@ietfa.amsl.com>; Mon, 17 Dec 2018 07:10:14 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6251129C6A for <din@irtf.org>; Mon, 17 Dec 2018 07:10:13 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id z13so9676727lfe.11 for <din@irtf.org>; Mon, 17 Dec 2018 07:10:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XCVsZMf0pIPwm/w7bFfpKqS89XACIn2SFA0UF0yJDIw=; b=lQwFSlu9VmXFyTvEZbN/EQp/U3S9MoMORWRq+4byK/AHgPqdBX0K3AiJ4MFf4w/I4v g8hkDde7IPLMgUPE1ka7dUKbWYV99/MVBU5N281Ff+kQPw5c2BQTGVyBJxdlPq0CQr8K 12nYe6GMFuf0Pc4ndNSdvUpLRgOKpqOrQNM12iutBFcmMFffY8yq0JK7513teAmTXgaW ZegIdqTdoTJq02lJVNzdDCuUDrEd2hBtwbvLsMVEVxQ+RzNIhcaxCHueE+T95SV9jjgr LCFyiratfgPB3Pmw3wVWsNzPqt/yYcj7ZfYh07b3FCq/qQZ2FQGyTlSn3zwPYRbvEnnH ensA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XCVsZMf0pIPwm/w7bFfpKqS89XACIn2SFA0UF0yJDIw=; b=GfkECOubGdUbrzSq5d5uHIeiQI6hLczVc1PN0IcWUW/nemgQFz4oMCwKDn9Ltxnf5t NESCpUzWlE8Jez9GBfocjTXoUW950CAQFxQPF0NAdL9wS4lJxic+oLl0Q3yaYiWgA/QL Pf61EwkcUCSuOtm4mY1Bt04POvsxz7uVAZgOE69z6zbJii9oyBxRYpNUPd3T+3MdXECB 8VtYlOq35YlshI14xQSCsYkS0tVRnLmahcXzEjyZE1BrcrO0EcgEr03EltL53WOlya+x YeTlTjz5h3XxRJqAnx5xgs75JeEhIbVjNIkFAgTcd4C4yYG+xFYPa8+7V0XJ8SKaNqHg 9s/w==
X-Gm-Message-State: AA+aEWbpbYkLWZDFQxN6JJO91EySbc2osjp7mH2pmdqkG25JOvD+wQf8 lc8b4WZMknRbll3vsns6MzXy4LVpCrH4LLe8hVs/JQ==
X-Google-Smtp-Source: AFSGD/XNfZ16RYj0PpQSzgGXOQ1e+JkwRdYyChcNP8LewI6Ho+ZA4mLytpMSPfzmJI1wloA85S8e+eurLCpHf61aU9s=
X-Received: by 2002:ac2:4343:: with SMTP id o3mr8035019lfl.129.1545059411759; Mon, 17 Dec 2018 07:10:11 -0800 (PST)
MIME-Version: 1.0
From: Piers Powlesland <pierspowlesland@gmail.com>
Date: Mon, 17 Dec 2018 15:10:00 +0000
Message-ID: <CAFXacXk2JS8yza_nJ-2b-e-rSxS60Vp+7Bi+SUOvLVmcAcxKdg@mail.gmail.com>
To: din@irtf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/COki8PdZmKAVpiFolmgHR0fcNOE>
Subject: [Din] draft-mazieres-dinrg-scp-05 nomination, reasons for peer selection process
X-BeenThere: din@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" <din.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/din>, <mailto:din-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/din/>
List-Post: <mailto:din@irtf.org>
List-Help: <mailto:din-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/din>, <mailto:din-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Dec 2018 15:10:16 -0000
Hello, Section 3.4 on page 10, describes the nomination protocol, where nodes suggest and agree on values to begin balloting with. A node limits itself to accepting suggestions from only certain validators, such that validators that appear in many of a node's quorum slices are favoured over those that appear in less quorum slices. It's not clear from the draft why this step is necessary. If the intent is to ensure that peers that appear in many of a node's quorums have more influence than those that don't, then the peer selection process seems redundant since nodes that appear in many quorums implicitly have more influence than those that don't, because they appear in more quorums. It also seems that, by limiting the peers that a node accepts suggestions from, the set of values that make it to balloting will also be limited. Values that didn't make it to balloting this slot will have to wait till the next slot to have a chance to be agreed upon. If this is the case then it seems that the peer selection process is limiting the responsiveness or throughput or both of the network. What would be the problem with not performing peer selection and each node simply accepting all suggestions from all of its validators during nomination?
- [Din] draft-mazieres-dinrg-scp-05 nomination, rea… Piers Powlesland