Re: [Ilc] Clarifications and thoughts purpose of ILC list

dm-list-ietf-ilc@scs.stanford.edu Thu, 23 February 2017 20:03 UTC

Return-Path: <dm-list-ietf-ilc@scs.stanford.edu>
X-Original-To: ilc@ietfa.amsl.com
Delivered-To: ilc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70311299F9 for <ilc@ietfa.amsl.com>; Thu, 23 Feb 2017 12:03:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Mt73ZP0oazTQ for <ilc@ietfa.amsl.com>; Thu, 23 Feb 2017 12:03:36 -0800 (PST)
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 EABF4129853 for <ilc@ietf.org>; Thu, 23 Feb 2017 12:03:36 -0800 (PST)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v1NK3aD1058239; Thu, 23 Feb 2017 12:03:36 -0800 (PST)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v1NK3a2w088645; Thu, 23 Feb 2017 12:03:36 -0800 (PST)
From: dm-list-ietf-ilc@scs.stanford.edu
To: Tony Arcieri <bascule@gmail.com>
In-Reply-To: <CAHOTMV+oupVB1Ems309FYFEY80OjvTijK27qeeTaL_hkzotYqQ@mail.gmail.com>
References: <87bmu194rx.fsf@ta.scs.stanford.edu> <CAHOTMV+qx_a44MNAaFN-M7YzA-rkmtRCRS_nNGeSibgNHUshrA@mail.gmail.com> <87poiaf5h5.fsf@ta.scs.stanford.edu> <CAHOTMV+_4E-Cf=7aKPiKpfT_dievyiABVMbkD=U81MJePttD4A@mail.gmail.com> <87ino0d808.fsf@ta.scs.stanford.edu> <CAHOTMV+oupVB1Ems309FYFEY80OjvTijK27qeeTaL_hkzotYqQ@mail.gmail.com>
Date: Thu, 23 Feb 2017 12:03:36 -0800
Message-ID: <87bmtsd693.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/ilc/fSl9ZKqMK8jxg0w_ddjhYWqzMEk>
Cc: ilc@ietf.org
Subject: Re: [Ilc] Clarifications and thoughts purpose of ILC list
X-BeenThere: ilc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: David Mazieres expires 2017-05-24 PDT <mazieres-rya2i9rr4x6j5putmmzqy5skkw@temporary-address.scs.stanford.edu>
List-Id: "Discussion of mechanisms and applications for Internet-level consensus." <ilc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ilc>, <mailto:ilc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ilc/>
List-Post: <mailto:ilc@ietf.org>
List-Help: <mailto:ilc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ilc>, <mailto:ilc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Feb 2017 20:03:38 -0000

Tony Arcieri <bascule@gmail.com> writes:

> Correctly designed AP systems support a merge operation to reconcile
> disparate states. CRDTs are an example of a system that can always merge
> data automatically in a conflict-free manner...
>
> ...
>
> The main option, which is particularly applicable to systems which publish
> to read-only clients, is to allow stale reads. This flips the semantics
> from CP to AP, allowing inconsistent views of the current state of the data
> (i.e. sacrificing consistency for availability), but should be safe if data
> being read is not incorporated into subsequent writes (i.e. stale reads are
> only allowed by truly read-only clients)

Ah, so I agree with the points you are making, I just think they are at
a different level of abstraction from the consensus mechanism.  In other
words, I can take a safe consensus protocol and use it to implement a
secure read-only log.  That log abstraction might support an operation
along the lines of "verify that some log prefix satisfies some
predicate," which one might then use to check that a particular
transaction committed, or to get a recent value of some variable without
necessarily knowing the latest.

So the question is not "are weak consistency models useful for systems?"
to which the answer would be an obvious yes.  The question is what, if
any, support would weakly consistent systems require from an underlying
Internet-level consensus protocol?  My preference would be to answer
"none," because I worry such support would complicate reasoning about
the safety of strongly consistent systems.  But that's obviously a good
topic for discussion on this list.

David