Implement PKTS_BETWEEN_PROBES for PMTUD#2514
Conversation
Add configurable spacing between PMTUD probes. When configured, PMTUD waits until the given number of non-probe packets has been sent before allowing the next probe. When configured, this prevents lost probes on idle connections from inflating the in-flight byte count, triggering PTO, and causing further probes. Without spacing, this can create a self-reinforcing loop that escalates the PTO exponent and generates unnecessary traffic.
| /// PMTUD probes. | ||
| /// | ||
| /// The default value is `0`. | ||
| pub fn set_pmtud_pkts_between_probes(&mut self, pkts: usize) { |
There was a problem hiding this comment.
Why default 0? If lost probes really escalate into a self-reinforcing PTO loop, opt-in-off means nobody's protected unless they know to flip it. Is 0 just conservatism, or is the loop rare enough in practice that opt-in is the right call?
There was a problem hiding this comment.
The default was chosen to preserve the existing behavior of the library.
Use case that motivated this change is a connection that sends all application data early, then stays open mostly idle until it is closed because of a long idle timeout. At that point, sending additional PMTUD probes is usually not useful, because the connection is unlikely to send more data. In that situation, continued probing can just keep exercising the PTO/loss path without providing much benefit.
| self.smallest_failed_probe_size != Some(MIN_PLPMTU) | ||
| self.smallest_failed_probe_size != Some(MIN_PLPMTU) && | ||
| self.pkts_since_last_probe | ||
| .is_none_or(|n| n >= self.pkts_between_probes) |
There was a problem hiding this comment.
More design question than objection: RFC 8899 spaces probes by time (≥1 RTT floor, PROBE_TIMER) or the idle-inhibit MAY in §4.3 ("no app data since previous probe") — not a packet count. And §3.7 is basically this bug: "Loss of a probe packet SHOULD NOT be treated as an indication of congestion and SHOULD NOT trigger a congestion control reaction." So the spec's own remedy is to keep lost probes out of the CC/PTO reaction rather than throttling probe cadence. Was a packet count chosen over either of those on purpose? It isn't non-conformant (§3 only mandates the ≥1-RTT floor), it just feels like it's damping the symptom while probe-loss-as-data-loss stays intact.
There was a problem hiding this comment.
Packet count was not chosen over either of those. The intent is to add an additional configurable condition on top of the existing PMTUD probing logic, not to replace the RFC 8899 time-based spacing or idle-inhibit behavior.
This idea is taken from Google QUICHE, where packets_between_probes exists: QuicConnectionMtuDiscoverer uses a packet-count threshold, starting from a base value and doubling it after each MTU probe attempt before scheduling the next probe.
So this should be read as an extra configurable cadence guard, not as the primary RFC 8899 remedy for probe-loss handling.
2 participants
Add configurable spacing between PMTUD probes. When configured, PMTUD waits until the given number of non-probe packets has been sent before allowing the next probe.
This prevents lost probes on idle connections from inflating the in-flight byte count, triggering PTO, and causing further probes. Without spacing, this can create a self-reinforcing loop that escalates the PTO exponent and generates unnecessary traffic.