Upgrade to libp2p-0.31.

[romanb]

This PR upgrades substrate to libp2p-0.31. Highlights:

• Multihash upgrade.
• Fixed ls response encoding for multistream-select. This will eventually be followed-up by [multistream-select] Re-enable use of ls for the dialer aka "parallel negotiation". libp2p/rust-libp2p#1847.
• More control over the scores and thus retention and ordering of external (e.g. observed) addresses, including the ability to add external addresses to a Swarm with an "infinite" retention. Thereby closes Addresses passed with --public-addr get purged after a while #7518.
• Limited initial buffer allocation when decoding multi-addresses (Limit buffer capacity in multiaddr visit_seq libp2p/rust-libp2p#1833).
• The V1Lazy multistream-select negotiation variant is now interoperable with V1 on the wire and configured to be used exclusively in substrate with this PR, both for transport and substream protocol negotiation ([multistream] Make the lazy variant more interoperable. libp2p/rust-libp2p#1855, [swarm] Permit configuration override for the substream upgrade protocol to use. libp2p/rust-libp2p#1858). This can avoid having the initiator of a connection or substream wait for every single protocol confirmation before it can send protocol data.
• More configurable connection limits, both for pending and established connections and separately for incoming and outgoing connections. This enables Limit the number of simultaneous inbound TCP connections #7432 to be addressed ([core/swarm] Refactor and extend configurable connection limits. libp2p/rust-libp2p#1848).

[romanb]

I'm wondering if we can already remove support for the fallback noise ix config with this PR? It would take out one negotiation round-trip from the connection setup.

[mxinden]

I'm wondering if we can already remove support for the fallback noise ix config with this PR? It would take out one negotiation round-trip from the connection setup.

As far as I can tell, the spec compliant handshake was introduced back in May with #6064 and should thus be supported by the majority of nodes. With that in mind, I don't see why not to remove the legacy fallback. Is there something I am missing?

[romanb]

As far as I can tell, the spec compliant handshake was introduced back in May with #6064 and should thus be supported by the majority of nodes. With that in mind, I don't see why not to remove the legacy fallback. Is there something I am missing?

Maybe not, I'm just never quite up-to-date w.r.t. which versions are running where and I think it is not uncommon for there to be a few months between a merged substrate PR and a polkadot deployment that includes these changes, so I better ask twice. If @tomaka also thinks we can remove it, I will go ahead and do it!

[romanb]

This is the patch for #7518.

[tomaka]

According to this comment, we have already broken compatibility with nodes that don't have #6064, and so we can remove the legacy noise handshake.

[tomaka]

Could you also update the burn-in PR?

[romanb]

Could you also update the burn-in PR?

Of course, done in paritytech/polkadot@4020626.

[tomaka]

The "request answer time", in other words the time before receiving a response to a request that the node has sent out, has been divided by two, as predicted.

The "request serving time", which is the other way around, has also been divided by two, and I don't understand why. Looking at the source code, this measures the time elapsed between upgrade_inbound being called and the response being written on the substream. If this is indeed what is being measured, then the times being shown (100ms to 300ms) don't make sense, and we should investigate this out of the scope of this PR.

Since nodes only perform one concurrent request at a time, a consequence of the serving time being reduced is that more requests are being served per second, and the bandwidth usage increased.
To me this is caused by the fact that the node running this burn-in is suddenly twice as good as all the other nodes on the network. Once this PR has been deployed, the bandwidth should be back to previous levels.

---

The number of failed connection attempts has increased, maybe because of the legacy Noise handshake. It is unclear whether this is caused by older nodes.

[mxinden]

The "request serving time", which is the other way around, has also been divided by two, and I don't understand why. Looking at the source code, this measures the time elapsed between upgrade_inbound being called and the response being written on the substream. If this is indeed what is being measured, then the times being shown (100ms to 300ms) don't make sense, and we should investigate this out of the scope of this PR.

This is indeed surprising. I compared the kusama-sentry-ew4-1 running this pull request with canary-sentry-ew4-0 running recent master.

First off, to proof that the above phenomenon is not just unrelated to this pull request and instead related to a change on master, the graph below compares the median request handling rate:

When comparing the 95th percentile instead of the median the difference becomes less obvious:

With that in mind, a wild guess from me would be: Given that the handshake time decreased, peers can ask for blocks more frequently. Asking for blocks more frequently implies smaller replies which in turn implies shorter request handling time.

[tomaka]

Given that the handshake time decreased, peers can ask for blocks more frequently.

But the handshake time hasn't decreased for requests emitted by remotes.

[romanb]

But the handshake time hasn't decreased for requests emitted by remotes.

Maybe I'm missing something, but if we have the inbound request handling like so

< /my/protocol
< [request-data]
> /my/protocol
> [response-data]

i.e. a single round-trip, isn't it expected that this is quicker than

< /my/protocol
> /my/protocol
< [request-data]
> [response-data]

?

[romanb]

Oh, I guess it is because other nodes don't use this branch yet that this is unexpected.

[mxinden]

The number of failed connection attempts has increased, maybe because of the legacy Noise handshake. It is unclear whether this is caused by older nodes.

Following up on the increased dialing attempt errors, I am not sure this is related to this pull request.

Again comparing kusama-sentry-ew4-1 running this pull request with canary-sentry-ew4-0 running recent master both face increased dialing attempt errors.

Query: sum(rate(polkadot_sub_libp2p_pending_connections_errors_total{instance=~"kusama-sentry-ew4-1.*|canary-sentry-ew4-0.*"}[$__interval])) by (instance)

Looking at the dialing attempt errors of the canary node over the last 30 days, this issue seems to have been introduced earlier this month around the 19th of November:

Query: sum(rate(polkadot_sub_libp2p_pending_connections_errors_total{instance=~"canary-sentry-ew4-0.*"}[$__interval])) by (instance)

[tomaka]

Let's merge this PR, then?

[tomaka]

bot merge

[ghost]

Trying merge.