-
Notifications
You must be signed in to change notification settings - Fork 123
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: Turn off PMTUD during QNS zerortt
test
#2064
fix: Turn off PMTUD during QNS zerortt
test
#2064
Conversation
PMTUD probes inflate what we sent in 1-RTT, causing QNS to fail the test. See ptrd/kwik#46 (comment)
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2064 +/- ##
==========================================
- Coverage 95.35% 95.35% -0.01%
==========================================
Files 112 112
Lines 36505 36505
==========================================
- Hits 34811 34810 -1
- Misses 1694 1695 +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 c35028a. coalesce_acked_from_zero 1+1 entries: No change in performance detected.time: [99.121 ns 99.393 ns 99.668 ns] change: [-0.4823% -0.0308% +0.4711%] (p = 0.90 > 0.05) coalesce_acked_from_zero 3+1 entries: No change in performance detected.time: [117.16 ns 117.51 ns 117.88 ns] change: [-0.2090% +0.1865% +0.5656%] (p = 0.35 > 0.05) coalesce_acked_from_zero 10+1 entries: No change in performance detected.time: [116.78 ns 117.25 ns 117.83 ns] change: [-0.4769% +0.0012% +0.4609%] (p = 1.00 > 0.05) coalesce_acked_from_zero 1000+1 entries: No change in performance detected.time: [97.628 ns 97.767 ns 97.916 ns] change: [-1.0093% -0.1971% +0.5645%] (p = 0.66 > 0.05) RxStreamOrderer::inbound_frame(): No change in performance detected.time: [111.26 ms 111.34 ms 111.41 ms] change: [-0.0803% -0.0005% +0.0848%] (p = 0.98 > 0.05) transfer/pacing-false/varying-seeds: No change in performance detected.time: [26.286 ms 27.262 ms 28.230 ms] change: [-4.6102% +0.6494% +6.1676%] (p = 0.81 > 0.05) transfer/pacing-true/varying-seeds: No change in performance detected.time: [36.111 ms 37.910 ms 39.713 ms] change: [-0.6064% +6.0580% +13.167%] (p = 0.08 > 0.05) transfer/pacing-false/same-seed: No change in performance detected.time: [31.384 ms 32.147 ms 32.885 ms] change: [-1.8140% +1.5315% +5.2426%] (p = 0.39 > 0.05) transfer/pacing-true/same-seed: No change in performance detected.time: [40.476 ms 43.792 ms 47.083 ms] change: [-13.127% -3.4377% +6.5429%] (p = 0.48 > 0.05) 1-conn/1-100mb-resp (aka. Download)/client: No change in performance detected.time: [114.72 ms 115.29 ms 116.00 ms] thrpt: [862.09 MiB/s 867.38 MiB/s 871.70 MiB/s] change: time: [-0.1825% +0.4364% +1.0772%] (p = 0.19 > 0.05) thrpt: [-1.0657% -0.4345% +0.1828%] 1-conn/10_000-parallel-1b-resp (aka. RPS)/client: No change in performance detected.time: [310.98 ms 314.84 ms 318.74 ms] thrpt: [31.373 Kelem/s 31.762 Kelem/s 32.156 Kelem/s] change: time: [-0.9234% +0.8666% +2.6548%] (p = 0.34 > 0.05) thrpt: [-2.5861% -0.8592% +0.9320%] 1-conn/1-1b-resp (aka. HPS)/client: No change in performance detected.time: [40.261 ms 40.949 ms 41.634 ms] thrpt: [24.019 elem/s 24.421 elem/s 24.838 elem/s] change: time: [-2.4958% -0.1103% +2.1122%] (p = 0.92 > 0.05) thrpt: [-2.0685% +0.1104% +2.5597%] Client/server transfer resultsTransfer of 33554432 bytes over loopback.
|
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 I understand correctly that it is these lines that fail?
I am fine with the fix here. In case the required changes in quic-interop-runner would be small, I would prefer the calculation in quic-interop-runner to be updated instead.
@mxinden yes, that is the failing calculation. What would the fix for QNS be? AFAIK the calculation is some heuristic that @marten-seemann came up with. |
Any ideas how we can improve the heuristics? The problem is, retransmitting already transmitted STREAM data in a PMTU packet is a totally reasonable strategy... |
I'll merge this now. I suggest opening a new issue for QNS to come up with a better heuristic. |
PMTUD probes inflate what we sent in 1-RTT, causing QNS to fail the test.
See ptrd/kwik#46 (comment)