Re: [amqp] Size-based link flow control

[Alan Conway <aconway@redhat.com>]

Qpid Dispatch uses the existing byte-based session flow control to bound its memory use. It does effectively block clients that send a lot of bytes - regardless of whether it is many small messages or some very large ones. Why do you need a per-link limit on top of that?

A per-link limit allows senders that create a ton of links to blow up the receiver. Of course a malicious sender could create a ton of sessions, but that's much less likely to happen by accident, and the max number of sessions is easy to limit giving you a guaranteed upper-bound on memory per connection.

On Fri, Mar 8, 2019 at 2:34 PM Clemens Vasters <clemensv@microsoft.com> wrote:

Our engineering team has the strong desire to add a flow control mode where link-credit is counted in bytes rather than in number of messages.

Â

Weâre occasionally getting into the situation where weâre being hammered with a ton of large messages all at once and team is convinced that a byte-oriented credit counter could allow for tighter control of what the client are allowed to push. For session-based flow control, the permitted windows we need are also too big.

Â

The Flow control section 2.6.7. in the core spec is surprisingly vague and doesnât have a hard reference to link-credit being a message counter. The only hard reference seems to be is in 2.7.4. where the link-credit section says that âThe current maximum number of messages that can be handled at the receiver endpoint of the linkâ

Â

So weâre thinking about an extra spec with a layered-on capability that allows for reinterpretation of link-credit and delivery-count as counts of bytes.

Â

Thoughts?