Re: [Din] draft-mazieres-dinrg-scp-04 peer priority algorithm

David Mazieres <dm-list-ietf-ilc@scs.stanford.edu> Tue, 07 August 2018 20:02 UTC

Return-Path: <dm-list-ietf-ilc@scs.stanford.edu>
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 10C141310E1 for <din@ietfa.amsl.com>; Tue, 7 Aug 2018 13:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scs.stanford.edu
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 F5_aSCQ2FHsF for <din@ietfa.amsl.com>; Tue, 7 Aug 2018 13:02:30 -0700 (PDT)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACAB41310EC for <din@irtf.org>; Tue, 7 Aug 2018 13:02:30 -0700 (PDT)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.16.0.21/8.16.0.21) with ESMTP id w77K2Tax024089; Tue, 7 Aug 2018 13:02:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scs.stanford.edu; s=scs; t=1533672149; bh=reOvKvKuATuPvyLvMROkvERPwet0CleJXRGGn13ah1w=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version; b=h6EPIAN721iWvnWvXi/aRIoNOyA1lpAUUrtTo/14/PTcmyoA05M6GbKY4uy0UeaCR cLHIoyyEJiHq4UaUgi9kTq37h1qUm73EdbaUJsDSFFv0NCfdRqq8Mow0hdsoHxBCBV PusN7zoIL9Gqj7ihXPZwvyBtvzoJQOjZ8pCuTMvw=
Received: (from dm@localhost) by market.scs.stanford.edu (8.16.0.21/8.16.0.21/Submit) id w77K2RjK000371; Tue, 7 Aug 2018 13:02:27 -0700 (PDT)
From: David Mazieres <dm-list-ietf-ilc@scs.stanford.edu>
To: Piers Powlesland <pierspowlesland@gmail.com>, din@irtf.org
In-Reply-To: <CAFXacXkx+y5mqwatwJoQib=q3W+6u02QHDLqtS66P4wGXqwCEQ@mail.gmail.com>
References: <CAFXacXkx+y5mqwatwJoQib=q3W+6u02QHDLqtS66P4wGXqwCEQ@mail.gmail.com>
Reply-To: David Mazieres expires 2018-11-05 PST <mazieres-qfjm5npktewj9sd8xp3u9afa5n@temporary-address.scs.stanford.edu>
Date: Tue, 07 Aug 2018 13:02:27 -0700
Message-ID: <8736vquer0.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/-YKZYvgTqIZB1CzE3aa_RPJvRBA>
Subject: Re: [Din] draft-mazieres-dinrg-scp-04 peer priority algorithm
X-BeenThere: din@irtf.org
X-Mailman-Version: 2.1.27
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: Tue, 07 Aug 2018 20:02:35 -0000

Piers Powlesland <pierspowlesland@gmail.com> writes:

> As I understand, this filtering could lead to a situation where the
> neighbours set is empty, since there is no guarantee that any hash
> calculated above will be less than '2^256 * weight(peer_id)'. Is this
> intentional?

There is a guarantee, because a node must belong to all of its own
quorum sets.  So even if a node has no other neighbors, it will still be
its own neighbor... which highlights the fact that maybe "neighbor" is a
misleading term here?  Or maybe at least suggests we should mention
this.

> Also what is the motivation for creating the "neighbours"
> set as opposed to simply selecting a peer from all peers based on
> their priority weighted by their weight?

The goal of this neighbor/priority scheme is twofold:

   1. Ensure that nodes that are not very important (because they appear
      only in a few quorum slices) also do not very often get to dictate
      the consensus value.

   2. Make it likely for nodes to listen to the same nodes for
      nomination values, so as to minimize the number of different
      values nominated.

The neighbor selection achieves #1, while the prioritization achieves
#2.  You seem to be proposing a unified mechanism that would ideally
achieve both goals at once, but don't think actually does.

As an example, suppose that my quorum slices consist of myself plus one
of 4 US nodes, plus one of 100 Chinese nodes.  (Assume the US and
Chinese nodes depends on one another in a robust way so the system is
safe.)  With your scheme, I will usually nominate my own value,
sometimes listen to one of the US nominated values, and almost never
listen to a Chinese node (because my own hash value would have to be
less than 0.01*2^256 and the US nodes would all have to be less then
0.04*2^256 for any Chinese node to have a chance).  In reality, my
quorum slice selection indicates that I consider Chinese nodes, in
aggregate, as important as US nodes--there just happen to be more
Chinese nodes.  So your scheme doesn't properly reflect the importance
of the nodes.

Does that make sense?

David