Re: [Blockchain-interop] Gatweay Crash Recovery Discussion #1

Rafael Belchior <rafael.belchior@tecnico.ulisboa.pt> Wed, 02 December 2020 13:06 UTC

Return-Path: <rafael.belchior@tecnico.ulisboa.pt>
X-Original-To: blockchain-interop@ietfa.amsl.com
Delivered-To: blockchain-interop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21443A13B5 for <blockchain-interop@ietfa.amsl.com>; Wed, 2 Dec 2020 05:06:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level:
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=tecnico.ulisboa.pt
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 mLPNrSNEVBIK for <blockchain-interop@ietfa.amsl.com>; Wed, 2 Dec 2020 05:06:44 -0800 (PST)
Received: from smtp1.tecnico.ulisboa.pt (smtp1.tecnico.ulisboa.pt [193.136.128.21]) (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 F16EC3A114C for <blockchain-interop@ietf.org>; Wed, 2 Dec 2020 05:06:43 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.tecnico.ulisboa.pt (Postfix) with ESMTP id 9D35580089A7; Wed, 2 Dec 2020 13:06:40 +0000 (WET)
X-Virus-Scanned: by amavisd-new-2.11.0 (20160426) (Debian) at tecnico.ulisboa.pt
Received: from smtp1.tecnico.ulisboa.pt ([127.0.0.1]) by localhost (smtp1.tecnico.ulisboa.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id coA9rJHwKxvc; Wed, 2 Dec 2020 13:06:37 +0000 (WET)
Received: from mail1.tecnico.ulisboa.pt (mail1.ist.utl.pt [IPv6:2001:690:2100:1::b3dd:b9ac]) by smtp1.tecnico.ulisboa.pt (Postfix) with ESMTPS id 6886B8C02225; Wed, 2 Dec 2020 13:06:37 +0000 (WET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tecnico.ulisboa.pt; s=mail; t=1606914397; bh=7srRLhc8YR1dQ1C2UDvheEeptWczGQJrCMn9XPJzT+g=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=s5ABibLXn93WCaOf2JkwV/4vOaFb+Ki1PIER0md6VBaBXvGO5gReIJCjjyKqnFzer QMcdpVNjJiDcJ+jS3ocC4xuTtp7Y8NzeqMqcj0NWxHJTauUia6KXtwjPO/bWWCgunB B7+6tKlbdMkKMxfWzGAO7QmPehMkY/T6PeXHwEjI=
Received: from webmail.tecnico.ulisboa.pt (webmail3.tecnico.ulisboa.pt [IPv6:2001:690:2100:1::912f:b135]) (Authenticated sender: ist180970) by mail1.tecnico.ulisboa.pt (Postfix) with ESMTPSA id 5A333360073; Wed, 2 Dec 2020 13:06:36 +0000 (WET)
Received: from [95.77.147.241] via vs1.ist.utl.pt ([2001:690:2100:1::33]) by webmail.tecnico.ulisboa.pt with HTTP (HTTP/1.1 POST); Wed, 02 Dec 2020 13:06:36 +0000
MIME-Version: 1.0
Date: Wed, 02 Dec 2020 13:06:36 +0000
From: Rafael Belchior <rafael.belchior@tecnico.ulisboa.pt>
To: Thomas Hardjono <hardjono@mit.edu>
Cc: blockchain-interop@ietf.org
In-Reply-To: <c0564c70e6a44fd29798e1ee6b4db5ae@oc11expo23.exchange.mit.edu>
References: <666e283e0d7a452fbf31dc7a42ec71b6@tecnico.ulisboa.pt>, <a1666b75233e112cd7d828ea4fa4fada@tecnico.ulisboa.pt> <a40dc7708df646b385e5ebbdcab43781@oc11expo23.exchange.mit.edu>, <a87a56a2e6e85666e32145d1c83e892e@tecnico.ulisboa.pt> <c0564c70e6a44fd29798e1ee6b4db5ae@oc11expo23.exchange.mit.edu>
Message-ID: <baae5633d50058666b7b71bc45ec9ea8@tecnico.ulisboa.pt>
X-Sender: rafael.belchior@tecnico.ulisboa.pt
User-Agent: Roundcube Webmail/1.3.15
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/blockchain-interop/nfcRWnP6cev_FQhvWtJ_im2a6JE>
Subject: Re: [Blockchain-interop] Gatweay Crash Recovery Discussion #1
X-BeenThere: blockchain-interop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Blockchain Gateway Interoperability Protocol <blockchain-interop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/blockchain-interop>, <mailto:blockchain-interop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/blockchain-interop/>
List-Post: <mailto:blockchain-interop@ietf.org>
List-Help: <mailto:blockchain-interop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/blockchain-interop>, <mailto:blockchain-interop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2020 13:06:47 -0000

Thomas,
Yes, those assumptions are reasonable; i) we can also consider the case 
where a public-private key pair is lost, and thus a new pair needs to be 
generated. ii) I think we can assume a new SSL connection is created. Do 
you envision problems with this?

I think it makes sense for the gateway to resume operations from the 
last message before the crash because this mode is blocking, in 
principle - we can resume from the last event.

If anyone thinks this could be improved, please do not hesitate in 
providing feedback :)

