Re: yet another MTU discovery scheme

Philippe Prindeville <philipp@Gipsi.Gipsi.Fr> Mon, 26 February 1990 02:18 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA26104; Sun, 25 Feb 90 18:18:21 PST
Received: by decwrl.dec.com; id AA02507; Sun, 25 Feb 90 18:18:14 -0800
Received: from [192.33.166.11] by inria.inria.fr (5.61+/89.0.8) via Fnet-EUnet id AA15777; Mon, 26 Feb 90 03:17:27 +0100 (MET)
Received: by gipsi.Gipsi.Fr (4.12/4.8) id AA16976; Mon, 26 Feb 90 03:18:27 -0100 (MET)
Date: Mon, 26 Feb 90 03:18:27 -0100
From: Philippe Prindeville <philipp@Gipsi.Gipsi.Fr>
Message-Id: <9002260218.AA16976@gipsi.Gipsi.Fr>
X-Phone: +33 1 30 60 75 25 / +33 1 47 34 42 74
To: deering@pescadero.stanford.edu
Subject: Re: yet another MTU discovery scheme
Cc: MTU Discovery <mtudwg>

Sorry, I jumped into the middle of my reply in the last message:  If
I understand your scheme (or one of them, anyway ;-) the host sends
Jumbo Don't Fragment messages to provoke a Can't Fragment message.
Assuming this is to be used with existing router software, there is
no indication of the maximum MTU of the link, so a host must determine
it by probes of different sizes, converging on the maximum MTU of
the "weakest" link.

And as I said in the last message, I feel it is necessary to find
(to a reasonable accuracy) the maximum usable MTU, not first-hop
or 576...

-Philip