Re: RF flag

[Steve Deering <[e-mail]>]

>	...the general feeling was that MTU discovery probably wasn't it.
>	So, that one's out...

The second phrase does not follow from the first.  I would interpret
the first phrase as an invitation to convince the IESG that MTU
discovery *is* what the bit should be used for.  Or was the decision
really, "It *shall* not be used for that purpose," and you were just
trying to be gentle?

>	(although you could still have such a bit, albeit in an option
>	which you insert every so often).

That's greatly inferior, as you know.  If the header bit is unavailable,
I'd be interested in exploring some of the approaches that Rich Fox
has suggested.  That is, let the transport protocol inform its peer
that it is willing to receive fragmentation reports.  The way of
asking for reports may in fact be an IP option inserted by the
transport protocol at connection-setup time (for connection or session
oriented protocols, at least), and the way of informing the sender that
fragmentation occurred may in fact be an ICMP message sent by the
transport protocol.  IP-layer MTU caching could still be used to
share discovered MTU info between multiple transport connections, and
to reduce the frequency of sending first-hop-MTU-size datagrams to
probe for MTU increases.  It would require minimal additional host
state (one extra bit in the state already maintained for each
connection/session/association/whatever), and, like the RF header
bit scheme, would detect an MTU decrease in the shortest possible time
(one RTT).

Steve