these variables may be updated.





 
RFC 1981              Path MTU Discovery for IPv6            August 1996


   A TCP implementation must also store the MSS value received from its
   peer, and must not send any segment larger than this MSS, regardless
   of the PMTU.  In 4.xBSD-derived implementations, this may require
   adding an additional field to the TCP state record.

   The value sent in the TCP MSS option is independent of the PMTU.
   This MSS option value is used by the other end of the connection,
   which may be using an unrelated PMTU value.  See [IPv6-SPEC] sections
   "Packet Size Issues" and "Maximum Upper-Layer Payload Size" for
   information on selecting a value for the TCP MSS option.

   When a Packet Too Big message is received, it implies that a packet
   was dropped by the node that sent the ICMP message.  It is sufficient
   to treat this as any other dropped segment, and wait until the
   retransmission timer expires to cause retransmission of the segment.
   If the Path MTU Discovery process requires several steps to find the
   PMTU of the full path, this could delay the connection by many
   round-trip times.

   Alternatively, the retransmission could be done in immediate response
   to a notification that the Path MTU has changed, but only for the
   specific connection specified by the Packet Too Big message.  The
   packet size used in the retransmission should be no larger than the
   new PMTU.

      Note: A packetization layer must not retransmit in response to
      every Packet Too Big message, since a burst of several oversized
      segments will give rise to several such messages and hence several
      retransmissions of the same data.  If the new estimated PMTU is
      still wrong, the process repeats, and there is an exponential
      growth in the number of superfluous segments sent.

      This means that the TCP layer must be able to recognize when a
      Packet Too Big notification actually decreases the PMTU that it
      has already used to send a packet on the given connection, and
      should ignore any other notifications.

   Many TCP implementations incorporate "congestion avoidance" and
   "slow-start" algorithms to improve performance [CONG].  Unlike a
   retransmission caused by a TCP retransmission timeout, a
   retransmission caused by a Packet Too Big message should not change
   the congestion window.  It should, however, trigger the slow-start
   mechanism (i.e., only one segment should be retransmitted until
   acknowledgements begin to arrive again).

   TCP performance can be reduced if the sender's maximum window size is
   not an exact multiple of the segment size in use (this is not the
   congestion window size, which is always a multiple of the segment




 
RFC 1981              Path MTU Discovery for IPv6            August 1996


   size).  In many systems (such as those derived from 4.2BSD), the
   segment size is often set to 1024 octets, and the maximum window size
   (the "send space") is usually a multiple of 1024 octets, so the
   proper relationship holds by default.  If Path MTU Discovery is used,
   however, the segment size may not be a submultiple of the send space,
   and it may change during a connection; this means that the TCP layer
   may need to change the transmission window size when Path MTU
   Discovery changes the PMTU value.  The maximum window size should be
   set to the greatest multiple of the segment size that is less than or
   equal to the sender's buffer space size.

5.5. Issues for other transport protocols

   Some transport protocols (such as ISO TP4 [ISOTP]) are not allowed to
   repacketize when doing a retransmission.  That is, once an attempt is
   made to transmit a segment of a certain size, the transport cannot
   split the contents of the segment into smaller segments for
   retransmission.  In such a case, the original segment can be
   fragmented by the IP layer during retransmission.  Subsequent
   segments, when transmitted for the first time, should be no larger
   than allowed by the Path MTU.

   The Sun Network File System (NFS) uses a Remote Procedure Call (RPC)
   protocol [RPC] that, when used over UDP, in many cases will generate
   payloads that must be fragmented even for the first-hop link.  This
   might improve performance in certain cases, but it is known to cause
   reliability and performance problems, especially when the client and
   server are separated by routers.

   It is recommended that NFS implementations use Path MTU Discovery
   whenever 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.