feat: Stop the PMTUD search at the interface MTU #2135
Conversation
WIP Should we optimistically *start* the search at the interface MTU, and only start from 1280 when that fails?
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2135 +/- ##
==========================================
+ Coverage 95.39% 95.40% +0.01%
==========================================
Files 112 112
Lines 36373 36372 -1
==========================================
+ Hits 34697 34700 +3
+ Misses 1676 1672 -4 ☔ View full report in Codecov by Sentry. |
larseggert
requested review from
KershawChang,
martinthomson and
mxinden
as code owners
Are there other projects using this optimistic approach? If I understand RFC 8899 correctly the local interface MTU is the end value, not the start value.
|
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
|
|
All true, but in practice, the local interface is most often the limiting hop. |
Benchmark resultsPerformance differences relative to 55e3a93. coalesce_acked_from_zero 1+1 entries: 💚 Performance has improved. time: [109.82 ns 110.16 ns 110.51 ns]
change: [-2.9114% -2.4202% -1.8027%] (p = 0.00 < 0.05)
coalesce_acked_from_zero 3+1 entries: 💚 Performance has improved. time: [123.78 ns 124.18 ns 124.61 ns]
change: [-29.538% -29.258% -28.981%] (p = 0.00 < 0.05)
coalesce_acked_from_zero 10+1 entries: 💚 Performance has improved. time: [123.25 ns 123.50 ns 123.85 ns]
change: [-36.277% -31.789% -29.118%] (p = 0.00 < 0.05)
coalesce_acked_from_zero 1000+1 entries: 💚 Performance has improved. time: [101.06 ns 101.31 ns 101.60 ns]
change: [-29.311% -28.682% -27.990%] (p = 0.00 < 0.05)
RxStreamOrderer::inbound_frame(): Change within noise threshold. time: [111.45 ms 111.51 ms 111.57 ms]
change: [+0.0464% +0.1135% +0.1826%] (p = 0.00 < 0.05)
transfer/pacing-false/varying-seeds: Change within noise threshold. time: [25.530 ms 26.407 ms 27.279 ms]
change: [-12.035% -7.6053% -2.5828%] (p = 0.00 < 0.05)
transfer/pacing-true/varying-seeds: Change within noise threshold. time: [34.298 ms 35.702 ms 37.119 ms]
change: [-12.235% -6.7940% -0.8800%] (p = 0.02 < 0.05)
transfer/pacing-false/same-seed: No change in performance detected. time: [25.555 ms 26.339 ms 27.135 ms]
change: [-7.4868% -3.6913% +0.4903%] (p = 0.08 > 0.05)
transfer/pacing-true/same-seed: No change in performance detected. time: [40.692 ms 42.746 ms 44.849 ms]
change: [-8.5706% -2.2515% +4.3434%] (p = 0.49 > 0.05)
1-conn/1-100mb-resp (aka. Download)/client: 💚 Performance has improved. time: [111.94 ms 112.59 ms 113.21 ms]
thrpt: [883.31 MiB/s 888.14 MiB/s 893.31 MiB/s]
change:
time: [-3.4473% -2.8717% -2.3106%] (p = 0.00 < 0.05)
thrpt: [+2.3653% +2.9566% +3.5704%]
1-conn/10_000-parallel-1b-resp (aka. RPS)/client: Change within noise threshold. time: [311.43 ms 314.67 ms 317.83 ms]
thrpt: [31.463 Kelem/s 31.779 Kelem/s 32.110 Kelem/s]
change:
time: [-3.3142% -1.7738% -0.2049%] (p = 0.03 < 0.05)
thrpt: [+0.2053% +1.8059% +3.4278%]
1-conn/1-1b-resp (aka. HPS)/client: Change within noise threshold. time: [34.024 ms 34.199 ms 34.393 ms]
thrpt: [29.076 elem/s 29.241 elem/s 29.391 elem/s]
change:
time: [+0.6039% +1.3595% +2.2038%] (p = 0.00 < 0.05)
thrpt: [-2.1563% -1.3413% -0.6003%]
Client/server transfer resultsTransfer of 33554432 bytes over loopback.
|
|
This PR exposed a bug in |
Let me make sure I understand the implications here correctly. Sorry for any potential mistakes. We only start probing once the connection is confirmed. neqo/neqo-transport/src/connection/mod.rs Lines 2794 to 2802 in 55e3a93 Say that a client's path MTU is smaller than their local interface MTU. Given that probing only starts once confirmed, i.e. after receiving Thus this optimization, and really all of PMTUD probing, assumes that the potential delay of one subsequent flight of HTTP requests by up to one PTO is worth the trade off of potentially increasing the overall connection throughput. Is that correct? |
This would need to change. What I think we should do is roughly this:
n should probably be something like 2, so we don't cause undue delay. |
|
In the case where a client's path MTU is smaller than their local interface MTU, this would add a delay of 2*PTO to every connection establishment, right? If so, isn't that a high cost for the potential increase in throughput? Or is such scenario just very rare? |
|
Yes. I think this is a rare case, but maybe we add some telemetry first to confirm? We could also cache a probed MTU towards a destination IP, like the OS does for a TCP MSS it has determined. |
How about we:
|
|
I was thinking we just log the log the local interface MTU together with the discovered PMTUD, and check for differences. |
Should we also optimistically start the search at the interface MTU, and only start from 1280 when that fails?