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

mogul (Jeffrey Mogul) Mon, 27 November 1989 23:29 UTC

Received: by (5.54.5/4.7.34) id AA08318; Mon, 27 Nov 89 15:29:31 PST
From: mogul (Jeffrey Mogul)
Message-Id: <>
Date: 27 Nov 1989 1529-PST (Monday)
Cc: MTU Discovery <mtudwg>
Subject: SMB's proposal: using an IP option for "Report Fragmentation" flag
In-Reply-To: Msg from dated Thu, 23 Nov 89 09:57:43 EST. <>

Steve B's proposal (introduce a new "flag" IP Option that means "Report
Fragmentation") has several nice advantages.  First, it doesn't appear
to require any changes to existing gateway implementations (which are
all required to pass along unknown options, subject to the usual
orthogonal rules about copying on fragmentation).  Second, it doesn't
intrude on any "architecture resource" scarcities (i.e., bits in the IP

Although this may turn out to be the best compromise, there are a few
problems here.  First, as has been noted, option processing is a pain
for gateways.  Even though this option would not actually require
action on the part of the gateway, the gateway would still have to
parse the options list.  True, this option would not be sent on every
packet, but it would be sent far more often than the RFC1063 option.

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.  Either
way, the sender's algorithm for deciding when to send the option
(or set the RF flag) is going to be complex, 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.  Meanwhile, the sender might have filled
the transmission pipe with mobygrams that are all being fragmented.

I think (powers that be permitting) the use of a "no-cost-to-routers"
RF flag in the IP header, which can be set on all the datagrams sent by
a host, is more efficient than the occasional sending of an option.  We
would still have to worry a bit about what a "naive" host/router would
do when it receives packets with this bit set.

The RFC1063 option, while it has its drawbacks, does manage to discover
the MTU as early as possible during the lifetime of a connection; since
many connections (e.g., SMTP) are short, this could be a plus.