Re: MTU discovery considered harmful?
Steve Deering <deering@pescadero.stanford.edu> Sun, 29 April 1990 01:04 UTC
Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34)
id AA16328; Sat, 28 Apr 90 18:04:40 PDT
Received: by decwrl.dec.com; id AA09722; Sat, 28 Apr 90 18:04:37 -0700
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA05073;
Sat, 28 Apr 90 18:04:06 PDT
Date: 28 Apr 1990 15:59-PDT
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: Re: MTU discovery considered harmful?
To: Drew Daniel Perkins <ddp+@andrew.cmu.edu>
Cc: mtudwg
Message-Id: <90/04/28 1559.523@pescadero.stanford.edu>
In-Reply-To: Drew Daniel Perkins's message of Fri, 20 Apr 90 205728 -0400 (EDT)
> 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
- MTU discovery considered harmful? smb
- Re: MTU discovery considered harmful? William Chops Westfield
- Re: MTU discovery considered harmful? Drew Daniel Perkins
- Re: MTU discovery considered harmful? Philippe Prindeville
- Re: MTU discovery considered harmful? Steve Deering
- Re: MTU discovery considered harmful? Drew Daniel Perkins