net/litep2p fail to send request ChannelClogged

[alexggh]

I've been running some testing in CPU restrictive environments, describe here: #5035 (comment), and I observed that when switching to litep2p parachains blocks production slow down from ~6s average to around ~10-11s, the problems seems to be that availability protocol is way slower, I see a lot of errors like:

sub-libp2p::request-response: /89b720ba4ad8cf2a849c2c19f2a8b8911f077fbc670a69e3123fcc4e2da25454/req_chunk/2: failed to send request to PeerId("12D3KooWFycxBdu976AXgJSL4g6dxMbW8swQ3LbkHcwY1qF53QPB"): ChannelClogged  

Logs: https://grafana.teleport.parity.io/goto/1Dgn9teSg?orgId=1

FYI: @paritytech/networking

[lexnv]

Nice catch! Thanks for reporting this to us 🙏

We have noticed some performance differences between libp2p and litep2p in terms of req-resp protocols.

It would be interesting to see how this performs with the latest version (0.7), once we merge this:

• litep2p: Update network backend to v0.7.0 #5609

Link to the channel bound:

polkadot-sdk/polkadot/node/network/protocol/src/request_response/mod.rs

Lines 294 to 299 in 06f0039

	// Hundreds of validators will start requesting their chunks once they see a candidate
	// awaiting availability on chain. Given that they will see that block at different
	// times (due to network delays), 100 seems big enough to accommodate for "bursts",
	// assuming we can service requests relatively quickly, which would need to be measured
	// as well.
	Protocol::ChunkFetchingV1 | Protocol::ChunkFetchingV2 => 100,