robelr@mythos.ucs.indiana.edu (Allen Robel) (05/08/91)
Oh, I get it now. It refers to the smallest MTU along
a path to a network. So, if you had:
ethernet FDDI T1
----------{}---------{}-----------
then the minimum MTU would be 1.544Mbs. It
just looked kinda funny at first glance...
-arjerry@olivey.ATC.Olivetti.Com (Jerry Aguirre) (05/08/91)
>From: Allen Robel <robelr@mythos.ucs.indiana.edu> >Oh, I get it now. It refers to the smallest MTU along >a path to a network. So, if you had: > >ethernet FDDI T1 >----------{}---------{}----------- > >then the minimum MTU would be 1.544Mbs. It >just looked kinda funny at first glance... Sort of except that MTU is the Maximum Transfer Unit, not the bandwidth. The MTU in your example would probably be limited by the ethernet to a 1500 byte packet. Even though the FDDI or the T1 might be able to handle larger packets that is the largest that one can send without having to worry about fragmentation. There is also a "minimum bandwidth" which would be the 1.544 Megabits/s that you mention. The T1 line being the slowest and thus establishing the minimum. Jerry Aguirre
robelr@mythos.ucs.indiana.edu (Allen Robel) (05/08/91)
>Sort of except that MTU is the Maximum Transfer Unit, not the >bandwidth. >No, the minimum data rate in the above picture is 1.544Mbs. The >minimum MTU in the above picture would be 1500 bytes. Yeah, one of those things that hits you right after you send it. Don't know why I thought bandwidth. The T1 MTU though, in most instances, would be 576 octets if you're connected to a regional network->NSFNet being that this is the Internet default... -ar
dana@thinman.cray.com (Dana Dawson) (05/08/91)
> Sort of except that MTU is the Maximum Transfer Unit, not the bandwidth. > The MTU in your example would probably be limited by the ethernet to a > 1500 byte packet. Even though the FDDI or the T1 might be able to > handle larger packets that is the largest that one can send without > having to worry about fragmentation. > > There is also a "minimum bandwidth" which would be the 1.544 > Megabits/s that you mention. The T1 line being the slowest and thus > establishing the minimum. Some (many?) IP implementations compare the source and destination IP addresses and use the interface MTU for "local" destinations (source and destination addresses have matching network parts), and 576 for non-local destinations because that is the smallest "required" MTU (see RFC 1122, "Requirements for Internet Hosts -- Communication Layers", page 56). This way, in theory, you "know" that no gateway along the way will have to fragment your datagrams. Do ciscos do a similar thing? Dana Dawson Cray Research, Inc.
forster@cisco.com (Jim Forster) (05/08/91)
>> Some (many?) IP implementations compare the source and destination IP >> addresses and use the interface MTU for "local" destinations (source and >> destination addresses have matching network parts), and 576 for non-local >> destinations because that is the smallest "required" MTU (see RFC 1122, >> "Requirements for Internet Hosts -- Communication Layers", page 56). >> This way, in theory, you "know" that no gateway along the way will have >> to fragment your datagrams. Do ciscos do a similar thing? What've you've described used to be a semi-reasonable approach for a host to take when deciding what size IP datagrams to send. A router don't have any choice; it takes what the hosts send, and fragments if it must. Note that in theory even packets destined for a different subnet should be subject to the 576 rule, but in practice these days, serial lines support the same size MTU as Ethernets. Everything is different and harder when you move from just Ethernets & Serial lines to Token Rings & FDDI. Both TR's and FDDI have substantially larger MTU's, and hosts would justifiably like to take advantage of this if possible, but not cause fragmentation if an Ethernet must be used. Thus the relevance of: RFC-1191 Mogul, J.C.; Deering, S.E. Path MTU discovery. 1990 November; 19 p. (Format: TXT=47936 bytes) (Obsoletes RFC 1063) which we will support in 8.3. -- Jim PS: I vaguely recall some BSD Unix flag "subnetsarelocal" which may be relevant. Does some know about this?
kre@munnari.oz.au (Robert Elz) (05/08/91)
Date: Tue, 7 May 91 17:47:30 CDT
From: dana@thinman.cray.com (Dana Dawson)
Message-ID: <9105072247.AA00263@thinman.cray.com>
and 576 for non-local destinations because that is the
smallest "required" MTU
This is simply not true, and is a myth that deserves to
be obliterated.
576 is the size of an IP datagram that all hosts must be
able to receive, ie: its one that you know that you can
send to any other host without it being rejected because of
being too big.
The smallest required MTU is 80 octets (ie: you can fragment
anything, as long as fragments are at least 80, except
possibly the last - this allows space for maximal headers,
and at least some data, in each fragment).
Choosing 576 as the size to send (its often 512 data,
plus headers, in reality, ie: typically 556 for tcp)
is simply a matter of observation, few nets have an MTU
smaller than 576, so fragmentation isn't likely to be needed.
But there is no guarantee.
kretcs@uunet.UU.NET (Terry Slattery) (05/09/91)
The MTU of 576 whas chosen because it is the largest datagram which can be transported over the old Arpanet/Milnet PSNs (packet switching node, aka IMP) as a single unit. When the internet was dying due to congestion in the mid-to-late 80's, dropping the MTU to this value for foreign networks ment that your data had a *much* greater chance of making it across the internet and avoided adding to the congestion if it didn't. If you used larger packets, they would be fragmented by the gateway (called routers these days) which connected to the internet PSN. If the source was on an ethernet and the destination was across the internet, the gateway would create three fragments. The PSNs could drop any one of the three, and often did when congestion was high. The chances of one of your fragments not making it across the internet was reasonably high, which in turn caused the entire packet to be retransmitted (as required by IP). This added to the already high congestion. Using 576 byte packets avoided fragmentation and therefore prevented the retransmission of data which had successfully made it to the destination. The BSD "subnetsarelocal" hack was from the recognition that subnets must be contiguous, therefore the internet could not be used to tie two subnets of the same network together. Since the data didn't have to traverse the internet, the MTU of the outgoing interface could be used if the source and destination networks were the same (ignoring subnetting information.) This reduces the packet processing overhead on the hosts and makes more efficient utilization of the network. -tcs
art@opal.acc.com (Art Berggreen) (05/09/91)
Let's try to quash a little misinformation here... In article <34877@boulder.Colorado.EDU> ccci!tcs@uunet.UU.NET (Terry Slattery) writes: >The MTU of 576 whas chosen because it is the largest datagram which can be >transported over the old Arpanet/Milnet PSNs (packet switching node, aka >IMP) as a single unit. When the internet was dying due to congestion in the Sorry, but the PSNs could handle up to 1007 (usually rounded down to 1006) bytes in a message. This still was not optimal for fragmenting Ethernet sized packets. >The chances of one of your fragments >not making it across the internet was reasonably high, which in turn caused >the entire packet to be retransmitted (as required by IP). This added to >the already high congestion. This unfortuneatly was painfully true for a time. >Using 576 byte packets avoided fragmentation and therefore prevented the >retransmission of data which had successfully made it to the destination. This happens to be true because of the PSNs larger MTU. The "magic" 576 is not the minimum sized packet an IP net has to be able to carry (which is 68, 60 bytes max IP header + 8 bytes data). The 576 is the minimum sized TCP SEGMENT which the underlying IP has to be able to REASSEMBLE without TCP negotiation. This was intended to allow for 64 byte of header and 512 bytes of TCP data (amazingly, the same as typical disk blocks of the time). 576 bytes is then just a "good guess" in lieu of any other information (like the new Path MTU Discovery RFC). >The BSD "subnetsarelocal" hack was from the recognition that subnets must be >contiguous, therefore the internet could not be used to tie two subnets of >the same network together. Rather that subnets were usually local collections of ethernets and since most traffic was local to this environment, it was desireable to use the largest usable MTU. Again, there is no architectural reason for subnets to be contiguous, only that available routing protocols lacked the ability to describe the topological information (i.e. RIP and EGP). One of OSPF's advantages will be the ability to have noncontiguous subnets. > -tcs Art
mikes@zephyr.ENS.TEK.COM (Mike Skrydlak -- Tektronix Network Services) (05/09/91)
I'm not sure if Allen is joking. Anyway, I believe his email included some 'IGRP derived' info. Part of the info seems to include the largest size packet you probably could send via this route without fragmentation by an intermediate router/gateway/hop. This might prove helpful in investigating performance problems possibly due to fragmentation. I seem to remember such a discussion about 4-5 years ago somewhere on the net. Please excuse me if I'm off base here, but I think that's the basis for calculating & providing 'min MTU' info in a route cache.
assg7@fel.tno.nl (Rene van den Assem) (05/13/91)
kre@munnari.oz.au (Robert Elz) writes: >This is simply not true, and is a myth that deserves to >be obliterated. >576 is the size of an IP datagram that all hosts must be >able to receive, ie: its one that you know that you can >send to any other host without it being rejected because of >being too big. >The smallest required MTU is 80 octets (ie: you can fragment >anything, as long as fragments are at least 80, except >possibly the last - this allows space for maximal headers, >and at least some data, in each fragment). >Choosing 576 as the size to send (its often 512 data, >plus headers, in reality, ie: typically 556 for tcp) >is simply a matter of observation, few nets have an MTU >smaller than 576, so fragmentation isn't likely to be needed. >But there is no guarantee. Yes, you're right. I've run into problems on this with a popular PC TCP/IP implementation that claims to support fragmentation. It actually allows only for two fragments and assumes that by setting the TCP MSS to 536(?), it will avoid fragmentation. Alas, this doesn't work for me. Rene van den Assem, TNO Physics and Electonics Lab The Netherlands assem@fel.tno.nl