IETF Logo Mail Archive

Re: yet another MTU discovery scheme

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

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA26078; Sun, 25 Feb 90 18:09:54 PST
Received: by decwrl.dec.com; id AA01729; Sun, 25 Feb 90 18:09:49 -0800
Received: from [192.33.166.11] by inria.inria.fr (5.61+/89.0.8) via Fnet-EUnet id AA14667; Mon, 26 Feb 90 03:08:41 +0100 (MET)
Received: by gipsi.Gipsi.Fr (4.12/4.8) id AA16950; Mon, 26 Feb 90 03:09:36 -0100 (MET)
Date: Mon, 26 Feb 90 03:09:36 -0100
From: Philippe Prindeville <philipp@Gipsi.Gipsi.Fr>
Message-Id: <9002260209.AA16950@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>

But if the MTU is not returned in the Can't Fragment message, one
must determine the appropriate size (or revert to 576 byte datagrams).
As bandwidth increases (and transmission time approaches zero
relative to propagation delay) we will start to see very large MTUs.
This will combat the ID wrap-around (to some extent).  But, using
576 bytes for the MTU will be intolerable.  Hence, one must discover the
exact (modulo some small N) MTU for efficient link usage.  So I think
a requirement of whatever solution we arrive at must allow such
determination.

Needless to say, I don't except the first-hop MTU or 576 byte
argument proposed by Jeff...

-Philip

v2.8.7 | Report a Bug | By Email