Re: How to use an IP-header bit for Path MTU discovery.

Steve Deering <deering@pescadero.stanford.edu> Sun, 25 February 1990 07:14 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA21517; Sat, 24 Feb 90 23:14:01 PST
Received: by decwrl.dec.com; id AA23293; Sat, 24 Feb 90 23:13:58 -0800
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA13646; Sat, 24 Feb 90 23:13:55 PDT
Date: 24 Feb 1990 22:59-PST
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: Re: How to use an IP-header bit for Path MTU discovery.
To: mogul (Jeffrey Mogul)
Cc: mtudwg
Message-Id: <90/02/24 2259.227@pescadero.stanford.edu>
In-Reply-To: mogul's message of 19 Feb 1990 1324-PST (Monday)

In response to John Wobus's clever new proposal, Jeff says:

>	Basically, if one is forced to think of how many rational
>	possibilities there are for the sender's segment size, one
>	can easily come up with 2: "576" and the first-hop-net MTU.
>	Coming up with a third choice is only necessary if we believe
>	that it is too far from optimal to be stuck with these two
>	choices.

Another scenario that *may* become important is FDDI-backbone-FDDI,
where the backbone has a 1500 byte MTU.  You'd rather not end up using
576 bytes as the path-MTU.

Also, the 576 rule still incurs fragmentation on those subnets whose MTU
is less than 576.  If the goal is to eliminate *all* fragmentation,
the simple "two-sizes" rule won't do it (unless you mandate intra-subnet
fragmentation and reassembly for subnets with MTU less than 576).

Steve