Scenario using SMB's RF option and different starting algorithm

[[e-mail] (Charlie Wickham, DECWest Engr. 01-Dec-1989 1549)]

I believe a combination of reporting fragmentation coupled with a
start-big-and-then-immediately-back-off start might help. Here's a scenario:

Force the first mongo-gram (whose size is greater than the nonlocal subnet
MTU) datagram to be fragmented by sending it on the local subnet as
unfragmented. SMB's IP RF option is also set.  While waiting for a reply, send
future datagrams at the normal nonlocal subnet MTU.  This should prevent the
pipe from getting filled with datagrams that need fragmentation. The response
should indicate whether frag'ing occured, e.g., if the path didn't fragment,
then the report option will indicated a size that was the same as the
mongo-gram.

The bad parts are: 1) MTU size isn't discovered until you send something big
enough and 2) there is potentially wasted bandwidth while waiting for the
report to come back. It has the same problems Jeff mentioned earlier (not
finding out the MTU until late in the game), but I think we should concentrate
on the case where a circuit is alive for a period of time. Mail messages
containing postscript will surely figure out the MTU. Do we know what the
average lifetime of a VC is? Has anyone collected any stats on VC life?

Some other random thoughts: it seems like two mechanisms are needed here: one
for short lived VCs such as small mail sessions and another where you want to
know the MTU size but not with alot of initial up-front cost. If an
application can advise the transport how long the circuit will be around, that
could be used to determine the strategy used in determining how soon the MTU
needs to known.

charlie