Re: [tcpm] PLPMTUD for all protocols

[Mikael Abrahamsson <[e-mail]>]

On Thu, 29 Mar 2018, [e-mail] wrote:

> And I don't care much *why* ICMPs are blocked, dropped, or never reach 
> the source - i.e., whether this is operator misconfiguration, deliberate 
> configuration, problems with NAT translation, or problems with tunnel 
> ingress relay back to the source. The result is the same, and I don't 
> think we can expect any of that to get better.

Agreed. Things go wrong, and protocols need to handle this fact. I don't 
really care how they handle it, and I'm ok with performance being 
severely reduced in this "limp mode" (the equivalent of a internal 
combustion engine mode where it still runs but at a severely reduced 
performance level, just so you can safely get yourself to a mechanic).

Once we have this limp mode, then people can think of how to optimize 
this, if they so want. There are smart people here, I've already seen 
proposals that look like they are worthwhile pursuing, but I would really 
like to get in place a very straight forward solution for the "this will 
not work at all"-case, where in TCPs case it seems to me that this is 5-8 
seconds of total loss, back in slow-start, nothing is working. We can then 
have probing back to (larger) PMTUD packet sizes after some time. Frankly, 
I don't much mind if this TCP session goes back to this painfully bad 
state every 30 seconds to re-probe the PMTUD value, at least it'll not be 
completely broken.

I just want this default-on in all major TCP stacks, in the next few 
years. The simpler, the better and the higher chance that it'll get 
adopted, right?

-- 
Mikael Abrahamsson    email: [e-mail]