Currently, a receiver always returns the full credits rather than the credits actually received by the receiver. Brian's description is below:
FC does not control flow tightly enough. I believe this may be because credit replenishments bring a sender up to max_credits from whatever credit level the sender is at, which has no direct relationship to how many bytes the receiver had seen. This is more of a problem under sustained over load when sender threads are timing out while blocking and sending credit requests. For example, with a config of max_credits = 1,000,000 and min_credits = 100,000. Sender is under enough client load that it basically always has sender threads blocking with messages totalling 1,000,000 bytes.

Sender sends 1,000,000 bytes and blocks.
Receiver processes slowly.
Receiver processes 900,000, sends credit replenishment 1.
Meanwhile, sender times out; sends credit request 1.
Sender gets credit replenishment 1; unblocks, sends another 1,000,000, blocks again.
Receiver processes 100,000, then gets credit request 1 and sends replenishment 2.
Sender times out; sends credit request 2.
Sender gets replenishment 2 and unblocks, sends 1,000,000 bytes.

At this point, the sender has sent 3,000,000 and the receiver has received 1,000,000. Further, there is a credit request in the channel, so after the receiver sees the next 1,000,000 bytes, it will have sent two more replenishments, theoretically allowing the sender to send 2,000,000 more bytes.

This is an extreme example, but the key point is a credit replenishment gives the sender the right to send up to max_credits, even though the receiver may have only seen min_credits when it sent the message.

Solution to this problem is two-fold:

1) Credit replenishment messages should include a payload indicating the number of bytes received. The sender only gives itself that many credits.