Flow Control Tuning

[gorryfair]

/ A receiver can use an autotuning mechanism to tune the frequency and
amount of advertised additional credit based on a round-trip time
estimate and the rate at which the receiving application consumes
data, similar to common TCP implementations.
/

• I think this has potential for strange pathologies where flow control interacts with ACKs within the transport. I now have at least some data where we have seen problems, from one policy that updated flow control too infrequently. Achieving similar behaviour to TCP could require more than currently stated.

[martinthomson]

After briefly discussing this with Gorry, I think that we concluded that advice about the frequency of flow control updates would help.

Where flow control limits broadly correspond to the congestion window size, those updates would need to be sent about as often as acknowledgments in order to ensure that flow control didn't stall unnecessarily. That would be the upper limit; larger flow control limits need proportionally fewer updates. If flow control limits are very large, updates could be far less frequent.

I don't think that we have an algorithm here, but it seems like this advice would go a long way to avoiding the worst problems.

There's a question then about where this advice goes. I am inclined to keep this in the transport doc as long as our response only extends to advice in the abstract.

[gorryfair]

Thanks for starting this issue. I will speak to my team and see if we can come up with some more context and plots that show the key issues and send a link to what we have.

[ianswett]

I think we should keep this in transport.

I think we can provide more specific guidance than we do now, including guidance to bundle flow control updates with ACK frames, but not to bundle them with every ACK frame(otherwise you end up ACK-ing ACKs, which we know is bad). I'm biased towards marking this editorial, but we can wait for a PR to see.

Our implementation does(approximately):

1. Send an update every time 1/2 the window has been consumed
2. Double the size of the window every time two updates are sent within an RTT.

Particularly early in the connection, ideally the flow control window is 2x the peer's current congestion control window, because the CWND doubles every RTT in slow start.

[larseggert]

Discussed in ZRH. Proposed resolution is to close with no action.