In message <200506220310.XAA02890@Sparkle.Rodents.Montreal.QC.CA>, der Mouse wr
ites:
>>> A nice reponse. But what's the impact on PMTU discovery,
>>> specifically in the case that path-PMTU increases?  Isn't the
>>> required PMTU-probe behaviour in that case exactly the scenario
>>> (remote peer sends "DF" segment with a lenght larger than the
>>> current mtu) which you propse to ignore?
>
>> No, you never get such messages from remote routers; they have no
>> idea what size you could have sent, so they can't tell you to send
>> something larger.  You're supposed to try larger MTUs after some
>> interval.  See Sections 6.3 and 7.1 of RFC 1191.
>
>No, you've missed the point.
>
>Say we've settled on a path MTU of 1100 octets.  Then we send a probe
>of (say) 1400 octets.  But the actual path MTU is now 1250; we get a
>need-frag ICMP giving 1250.  But 1250 > 1100, so the algorithm would
>have us ignore the ICMP.
>
>The obvious fix, of course, is to add an exception that says "...unless
>we've recently sent a PMTU-D MTU-growth probe no smaller than the size
>in the packet".  Or, equivalently, when we send the probe, we raise our
>local idea of the path MTU at the same time, optimistically, and let it
>get cut back immediately if needed.

I think the latter is by far the easiest way to do it, since the probe 
isn't an out-of-band message, it's simply a packet with a larger MTU.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb