Re: [tcpm] PLPMTUD for all protocols

[Mikael Abrahamsson <[e-mail]>]

On Thu, 29 Mar 2018, William Herrin wrote:

> fails. It's also arguable that every instance of a PMTUD black hole is
> a consequence of an operator configuration error.

Some are, some are not.

> It's also fair to wonder why router and firewall vendors don't offer 
> configurations designed to mitigate the PMTUD black hole problem. 
> Firewall vendors could warn on attempts to block ICMP or require 
> explicit overrides to block ICMP destination unreachable messages. 
> Router vendors could offer a configuration option to issue ICMP 
> destination unreachables from the a configured public IP address rather 
> than from the interface's (sometimes private) IP address. They don't do 
> these things.

These are some reasons for PMTUD blackhole, but far from all. Some are 
caused by anycast configurations where the ICMP packet simply doesn't make 
it to the node that needs it. Load balancers doing the wrong thing.

> In principle the IETF could even designate a standard public IP address 
> to be used when routers that have no public IP addresses need to issue a 
> a fragmentation needed message. After a couple equipment cycles the 
> PMTUD black hole problem would presumably fall back to 1990s levels 
> which weren't so bad.

My take on this is that operators should do the right thing (make PMTUD 
work), and protocols should handle when things go wrong.

I have very little problem with TCP using an extremely stupid algorithm as 
in "I'll use PMTUD, but if it doesn't work I'm going to try 576/1280, and 
if that works I sometimes go back to PMTUD value to see if things have 
improved". This still means it'll work, somewhat.

-- 
Mikael Abrahamsson    email: [e-mail]