PLPMTUD?

[timchown]

Michael Richardson commented on the list:
"I would like section 5.7 to speak more strongly about PLPMTU.
I think it should be turned on by default.
(I turn it on everywhere)

Near the end of RFC8504, I was trying to get sufficient evidence that it
causes no harm. I also investigating what it would take to get Linux distros
to ship with it on by default, or for the Linux kernel to change it's
default.

When investigating this I learn that:

1. few or none of the big properties had it turned on. They just set their
   TCP (max) segment size to 1400 or some number like that.

2. this is because TX opportunities were considered scarce, they use TCP
   Segment Offload, so in order to send any probe packets, they would have to
   do something else.

3. sending 10 1400 byte packets is less expensive than sending 9 1500 byte
   packets, if any of those packets will need to be retransmitted because of
   an MTU issue.

As such none of the big properties could provide any evidence that PLPMTU was
not harmful.

Maybe it just doesn't matter. Maybe we should just all set a knob making
~1400 be the largest TCP segment size. Will we ever get to 9K packets on the
Internet? Does anyone still want to go there?"

and

"What about an SSH connection IPv6 at home over VDSL (PPPoE) to some server
with a 9000 MTU? Does that work? I see it fail regularly because PPPoE
usually has a 1480-ish value."

[timchown]

Another request from Michael:

"I wish again to argue for nodes implementing PLMTUD as a MUST, and
to relegate PMTUD (via returned ICMP messages) as a "if it works, great, but
don't depend upon it"

I've been turning this on as a default for over a decade, and it really
really helps... Particularly as things like SSH key negotiations take more
than 1400 bytes.

My attempts to get it to become the default for many OSes failed 5-7 years
ago. Does someone have some experimental experience in the large with doing
this. Well, the problem is that TCP Segment Offload means that most systems
never ever want to experience fragmentation, so they never push the MTU to
max. So the hyper-scalers never even try. PMTU is dead for them, and they
have no data.

Is there some way we can get enough "it works" data to make PLPMTUD a very
strong SHOULD?

All this means it's very hard for anyone to push their local MTU to 9000.
I'm told the CERN/HEPNET people have 9000 all through the R&E networks.
I think Tim has experience with this? I guess it's easier to get those ICMP
messages across your "internal" network to the places where R&E networks
connect to 1500byte Internet.

But, still, the pain point is home users with PPPoE, and 1480 restrictions
at their ISP, and the idiot banks who still drop all ICMPs. But, in IPv4,
the NAT44 "clamps" the MSS to a lower number, so we don't see the failures.
Which we do see in IPv6."