[Blockchain-interop] Terminology and Gateway Session IDs

Thomas Hardjono <hardjono@mit.edu> Wed, 27 October 2021 14:11 UTC

Return-Path: <hardjono@mit.edu>
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 6017A3A0C6E for <blockchain-interop@ietfa.amsl.com>; Wed, 27 Oct 2021 07:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 d0QxfwOIcOBh for <blockchain-interop@ietfa.amsl.com>; Wed, 27 Oct 2021 07:11:36 -0700 (PDT)
Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (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 370D83A0C74 for <blockchain-interop@ietf.org>; Wed, 27 Oct 2021 07:11:36 -0700 (PDT)
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id 19REAa2L005290; Wed, 27 Oct 2021 10:10:50 -0400
Received: from w92expo23.exchange.mit.edu (18.7.74.77) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1497.24; Wed, 27 Oct 2021 10:10:23 -0400
Received: from oc11expo23.exchange.mit.edu (18.9.4.88) by w92expo23.exchange.mit.edu (18.7.74.77) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Wed, 27 Oct 2021 10:10:39 -0400
Received: from oc11expo23.exchange.mit.edu ([18.9.4.88]) by oc11expo23.exchange.mit.edu ([18.9.4.88]) with mapi id 15.00.1497.023; Wed, 27 Oct 2021 10:10:39 -0400
From: Thomas Hardjono <hardjono@mit.edu>
To: "blockchain-interop@ietf.org" <blockchain-interop@ietf.org>
CC: Denis Avrilionis <denis@compell.io>, "luke.riley@quant.network" <luke.riley@quant.network>
Thread-Topic: Terminology and Gateway Session IDs
Thread-Index: AQHXyzvxqd3B0DelM0GggeFxNtcaUQ==
Date: Wed, 27 Oct 2021 14:10:39 +0000
Message-ID: <1f53592c1bf841edb2ce8524189ae7de@oc11expo23.exchange.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [73.100.88.16]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/blockchain-interop/b9VKQNjHPSgl0eDIopS3EnF3PP0>
Subject: [Blockchain-interop] Terminology and Gateway Session IDs
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, 27 Oct 2021 14:11:40 -0000

I thoughts yesterday’s discussion was very illuminating (thanks Luke and Denis).  

It highlights the fact that we are bringing together concepts and terminologies from three different disciplines: (i) software applications/cloud engineering; (ii) database transactional processing (e.g. 2PC and 3PC, etc.); and (iii) DLT and blockchains (e.g. consensus/BFT, finalization, views, etc.).

Here is the link to Denis’ slides on the Github Repo:

https://bit.ly/3CmxiR1


For our terminology, I was thinking of qualifying the use of the word “transaction” going forward and use the following:

-- Gateway-to-gateway transfer transaction (or simply:  gateway transaction).

-- DLT transaction

-- Application-to-Application Interaction (or simply:  application interaction)


For the session IDs, can we assume there are four (4) different “sessions” used:

(a) Between gateway GW1 and gateway GW2  (who chooses the Session ID).

(b) Between APP1 and GW1 (local session)

(c) Between APP2 and GW2 (local session)

(d) Between APP1 and APP1 (app-layer session)


I have a couple of questions about the Gateway SessionIDs:

(i) In the gateway transaction, which gateway selects the Gateway SessionID? (is it GW1?).

(ii) Can we assume that GW1 will communicate this SessionID up to its APP1, which will then communicate it to APP2 (and then down to GW2).

(iii) Can we assume that APP1 and APP2 will “bind” the Gateway SessionID to their own app-layer session identifier? (nb. the mechanics is out of scope for us, but we still need to state assumptions).

(iv) Do Views use SessionIDs?  That is, when GW1 generates a View Data (as the result of GW2 invoking the View Address from DLT1/N1), is there some "embedded" session numbering associated with the resulting Data?



Best


--thomas