Re: SMB's proposal: using an IP option for "Report Fragmentation" flag

[mogul (Jeffrey Mogul)]

Steve Deering writes:

    If a host is not sending datagrams large enough to be fragmented,
    why would it *care* what the path MTU is?  Some sessions will never
    incur fragmentation [...]

and    

    >	... and (this is the part that applies equally to Steve D's method)
    >	it might take a while for the sender to discover the MTU.
    
    It takes one round-trip time, same as the RFC-1063 mechanism.

After I sent my message (to which Steve D responded, to which I am
responding) I realized that I wasn't entirely clear about the scenario
I was thinking of.

Think of what happens during the lifetime of an SMTP connection.
Since there is an SMTP-level handshake that goes on, the first
few datagrams of an SMTP connection are going to be "small".  After
this handshake, the body of the mail message is sent, which may
cause several "large" segments to be sent.

Now, if one used a method (such as Steve's) that depended upon the
"probing" transmission of a large segment in order to obtain the
path MTU, the SMTP sender won't discover the MTU until at least
the first large segment has been sent (and perhaps several more,
if the ACK arrives before the ICMP report).  True, it takes one
RTT from the time that the probe is sent, but the probe is sent
relatively late in the connection.

The method in RFC1063 (whatever its other flaws) allows the SMTP
sender to ask about the path MTU using a datagram of any size,
in particular the first datagram of the connection ... well in advance
of the need to send a large segment.  This is the point I was
trying to make about how long it takes to discover the path MTU.

Telnet connections also presumably start with small segments and
potentially go on to large ones.  Ditto NFS (since you have to
do a lookup before doing a read or write).

    No point in wasting cycles on MTU discovery, if you're not actually
    going to incur fragmentation.

Well, yeah, but the whole point is to avoid fragmentation.

    Regarding packets being dropped on the return path, ICMP reports are no
    more likely to get lost than any datagram bearing an IP MTU Reply option.

Except that a TCP (for example) datagram carrying a Reply option will
(sooner or later) get retransmitted if it is lost along the way.  (We
may have to think about the suggested algorithm for when to send the
Reply option; maybe the Reply option should be carried on any
retransmission aof a segment.)
    
    Assuming reassembly succeeds most of the time, how much do we care about
    the overhead of fragmentation and reassembly for one round-trip time?

One of the original motivations for MTU discovery was that in many
cases it was observed that reassembly does not "succeed most of the time."
Perhaps the state of the art in interface and router technology has
obviated this problem, but I'd rather not make this assumption.

-Jeff