Re: Scenario using SMB's RF option and different starting algorithm

[sytek![e-mail] (Keith Mc Cloghrie)]

> 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.

Two comments:

1. In order to send only one "mongo-gram" followed by normal 
nonlocal MTU sized datagrams, the probing would have to be 
driven from the TCP (or UDP application) level.  Which means 
that every new connection/application would be doing it.  With 
a busy host, that would be many concurrent MTU-discovery 
attempts being done in parallel and no caching of knowledge 
from one connection/application to the next.  In order to 
avoid this, the probing needs to be driven from the IP level.

2. Your example of "the report option will indicate ..." suggests
you are using a 1063-like option, even though you said SMB's IP RF
option would be set.  I agree, though, that a size-reporting option 
is needed in this scheme, since with report-fragmentation there 
would be no deterministic way to distinguish between no-fragmentation 
and loss of the mongo-gram or responding ICMP message (which means 
you have to re-transmit it enough times so that the statistical
liklihood of a loss is neglible).

Keith.