Features

[kbala444]

Here's a preliminary list of features we might be able to use to classify potential peers:

1. How often the peer loses it's ledger
2. Debt ratio of peer
3. Average latency of connection to peer
4. Available bandwidth of peer
5. Demand/rarity of block we are trying to obtain from peer (maybe if the block is rare we should tolerate slower connections/less bandwidth)
6. Total uptime of peer

I'm not too sure how difficult it will be to obtain data for some of these.

[whyrusleeping]

1. Available bandwidth of peer

This is the bandwidth between the remote peer and us? That one might be really hard to gague.

1. Total uptime of peer

This is currently available through the ipfs net diag functionality, but dont expect it to stick around. We might be able to add some basic information exchange into the handshake, but that could be faked. Maybe a better heuristic is "lifetime of our connection to them"

[kbala444]

Maybe instead of bandwidth we could try a partial download like in Adaptive Peer Selection and use the average download speed in the first N seconds as the feature? The cost of doing this might not be worth it though.

Is lifetime of our connection the time we've been connected to a peer?

[jbenet]

some more:

• number of disconnections
• connection lifetime
• connection performance (bandwidth, latency, throughput, etc)
• age of relationship (old peer, or new peer?)
• blocks received
• blocks requested (maybe peers that are very active are better partners or vv)
• cancels received
• protocol and agent versions
• geographical location, and proximity
• network address features (internal or external, in specific countries or ISPs, etc)

may also want to test multiple functions over variables (e.g. mean, median, total, variance, max, min, etc).

[whyrusleeping]

Is lifetime of our connection the time we've been connected to a peer?

yes. which is a debateable metric, but we cant trust peer to be honest about their uptime. we can only use features that we can observe ourselves.