Core: Introduce rate limiting at the binding level

The limit of 5 in-flight messages is arbitrary, and might be too high considering a RAMF message can be ~8 MiB (so a single connection may require up to 40+ MiB of RAM).

rs000-core.md

@@ -168,14 +168,16 @@ message CollectedParcel {
 
 ## Message Transport Bindings
 
-A message transport binding, or simply _binding_, defines the [adjacent-layer interactions](https://upskilld.com/learn/same-layer-and-adjacent-layer-interactions/) in Relaynet. [Parcel delivery bindings](#parcel-delivery-binding) define the communication between endpoints and gateways, and [cargo relay bindings](#cargo-relay-binding) define the communication between gateways and couriers. This document describes the requirements applicable to all bindings, but does not define any concrete binding.
+A message transport binding, or simply _binding_, defines the [adjacent-layer interactions](https://upskilld.com/learn/same-layer-and-adjacent-layer-interactions/) in Relaynet. Their objective is to facilitate the exchange of messages in endpoint and gateway messaging protocols (e.g., parcels, cargoes, acknowledgements). This document describes the requirements applicable to all bindings, but does not define any concrete binding.
 
 Bindings will typically leverage [Layer 7](https://en.wikipedia.org/wiki/Application_layer) protocols, such as HTTP or purpose-built ones, but they can also use an Inter-Process Communication (IPC) mechanism provided by the host system.
 
 Communication MUST be encrypted when the two nodes are on different computers, otherwise it is optional. Communication is deemed to happen on the same computer when either the loopback network interface (i.e., addresses in the range `127.0.0.0/8`) or IPC is used. When encryption is used, it MUST be provided by Transport Layer Security (TLS) version 1.2 ([RFC 5246](https://tools.ietf.org/html/rfc5246)) or newer, or an equivalent technology in non-TCP connections (e.g., [DTLS](https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security)). When using TLS, Server Name Identification per [RFC 6066](https://tools.ietf.org/html/rfc6066) MUST be supported by clients and it MAY be used by servers.
 
 For performance reasons, nodes SHOULD use Unix domain sockets or any other IPC mechanism instead of the loopback network interface when they are on the same computer.
 
+For availability and performance reasons, the node sending messages SHOULD limit the number of messages pending acknowledgements to five. Consequently, the node on the receiving end MUST hold at least five incoming messaging in its processing queue at any point in time. The receiving end MAY close the connection when this limit is exceeded.
+
 For privacy and censorship-circumvention reasons, public addresses using DNS records SHOULD be resolved using [DNS over HTTPS](https://tools.ietf.org/html/rfc8484) or [DNS over TLS/DTLS](https://tools.ietf.org/html/rfc8310), using a DNS resolver trusted by the implementer. Advanced end users SHOULD also be allowed to override the DNS resolver or even use the one provided by the host system.
 
 Bindings MAY extend this specification, but they MUST NOT override it.