Proposal: dynamically limit the number of streams per protocol

[marten-seemann]

Some of the protocols running on top of libp2p consume streams greedily, opening as many streams as they can get their hands on.

We now have resource managers in all libp2p implementations that prevent this from becoming a DoS attack, however, when the resource manager kicks in, all that the peer learns is that the stream was reset. This can happen for any number of reasons, so it's really hard to programmatically react to stream resets.

Once we have error code (#479) and HTTP (#508) we can be a lot smarter. By using the 429 HTTP status code (and an equivalent that we define as a stream error code), we can tell the peer that it is (temporarily) overloading us with requests, allowing it to take action (e.g. slow down, wait until a few in-flight requests have finished, etc.).

[rkuhn]

While I agree with the impetus, the approach seems implausibly narrow: why add thousands of pages of spec (i.e. HTTP) when a single protocol message would suffice?

[marten-seemann]

Limiting the number of streams per protocol is not the motivating force behind the libp2p+HTTP proposal. See #477 and #508 (comment) for some of the use cases we hope to enable by adding HTTP support.

Neither is HTTP support required to make this work, as I've explained above:

By using the 429 HTTP status code (and an equivalent that we define as a stream error code)

I was just pointing out that this proposal works both over classic libp2p streams (once we have error codes) and for libp2p+HTTP, which is a neat property.