On Mon, Apr 19, 2010 at 08:30:31AM -0400, Simon Perreault wrote:
> PMTUD can only lower TCP MSS (either the default one or the one
> advertised by the peer), not raise it.
I don't think that's actually true, but it's possible that I'm
misunderstanding one or more of {you, the code, RFC 1191}.
I *think* the relevant text from RFC 1191 is this:
The PMTU of a path may change over time, due to changes in the
routing topology. Reductions of the PMTU are detected by Datagram
Too Big messages, except on paths for which the host has stopped
setting the DF bit. To detect increases in a path's PMTU, a host
periodically increases its assumed PMTU (and if it had stopped,
resumes setting the DF bit). This will almost always result in
datagrams being discarded and Datagram Too Big messages being
generated, because in most cases the PMTU of the path will not have
changed, so it should be done infrequently.
I don't think it's required (based on this language and the rest of the
RFC) that a host periodically increase its presumed PMTU in order to
find out if the actual PMTU has increased, but I certainly think it's
allowable behavior. Whether or not it's desirable is another matter,
which I'll talk about in the next paragraph.
The presumed PMTU should never be increased above that advertised by the
peer, since that's pointless. But it might make sense, if the current
PMTU is much lower than that advertised by the peer, to try a value equal
to that advertised by the peer with the hope that routing has changed in
a favorable way. To illustrate by example: if the peer is advertising
1200 and the current PMTU is 1180, it's probably not worth periodically
testing to see if 1200 is possible. But if the peer is advertising
1200 and the current PMTU is 600, it may be worth the overhead to check
occasionally to see if anything better is available.
The thing is, "occasionally" is nebulous -- and even if a higher PMTU
is available, it's only a win if the overhead of discovering it is less
than is saved by using it. (Figuring out that the PMTU can be increased
from 600 to 940 for the last 4K of a 10M transfer is probably not a win.)
Moreover, as far as I'm aware, the only way to find out what's possible
is to run the experiment: there's no way a priori to estimate whether or
not the source<->destination path has changed (and modulo an interesting
change on a device in that path, it's a change in the path not a change on
the path that's most likely to result in a different PMTU).
So is it reasonable to say (in pseudocode):
if (the PMTU is low)
AND (the PMTU is considerably lower than the peer)
AND (it's been a while since we last checked the PMTU)
then
it's worth trying to see if a higher PMTU is available
or is this simply additional complexity that is unlikely to result
in much real-world throughout improvement?
---Rsk
