[Din] draft-mazieres-dinrg-scp-04 (page 16) Potential improvement to balloting protocol, setting cCounter

Piers Powlesland <pierspowlesland@gmail.com> Fri, 02 November 2018 14:41 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 CCF2D130DCE for <din@ietfa.amsl.com>; Fri, 2 Nov 2018 07:41:25 -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 1CeLO_n0lUr1 for <din@ietfa.amsl.com>; Fri, 2 Nov 2018 07:41:24 -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 1FAF0130DC1 for <din@irtf.org>; Fri, 2 Nov 2018 07:41:23 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id x3-v6so1932509lji.13 for <din@irtf.org>; Fri, 02 Nov 2018 07:41: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=laxkGtzjlTIM1MdV4vgpUzNG0ZuUK3j7zrgefVgayCc=; b=VD4Esy3NJvKJXCv03nlQ8KwTDbRouu+q8bopXa11oHjleiYYygbopuT7Hi+2VncDMJ luUBB2E/RIcfeodIujmr+/tb+SR2G+bIwmqvz1hDj8/zp0iam1BFiEQCbReJIXZg5jHU 4+ux9HTT3f7451PKBfXmat97BXSdK7qcuVhpuWUhJHMQNfVHL8zuChcJtnAcDWC8e6Ne 8l0XBC9PvMjUghynVZYyplkuQHLZ+fSTjaGDPvQs5CLKtEhwrVIrNnqh56tLSmZtRQPD aWe/+bmzw1ImvEseScFaDiGBOUozG1eayTNe5HPjYyMNW+/utPsSjfx7+JE9igL5Z6BP AinQ==
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=laxkGtzjlTIM1MdV4vgpUzNG0ZuUK3j7zrgefVgayCc=; b=dbd5zRD+Wy3QGzU2xLv9//nJpVcBAmgUU80lPC+sL1E/4Meu1ekNbru/X7FtVcQYU9 F3gUFGP3p0iZ4fgycgu2UeYisrQlQ7PNthy0BH6nn0vkOIA2qK1+CIkVIIt1PWQjFjgU yeqSgSGNl5ti27JAXelRo/3D4vIHxC+Pv8QH8pR9m12DFGPx1Ym4/06LAkHFI6JCVq3e 2m328HSC1KQ/kl85MRkB/SG/d/bqO37OAyqSGB1dRwqXH8gsma8sY4WVLoxSO8xn8Pb7 DGIgfQileea6dvomAIzAxMWRrxuHYH9YSpKc+EOmcmQKGZdTbscp6uJ10ZOThxN+dXPZ gasQ==
X-Gm-Message-State: AGRZ1gJiOZIYkfkD/AIQQzlIi3uo2WTQG4327CkW/G97g9RJatOsERMb UgCcJMsYRQN17f1ftl5bifkBBZgqW2kupwmMaT4roso+
X-Google-Smtp-Source: AJdET5eaHEK5HZ64i/jvOXc5h+ae0bsA+B7AdY8sjihrf0vxRIFgLltc47Amc69PLzLMJzFv8zzTasN3y+WLqAjvGxQ=
X-Received: by 2002:a2e:95c6:: with SMTP id y6-v6mr7643885ljh.59.1541169679628; Fri, 02 Nov 2018 07:41:19 -0700 (PDT)
MIME-Version: 1.0
From: Piers Powlesland <pierspowlesland@gmail.com>
Date: Fri, 2 Nov 2018 14:41:08 +0000
Message-ID: <CAFXacXm5U6VNEyQ3ienwgcGaAj1yQ1YVJNFT1eY9EMRsNFZ9hA@mail.gmail.com>
To: din@irtf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/Z73oDkHZBceJJdojaXmZNRLh7AU>
Subject: [Din] draft-mazieres-dinrg-scp-04 (page 16) Potential improvement to balloting protocol, setting cCounter
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: Fri, 02 Nov 2018 14:41:26 -0000

I think it may be possible to improve the chances of nodes being able
to accept ballots as committed during the prepare phase.

The following instructions are given to update cCounter.

> * If either "(prepared > c && prepared.value != c.value)" or
>   "(preparedPrime > c && preparedPrime.value != c.value)", then
>   reset "c = NULL".
>
> * If "c == NULL" and "hCounter == ballot.counter" (meaning
>    "ballot" is confirmed prepared), then set "c" to "ballot".


If we consider an example where a node has the following state.

ballot = (8,x)
prepared = (8,x)
preparedPrime = (3,y)
cCounter = 4
hCounter = 8

If the node accepts prepared (4,z) then using the update steps above c
will be set to NULL and then c will be set to ballot. This means that
the node will transition from voting to commit ballots with value == x
and counters 4...8 to just the single ballot (8,x).

Out of the ballots that the node was previously voting to commit only
(4,x) has been accepted aborted due to setting preparedPrime = (4,z),
so it seems that it would still be legal to vote to commit ballots
with value == x and counters 5...8.

So I am proposing that the first part of the above update step is
changed to the following, to allow for that.

> * If c != NULL set c.counter to the counter of the lowest ballot with value ==
>   h.value and not accepted aborted according to p and p'. If c.counter >
>   hCounter, then set c=NULL