-
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
test: Add a test case for 0-RTT loss #2057
Conversation
This currently fails, because we have a bug where the server does not accept retransmitted 0-RTT packets when it should.
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
|
It's not a bug, but a test configuration issue. See larseggert#29. |
So this also happens in the interop runner though - that inspired the test... |
That probably means that we need to be more generous with our tolerance to delay. The default we have in our server is 10 seconds, which seems fine. Are those tests that fail doing so because of being outside that window? |
I'm attaching a log (taken locally) where this happens. The The real bug here may be that the client never seems to retransmit the frame data in the 0-RTT packet (after printing (Even if this is the real bug, I think the server should still have accepted the 0-RTT...) |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2057 +/- ##
=======================================
Coverage 95.35% 95.35%
=======================================
Files 112 112
Lines 36499 36500 +1
=======================================
+ Hits 34805 34806 +1
Misses 1694 1694 ☔ View full report in Codecov by Sentry. |
Benchmark resultsPerformance differences relative to a9f707f. coalesce_acked_from_zero 1+1 entries: 💔 Performance has regressed.time: [134.74 ns 135.16 ns 135.60 ns] change: [+34.420% +35.048% +35.583%] (p = 0.00 < 0.05) coalesce_acked_from_zero 3+1 entries: 💔 Performance has regressed.time: [166.03 ns 166.60 ns 167.19 ns] change: [+40.423% +41.248% +42.013%] (p = 0.00 < 0.05) coalesce_acked_from_zero 10+1 entries: 💔 Performance has regressed.time: [165.76 ns 166.36 ns 166.98 ns] change: [+40.396% +40.935% +41.450%] (p = 0.00 < 0.05) coalesce_acked_from_zero 1000+1 entries: 💔 Performance has regressed.time: [138.06 ns 138.25 ns 138.47 ns] change: [+23.159% +34.043% +42.063%] (p = 0.00 < 0.05) RxStreamOrderer::inbound_frame(): Change within noise threshold.time: [111.04 ms 111.11 ms 111.18 ms] change: [-0.4820% -0.3912% -0.2986%] (p = 0.00 < 0.05) transfer/pacing-false/varying-seeds: No change in performance detected.time: [26.473 ms 27.443 ms 28.407 ms] change: [-3.7658% +1.3027% +6.4133%] (p = 0.62 > 0.05) transfer/pacing-true/varying-seeds: No change in performance detected.time: [35.005 ms 36.516 ms 38.042 ms] change: [-0.1852% +5.8854% +12.092%] (p = 0.06 > 0.05) transfer/pacing-false/same-seed: No change in performance detected.time: [31.651 ms 32.506 ms 33.322 ms] change: [-1.4171% +1.8578% +5.2168%] (p = 0.26 > 0.05) transfer/pacing-true/same-seed: No change in performance detected.time: [42.924 ms 45.858 ms 48.770 ms] change: [-3.8406% +6.0339% +17.302%] (p = 0.25 > 0.05) 1-conn/1-100mb-resp (aka. Download)/client: 💔 Performance has regressed.time: [115.07 ms 115.40 ms 115.72 ms] thrpt: [864.13 MiB/s 866.56 MiB/s 869.05 MiB/s] change: time: [+1.0044% +1.5351% +2.0714%] (p = 0.00 < 0.05) thrpt: [-2.0294% -1.5119% -0.9944%] 1-conn/10_000-parallel-1b-resp (aka. RPS)/client: No change in performance detected.time: [310.82 ms 314.57 ms 318.38 ms] thrpt: [31.409 Kelem/s 31.790 Kelem/s 32.173 Kelem/s] change: time: [-0.2459% +1.3835% +3.1446%] (p = 0.11 > 0.05) thrpt: [-3.0487% -1.3646% +0.2465%] 1-conn/1-1b-resp (aka. HPS)/client: No change in performance detected.time: [40.245 ms 40.938 ms 41.626 ms] thrpt: [24.023 elem/s 24.427 elem/s 24.848 elem/s] change: time: [-2.0272% +0.2005% +2.7398%] (p = 0.87 > 0.05) thrpt: [-2.6667% -0.2001% +2.0692%] 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.
Nits only.
Co-authored-by: Martin Thomson <mt@lowentropy.net> Signed-off-by: Lars Eggert <lars@eggert.org>
Co-authored-by: Martin Thomson <mt@lowentropy.net> Signed-off-by: Lars Eggert <lars@eggert.org>
Co-authored-by: Martin Thomson <mt@lowentropy.net> Signed-off-by: Lars Eggert <lars@eggert.org>
Off the top of my head, I am not sure how, given that the move to I can take a look. With which server does |
This currently fails, because we have a bug where the server does not accept retransmitted 0-RTT packets when it should.