Re: [tcpm] PLPMTUD for all protocols

[William Herrin <[e-mail]>]

On Thu, Mar 29, 2018 at 11:31 AM, Mikael Abrahamsson <[e-mail]> wrote:
> On Thu, 29 Mar 2018, William Herrin wrote:
>> 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.

Hi Mikael,

Load balancers doing the wrong thing seems to me like some combination
of implementation error and configuration error.

How would PLPMTUD detect a path MTU black hole for DNS response
packets from an anycasted node? It's fire and forget; the server is
not expecting another packet from the querent.

Where something more complicated is done with anycast such as TCP
without suitable modifications (e.g.
https://bill.herrin.us/network/anycasttcp.html) then they've already
accepted that a portion of their prospective users will be
unreachable. I have no sympathy when folks decide to intentionally
implement breakage because it will, statistically, only be broken some
of the time.

You make an interesting point here about icmp unreachables in the TCP
anycast scenario that I haven't accounted for in that paper. I'll have
to think that through.


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

Operators "should" have the tools which:

A) make it practical to make PMTUD work in all commonly deployed
architectures and

B) do a respectable job preventing "design induced operator error"
with respect to PMTUD.

Currently shipping routers and firewalls mostly fail both criteria.


> 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.

I have no problem with falling back after a smart enough delay/retry
cycle concludes a very high probability a PMTUD black hole. I have
little problem with those connections suffering the performance hit of
small packets for the duration. I have a bigger problem if routine
packet loss or a brief path outage gets commonly misdetected as a
PMTUD black hole. I worry most that allowing the algorithm to the hunt
for the MTU will justify allowing a higher false positive rate for
black hole detection so that everybody suffers a performance hit even
when there are no black holes. There are no obvious ways to implement
that hunt which don't harm performance. I'd rather see it fall back
and stay back with an OS tunable for how confident it has to be of a
black hole before it falls back.

Regards,
Bill Herrin



-- 
William Herrin ................ [e-mail]  [e-mail]
Dirtside Systems ......... Web: <http://www.dirtside.com/>