Re: MTU discovery considered harmful?

Drew Daniel Perkins <> Sat, 21 April 1990 01:00 UTC

Received: from by (5.54.5/4.7.34) id AA17651; Fri, 20 Apr 90 18:00:27 PDT
Received: by; id AA09441; Fri, 20 Apr 90 18:00:21 -0700
Received: by (5.54/3.15) id <AA05921> for; Fri, 20 Apr 90 21:00:57 EDT
Received: via switchmail; Fri, 20 Apr 90 21:00:52 -0400 (EDT)
Received: from via qmail ID </afs/>; Fri, 20 Apr 90 20:57:40 -0400 (EDT)
Received: from via qmail ID </afs/>; Fri, 20 Apr 90 20:57:33 -0400 (EDT)
Received: from via; Fri, 20 Apr 90 20:57:28 -0400 (EDT)
Message-Id: <>
Date: Fri, 20 Apr 90 20:57:28 -0400 (EDT)
From: Drew Daniel Perkins <>
To: mtudwg
Subject: Re: MTU discovery considered harmful?
In-Reply-To: <>
References: <> writes:
> Let's look at a not-so-absurd limiting case:  FDDI rings at both
> LANs, and point-to-point links across a regional net.  FDDI
> uses a 4K MTU; serial lines, being HDLC, have more or less arbitrary
> MTUs, and will likely be set to 4K once FDDI becomes common.  Current
> TCPs (at least, many of them) have default window sizes of 4K.
> This means that we've reduced sliding window to send-and-wait.

William "Chops" Westfield <> writes:
> You have some invalid assumptions.  I doubt that anyone will run across
> FDDI with a 4K window.  Experiments are already being done with window
> sizes larger than 64K (window scaling), a necessary extension when you
> want to run nets with a delay bandwidth product greated than 64kbytes
> (this includes T1 satallite links and T3 TERRESTRIAL (!) links, if I
> remember correctly).  HDLC does NOT have arbitrary MTUs - indeed, the
> rest of your message makes more of an argument for using small MTUs on
> serial links (and doing MTU discovery) than for not doing MTU discovery.

HDLC does too have essentially arbitrary MTUs.  In particular, when
used with PPP, the MTU can be negotiated to any value up to 65536.
However, the MTU is likely to be set based approximately on the function:

    ((.2 seconds) * (serial_line_bit_rate bits/second) / (8 bits/byte)))

This function limits the maximum time a single frame can use the wire
to approximately 200 ms in order to guarantee low delay for other
frames (at least ones marked with a low delay TOS).  See Van Jacobson's
TCP/IP header compression RFC for a better and more detailed treatise.
Using this function, I would say that you shouldn't use more than a
1400 byte MTU on a 56kb line (1500 is probably close enough).

Therefore, if you are not using a 4K MTU, you really would like to use
a MTU discovery mechanism so that you don't have to send 576 octet datagrams.

Also, as Bill pointed out, people will probably NOT use 4k windows
with FDDI...

> To grossly oversimplify things, to a (poor) first approximation
> the optimum MTU size is the window size divided by the number of
> hops, or at least the number of ``slow'' (a term I'll leave undefined)
> hops.  That way, each router can be busy sending a packet simultaneously.

I think you are looking at this backwards.  Why are you holding the
window size constant?  Another (I think better) way to look at this is
that the window size should be atleast the number of hops times the
TCP segment size in order to get maximum pipelining out of the system.
The TCP segment size should be based on a relationship of the per
packet cost vs. per octet cost (on a local Ethernet with Sun 3/60s
(3/50s?) I think Van calculated approximately 1100 octets for maximum

> The proposal in the draft RFC gives a good mechanism for calculating
> the PMTU, but yields no information on the hop count.  Informal

If you agreed with my statements above, then I think the TCP slow
start mechanism yields all the remaining information that you need
(a very indirect derivation of the hop count).