Re: decreases in MTU

Philippe Prindeville <philipp@Gipsi.Gipsi.Fr> Tue, 06 March 1990 00:02 UTC

Received: from by (5.54.5/4.7.34) id AA17453; Mon, 5 Mar 90 16:02:20 PST
Received: by; id AA23213; Mon, 5 Mar 90 15:54:12 -0800
Received: from [] by (5.61+/89.0.8) via Fnet-EUnet id AA10499; Tue, 6 Mar 90 00:51:26 +0100 (MET)
Received: by Gipsi.Gipsi.Fr (4.12/4.8) id AA17250; Tue, 6 Mar 90 00:52:38 -0100 (MET)
Date: Tue, 6 Mar 90 00:52:38 -0100
From: Philippe Prindeville <philipp@Gipsi.Gipsi.Fr>
Message-Id: <9003052352.AA17250@Gipsi.Gipsi.Fr>
X-Phone: +33 1 30 60 75 25 / +33 1 47 34 42 74
Subject: Re: decreases in MTU
Cc: MTU Discovery <mtudwg>

	It would be just as easy to mandate that *all* gateways employ the new
	type of Can't Fragment message.  However, mandating does not make it so.

Sorry, instead of "easy" I should have said "realistic".

	Van's new RFC on TCP header compression recommends small MTUs for low
	speed (i.e., 19,200 bps and lower) links, to give reasonable interactive
	responsiveness.  The DARPA PR (packet radio) net has a sub-576 MTU -- is
	it still in use in the Internet?  What's the MTU for IP on AppleTalk?

I don't mean to sound snotty -- but are these "real" (or substantial)
networks?  I don't consider ARCnet substantive, for example: it is
suitable for running netware on your PC (again, neither of which is
substantive).  Yes, IP is powerful because it runs on anything save
two tin cans and a piece of string.  But if all you have is two
tin cans and a piece of string, maybe there is a more appropriate
protocol.  What I'm trying to say, and perhaps not succeeding, is
that one has to draw the line somewhere or everything becomes dragged
down to the lowest common denominator and lost in endless compromise.

For Van's needs, for example, 19.2k is obviously inadequate (it is
for me as well) -- he is just wasting time trying to make the lack
of a vital resource a little more bearable.  The solution is
obvious, though:  more bandwidth.


P.S.	I just know I'm going to be flamed.  Sigh.