RFC 1191 Path MTU Discovery November 1990
routers are involved. Most NFS implementations allow the RPC
datagram size to be changed at mount-time (indirectly, by changing
the effective file system block size), but might require some
modification to support changes later on.
Also, since a single NFS operation cannot be split across several UDP
datagrams, certain operations (primarily, those operating on file
names and directories) require a minimum datagram size that may be
larger than the PMTU. NFS implementations should not reduce the
datagram size below this threshold, even if PMTU Discovery suggests a
lower value. (Of course, in this case datagrams should not be sent
with DF set.)
6.6. Management interface
We suggest that an implementation provide a way for a system utility
program to:
- Specify that PMTU Discovery not be done on a given route.
- Change the PMTU value associated with a given route.
The former can be accomplished by associating a flag with the routing
entry; when a packet is sent via a route with this flag set, the IP
layer leaves the DF bit clear no matter what the upper layer
requests.
These features might be used to work around an anomalous situation,
or by a routing protocol implementation that is able to obtain Path
MTU values.
The implementation should also provide a way to change the timeout
period for aging stale PMTU information.
7. Likely values for Path MTUs
The algorithm recommended in section 5 for "searching" the space of
Path MTUs is based on a table of values that severely restricts the
search space. We describe here a table of MTU values that, as of
this writing, represents all major data-link technologies in use in
the Internet.
In table 7-1, data links are listed in order of decreasing MTU, and
grouped so that each set of similar MTUs is associated with a
"plateau" equal to the lowest MTU in the group. (The table also
Mogul & Deering [page 15]
RFC 1191 Path MTU Discovery November 1990
includes some entries not currently associated with a data link, and
gives references where available). Where a plateau represents more
than one MTU, the table shows the maximum inaccuracy associated with
the plateau, as a percentage.
We do not expect that the values in the table, especially for higher
MTU levels, are going to be valid forever. The values given here are
an implementation suggestion, NOT a specification or requirement.
Implementors should use up-to-date references to pick a set of
plateaus; it is important that the table not contain too many entries
or the process of searching for a PMTU might waste Internet
resources. Implementors should also make it convenient for customers
without source code to update the table values in their systems (for
example, the table in a BSD-derived Unix kernel could be changed
using a new "ioctl" command).
Note: It might be a good idea to add a few table entries for
values equal to small powers of 2 plus 40 (for the IP and TCP
headers), where no similar values exist, since this seems to
be a reasonably non-arbitrary way of choosing arbitrary
values.
The table might also contain entries for values slightly less
than large powers of 2, in case MTUs are defined near those
values (it is better in this case for the table entries to be
low than to be high, or else the next lowest plateau may be
chosen instead).
7.1. A better way to detect PMTU increases
Section 6.3 suggests detecting increases in the PMTU value by
periodically increasing the PTMU estimate to the first-hop MTU.
Since it is likely that this process will simply "rediscover" the
current PTMU estimate, at the cost of several dropped datagrams, it
should not be done often.
A better approach is to periodically increase the PMTU estimate to
=9= |