Re: [alto] alto Digest, Vol 92, Issue 27 - NEW

[Stefan HOMMES <[e-mail]>]

Dear Wendy,

thanks a lot for taking your time and providing us with the comments concerning our draft (draft-hommes-alto-blockchain-01). Here my comments in line:

----------
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.

[Stefan]: A good point, it is not clearly stated. If I understood correctly, there are basically two possible ways: 1) ALTO is calculating the cost to reach peers by providing ALTO a list of potential peers, and 2) ALTO has the knowledge about the peers since it is connected to a resource directory, which contains all list of available peers. In the second case, if I understood correctly, ALTO could be used to bootstrap a blockchain peer by providing the peer with the address of an ALTO server. The ALTO server could then afterwards propose the best peer(s) by requesting them from the resource directory. Correct?

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.

[Stefan]: Yes, it should be minutes instead of seconds.


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.

[Stefan]: I think this can be solved in a similar way as described in the previous section.

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?

[Stefan]: I will better describe this part. But my idea was that ALTO could give a recommendation to a peer after it has received a potential list of peers from the DNS server.

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.

[Stefan]: In case that the ALTO server has no knowledge about the available peers, I agree that the peer should propose in the request which metric that needs to be applied, and ALTO requires no knowledge about the different roles. But when ALTO has a resource directory that contains all potential nodes, I believe it would make sense to give ALTO the information about what peer is belonging to each role in order to give a proper recommondation. 
 
------------------------

Kind Regards,
Stefan



-----Original Message-----
From: alto [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 12 July 2016 11:25
To: [e-mail]
Subject: alto Digest, Vol 92, Issue 27

Send alto mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/alto
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific than "Re: Contents of alto digest..."


Today's Topics:

   1. Draft: Alto for the blockchain (Wendy Roome)
   2. my email address (Jan Seedorf)
   3. Re: Draft: Alto for the blockchain (Stefan HOMMES)
   4. Re: Draft: Alto for the blockchain (Stefan HOMMES)


----------------------------------------------------------------------

Message: 1
Date: Mon, 11 Jul 2016 15:55:52 -0400
From: Wendy Roome <[e-mail]>
To: IETF ALTO <[e-mail]>
Subject: [alto] Draft: Alto for the blockchain
Message-ID: <[e-mail]>
Content-Type: text/plain;	charset="US-ASCII"

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