AW: [amqp] Size-based link flow control

The session flow control has frame-size resolution and we also use that to cap memory use in the gateway.

The links end up interacting with the respective link targetâs backend processor/storage. We do have the scenario where a single inbound session carries a bundle of links where each link talks to a different backend. For that, the team wants finer grained flow control metric than a message count.

Von: Alan Conway <aconway@redhat.com>
Gesendet: Freitag, 8. MÃrz 2019 12:46
An: Clemens Vasters <clemensv@microsoft.com>
Cc: amqp@lists.oasis-open.org
Betreff: Re: [amqp] Size-based link flow control

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?

amqp message