fix: Drop of Initial space only after sending 1st Handshake #2118
Conversation
This is what RFC9000 says, and it helps with servers that expect ACKs in the Initial packet number space to happen. It also eliminates a difference in behavior we had when a client received an Initial packet containing an ACK and a CRYPTO frame vs. a CRYPTO frame and an ACK, where that CRYPTO frame caused the Initial packet number space to be dropped. Broken out of mozilla#1998
larseggert
requested review from
KershawChang,
martinthomson and
mxinden
as code owners
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2118 +/- ##
==========================================
- Coverage 95.35% 95.33% -0.02%
==========================================
Files 112 112
Lines 36336 36333 -3
==========================================
- Hits 34648 34638 -10
- Misses 1688 1695 +7 ☔ 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 55e3a93. coalesce_acked_from_zero 1+1 entries: 💚 Performance has improved. time: [99.020 ns 99.373 ns 99.748 ns]
change: [-12.625% -12.109% -11.519%] (p = 0.00 < 0.05)
coalesce_acked_from_zero 3+1 entries: 💚 Performance has improved. time: [116.71 ns 117.07 ns 117.47 ns]
change: [-33.575% -33.290% -33.015%] (p = 0.00 < 0.05)
coalesce_acked_from_zero 10+1 entries: 💚 Performance has improved. time: [116.19 ns 116.44 ns 116.81 ns]
change: [-39.985% -35.771% -33.269%] (p = 0.00 < 0.05)
coalesce_acked_from_zero 1000+1 entries: 💚 Performance has improved. time: [97.353 ns 97.537 ns 97.759 ns]
change: [-32.104% -31.560% -30.951%] (p = 0.00 < 0.05)
RxStreamOrderer::inbound_frame(): Change within noise threshold. time: [111.59 ms 111.73 ms 111.95 ms]
change: [+0.1729% +0.3073% +0.5402%] (p = 0.00 < 0.05)
transfer/pacing-false/varying-seeds: No change in performance detected. time: [27.051 ms 28.047 ms 29.043 ms]
change: [-6.8650% -1.8673% +3.1094%] (p = 0.48 > 0.05)
transfer/pacing-true/varying-seeds: No change in performance detected. time: [34.872 ms 36.392 ms 37.908 ms]
change: [-10.358% -4.9922% +1.1502%] (p = 0.10 > 0.05)
transfer/pacing-false/same-seed: 💚 Performance has improved. time: [9.3547 ms 9.7340 ms 10.139 ms]
change: [-66.135% -64.408% -62.490%] (p = 0.00 < 0.05)
transfer/pacing-true/same-seed: 💚 Performance has improved. time: [27.417 ms 29.036 ms 30.657 ms]
change: [-38.208% -33.603% -29.174%] (p = 0.00 < 0.05)
1-conn/1-100mb-resp (aka. Download)/client: 💚 Performance has improved. time: [113.54 ms 113.86 ms 114.18 ms]
thrpt: [875.83 MiB/s 878.25 MiB/s 880.74 MiB/s]
change:
time: [-2.1369% -1.7783% -1.3912%] (p = 0.00 < 0.05)
thrpt: [+1.4109% +1.8104% +2.1836%]
1-conn/10_000-parallel-1b-resp (aka. RPS)/client: No change in performance detected. time: [312.32 ms 316.44 ms 320.43 ms]
thrpt: [31.208 Kelem/s 31.601 Kelem/s 32.018 Kelem/s]
change:
time: [-2.9836% -1.2214% +0.5215%] (p = 0.17 > 0.05)
thrpt: [-0.5188% +1.2365% +3.0754%]
1-conn/1-1b-resp (aka. HPS)/client: No change in performance detected. time: [33.676 ms 33.863 ms 34.064 ms]
thrpt: [29.357 elem/s 29.530 elem/s 29.694 elem/s]
change:
time: [-0.4043% +0.3648% +1.0771%] (p = 0.36 > 0.05)
thrpt: [-1.0656% -0.3635% +0.4060%]
Client/server transfer resultsTransfer of 33554432 bytes over loopback.
|
There was a problem hiding this comment.
This makes sense to me.
Can you link to the concrete section of RFC 9000 you are referring to?
I can only find the following in RFC 9001 4.9.1:
The successful use of Handshake packets indicates that no more Initial packets need to be exchanged, as these keys can only be produced after receiving all CRYPTO frames from Initial packets. Thus, a client MUST discard Initial keys when it first sends a Handshake packet and a server MUST discard Initial keys when it first successfully processes a Handshake packet. Endpoints MUST NOT send Initial packets after this point.
|
That is the section in question. |
|
@martinthomson I'd appreciate a review, since the code I am touching is pretty complex. |
This is what RFC9000 says, and it helps with servers that expect ACKs in the Initial packet number space to happen. It also eliminates a difference in behavior we had when a client received an Initial packet containing an ACK and a CRYPTO frame vs. a CRYPTO frame and an ACK, where that CRYPTO frame caused the Initial packet number space to be dropped.
Broken out of #1998