Re: decreases in MTU

Steve Deering <deering@pescadero.stanford.edu> Sun, 04 March 1990 23:27 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA10474; Sun, 4 Mar 90 15:27:29 PST
Received: by decwrl.dec.com; id AA08499; Sun, 4 Mar 90 15:27:25 -0800
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA15535; Sun, 4 Mar 90 15:27:14 PDT
Date: 4 Mar 1990 14:54-PST
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: Re: decreases in MTU
To: sytek!rfox@sun.com (Rich Fox)
Cc: mtudwg
Message-Id: <90/03/04 1454.939@pescadero.stanford.edu>
In-Reply-To: sytek!rfox's message of Sat, 3 Mar 90 132645 PST

>	In your new scheme how is the descrease/increase of the MTU handled?
>	It seems that this is a potential problem.

Rich,

A sender detects a decrease of MTU whenever it tries to send a packet
larger than the new MTU with the DF bit set.  Such a packet triggers
a Can't Fragment message that tells the sender what the new MTU is.

Reception of an old-style Can't Fragment message that does not contain
a recommended MTU value causes the receiver to stop setting the DF bit
and to assume an MTU of 576; if the real MTU is less than 576, or if it
subsequently changes to a value less than 576, that will not be discovered
by the sender and fragmentation may occur.

A sender detects an increase of MTU by periodically restarting the
discovery process, i.e., by assuming that the MTU is MIN(first-hop-MTU,MSS)
and setting the DF bit on all packets.

Does that answer your question, or have I misunderstood?

Steve