Re: What's your favorite MTU?

[Drew Daniel Perkins <[e-mail]>]

Excerpts from mail: 13-Apr-90 Re: What's your favorite MTU? Jeffrey
[e-mail] (2452)

>     Don't 16Mbit TRs support much larger MTUs?

> RFC1042 mentions that 802.5 systems can potentially support these MTUs:
> 	8188, 4092, 2044, 1020, 508
> It isn't clear from the RFC just which of these actually get used.
> I have plateaus at or just below all of these values, except for
> 4092.  Putting one at 4092 would probably cause some problems as
> FDDI becomes ubiquitous; either there would be an extra RTT spent
> getting from an FDDI MTU to an Ethernet MTU, or I would have to
> remove the FDDI plateau (now changed to 4352, in the lastest
> draft RFC) and potentially waste 6% of the FDDI MTU.  If you
> expect that 802.5 networks with MTU=4092 are going to be common,
> then I will have to take that into account.
>     
RFC 1042 mentions that 802.5 source routing BRIDGES support those
numbers; it does NOT say that 802.5 TOKEN RINGS support those sizes. 
Understanding this requires an understanding of IBM source routing. 
Source routing utilizes an IBM (not IEEE) specified field in the packet
called a Routing Information Field (RIF).  The RIF includes a field
called the Largest Frame (LF) field.  It is used to find the maximum MTU
supported along a source routed path (same thing we're trying to do
actually). I guess they didn't want to use two (or more) full octets, so
they encoded it, originally as a 3-bit field.  That encoding is what is
described in RFC 1042.  I'm not certain of this, I would guess that IBM
chose the values based on the formula 2^(9+x) + 4, giving them LLC data
lengths corresponding to powers of two  (512, 1024, 2048, 4096, and
8192; the LLC header is 4 octets).  However, somebody (probably IEEE)
later decided that the length field should be four bits and should
indicate more useful values, where useful means that they correspond to
other 802 networks.  Below is a table containing all the values.  The
ones marked with * are the original IBM codes which are now "reserved".

LF	802	MAC	Info	IP
Code	Network	Length	Length	MTU
----------------------------------------
0000*		552	516	508
0001		 "	 "	 "
0010*		1064	1028	1020
0011	802.3	1536	1500	1492
0100*		2088	2052	2044
0101		 "	 "	 "
0110*		4136	4100	4092
0111	802.5	4508	4472	4464
1000*		8232	8196	8188
1001	~802.4	8227	8191	8183

Now to make the waters muddier...  The lengths above do NOT correspond
to the MTUs of IBM Token Rings.  Theoretically, the maximum packet size
on a token ring is based on the maximum time a node may hold a token. 
This varies with the number of nodes on the ring and the ring speed. 
Worse yet, various token ring implementations have all supported
different maximum packet lengths.  The original TI implementation will
support an IP MTU of up to 4464 octets, which (I think) corresponds to a
ring with the maximum number of nodes.  However, IBM's original token
ring implementation (the IBM PC Token Ring Card)  will only support an
IP MTU of 2002.  Therefore, in RFC 1042 we suggested that all
implementations support ATLEAST 2002.  You CAN support more (like the
full 4464), and I think some people like cisco actually do.  In the
meantime, IBM has made two more changes.  Their latest 4 Mb token ring
interface seems to support an IP MTU of 4408.  The 16 Mb interface
should support up to 17914 (increasing the data rate increases the MTU
with the same token hold time).

In conclusion, for the purposes of this WG, I would suggest that we use
the values 2002, 4408, and 17914 for the token ring MTUs of interest.

Drew