Consequences for increasing flowControlWindow?

[thas....@gmail.com]

I am using NettyChannelBuilder on my client and NettyServerBuilder on my server. I notice when I increase the flowControlWindow option on the client and server, e.g:

.flowControlWindow(NettyServerBuilder.DEFAULT_FLOW_CONTROL_WINDOW * 10)

I notice higher throughput ability in my stream, I believe this is because it increases the TCP flow control window so more bytes can be in-flight/buffered on each side. 
However are there any possible downsides to increasing this value? What actually happens on a lower level? Does it just increase the memory allocated to the internal buffers? 

Thanks in advance!

[Spencer Fang]

This actually refers to the HTTP/2 flow control window: https://http2.github.io/http2-spec/#FlowControl

Yes, increasing the flow window to a larger value will allow the other end of the connection to continue writing even if we are not able to keep up with the work. In HTTP/2, there is a connection level flow control window and each stream has its own flow control window. The setting you mentioned refers to the connection level flow control window. Even if the connection level flow control window is exhausted, non-DATA frames such as SETTINGS can still be sent on the connection, which is why it exists instead of relying on the TCP level window.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/93e6301e-0a8b-4201-991b-a0d7865ea068%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Spencer Fang

[Eric Anderson]

I'd suggest increasing the number only if you can show the result of (bandwidth * RTT) is higher than the current value (1 MB). We'd really like to be auto-tuning this value, but because we use such a high default value it's not been a huge burden. Go and C actually already auto-scale. And Java even has the code, but we need to fix a few edge cases to avoid upsetting some other HTTP/2 implementations.

Most networks only need 64 KB. Some cloud-type networks need 1 MB when you're "slightly far" away from the remote side. And then something like an intercontinental transfer on a nice/fat network might need 4 MB. Note this value only impacts receiving; you want to set it on the receiver, or on both sides if both sides receive large amounts.