Re: quibbling with Meeting report

mogul (Jeffrey Mogul) Wed, 13 December 1989 21:37 UTC

Received: by acetes.pa.dec.com (5.54.5/4.7.34) id AA26146; Wed, 13 Dec 89 13:37:30 PST
From: mogul (Jeffrey Mogul)
Message-Id: <8912132137.AA26146@acetes.pa.dec.com>
Date: 13 Dec 1989 1337-PST (Wednesday)
To: Craig Partridge <craig@nnsc.nsf.net>
Cc: mtudwg
Subject: Re: quibbling with Meeting report
In-Reply-To: Craig Partridge <craig@NNSC.NSF.NET> / Wed, 13 Dec 89 08:59:50 -0500. <8912131400.AA24077@decwrl.dec.com>

	But... I'd like to urge you all to reconsider the notion the MTU
    is stored per transport protocol.  NFS *CAN* use MTU information
    as can most other applications if it is made available to them....

A misimpression conveyed by my summary, I guess.  Senders store MTU
per destination (i.e., in the IP layer).  The receiver, we decided,
should not send an ICMP Fragmentation Report message in reply to
an NFS packet unless it has received an option from that host+port
indicating that the NFS implementation ON THAT HOST is willing to
do something with this ICMP.  Otherwise, we are just filling the
internet with useless ICMPs.

Consider the case where one pair of hosts simultaneously has an
NFS and a TCP connection in progress.  Suppose that the receiver
stored the "sent RF" per-host, rather than per-port.  Then, suppose
that the sender TCP is sending the RF flag (in an option or wherever)
but the NFS is not (because, for whatever reason, the sender's NFS
is not willing to listen to the Fragmentation Reports).  Then, the
receiver will continually send Frag Reports to the sender in response
to NFS packets, even though (1) the sender's TCP may never cause
fragmentation and (2) the sender's NFS will never do anything with
these ICMPs.  Wasted bandwidth.

But this is an "implementation suggestion", perhaps even a "good
citizen requirement", not a part of the actual protocol spec.

-Jeff