fix: Single-packet RTX in Initial/Handshake + RTX handshake ACKs #2027
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is not yet complete. It works for the first RTX of a lost server Initial, which now contains the same data as the original transmission. A third RTX only contains pings. Something is off about our probe logic. Will continue investigating, but want to see what the bench and QNS impacts of this change are.
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
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2027 +/- ##
==========================================
+ Coverage 95.35% 95.38% +0.02%
==========================================
Files 112 112
Lines 36507 36516 +9
==========================================
+ Hits 34812 34831 +19
+ Misses 1695 1685 -10 ☔ View full report in Codecov by Sentry. |
Benchmark resultsPerformance differences relative to 4a5a041. coalesce_acked_from_zero 1+1 entries: Change within noise threshold. time: [191.94 ns 192.40 ns 192.94 ns]
change: [+0.3425% +0.7406% +1.1239%] (p = 0.00 < 0.05)
coalesce_acked_from_zero 3+1 entries: 💔 Performance has regressed. time: [235.81 ns 236.38 ns 236.97 ns]
change: [+1.1324% +1.5194% +1.9216%] (p = 0.00 < 0.05)
coalesce_acked_from_zero 10+1 entries: 💔 Performance has regressed. time: [236.01 ns 236.88 ns 237.90 ns]
change: [+1.6128% +2.2558% +3.0309%] (p = 0.00 < 0.05)
coalesce_acked_from_zero 1000+1 entries: Change within noise threshold. time: [216.95 ns 217.03 ns 217.11 ns]
change: [+0.1359% +0.8773% +1.5342%] (p = 0.01 < 0.05)
RxStreamOrderer::inbound_frame(): Change within noise threshold. time: [119.21 ms 119.30 ms 119.39 ms]
change: [-0.4797% -0.3708% -0.2698%] (p = 0.00 < 0.05)
transfer/pacing-false/varying-seeds: Change within noise threshold. time: [38.945 ms 40.916 ms 42.944 ms]
change: [-12.524% -6.5467% +0.0121%] (p = 0.04 < 0.05)
transfer/pacing-true/varying-seeds: No change in performance detected. time: [57.063 ms 59.989 ms 62.928 ms]
change: [-1.1142% +6.3451% +14.212%] (p = 0.10 > 0.05)
transfer/pacing-false/same-seed: No change in performance detected. time: [48.774 ms 50.516 ms 52.214 ms]
change: [-2.0857% +2.8388% +7.8430%] (p = 0.26 > 0.05)
transfer/pacing-true/same-seed: No change in performance detected. time: [72.918 ms 79.133 ms 85.317 ms]
change: [-2.4009% +8.5439% +20.421%] (p = 0.14 > 0.05)
1-conn/1-100mb-resp (aka. Download)/client: No change in performance detected. time: [129.18 ms 129.88 ms 130.53 ms]
thrpt: [766.10 MiB/s 769.97 MiB/s 774.09 MiB/s]
change:
time: [-7.0309% -1.3579% +2.1144%] (p = 0.76 > 0.05)
thrpt: [-2.0706% +1.3766% +7.5627%]
1-conn/10_000-parallel-1b-resp (aka. RPS)/client: Change within noise threshold. time: [409.09 ms 412.98 ms 416.82 ms]
thrpt: [23.991 Kelem/s 24.214 Kelem/s 24.444 Kelem/s]
change:
time: [-0.0080% +1.3512% +2.7025%] (p = 0.05 < 0.05)
thrpt: [-2.6314% -1.3332% +0.0080%]
1-conn/1-1b-resp (aka. HPS)/client: No change in performance detected. time: [46.490 ms 47.264 ms 48.041 ms]
thrpt: [20.816 elem/s 21.158 elem/s 21.510 elem/s]
change:
time: [-1.5841% +0.6018% +2.9852%] (p = 0.61 > 0.05)
thrpt: [-2.8987% -0.5982% +1.6096%]
Client/server transfer resultsTransfer of 33554432 bytes over loopback.
|
larseggert
requested review from
KershawChang,
martinthomson and
mxinden
as code owners
larseggert
changed the title
mxinden
reviewed
Aug 2, 2024
larseggert
changed the title
|
That last change seems to really have helped with |
|
And now the |
larseggert
commented
Aug 9, 2024
Signed-off-by: Lars Eggert <lars@eggert.org>
Signed-off-by: Lars Eggert <lars@eggert.org>
Signed-off-by: Lars Eggert <lars@eggert.org>
mxinden
approved these changes
Aug 13, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With this change, we're now only sending one packet on PTO in the Initial and Handshake packet number spaces, for both server and client. Before, the server was allowed to send two and the client was allowed to send two during Handshake, which meant that if one packet was lost, we would RTX the lost packet and a (useless) empty PING. The server would then hit the amplification limit. With this change, we only RTX the lost packet, making the Handshake more robust under loss.
A second change here is to immediately force an ACK during the Handshake when a previous ACK was lost. Before this, the original Initial form the server contained an ACK, but any RTX did not, because we stopped the ACK timer when generating the first ACK and never restarting it.
Both these changes reduce
L1andC1interop failures.