Re: [tcpm] PLPMTUD for all protocols

[Mikael Abrahamsson <[e-mail]>]

On Thu, 29 Mar 2018, William Herrin wrote:

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

Then the resolver needs to ask again, but make sure that the response is 
small enough. This is up to the protocol implementer to figure out. If the 
protocol implementer wants stateless unicast to work as a deployment 
scenario, then they need to design the protocol for PLPMTUD to work.

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

I am perfectly fine with the PMTUD blackhole algorithm kicking in after 5 
seconds of complete loss and TCP going back to slow start. I do not care 
much if performance is really bad when there is a PMTUD blackhole. What I 
want to avoid is that things don't work at all. Abysmal performance is 
better than things not working at all (which is often the case right now).

Also, if PMTUD blackhole detect kicks in, I'd like to be able to diagnose 
it with counters or logs from the TCP stack, telling me that this is going 
on.

-- 
Mikael Abrahamsson    email: [e-mail]