Per-connection data limits

[sakridge]

I believe these are the knobs for data limits:

https://docs.rs/quinn/latest/quinn/struct.TransportConfig.html#method.stream_receive_window
https://docs.rs/quinn/latest/quinn/struct.TransportConfig.html#method.receive_window

Would like to be able to set these per-connection.

Also, would be great to release this: #1315

I suppose if a client violates these settings, the connection is just dropped and it's up to the implementer to reject the next connection attempt from said user if so desired, does that sound right?

[Ralith]

Would like to be able to set these per-connection.

That seems like a reasonable thing for us to support.

I suppose if a client violates these settings, the connection is just dropped and it's up to the implementer to reject the next connection attempt from said user if so desired, does that sound right?

A QUIC client violating flow control limits is not correctly implementing the protocol, so the connection will be immediately terminated with a transport error. This should generally be quite rare as it indicates a serious bug in the client's transport layer. You could respond to transport errors by banning that user, but that seems a bit heavy-handed, since such errors are not disruptive to the server.

[sakridge]

A QUIC client violating flow control limits is not correctly implementing the protocol, so the connection will be immediately terminated with a transport error. This should generally be quite rare as it indicates a serious bug in the client's transport layer. You could respond to transport errors by banning that user, but that seems a bit heavy-handed, since such errors are not disruptive to the server.

Ok. How about a client that drops and re-establishes the connection to reset their limits?

[sakridge]

Would the implementation be similar to #1315 ?

[Ralith]

Ok. How about a client that drops and re-establishes the connection to reset their limits?

This would cause the in-flight data to be discarded, and hence neither consume increased server resources nor accomplish anything for the client. Flow control specifically governs data which has not yet been consumed by the peer application layer.

Would the implementation be similar to #1315 ?

Broadly, yeah.

[Ralith]

Dynamic connection-level flow control configuration was introduced by #1386. If anyone still specifically wants dynamic stream-level flow control configuration, feel free to open a new issue.