Re: some further musings

Philippe Prindeville <> Tue, 05 December 1989 17:15 UTC

Received: from by (5.54.5/4.7.34) id AA20846; Tue, 5 Dec 89 09:15:23 PST
Received: by; id AA25219; Tue, 5 Dec 89 09:15:15 -0800
Received: from by (5.61+/89.0.8) via Fnet-EUnet id AA29560; Tue, 5 Dec 89 18:14:23 +0100 (MET)
Received: by; Tue, 5 Dec 89 18:14:53 -0100 (MET)
Date: Tue, 5 Dec 89 18:14:53 -0100
From: Philippe Prindeville <>
Message-Id: <>
Phone: +33 1 30 60 75 25 / +33 1 47 34 42 74
Subject: Re: some further musings
Cc: MTU Discovery <mtudwg>

	up.  Conforming hosts today shouldn't be sending packets that need
	fragmentation as long as every hop accepts 576 or larger.  This implies
	that most jumbograms are from hosts that are trying to do MTU
	discovery, in which case they'd understand the ICMP message.  A

Except for SUNs with RPC and NFS (but that's hardly any ;-).

	comparatively small cache could be kept of source-destination pairs
	that had been sent such messages recently.  Since this cache is soft
	state, it doesn't matter too much if it's lost on a reboot, unless the

Ah, the dirty word: state.  I don't like building this into IP.

	We could further embellish this scheme by using the cache when routes
	change.  If the new route to a destination lowers the MTU, flush the
	cache for that destination -- you want to send new options.  If it
	raises the MTU, flag the cache entries; when any packet flows through
	for a source-destination pair that's in the cache -- and hence for
	which the sencder has previously been advised of the proper MTU -- send
	it a new report to raise the MTU.  This last may be overkill, of

It seems to me that routers are starting to pick up a lot of
complex associations here (read: excess baggage).  I don't like

It seems to me that a lot of this "when to" and "when not to"
and "what if he won't cooperate" questions (regarding throttle
control of Report Fragmentation) messages must have been faced
by the Source Quench designers.  Perhaps we can draw on their