re: some further musings

Philippe Prindeville <philipp@gipsi.gipsi.fr> Wed, 06 December 1989 16:40 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA02997; Wed, 6 Dec 89 08:40:35 PST
Received: by decwrl.dec.com; id AA22119; Wed, 6 Dec 89 08:40:25 -0800
Received: by mcsun.EU.net with SMTP; Wed, 6 Dec 89 17:39:36 +0100 (MET)
Received: from gipsi.gipsi.fr by inria.inria.fr (5.61+/89.0.8) via Fnet-EUnet id AA21418; Wed, 6 Dec 89 14:27:48 +0100 (MET)
Received: by gipsi.gipsi.fr; Wed, 6 Dec 89 14:28:16 -0100 (MET)
Date: Wed, 6 Dec 89 14:28:16 -0100
From: Philippe Prindeville <philipp@gipsi.gipsi.fr>
Message-Id: <8912061328.AA00390@gipsi.gipsi.fr>
Phone: +33 1 30 60 75 25 / +33 1 47 34 42 74
To: MTU Discovery <mtudwg>
Subject: re: some further musings

	What would folks think about combining these two schemes.  That is
	defining both IP options: 1063's for infrequent but periodic usage
	for determining MTU increases; and the report-N-fragmentations for
	setting-up triggers for the immedaite discovery of MTU decreases.

What do I think?  I think any sort of connection state should be
maintained by the connection end-points.  Thus, requiring routers
to maintain counters on associative flows is not reasonable.
Routers will have to switch packets faster and faster in the
future (though arguably, larger packets will need to be switched
less often than smaller ones), and this can only really be done
if there is no state associated with each packet.  Any proposal
the builds state into IP receives my dead opposition.

-Philip