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

[mogul (Jeffrey Mogul)]

    This may sound a little heretical, but perhaps we are considering
    fragmentation "Not Harmful Enough"?  Maybe fragmentation really
    should be looked upon as something quite severe and that *any*
    fragmentation should be reported via an ICMP message back to the
    source.  This way, no options or header bits are used.  We would
    have to allocate a new ICMP message type, though: reason being it
    must be something that hosts not yet equiped with this MTU discovery
    code can safely ignore (albiet at the cost of much degraded
    performance -- if the performance is bad enough, perhaps the users
    will bang on the management to upgrade to a more reasonable release).
    Anyway, just using Fragmentation Required But Not Permitted (or
    whatever, I don't have 791 handy) with a different Code would not
    be adequate.

Chris and I examined a variant of this suggestion (inspired by Charles Lynn)
in our paper.  The problem is that if the receiver (of the fragments)
sends ICMPs to a sender that is not going to pay attention to them,
not only will this cause even more congestion but it will happen
repeatedly (because the sender will persist in its behaviour).

One could imagine some sort of throttle (only send a "Fragment Received"
ICMP once per minute or something like that) but even in this case,
I think it's a bad idea for the receiver to send totally unsolicited
reports.  There may be a few situations where fragmentation is in fact
the correct strategy; my intuition is that these cases involve at least
one low-bandwidth path (or else why would its MTU be so small) and asking
that path to carry superfluous unsolicited traffic is a mistake.

-Jeff