Re: routing protocols will provide path-MTU

Steve Deering <deering@pescadero.stanford.edu> Tue, 27 February 1990 21:00 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA08792; Tue, 27 Feb 90 13:00:35 PST
Received: by decwrl.dec.com; id AA22581; Tue, 27 Feb 90 13:00:27 -0800
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA26630; Tue, 27 Feb 90 12:59:27 PDT
Date: 27 Feb 1990 12:19-PST
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: Re: routing protocols will provide path-MTU
To: jnc@PTT.LCS.MIT.EDU (Noel Chiappa)
Cc: mtudwg
Message-Id: <90/02/27 1219.452@pescadero.stanford.edu>
In-Reply-To: jnc's message of Tue, 27 Feb 90 114556 EST

Thanks, Noel.  Your message confirms my suspicion that different people
are thinking of different things when they say, "Within a few years,
the routing protocols will be providing MTU information."

I think a lot of people have the idea that Craig and Jeff mentioned,
that current-generation routing protocols will be enhanced to slosh
MTU information around, along with the other metrics that they
currently exchange.  I wanted to kill that notion, because of its
scaling problems.

Then there is the grand vision that you outlined.  I'd put that in the
same category as, "In a few years, everything will be carried in ATM
cells which will provide internal fragmentation and reassembly of IP
packets; therefore, we won't have to do MTU discovery."  In other words,
it is a long ways off and far from certain.  It should not discourage
us from coming up with a good MTU discovery protocol with a long
projected lifetime.

(That's not to say that we should take a long time doing it!  I do feel
some guilt for bringing up alternate proposals at this late date, but I
don't think I'm taking us "around in circles".  Rather, I believe I am
exploring a part of the solution space that we haven't examined thoroughly
before.  Think of it as "spiralling-in".)

Steve