fragmentation ICMP error

art@sage.acc.com Wed, 29 November 1989 00:54 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA15449; Tue, 28 Nov 89 16:54:13 PST
Received: by decwrl.dec.com; id AA04512; Tue, 28 Nov 89 16:54:07 -0800
Message-Id: <8911290054.AA04512@decwrl.dec.com>
Date: Tue, 28 Nov 1989 16:49:00 -0800
From: art@sage.acc.com
Subject: fragmentation ICMP error
To: mtudwg <mtudwg>

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

This has been proposed before.  The main problem is that as long as most
hosts don't understand this new error, all we are doing is causing more
traffic ( and unproductive traffic as well).

Also, if the IP layer is caching MTU information for use by any transport
protocol, it is preferable to learn the MTU of the path before someone
needs it and sends a packet which must get fragmented.


+-----------------------------------------------------------------------+
|	Art Berggreen		Advanced Computer Communications	|
|	<art@sage.acc.com>	Santa Barbara Street			|
|	(805)963-9431		Santa Barbara, CA 93101			|
+-----------------------------------------------------------------------+