Path MTU Discovery is highly affected by packet loss

[marten-seemann]

Loss of a single probe packet will make the MTU discoverer believe that it has reached the path's MTU. This is unnecessarily aggressive.

It doesn't cost a lot to send a second probe packet of the same size (in most cases just 1 extra packet, if you're careful), to confirm that the loss was actually caused by exceeding the MTU.

The concrete algorithm is still tbd.

[marten-seemann]

We might not need #4519 (or at the very least reduce the number of flake attempts) once we have this.

[bt90]

Loss of a single probe packet will make the MTU discoverer believe that it has reached the path's MTU. This is unnecessarily aggressive.

I think this even violates RFC 8899:

The PL is REQUIRED to be robust in the case where probe packets are lost due to other reasons (including link transmission error, congestion).

The RFC seems to recommend up to 3 probes before giving up: https://datatracker.ietf.org/doc/html/rfc8899#name-constants

This paper by the RFC 8899 authors looks quite interesting:

https://www.hb.fh-muenster.de/opus4/frontdoor/deliver/index/docId/14965/file/dplpmtudQuicPaper.pdf

[marten-seemann]

Thank you @bt90! I wasn't aware of this paper, and I'm not sure I understand how they deal with packet loss: Every time a probe packet is lost, you have the choice to either re-probe the same size, or reduce the probe size by a little and probe a slightly smaller size.

I don't think it hugely matters, PMTUD is cheap, so going for something simple might be the better answer than hunting for the most optimal solution.

[bt90]

Every time a probe packet is lost, you have the choice to either re-probe the same size, or reduce the probe size by a little and probe a slightly smaller size.

That one is covered by the RFC:

https://datatracker.ietf.org/doc/html/rfc8899#name-probing-for-a-larger-plpmtu

tl;dr: the search only stops after multiple probes failed

[marten-seemann]

@bt90 I implemented an algorithm that should be more resilient to packet loss in #4545. Would you mind taking a look?