[alto] Draft: Alto for the blockchain

Wendy Roome <wendy.roome@nokia-bell-labs.com> Mon, 11 July 2016 19:55 UTC

Return-Path: <wendy.roome@nokia-bell-labs.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E965A12D19E for <alto@ietfa.amsl.com>; Mon, 11 Jul 2016 12:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 MkIJZQN_6mkI for <alto@ietfa.amsl.com>; Mon, 11 Jul 2016 12:55:58 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (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 1D93512D0CB for <alto@ietf.org>; Mon, 11 Jul 2016 12:55:58 -0700 (PDT)
Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 3D1FC315296A0 for <alto@ietf.org>; Mon, 11 Jul 2016 19:55:53 +0000 (GMT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u6BJtuje006077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <alto@ietf.org>; Mon, 11 Jul 2016 19:55:57 GMT
Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u6BJttN4003859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <alto@ietf.org>; Mon, 11 Jul 2016 19:55:56 GMT
Received: from [135.222.152.71] (wdr-i7mbp2.mh.lucent.com [135.222.152.71]) by umail.lucent.com (8.13.8/TPES) with ESMTP id u6BJtrKU002918 for <alto@ietf.org>; Mon, 11 Jul 2016 14:55:55 -0500 (CDT)
User-Agent: Microsoft-MacOutlook/14.6.5.160527
Date: Mon, 11 Jul 2016 15:55:52 -0400
From: Wendy Roome <wendy.roome@nokia-bell-labs.com>
To: IETF ALTO <alto@ietf.org>
Message-ID: <D3A97208.7D4ECB%w.roome@alcatel-lucent.com>
Thread-Topic: Draft: Alto for the blockchain
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/gB3KqDhl2EwTs0pjj6OkkONoi0Q>
Subject: [alto] Draft: Alto for the blockchain
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jul 2016 19:56:00 -0000

Comments on ALTO for the blockchain, draft-hommes-alto-blockchain-01:


Section 4, second & third paragraphs:

If I read these correctly, the 2nd paragraph says that an ALTO server can
give a new blockchain client a set of existing peers, so the new client
can bootstrap itself. Then the 3d paragraph says that is a bad idea,
because it centralizes trust in the ALTO server, and hence "the use of
ALTO should be reduced to a role of guidance on what peers to select".

However, unless I missed it, an ALTO server simply cannot provide a new
blockchain client with set of existing peers to use to bootstrap itself. A
new peer must obtain that list from somewhere else. All an ALTO server can
do is advise the client about the costs of communicating with that set.

So it seem like the 2nd paragraph suggests doing something which ALTO
cannot, and then the 3d paragraph goes on to say that's a bad idea.

If that is the case, then what is the point of those two paragraphs? So I
suggest deleting the 2nd paragraph and the first part of the third
paragraph.


Section 5:

"approximately every 10 seconds a new block is added"

Not quite! It's really every 10 minutes. If you're lucky, that is. The
distribution has a long tail.


Section 5, 4th paragraph:

That paragraph implies that an ALTO server tells a client about the relay
network. I believe that is misleading. An ALTO server can certainly give
the client the costs to/from the peers in the relay network, but the
client must determine the peers in the relay network for itself.

Perhaps you mean that a peer could look at the ALTO server's full cost
map, including the costs between all the blockchain peers known to the
client, and infer the "relay network" from that? E.g, if nodes 1-6 are
known to be blockchain peers, and if the costs between nodes 1, 2 and 3
are much lower than the costs between the other peers, then the client
could infer that 1,2,3 are better connected and it will get faster results
if it connects to them rather than 4, 5 or 6. If so, then please say that
instead.


Section 5, last paragraph:

"ALTO could further be used to exchange information with the DNS seeds, or
filtering their response of peers by adding other relevant information
obtained by its global view on the network."

Could you explain that in more detail, and/or give an example of how an
ALTO server would do that?


Section 6:

"This requires that the ALTO server is aware of the different roles and
which metrics need to be applied for each role."

I disagree with that sentence as phrased: I believe an ALTO server does
not, and should not, know the client's role.

What I think you are getting at is that different clients need different
cost metrics. For example, a miner is concerned with delay, and would want
a cost metric that reflects delay.

So I suggest rephrasing to say that a blockchain-friendly ALTO server
should provide several different cost metrics, tuned to the different
roles clients play, so that a client can select the appropriate metric for
that client's role.

As it stands now it, that section implies that an ALTO server knows the
client's role and automatically selects the appropriate cost metric. I
disagree with that.

	- Wendy Roome