From nobody Mon Aug 6 23:52:34 2018 Return-Path: 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 E8E3B130E76 for ; Mon, 6 Aug 2018 23:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 PsAlRkcbk-Uk for ; Mon, 6 Aug 2018 23:52:29 -0700 (PDT) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (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 93993130E7B for ; Mon, 6 Aug 2018 23:52:28 -0700 (PDT) Received: by mail-oi0-x241.google.com with SMTP id 8-v6so26687575oip.0 for ; Mon, 06 Aug 2018 23:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=d5wJl7Euu7qqD/ybM5WW64XZ+E/DcfAsqQedUKMc4II=; b=ubCR8Ryl2o82Rho7+Bwarm5hni0QJEvcHI/xQcvG01yWNTHgeT4bk1R+PzVX4KPewK 1/Pyd6bFlLtdys16wi1VR0UPTakAbv/7Vvhu4z1LT5J6HQ2fdADAISOLav4Lr+lVMUUN +zBS7gI7js3SRcV3DCMnPrW8FOSozxd5cZ1JXcH+ETFGo2G/PQAofza99Q1yAnzC+ONw fyQ918wEHrZgE7a4zO96IpmNIcJ5+KFcws/YR/AZgou2l272eRRQwajjGuI682IK88UV gs6LedcZlNnz1fb3vK3FSND41ZnZrIhNUEIYiS4pK+1eGCzpHnipaQUqV77hmHD7LWJ2 OrEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=d5wJl7Euu7qqD/ybM5WW64XZ+E/DcfAsqQedUKMc4II=; b=sc1gT4lBAIb9x15BltHBjbJPF8pGXZLjIh1/93TaCJojlva3XMIslPRHmP1YaBF1wQ FHQu4YTxeikr1sc3Gb8C4oMd/ZSff+qeWCsg9F9HicmlNjulRwSTK4JXpjurknvbPEpN vWwRV1XMf6l4aw9zYb4rs8sBS5Pg/7ig9pXd/IZHPuzxvnr2ELK951bVbJILUnYAEasL 5G/WmwSiH0h2WXajRXGrVCLerfaGkCHbgS3kY6JRbMa06B84tNQnaSLWpOcz2IQBDnK1 DuF6vuo6rt7BxpvixT5j/IdoeRK2pQMYLNb/MIJfZi2iXikVC87dmY82OiTQuFWeXHlP YpnQ== X-Gm-Message-State: AOUpUlEk63Hb0rw8i1L3PgpKfMQmILotrQk8jfNlGMWWgeV21hy/qRZS E+/NvP1+doCDsnZBrcv2esTO7D3XShRaH5QC9FOoh4he X-Google-Smtp-Source: AAOMgpeadvD6BseGUKwp8hOg28+nx3pZgj+BOxU0gwBqCTXPzYL/TJIUCkXxxVIuqj0AwTO5Me8MDmIOFJmzCOvCLCQ= X-Received: by 2002:aca:df55:: with SMTP id w82-v6mr16265643oig.355.1533624747682; Mon, 06 Aug 2018 23:52:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:a64c:0:0:0:0:0 with HTTP; Mon, 6 Aug 2018 23:52:27 -0700 (PDT) In-Reply-To: <153362405797.26785.8401463535368878444.idtracker@ietfa.amsl.com> References: <153362405797.26785.8401463535368878444.idtracker@ietfa.amsl.com> From: Alexander Mayrhofer Date: Tue, 7 Aug 2018 08:52:27 +0200 Message-ID: To: din@irtf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Din] Fwd: New Version Notification for draft-mayrhofer-did-dns-00.txt 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 06:52:33 -0000 Hello, I've just submitted an individual draft on how to publish "Decentralized Identifiers" (DIDs) in the DNS. DIDs is an addressing scheme for resources on distributed ledgers, such as blockchains, as most of you will probably know. They do use a provisional URI scheme ('did'), and are specified in the W3C Community Group here: https://w3c-ccg.github.io/did-spec/ We'd appreciate any feedback on this, and i'm also more than happy to talk about this during IETF 103, if DINRG does do a session. best, Alex P.S.: I'm cross-posting this on dnsop as well - it sort of sits "between" those two groups ---------- Forwarded message ---------- From: Date: Tue, Aug 7, 2018 at 8:40 AM Subject: New Version Notification for draft-mayrhofer-did-dns-00.txt To: Dimitrij Klesev , Alexander Mayrhofer , Markus Sabadello A new version of I-D, draft-mayrhofer-did-dns-00.txt has been successfully submitted by Alexander Mayrhofer and posted to the IETF repository. Name: draft-mayrhofer-did-dns Revision: 00 Title: The Decentralized Identifier (DID) in the DNS Document date: 2018-08-06 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-mayrhofer-did-dns-00.txt Status: https://datatracker.ietf.org/doc/draft-mayrhofer-did-dns/ Htmlized: https://tools.ietf.org/html/draft-mayrhofer-did-dns-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-mayrhofer-did-dns Abstract: This document specifies the use of the URI Resource Record Type to publish Decentralized Identifiers (DIDs) in the DNS. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Aug 7 09:04:07 2018 Return-Path: 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 B2774131032 for ; Tue, 7 Aug 2018 09:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 KmZcRnQ9hLJQ for ; Tue, 7 Aug 2018 09:04:03 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 61E4D130F76 for ; Tue, 7 Aug 2018 09:04:03 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id s12-v6so13888259ljj.0 for ; Tue, 07 Aug 2018 09:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=u89s35pdc4dOlb0PTGmaWtiah3AT4mrbdJQetYFfWcY=; b=RIg/Rj/3hDRe5yfcdjpKGUGiNaIzUltcxRuvWWbPBY19CGBaBp6ipU1+99h1FuCB+R ahXgDwtnWiWNFxTQfiR5Aie/79LKeaJGrQO7cem4s+DMxoB11muh9SFX8YEE6hjBtipI Q5ItNS3PV4y3h+WlTyPffccZB2D4r591E/RK3QfISdhxCrp/txe+6Uj9RqdLLFwWcwzV MWXog+547Y+CfDu00qqiTKxzBZpB7qyblXz7oJiiqnXWvWen5qzNiFbaHEcDfTwccDnb meXPyDD1cTWgzDtcbU2vjQO+OC7PmDb5PWd+1E7cF++/uEK2qSwOhedzoYRE8aLU1dvj CtJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=u89s35pdc4dOlb0PTGmaWtiah3AT4mrbdJQetYFfWcY=; b=AHO7HpaArnlXL8E5oAE2k0DaeUywHzXZJj+IRT9/rrh0QzMybDEiJ2R9XxoZ1YYycK STQQbrkB/qNClJiELNj/98Kd45TM7GAh29LejGBKQsxUMxmKOsEdfc9UWgvFwgVf9m90 +Z2QGsh3Vl7fFNq+ycqcWuG5/IAzW6C4a5WH1wrNwivAK+7CxJy+oeBS5q53qDpjR9yp +s06ecKsdRjhM0khdI7XVXe4AyQjk5QS63VTGsE2js4ydSo1uAgkeBcbjHJtFYsiHxND 33QwifmiHltinhWVcVPtV36p0QOz+812Ny4IO+e+z6op8dr/hAxMDghc6ONfZYCmpBLG G1rQ== X-Gm-Message-State: AOUpUlEMCsIMDCdmB7k1METXwHxgxb7KftZ6DA+Y0lsu/GuCU7rla8ab RMUhEU8HIZcgkuzlTuDGH1b40NweWBoKZ6aBDJ6aVXLa X-Google-Smtp-Source: AAOMgpcFYJ95lDUbZyNZ75tYgPW17MgZBGmDroYwB1TgYNnw+ZnaLlayu8Ku+VNv2Ay8z32NovoE3Fu2SZQRj/MQ2Zw= X-Received: by 2002:a2e:990b:: with SMTP id v11-v6mr15640148lji.87.1533657841607; Tue, 07 Aug 2018 09:04:01 -0700 (PDT) MIME-Version: 1.0 References: <87vaambccw.fsf@ta.scs.stanford.edu> <87h8m5e71a.fsf@ta.scs.stanford.edu> <87efh80zs0.fsf@ta.scs.stanford.edu> <87muvu1pra.fsf@ta.scs.stanford.edu> <87k1qubs0z.fsf@ta.scs.stanford.edu> In-Reply-To: <87k1qubs0z.fsf@ta.scs.stanford.edu> From: Piers Powlesland Date: Tue, 7 Aug 2018 17:03:50 +0100 Message-ID: To: David Mazieres expires 2018-09-17 PDT , din@irtf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Din] New SCP draft 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 16:04:06 -0000 Hi David, Thank you for the clarification. Piers On Tue, Jun 19, 2018 at 6:33 PM David Mazieres expires 2018-09-17 PDT wrote: > > Piers Powlesland writes: > > > Ahh, I think I was misunderstanding the definition for quorum threshold. > > > > Please could you clarify if my current understanding is correct? > > > >> 1. "v" itself has issued (digitally signed) the message, > > > > This part is self evident. > > > >> 2. The number of nodes in "validators" who have signed "m" plus the > >> number "innerSets" that (recursively) meet this condition is at > >> least "k", and > > > > Here I am interpreting "(recursively)" to be applying to the innerSets, so for > > each innerSet the number of validators plus innerSets that have signed "m" > > must be at least this innerSet's threshold, and so on for this innerSet's > > innerSets recursively. > > Correct. > > >> 3. These three conditions apply (recursively) at some combination of > >> nodes sufficient for condition #2. > > > > Here I am interpreting "(recursively)" as applying to nodes. Meaning > > that these 3 conditions apply at some set of nodes that are sufficient > > for condition 2 to hold for this node, but also they apply at all the > > nodes from this nodes validators and inner sets that have signed > > message "m" and are contributing to this node meeting its threshold > > and so on recursively. > > Correct. > > > If the above is correct, I am wondering what is the mechanism for a > > node to learn about the messages signed by nodes outside of its slices > > but inside it's quorum? Or put another way, how is a node able to > > acquire all of the information needed for it to determine if it has > > reached quorum threshold? > > In Stellar, the messages are broadcast through an overlay network. > However, this is really out of scope of the consensus document, because > end system multicast is an independent problem. A dumb thing you can do > is just have each node configure a number of peers and flood each > message to every peer that has not yet received it. That will cause > redundant traffic, but at least get the job done. > > David From nobody Tue Aug 7 09:58:27 2018 Return-Path: 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 92A55130F25 for ; Tue, 7 Aug 2018 09:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 VdM4BU3VnSXE for ; Tue, 7 Aug 2018 09:58:23 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 5A11812777C for ; Tue, 7 Aug 2018 09:58:23 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id y17-v6so13985268ljy.8 for ; Tue, 07 Aug 2018 09:58:23 -0700 (PDT) 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=FIPX/DTJQvR/UEcwjK9SCYceEMSVaqfYL9nd7x/1hLw=; b=ksU11QAOE9PE7Kg79ba5QuOrF/WHo8OixDJhBmMVKMUQIfxy3bevvU1UD+nKSKk02F 1yajSFsAGiTWfPYuCoJWLTpugWYt9LlOoRSucBpVEQdtMcetCpVVcEY+2zxFolEJYx6q 4Mr5ch/41p0FQnf7AndwczNjGCU4cpYuj5eb34tAK791WQaVv89yoQdKG1QKNbBALVde FpU2Fq5WQgEeqS9lI82jfm57A0wK41VuwAxQ3eGvKr/rRqwpQCuccpUf/q7KlZYDGlnl iYP25TfdSi7sVbs2d1hjGZcHfbqR8E27IMQCq4nUkU4LW+MEQRrflis+J60VPaCstfB2 Bk7A== 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=FIPX/DTJQvR/UEcwjK9SCYceEMSVaqfYL9nd7x/1hLw=; b=e19Nx4NZHQGV46tAjVFv7E7CTzsUuh54QHcCWNBxYhd/tRESjM2w00C0ySqHvAa9If wJT7z8JpiXkvcGX4uH4VA+QbWiPlXEbkVw+dmsro4AZr7LRrHgUiIsGr8o+o7mDsr+Co dl4igS9N7exyVuzAJZBG+J0HH/7ISt3ICjuMeN2ThWDFq6SAYwXVs7N1o/yfkuslXDAL pdfWkSUSRAoppCpanoRe9CPfByMaSzKGAHtTwU2oEnmQeMWdZvEEFz+M3AJ58Wu/cVnD G9sNfwKRAHkoXymXU8LnUhxQ4Q+6KMbeAPvcj2k1/ckkrFq4NCTTmXpOkb/vYtj2IEeU zFsw== X-Gm-Message-State: AOUpUlFUjuZ3DtfjuJkz6WZ+glnyX/4xOU1KTNLJ5fPthzs0854Cn20S 9vZRToTqEXtuCYWQwjsdnlbt+RCdlNwbNQgBrF6v2AOwhXQ= X-Google-Smtp-Source: AAOMgpf8mdrqIQaRnCAOwTvGHVLXLjCiv180DZiiCKpV9yRX1mrka4EKpbquFgLsqrxE6V/TTa66UX1p2Jz0iruAmng= X-Received: by 2002:a2e:59d1:: with SMTP id g78-v6mr17221466ljf.79.1533661101204; Tue, 07 Aug 2018 09:58:21 -0700 (PDT) MIME-Version: 1.0 From: Piers Powlesland Date: Tue, 7 Aug 2018 17:58:10 +0100 Message-ID: To: din@irtf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 16:58:26 -0000 Hello, On page 10 of https://tools.ietf.org/pdf/draft-mazieres-dinrg-scp-04.pdf an algorithm is described to determine the priority of peers for a given node. Peers are selected from a set "neighbours" based on a priority calculated for each peer. The "neighbours" set is constructed by taking the set of peers that constitute the quorum slices for a node and then filtering them to remove any peer for which sha-256(slot_number || 1 || nomination_round || peer_id ) < 2^256 * weight(peer_id) Where "||" means concatenation of serialised values and "weight(peer_id)" is the fraction of slices containing peer_id. 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? 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? From nobody Tue Aug 7 13:02:37 2018 Return-Path: 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 ; 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 ; 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 ; 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 To: Piers Powlesland , din@irtf.org In-Reply-To: References: Reply-To: David Mazieres expires 2018-11-05 PST 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: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 20:02:35 -0000 Piers Powlesland 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 From nobody Tue Aug 7 13:08:28 2018 Return-Path: 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 295FD1310C9 for ; Tue, 7 Aug 2018 13:08:27 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 hxBk5jepHR3l for ; Tue, 7 Aug 2018 13:08:25 -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 D4ADA1310C3 for ; Tue, 7 Aug 2018 13:08:25 -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 w77K8OM4085305; Tue, 7 Aug 2018 13:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scs.stanford.edu; s=scs; t=1533672504; bh=WRURceUWu7iBDb5ka1RsIJoFrjHFVuGOObBSQ6q5Veo=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version; b=k29rarBdTNSmORjDkP470HsCbJnLG55N9WMx2nQ0QmFlxF0B5TITAOGZnD/uGL2Bg sVU2HEJyxrX+f4GtjQ4ooNRzQ5Ei2UZeG6TKYKAwEBNjzESbkNuca8vjRzSFj1ugST jrgwTzCs6ykl5crs35X5ydfZOpR+n/mpQEmuVdw0= Received: (from dm@localhost) by market.scs.stanford.edu (8.16.0.21/8.16.0.21/Submit) id w77K8Onl081658; Tue, 7 Aug 2018 13:08:24 -0700 (PDT) From: David Mazieres To: Piers Powlesland , din@irtf.org In-Reply-To: <8736vquer0.fsf@ta.scs.stanford.edu> References: <8736vquer0.fsf@ta.scs.stanford.edu> Reply-To: David Mazieres expires 2018-11-05 PST Date: Tue, 07 Aug 2018 13:08:24 -0700 Message-ID: <87zhxyszwn.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 20:08:27 -0000 David Mazieres 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. I went to clarify this in the draft and realize it's not clear at all because of the way slices are defined. (You implicitly have to be in a quorum, but it never says you are in every slice.) So I propose the following wording on neighbors: o Define the set of nodes "neighbors(n)" as the set of nodes v for which "Gi(1 || n || v) < 2^{256} * weight(v)", where "1" and "n" are both 32-bit XDR "int" values. Note that a node is always its own neighbor because conceptually a node belongs to all of its own quorum slices. David From nobody Wed Aug 8 11:29:00 2018 Return-Path: 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 154D7130EBF for ; Wed, 8 Aug 2018 11:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.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 bJSmNLfU3i5X for ; Wed, 8 Aug 2018 11:28:57 -0700 (PDT) Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (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 A27F4130EBD for ; Wed, 8 Aug 2018 11:28:57 -0700 (PDT) Received: by mail-pl0-x236.google.com with SMTP id b90-v6so1402212plb.0 for ; Wed, 08 Aug 2018 11:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ZDMLu2hjOx7ERLz6GM1ED+Lsat3i1K9cYwgpAPFRigQ=; b=ZP5rAx6/4R/rD9HB30daVPIioIsZWDFCbdPqSKOYEPvzMrKlbeonC1r0cQdOZGO9UM dk2E4D8kFhsjqpFSOR1OiK/mTWEeWeQh5WSk/G0HDgV/Lxn+FkiCDzFGFgoV1WaW7RtO TrvYGjS0l9xdZimmu4wjoua5BELPgEAAlU4y0dcTsnJ9wkrVBFQ8u+bMhOPYrPljreXe sEq/yh3ebZksMdISxYd1WAGDcuIfadm7+F4mHp17TBrQ2R/SBEwtLo1GWDCLPp5GHSgm LTof4U9+7b4cmku7bhHVX9CeRUaSK7dntgZ54hzgPxn1voRWAephmSJyTwZmUPAqMal0 hXXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZDMLu2hjOx7ERLz6GM1ED+Lsat3i1K9cYwgpAPFRigQ=; b=kj/S++J5tI7hWG92tiLgdCEHIogL8IFOcX9E4ZUIcqPTCYSZEN9Z6O5kkTGE2sNh3O lnGJa/vSGoUu7JJqDNURzEosnghFAqmVZdekjGf4RSogjoIzpxouvuOICWPq0ONz8uoQ YaSMLM4u5UG0YQIxn/qrInqGnLsMm11XqXnwMHQHKKfwt7ADqFFwltZqA07IFeh/Xl1s oA5n1QXBfskBlLbw2Okx4Z5+omONODYngck4kdwjOObBGV1uc2bZOcTrKIjWWS19J2Iz kiuHs6f5uVFvPP85GTB6OaH7XXHBfknW92s0G38oLpJLwM/VLJnDg2OhqowJG+TWORer lxtA== X-Gm-Message-State: AOUpUlED02/n0dOduHcMFciwyVSmaQgUCpxcLLe2Tie0qmi5rYoAin3s SmdExDcqBff++B1Cax4KDAdw X-Google-Smtp-Source: AA+uWPz7ND+q24JGUJS/7yKVBLoGVbQUsBqQhqZjlryC2Q/7kuxO9PcZMOvOUS5J/c0oQity2i0hCA== X-Received: by 2002:a17:902:26c:: with SMTP id 99-v6mr3472208plc.341.1533752937141; Wed, 08 Aug 2018 11:28:57 -0700 (PDT) Received: from aspen.local (216-67-116-106-radius.dynamic.acsalaska.net. [216.67.116.106]) by smtp.gmail.com with ESMTPSA id p26-v6sm10418158pfi.183.2018.08.08.11.28.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Aug 2018 11:28:56 -0700 (PDT) To: Nathan Aw , din@irtf.org, ietf@dkutscher.net References: From: Melinda Shore Message-ID: Date: Wed, 8 Aug 2018 10:28:54 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Din] Decentralised Public Key Infrastructure (PKI) D-PKI / Decentralised Certificates Authority (CA) - Nathan Aw from Singapore 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 18:28:59 -0000 On 8/8/18 6:40 AM, Nathan Aw wrote: > Hi Dirk, Melinda, All, > > As part of "Trust management in decentralized communication settings", I > am requesting for Hyperledger Indy (Soverin) to be added. Hi, Nathan - Typically the way we work is through presentation and discussion. IRTF research groups do not typically have the sorts of deliverables associated with work in the IETF, and if the RG does decide that a draft should be adopted for publication as a research group deliverable it's after quite extensive discussion on the mailing list. So, if you're interested in seeing this published through the IRTF at some point in the future, you'll need to start with discussion and with incorporating feedback from other RG participants. We should note that we're waiting to hear on whether or not we're approved as a full research group. Many thanks! Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F From nobody Wed Aug 8 23:48:28 2018 Return-Path: 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 54ABE130DE1 for ; Wed, 8 Aug 2018 23:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.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 xIMnFRqpfX1m for ; Wed, 8 Aug 2018 23:48:25 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 D08DA12DD85 for ; Wed, 8 Aug 2018 23:48:25 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id a26-v6so2371310pfo.4 for ; Wed, 08 Aug 2018 23:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=NSCmzf6O5VIkhVM8bLPc3KdxVMVTZ7Q9eP8RxRpQc74=; b=SSXk9ERTHvGVt1dURVZbxlAiFun7yAs2NOWsgNtSjhEl+buJuQpWYkWJTZZTh0k8x2 asuDKVjLDttAICnT2KUmHAZnR5i+4JUZBnF4l0F/3Ny+cySj3A3WVwRBwKTNUdOUWFJw RMRxo3kSxzBwicgLPfpb+81KDyyeW63bpzfeTXb9F99AkeCB7cPaje3K37xJfWiAdExT Hi3OtO5o1ixOgrW+Im+xR+XNf2dsBBxotS2uglOkc8x12mxnIviEzSU1kfBriS9Zw0V/ vzjeTIlPMQU8HJGA82y9HPQHoRSOfENhHnU23IPgruo+lU+inrzTicaUF/cc7ZV0OQxx dPEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=NSCmzf6O5VIkhVM8bLPc3KdxVMVTZ7Q9eP8RxRpQc74=; b=MPv9h00SZmb5srjZ4ibgqwFzFjaaqT34ejLnNciZzvCjbqNlUbmsn5pspy+rZosP/d 6idxg3SwptjMTk75BJpicwhwCyXCJQz9+Hkhl3YJ5hZyAa0OEWQaktwpn0cR7H5nmZll lp34Phn8YQtOQymHXsdxi5dOvlXMnYSkIdJQ71ooePeIMorH1LN1DuGIpq86b6y/o7yt uBlPgB+Ww6u+OSP5oFKS+isR5EZG1t/OKwXgyq8PQbpacJwmAdQyEJJmrdELUYc309BK 81aARGKCg6s04bs/lA8l5ordcW9PW0OxSaxFxjH8It/WK6bmMWN1uXMtbJk8BfBbyZf4 iKwg== X-Gm-Message-State: AOUpUlEkCt5RBmUfxi3HiUYy2PzV/YjLWeD/YS2HRkr8g8niNVxz7bkL rDZIvtJfh3mLF6JuhGgHnNvZUkNwzA== X-Google-Smtp-Source: AA+uWPxpFA/STw4YsgrQLZ3prZAz7eLzJnL31aLD2wNUDPMaCRMZu742g1GSdsiPtsWeQz2YeZ713g== X-Received: by 2002:a62:4909:: with SMTP id w9-v6mr1022839pfa.154.1533797304890; Wed, 08 Aug 2018 23:48:24 -0700 (PDT) Received: from aspen.local (216-67-116-106-radius.dynamic.acsalaska.net. [216.67.116.106]) by smtp.gmail.com with ESMTPSA id g184-v6sm15886365pgc.22.2018.08.08.23.48.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Aug 2018 23:48:24 -0700 (PDT) To: "din@irtf.org" From: Melinda Shore Message-ID: Date: Wed, 8 Aug 2018 22:48:23 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Din] Minutes from IETF 102 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 06:48:27 -0000 Hi, all: I've uploaded an initial draft of minutes from our session at IETF 102, and they're available at https://datatracker.ietf.org/meeting/102/materials/minutes-102-dinrg-00. Please review and send corrections, etc. to the mailing list. Thanks, Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F From nobody Fri Aug 10 10:14:42 2018 Return-Path: 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 AA175130E5C for ; Fri, 10 Aug 2018 10:14:40 -0700 (PDT) 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 fViMXZ1U_vQI for ; Fri, 10 Aug 2018 10:14:38 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 E57D3130EA3 for ; Fri, 10 Aug 2018 10:14:37 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id u202-v6so7069256lff.9 for ; Fri, 10 Aug 2018 10:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LbcHGbs7MOfj/+qMcaFsD0OZTY6Ya9A5v49ZRz8gZ/I=; b=gWmRPPxWAHwdZNH0F145rLh2XydXtsOOwXsHQzxUXRkzXVC+jwN4gnfD3V+JgGFY7i jRwQkG/59fDcsV809Kpu/W3KJHimcSsBSYnr8DX/+4JE6BjxH5P3HSvktuEFuLbNiO4e BOmnsDvhEUVxHtwTYw82/doIwmACkJ7Ju2QUmKYAGWvh1F8B5Engnf5DIaXf4ToQbhy1 Jx484m+6o89BO6w9LuuZxFPja1RUL7Uwe6FQIM+Q6jrvbFcHtS7sNoeOSetCOdJ49ne0 xH6gNP4aWbmtWbiGium4/kRBcuYQYfAanDH6wTxOgtqGaQzNYvzPVy1RQrNncs9LSLqm VZYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LbcHGbs7MOfj/+qMcaFsD0OZTY6Ya9A5v49ZRz8gZ/I=; b=ch+rcIsJ5UwBcCKzqvfCMlcGWIBTmCmrOTcpbqrAVKLhS9Gxvjq7XlPJGAENSB9iMc zpNaeAYKMVSagBgOkSIOFFnrXlWADs4XhfSNTj+wM/uu6VD8eoroGt3Q00EY+BTRYRg0 O+5szsB9dLMABCX9U4BMG4mcxSfQtbRFzFNN0MeFoOvqUCn18k/Ecpci1CKxksH9uDSz AzsS3iG76acXQfChLFIyQhEvVfwyxXnXSpMBIBW8+SJ3jT0EJ0lvRFKqa0Y70Fxtpkd8 fLzF1dEXCRPaJtnPkm8whtG/MQrSOfG6vT+Y9Ou/iWeK3+jrZ8f98mdcg+udz0sP5Z+w Wq4Q== X-Gm-Message-State: AOUpUlF6ZgpvXlluE9ajFgf3LP/km71JjsEU2y2dmmOPyk14NBuIJUnq y2pgIv4Df/euUd/AfFC8QiGDrcUc5oxdIUIgAmfzmoDA X-Google-Smtp-Source: AA+uWPzEwSCNJK03Sen/rk1CE3SEdl3fAvqtBRe3bbfI9VWcrPwglAsybYJoGAUZxgxUo7yZZmTAG+UcdUeARPbThfg= X-Received: by 2002:a19:5d54:: with SMTP id p20-v6mr4858746lfj.143.1533921275885; Fri, 10 Aug 2018 10:14:35 -0700 (PDT) MIME-Version: 1.0 References: <8736vquer0.fsf@ta.scs.stanford.edu> <87zhxyszwn.fsf@ta.scs.stanford.edu> In-Reply-To: <87zhxyszwn.fsf@ta.scs.stanford.edu> From: Piers Powlesland Date: Fri, 10 Aug 2018 18:14:24 +0100 Message-ID: To: mazieres-w6kdgs48q4kevhhfbq3r54nani@temporary-address.scs.stanford.edu Cc: din@irtf.org Content-Type: text/plain; charset="UTF-8" Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 17:14:41 -0000 Hi David, The new wording looks good to me. And thanks for clarifying the 2 stage approach to choosing a preferred peer, I can see now that my approach would not correctly reflect the importance nodes as they appear in SCPSlices. On Tue, Aug 7, 2018 at 9:08 PM David Mazieres wrote: > > David Mazieres 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. > > I went to clarify this in the draft and realize it's not clear at all > because of the way slices are defined. (You implicitly have to be in a > quorum, but it never says you are in every slice.) So I propose the > following wording on neighbors: > > o Define the set of nodes "neighbors(n)" as the set of nodes v for > which "Gi(1 || n || v) < 2^{256} * weight(v)", where "1" and "n" > are both 32-bit XDR "int" values. Note that a node is always its > own neighbor because conceptually a node belongs to all of its own > quorum slices. > > David