-
Notifications
You must be signed in to change notification settings - Fork 5k
Send connection WINDOW_UPDATE before RTT PING #97881
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Tagging subscribers to this area: @dotnet/ncl Issue DetailsFixes #97131. Some servers in GCP have a non-standard ping accounting mechanism, meaning they reset their unsolicited PING counter when receiving
Ideally, this fix should be backported to all supported versions.
|
if (_pendingWindowUpdate == 0) return false; | ||
LogExceptions(SendWindowUpdateAsync(0, _pendingWindowUpdate)); | ||
_pendingWindowUpdate = 0; | ||
return true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ExtendWindow
has unnecessary synchronization around _pendingWindowUpdate
manipulation which is didn't add to this method. See #97878.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is lite on unit tests. What about tests for scenarios that will and won't trigger a ping? And a test that fails if WINDOWS_UPDATE isn't present.
...libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http2StreamWindowManager.cs
Show resolved
Hide resolved
...libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http2StreamWindowManager.cs
Show resolved
Hide resolved
Pushed a test in e93920a. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I don't fully understand the window & ping management but I don't have any concerns. Hopefully testing was done to ensure correctness.
And I guess excessive updates is the biggest risk of this change, right?
The amount of WINDOW_UPDATE-s we send did not get significantly higher. Now we essentially do the same as the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Side question: as far as I understand our current logic, we'll keep sending pings once every ~2 seconds, but only update the RTT if it gets lower.
Are the updates after the initial burst meaningful? That is, we expect the RTT might decrease, but we don't care if it increases?
[Deleted my previous comment because it did not make sense.] Adjusting RTT upwards would risk growing the window "accidentally" in case of an occasional high delay measurement: Lines 108 to 109 in 4928f3c
With an unstable connection the minimum delay is hopefully constant in long run for most practical SocketsHttpHandler use cases, or at least this is the assumption behind the current strategy. |
…med_ResetsStreamAndThrowsOnRequestStreamWriteAndResponseStreamRead...
/azp run runtime-libraries-coreclr outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
CI failures are unrelated, the massive outerloop failures are caused by #96035. |
/backport to release/8.0-staging |
Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/7892640557 |
/backport to release/7.0-staging |
Started backporting to release/7.0-staging: https://github.com/dotnet/runtime/actions/runs/7892642858 |
/backport to release/6.0-staging |
Started backporting to release/6.0-staging: https://github.com/dotnet/runtime/actions/runs/7892646182 |
/backport to release/8.0-staging |
Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/13948929374 |
@antonfirsov backporting to "release/8.0-staging" failed, the patch most likely resulted in conflicts: $ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch
Applying: send a connection WINDOW_UPDATE before RTT PING
Using index info to reconstruct a base tree...
M src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http2Connection.cs
Falling back to patching base and 3-way merge...
Auto-merging src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http2Connection.cs
CONFLICT (content): Merge conflict in src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http2Connection.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Patch failed at 0001 send a connection WINDOW_UPDATE before RTT PING
Error: The process '/usr/bin/git' failed with exit code 128 Please backport manually! |
Fixes #97131.
Some servers in GCP have a non-standard ping accounting mechanism, meaning they reset their unsolicited PING counter when they receive
DATA
,HEADERS
orWINDOW_UPDATE
. To comply with this behavior, this PR adjusts the RTT logic ensuring that a connectionWINDOW_UPDATE
is being sent out before we send an RTTPING
by applying two changes:_pendingWindowUpdate
credits. Do not send a PING if this is not possible (_pendingWindowUpdate == 0
). Just like RTT PINGs, such WINDOW_UPDATEs are relatively rare and should not hurt performance.Ideally, this fix should be backported to all supported versions.