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

Tony Arcieri <bascule@gmail.com> Thu, 23 February 2017 19:38 UTC

Return-Path: <bascule@gmail.com>
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 C31B3129A4A for <ilc@ietfa.amsl.com>; Thu, 23 Feb 2017 11:38:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 yskioyCSv0lq for <ilc@ietfa.amsl.com>; Thu, 23 Feb 2017 11:38:39 -0800 (PST)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 60D7B12996D for <ilc@ietf.org>; Thu, 23 Feb 2017 11:38:39 -0800 (PST)
Received: by mail-it0-x22c.google.com with SMTP id y135so15273973itc.1 for <ilc@ietf.org>; Thu, 23 Feb 2017 11:38:39 -0800 (PST)
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 :cc; bh=9FpEe/O12lV60bagn9dmmaBmoku7XgbVz3qYwFxHUb0=; b=ZfKZ+NxG/A4AvgIdrGystM56deq78m80QX4kl+OgUyorc9rU0O3XKD0OTD+u1w9ryP yflK77U/MeXnd3zn28AGaRLsHqHomB9R16gBHkmZVfxPyCGIOtp5qvGx6GpRsbEc0Z/n QUPkiaL34Y0DY6QhXiv3LgdPGGCK8dh+1xPV6lSjLpGrztyiYweD6QNq3l3j+++EFYqs 76p0Kw2HWEc6lWWQTvGgv274hr/LtiYeg94jmU8R92AS7rW2gPPkNXfr9iLhmoQsIiYS ehHHBdIgCtMNpFxVGerSB6p90jt8iApgzdJ4syzMRDx5/XY4yRPo2lCnNJIGLYuvsOl4 8yoQ==
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:cc; bh=9FpEe/O12lV60bagn9dmmaBmoku7XgbVz3qYwFxHUb0=; b=YCBmBYaEa05yj7Smdt9RriZKChyiz+H8Pvf9c9Vg3lgUr8U3/OVXOO8uWjLBRIqhuk kEZhTlN1wL89xbb5r3MGAqbpbjsGv08VvolSUo04hWoomPMNBDXKNQBTIy8CGJYRXPuA 62Ciamd+V9Dado12rfFVfB/SqwybhSWtybbwSV1o11ZFwf/0KLqZlfrNAv0FC+NIEkfX AAqXZhgAP6XS8bcAhrCfnMxIfwxqUctYvakhWggLMXyRIXv9ntEC2XULNA7RjgDP01Q6 taENeEBEY1DnnPcOd8ZvsFMcNUeQV17+JDkCe0yfiF7mbNaot8s9eJpv8gdBAYdQzQkT scKw==
X-Gm-Message-State: AMke39m3AqNFkQICs+2GzJ6WubpQ79+pryFfU3YBy1iwNq3fC3z2E5cYC6/QyD7bs9J64g2mWHMNp5PBj+KJLQ==
X-Received: by 10.107.10.11 with SMTP id u11mr33308230ioi.139.1487878718771; Thu, 23 Feb 2017 11:38:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.5.21 with HTTP; Thu, 23 Feb 2017 11:38:18 -0800 (PST)
In-Reply-To: <87ino0d808.fsf@ta.scs.stanford.edu>
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>
From: Tony Arcieri <bascule@gmail.com>
Date: Thu, 23 Feb 2017 11:38:18 -0800
Message-ID: <CAHOTMV+oupVB1Ems309FYFEY80OjvTijK27qeeTaL_hkzotYqQ@mail.gmail.com>
To: David Mazieres expires 2017-05-24 PDT <mazieres-esgdmdyb3ht2bf46xbpvnxe97n@temporary-address.scs.stanford.edu>
Content-Type: multipart/alternative; boundary=001a113ed60a80594f054937c236
Archived-At: <https://mailarchive.ietf.org/arch/msg/ilc/muTD9ujx0cQSaQd-jZ3oE-tjoTA>
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
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 19:38:41 -0000

On Thu, Feb 23, 2017 at 11:25 AM, David Mazieres <
dm-list-ietf-ilc@scs.stanford.edu> wrote:

> I agree about CP, but not AP.  AP systems are not safe, and hence will
> clobber data.
>

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. In absence of that you need a
domain-specific user defined merge function.

That said Last Writer Wins is a popular strategy in systems describing
themselves as AP, and exhibits this sort of data clobbering behavior. I'm
not sure such systems should describe themselves as partition tolerant,
though.

Right, so basically you are saying any Internet-level consensus
> mechanism should guarantee safety even in an asynchronous communication
> model where you can't distinguish slow from failed nodes.  I agree,
> personally.  However, reasonable people might push for greater
> availability.  It would be interesting to see if list members have
> "rough consensus" (non-technical meaning) on this point, or
> alternatively if makes sense to layer a less safe but more available
> "short-term" system on top of one that guarantees safety for long-term
> events (e.g., for certificates issued over a week ago).  We may want to
> revisit this question down the line after discussing more applications.


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)

-- 
Tony Arcieri