-
Notifications
You must be signed in to change notification settings - Fork 124
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
fix: Replace find_path_with_rebinding
with find_path
#2176
Conversation
We need to do a path challenge even if only the remote port changes.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2176 +/- ##
==========================================
- Coverage 95.39% 95.38% -0.01%
==========================================
Files 112 112
Lines 36373 36338 -35
==========================================
- Hits 34697 34661 -36
- Misses 1676 1677 +1 ☔ View full report in Codecov by Sentry. |
Failed Interop TestsQUIC Interop Runner, client vs. server neqo-latest as client
neqo-latest as server
All resultsSucceeded Interop TestsQUIC Interop Runner, client vs. server neqo-latest as client
neqo-latest as server
Unsupported Interop TestsQUIC Interop Runner, client vs. server neqo-latest as client
neqo-latest as server
|
Benchmark resultsPerformance differences relative to 62415bf. coalesce_acked_from_zero 1+1 entries: 💚 Performance has improved.time: [88.804 ns 89.105 ns 89.406 ns] change: [-11.058% -10.676% -10.275%] (p = 0.00 < 0.05) coalesce_acked_from_zero 3+1 entries: 💚 Performance has improved.time: [99.599 ns 99.944 ns 100.31 ns] change: [-17.047% -16.098% -15.343%] (p = 0.00 < 0.05) coalesce_acked_from_zero 10+1 entries: 💚 Performance has improved.time: [99.086 ns 99.463 ns 99.934 ns] change: [-16.187% -15.523% -14.812%] (p = 0.00 < 0.05) coalesce_acked_from_zero 1000+1 entries: 💚 Performance has improved.time: [78.147 ns 78.289 ns 78.452 ns] change: [-20.693% -19.826% -18.936%] (p = 0.00 < 0.05) RxStreamOrderer::inbound_frame(): Change within noise threshold.time: [111.59 ms 111.64 ms 111.68 ms] change: [+0.4174% +0.4822% +0.5464%] (p = 0.00 < 0.05) transfer/pacing-false/varying-seeds: No change in performance detected.time: [25.909 ms 27.015 ms 28.114 ms] change: [-6.5143% -1.1814% +4.3327%] (p = 0.67 > 0.05) transfer/pacing-true/varying-seeds: No change in performance detected.time: [33.675 ms 35.149 ms 36.637 ms] change: [-6.9395% -1.0472% +5.4396%] (p = 0.73 > 0.05) transfer/pacing-false/same-seed: No change in performance detected.time: [25.496 ms 26.248 ms 26.991 ms] change: [-2.8083% +1.2463% +5.7304%] (p = 0.55 > 0.05) transfer/pacing-true/same-seed: No change in performance detected.time: [39.700 ms 41.676 ms 43.701 ms] change: [-4.7132% +1.1022% +8.3606%] (p = 0.74 > 0.05) 1-conn/1-100mb-resp (aka. Download)/client: No change in performance detected.time: [113.14 ms 113.72 ms 114.28 ms] thrpt: [875.02 MiB/s 879.37 MiB/s 883.86 MiB/s] change: time: [-0.6648% +0.0154% +0.6470%] (p = 0.96 > 0.05) thrpt: [-0.6429% -0.0154% +0.6692%] 1-conn/10_000-parallel-1b-resp (aka. RPS)/client: No change in performance detected.time: [313.54 ms 317.20 ms 320.84 ms] thrpt: [31.169 Kelem/s 31.526 Kelem/s 31.894 Kelem/s] change: time: [-1.1490% +0.5558% +2.2936%] (p = 0.53 > 0.05) thrpt: [-2.2422% -0.5527% +1.1624%] 1-conn/1-1b-resp (aka. HPS)/client: No change in performance detected.time: [34.042 ms 34.273 ms 34.523 ms] thrpt: [28.967 elem/s 29.178 elem/s 29.375 elem/s] change: time: [-0.6345% +0.3546% +1.3443%] (p = 0.48 > 0.05) thrpt: [-1.3264% -0.3534% +0.6385%] Client/server transfer resultsTransfer of 33554432 bytes over loopback.
|
/// We use this when the other side migrates to skip address validation and | ||
/// creating a new path. |
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.
Why did we previously skip address validation on port change?
If I understand RFC 9000 correctly, the port is always part of the validation process:
In path validation, endpoints test reachability between a specific local address and a specific peer address, where an address is the 2-tuple of IP address and port.
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.
@martinthomson might know?
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.
We did that deliberately, because if a peer changes just the port, it's probably just a NAT rebinding. No point in wasting the effort.
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.
Do we care that that will make us violate the spec and fail a QNS test?
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.
If this results in full address validation for a port change, that's probably not OK. I mean, we don't really implement the server end, but it's a regression in capabilities for the server.
Now part of #2170. |
We need to do a path challenge even if only the remote port changes.
This makes us pass the
rebind-port
QNS test.