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

Steve Deering <deering@pescadero.stanford.edu> Tue, 28 November 1989 09:14 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA10359; Tue, 28 Nov 89 01:14:22 PST
Received: by decwrl.dec.com; id AA10888; Tue, 28 Nov 89 01:14:18 -0800
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA03950; Tue, 28 Nov 89 01:14:11 PDT
Date: 27 Nov 1989 23:52-PST
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: Re: SMB's proposal: using an IP option for "Report Fragmentation" flag
To: mogul (Jeffrey Mogul)
Cc: MTU Discovery <mtudwg>
Message-Id: <89/11/27 2352.364@pescadero.stanford.edu>
In-Reply-To: mogul's message of 27 Nov 1989 1529-PST (Monday)

Jeff writes:

>	This leads me to my second point, which is also a complaint about
>	Steve D's proposal (and indeed, anything based on "report
>	fragmentation").  The problem is that the sender has no way of
>	knowing if it has discovered the path MTU unless and until it
>	receives an ICMP report.  Perhaps the ICMP reports are being
>	dropped on the return path; or perhaps the datagrams aren't large
>	enough to be fragmented yet.

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, because:

	- the need to send "full-size" datagrams never arises, or

	- the MSS is <= the path MTU, or

	- the first-hop MTU is <= the path MTU.

No point in wasting cycles on MTU discovery, if you're not actually
going to incur 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.

>	Either way, the sender's algorithm for deciding when to send the
>	option (or set the RF flag) is going to be complex, ...

The algorithm for setting the RF flag is trivial: set it on every datagram
(assuming it's a "type 1" protocol, able to react to MTU changes).  You'd
send the option with every datagram too, if it weren't so inefficient.

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

>	Meanwhile, the sender might have filled the transmission pipe with
>	mobygrams that are all being fragmented.

Good point.  Slow-start may help in some cases, but if a connection
starts off with a number of short datagrams, it may already be going
full blast by the time it gets around to sending the big guys.
(I suppose a protocol could intentionally go into slow-start when it
transitions to sending "full-size" datagrams.)  Saving the discovered
MTU in the routing cache will certainly alleviate this problem.

Note that this problem arises with both my scheme and RFC-1063, in the
(much less frequent) case where the path MTU shrinks while the protocol
is streaming big datagrams -- it still takes at least one RTT to learn
the new MTU, longer if the MTU options are not included in every datagram.

Assuming reassembly succeeds most of the time, how much do we care about
the overhead of fragmentation and reassembly for one round-trip time?

Steve