Implement PMTU_RAISE_TIMER for PMTUD re-probing#2534
Open
cf-rhett wants to merge 1 commit into
Open
Conversation
cf-rhett
marked this pull request as ready for review
July 9, 2026 17:52
cf-rhett
force-pushed
the
rhett/pmtud-raise-timer
branch
2 times, most recently
from
July 15, 2026 17:47
042fe03 to
07b04cb
Compare
After PMTUD settles on a PLPMTU it never probes again, so a path that later supports a larger MTU is never rediscovered. Arm a raise timer (default 600s) once a PMTU is found and re-enter the Search Phase when it expires, per RFC 8899 Section 5.1.1, reusing the existing optimistic binary search. The interval is configurable through Config, the C FFI, and tokio-quiche settings; a zero duration disables re-probing and preserves the previous settle-and-stop behavior.
cf-rhett
force-pushed
the
rhett/pmtud-raise-timer
branch
from
July 15, 2026 18:24
07b04cb to
0cf3fd2
Compare
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Right now PMTUD stops for good once it settles on a PLPMTU. If the path later starts supporting a larger MTU, quiche never notices, because there is no mechanism to go back and look. This adds the RFC 8899 raise timer: once configured and a PMTU is found, the path re-enters the Search Phase when the timer fires and re-runs the existing optimistic binary search. If the path grew, we find the larger MTU; if not, we re-confirm the same one. RFC 8899 recommends a 600-second interval.
It is configurable through Config, the C FFI, and tokio-quiche, including the mid-handshake ex_data path. The tokio-quiche setting is serialized as
pmtud_raise_timer_ms, so the RFC interval is600000; zero or an omitted value disables periodic re-probing.Periodic re-probing is disabled by default because QUIC PMTU probes are ACK-eliciting. Without RFC 8899's optional idle suppression, they can reset the QUIC idle timer and act as an implicit keepalive when the configured idle timeout exceeds the raise interval. I left idle suppression out for now rather than coupling application-activity tracking into this change.
Risk: low. Existing PMTUD users retain the current settle-and-stop behavior, while users who opt in reuse the existing probe and search machinery.