[PATCH 0 of 4] QUIC path MTU discovery

[Sergey Kandaurov]

> On 6 Jul 2023, at 17:57, Roman Arutyunyan <arut at nginx.com> wrote:
> 
> Updated PMTUD:
> 
> - Eliminated getting local interface MTU.  This was too intrusive and platform-
>  dependent.

RFC 8899 how the following statement on this:

A DPLPMTUD sender is RECOMMENDED to utilize information about
the maximum size of packet that can be transmitted by the sender
on the local link (e.g., the local link MTU). <..> This avoids
implementations trying to send probe packets that cannot be
transferred by the local link.

I won't insist on keeping this part,
but we can reconsider it in future.

> 
> - Added timeout (1 sec) before each PMTUD iteration to reduce PMTUD traffic
>  in short connections.

While I understand that this is used to avoid over-utilising paths,
such long deferred probes can cause under-utilisation.
Probably some value derived from path's PTO might have sense, e.g. 3PTO.
The delay as implemented causes delays for subsequent probes as well,
which might be too conservative.

> 
> - Size search reimplemented.  MTU is increased by 256 bytes until failure,
>  after which binary search is used.  Real life MTU will be around 1500, while
>  initial payload size is 1200.  Doing binary search from 65k down to 1500 will
>  produce a lot of failed syscalls and useless traffic.  Ascending from 1200
>  to a first failre will be quick.

I agree that starting from below have more sense.
Further, if multiplying probe MTU, as proposed in addendum,
looks more suitable for benchmarking.
OTOH, 256 byte steps may be more realistic approach,
given that well known PMTUs usually don't exceed 1500 bytes.

> 
> --
> Roman Arutyunyan
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-devel

-- 
Sergey Kandaurov