Cheers,
Rafael


A 2020-12-02 00:17, Thomas Hardjono escreveu:
> Thanks Rafael.
> 
> Inline:
> 
>>>> > -- Which mode (self-healing mode, or primary-backup mode) do you
>>>> >>> > recommend?  (Which one would be the simplest approach for now, and
>>>> > what assumptions would we need to make).
>>>> 
>>>> The self-healing mode is simpler, as the same machine eventually
>>>> recovers, continuing its operations since the latest log entry. It 
>>>> does
>>>> not require, in principle, to read from the log storage API. 
>>>> However, we
>>>> are assuming it eventually recovers, and while this happens the 
>>>> system
>>>> is down, prejudicing availability.
> 
> For this scenario, there may need to be some assumptions about the
> gateway node.
> 
> For example, (i) the gateway recovers to 100% without any internal
> losses (e.g. loss of private-keys); (ii) that the SSL connection has a
> longer life-time than the duration of crash (unavailability); etc.
> 
> For short-duration unavailabilities, would the gateway pick-up
> (restart) from the last message before crash, or does it start from
> the beginning of the Phase?
> 
> Best
> 
> 
> -- thomas --
> 
> 
> 
> 
>> ________________________________________
>> From: Blockchain-interop [blockchain-interop-bounces@ietf.org] on
>> behalf of Rafael Belchior
>> [rafael.belchior=40tecnico.ulisboa.pt@dmarc.ietf.org]
>> Sent: Monday, November 30, 2020 11:49 AM
>> To: blockchain-interop@ietf.org
>> Subject: [Blockchain-interop] Gatweay Crash Recovery Discussion #1
>> 
>> Dear All,
>> Attached, the slides of the first discussion on the crash recovery
>> mechanism for gateways, that took place during the last meeting.
>> 
>> 
>> Cheers,
>> 
>> --
>> Rafael Belchior
>> Ph.D. student in Computer Science and Engineering, Blockchain - 
>> Técnico
>> Lisboa
>> https://rafaelapb.github.io/
>> https://www.linkedin.com/in/rafaelpbelchior/
> 
> --
> Rafael Belchior
> Ph.D. student in Computer Science and Engineering, Blockchain - Técnico
> Lisboa
> https://rafaelapb.github.io/
> https://www.linkedin.com/in/rafaelpbelchior/

-- 
Rafael Belchior
Ph.D. student in Computer Science and Engineering, Blockchain - Técnico
Lisboa
https://rafaelapb.github.io/
https://www.linkedin.com/in/rafaelpbelchior/