You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having appropriately sized flow control windows can have a significant effect on the throughput of a connection. If the window is too small then connections can stall waiting for WINDOW_UPDATEs.
The bandwidth-delay-product (BDP) of a connection measures how much data can fit "on the wire". gRPC implementations (but not grpc-swift, yet) do this by estimating the BDP and comparing it to the current connection window size and adjusting it as appropriate.
The algorithm works as follows: when a DATA frame is received and there is no PING frame waiting for an ACK then note the current time and begin counting the number of flow controlled bytes (including the just received DATA frame) and send a PING frame to the remote peer. When a PING ACK is received, compute the round-trip-time.
The product of the number of flow controlled bytes received and the RTT is an effective measure of 1.5 * BDP (as there was half-a-round-trips worth of DATA already on the wire when the first PING was sent). If this value is close to the current flow control window size then the window should be increased in size. If it is low enough (say, 2/3 of the current window size) then the window size can be reduced (to shrink buffer sizes).
Having appropriately sized flow control windows can have a significant effect on the throughput of a connection. If the window is too small then connections can stall waiting for WINDOW_UPDATEs.
The bandwidth-delay-product (BDP) of a connection measures how much data can fit "on the wire". gRPC implementations (but not grpc-swift, yet) do this by estimating the BDP and comparing it to the current connection window size and adjusting it as appropriate.
The algorithm works as follows: when a DATA frame is received and there is no PING frame waiting for an ACK then note the current time and begin counting the number of flow controlled bytes (including the just received DATA frame) and send a PING frame to the remote peer. When a PING ACK is received, compute the round-trip-time.
The product of the number of flow controlled bytes received and the RTT is an effective measure of 1.5 * BDP (as there was half-a-round-trips worth of DATA already on the wire when the first PING was sent). If this value is close to the current flow control window size then the window should be increased in size. If it is low enough (say, 2/3 of the current window size) then the window size can be reduced (to shrink buffer sizes).
This is described in some more detail here.
I'll likely experiment with this in gRPC first and report back.
The text was updated successfully, but these errors were encountered: