PROXY  WHOIS  RQUOTE  TEXTS  SOFT  FOREX  BBOARD
 Music  Philosophy  Code  Literature  Russian

= ROOT|Technical|RFC|rfc1191.txt =

page 9 of 11



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=

1|2|3|4|5|6|7|8| < PREV = PAGE 9 = NEXT > |10|11

UP TO ROOT | UP TO DIR | TO FIRST PAGE

Google
 


E-mail Facebook Google Digg del.icio.us BlinkList Fark Furl Ma.gnolia Netscape NewsVine Reddit Slashdot Spurl StumbleUpon Technorati YahooMyWeb LiveJournal Blogmarks TwitThis Live News2.ru BobrDobr.ru Memori.ru MoeMesto.ru

0.0329318 wallclock secs ( 0.01 usr + 0.00 sys = 0.01 CPU)