Subject: Re: [tcpm] PLPMTUD for all protocols

From: John Heffner <[email-masked]>
Date: Sun, 1 Apr 2018 12:52:27 -0400

On Fri, Mar 30, 2018 at 10:28 AM, Mikael Abrahamsson <[email-masked]>
wrote:

> On Fri, 30 Mar 2018, Joe Touch wrote:
>
> - use IPv6 and go home (we shouldn’t be optimizing PMTUD for IPv6 - we
>> should just be sticking to IPv6 MTU requirements
>>
>
> In the longer term, I want to be able to deploy jumbo frames and run 9k
> access network including customer LAN. This means that a stupid MTU1280
> fallback isn't optimal, even though I'll gladly take that if the
> alternative is no PMTU blackhole detect at all.
>
>
> --
> Mikael Abrahamsson    email: [email-masked]
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>

I'd certainly be interested to look at concrete scenarios where performance
is a concern, even better with numbers, if anyone has gathered them.

Linux *will* probe upward after a black hole detection event has reduced
the effective path mtu.  One issue is that the currently-implemented
probing heuristic results in sub-optimal effective path mtu that will
remain in use indefinitely.  It shouldn't take much to improve on what's
there now if this is a real problem for people.

I haven't looked at the code, but from the description above, it doesn't
sound like FreeBSD implements what I would call RFC4821 PLPMTUD.

FWIW, one of the objectives when writing RFC4821 was to make it easy to
enable jumbo frames.  At the time, I ran my own laptop and a handful of
servers with a 9k or MTU for quite a while, and felt it generally worked
well with the setting tcp_mtu_probing = 2, i.e., always starting with a
small effective path mtu and probing upward.  (I imagine more
performance-sensitive applications, especially within data centers for
instance, might make different trade-offs.)

Thanks,
  -John