Re: [tcpm] PLPMTUD for all protocols

[Toerless Eckert <[e-mail]>]

So, whats the summary ?

Write rfc4821bis with recommendations for an additional,
simplified procedure dropping to 1280/576 and use most simple upspeeding 
option ? Because 10 years have shown full rfc4821 is not widely supported
in host stack because its too complex ?

Another, potentially complementary option is to do an rfc3542bis
or some small "highly reliable socket" BCP recommendation for
apps requring highest reliability to use 1280/576 MTU through appropriate
socket API calls. Could be done n TAPS ?

In any case, it would be good to document the broken cases Mikael
mentions as well as the difficulties getting complex host stack
workarounds implemented broadly - otherwise it will be hard to persuade
the MTU/performance part of the community of any such recommendations.

Cheers
    toerless

On Thu, Mar 29, 2018 at 12:58:07PM -0400, William Herrin wrote:
> 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/>
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
---
[e-mail]