Re: MTU discovery considered harmful?

[Steve Deering <[e-mail]>]

> However, the MTU is likely to be set based approximately on the function:
>
> min(max(all_interface_MTUs),
>    ((.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.

This reminded me of some concerns I had about Jeff's MTU plateau scheme
and serial line MTUs.  But first, in case someone is plannning to publish
a list of recommended MTUs for various speed serial lines (which I
think would be good idea), I'd like to suggest that a more precise formula
for the MTU of a line using Van's header compression scheme would be
the following:  (This replaces the second line of Drew's formula above.)

	max(68, (.2 * bps / bpo) + 33)

where	68 is the minimum legal MTU,
	bps is the line speed in bits/sec,
	bpo is "bits per octet", which is 8 for synchronous lines
		and 10 for asynch lines with one stop bit, and
	33 accounts for a 40-byte IP/TCP header being compressed down
		to 3 bytes, and the addition of 4 bytes of PPP framing.

For example, at 2400 bps asynch, this gives an MTU of 81.  An IP/TCP
datagram of that size will compress down to 44 octets; with 4 octets
of framing, it will result in 48 octets or 480 bits on the wire, which
is the desired 200 ms.

For lines that are not using header compression, omit the "+ 33", to get
the same formula as Drew suggested.

Now, one question is, how close should the MTU be to the value generated
by these formulas?  Here is a table of MTUs computed by these formulas
for various standard line speeds:

	  asynchronous, 1 stop bit		synchronous
        ----------------------------     ---------------------------
bps	compress ON    compress OFF      compress ON    compress OFF
-----   -----------    ------------      -----------    ------------
 1200		 68		 68		  68		  68
 2400		 81		 68		  93		  68
 4800		129		 96		 153		 120
 9600		225		192		 273		 240
19200		417		384		 513		 480
38400		801		768		 993		 960
56000		n/a		n/a		1433		1400
64000		n/a		n/a		1633		1600

If people configure their serial lines according to these formulas,
and hosts start using Jeff's list of plateaus, and the routers
attached to the serial lines are not upgraded to provide the Next-Hop
MTU field in Datagram Too Big messages, then our MTU discovery scheme
is not going to work as well as we would like.  For example, there are
currently no plateaus between 296 and 68, which means it'll end up using
68 as the PMTU for any path that includes a serial line of 9600 bps or
slower.  Similarly, the plateau of 1492 is just a little too high for
the computed MTU for 56Kb lines.

A few (perhaps obvious) points:

	- We can adjust Jeff's plateaus and maybe add some new ones to
	  take these numbers into account (although Jeff's scheme degrades
	  as more plateaus are added).

	- We could lobby the point-to-point people to restrict their
	  choice of MTUs to a more limited set of choices, matching
	  our plateaus wherever possible.  For example, as Drew said
	  in his message, using an MTU of 1500 for a 56Kb line is
	  "probably close enough".  Anyone care to quantify how close
	  is close enough, especially for the lower bit rates?  I guess
	  the point here is, if people are allowed to chose arbitrary MTUs
	  for their serial lines, then they might chose values that are
	  just slightly below the MTU plateaus, which is pessimal for
	  Jeff's MTU discovery scheme.

	- Perhaps this is a non-issue, because any router sophisticated
	  enough to use any MTU other than 1006 or 1500 for a serial
	  line is likely to support the Next-Hop MTU field in the
	  Datagram Too Big message within a very short period of time?

Maybe this is something we should discuss with the PPP people.  Are
they planning to publish a table like the one above, but with fewer
discrete choices of MTU?  (As I said, I think that would be a good
thing for them to do.)

Steve