[alto] Reviews of draft-hommes-alto-blockchain-02

[xin wang <[e-mail]>]

Dear authors of "ALTO for the blockchain",


Your draft about using ALTO to improve the communication in a blockchain network looks very practical and interesting. It would be grateful to deploy ALTO in a blockchain network. The following is a review of the draft:


a. Fixed peer relationship or not?


The broadcasting mechanism in a blockchain network needs a node to broadcast transactions/blocks in the network, and the goal is to minimize the information propagation time. The broadcast mechanism depends on peer relationship between nodes to transfer information. Then, ALTO can help with the peer selection process which decides peer relationship based on communication performance obtained from an ALTO server. From the section 3, I assume the peer selection happens at the very beginning when a node joins a blockchain network. Therefore, the peer relationship should be fixed if there is no failure. Then, one question would be that is it possible to change the peer relationship as the system running to get a better communication performance? Here is a draft about ALTO incremental updating (https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/

draft-ietf-alto-incr-update-sse-05 - ALTO Incremental ...<https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/>
datatracker.ietf.org
ALTO Incremental Updates Using Server-Sent Events (SSE) (Internet-Draft, 2017)



) which can be used to get updated values from ALTO server.


b. Centralized peer selection or not?


The draft describes two frameworks where an ALTO client can be embedded into: the Resource Directory and a blockchain node. From my thinking, the resource directory framework really provides a centralized view of a blockchain network, which is able to get the optimal solution for the peer selection. However, if an ALTO client is embedded into a blockchain node, then each node can only make a selection based on information of the neighboring of the node, which may not be able to be optimal.


c. Cost map service and ECS in two frameworks


Another comment about the two frameworks is that you are trying to apply the cost map service for the Resource Directory and Endpoint Cost Service (ECS) for public blockchains respectively. It might be true that requesting a cost map could reduce the information exposure about the topology, but I recommend you for another draft about Routing State Abstraction (https://datatracker.ietf.org/doc/draft-gao-alto-routing-state-abstraction/

draft-gao-alto-routing-state-abstraction-03 - ALTO ...<https://datatracker.ietf.org/doc/draft-gao-alto-routing-state-abstraction/>
datatracker.ietf.org
ALTO Extension: A Routing State Abstraction Service Using Declarative Equivalence (Internet-Draft, 2017)



) which aims to provide an abstract topology against a raw topology. For public blockchains, I am not sure your choice to use ECS instead of a cost map is better for the large number of peers in the network.


And here are some typos you may fix:


Page 5: e.i. -> i.e.


Page 6: occur -> occurs, send -> sent



Best,

Xin