Path MTU Discovery is highly affected by packet loss about quic-go HOT 5 CLOSED

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

from quic-go.

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

from quic-go.

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.

from quic-go.

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

from quic-go.

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

from quic-go.