Why An MTU Of !500 For Ethernet Networks

I was wondering if anyone knew why an MTU = 1500 was selected for Ethernet Networks? Yes, I did Google it, but did not find any satisfactory answers.

I've read how to modify MTU values in the Windows Registry. Is this the only place to modify it or is there any other place we can change it? But I heard that even if you modify MTU's to higher than 1500, ISP's would size it down to 1500 during transmission. Why would ISP's do that?

To my understanding, it was defined as the maximum allowed for IEEE 802.3 because it seemed a reasonable value at the time (we' re speaking for 10mbps ethernet links back in the '80). In later implementations it was retained for compatibility reasons. Some say that they should have raised that limit in fast ethernet (802.3u) -and it would be better in purelly terms of performance-, I think that would propably enforce every ISP to upgrade their hardware as soon as possible, to avoid possible complications, which could have a bad influence in the final price of the Internet Services.

In practice, the overhead is somewhat acceptable in fast ethernet but becomes potentially a serious waste in gigabit ethernet, especially in high quality connections with low loss ratio. So I assume that in direct links between backbone routers they propably do use larger MTU via "jumbo-frames" (a gigabit ethernet feature).

The thing is that there are still many old ethernet routers arround, (some even configured to accept and transmit with 576 bytes max frame size, to imagine!) and transmitting frames with larger than 1500 bytes size blindly to the internet would break the interoperability amongst them and the fast ones, with lots and lots of consequent problems.

Also using frame size larger than 1500 wouldn't necessarily yield better performance in a wan such as the internet, since there is a high average loss-retransmission ratio -higher the more the inbetween routers are-. Imagine that you would be saving a percentage of effective data transfer rate by stuffing more usefull stuff in a packet, but from a point after you would be losing much more from having to retransmit those big packets in case they get lost or corrupt on their way (too roughly, you would gain in performance in connections with nodes close to you but lose in conections away from you, so there's a trade off). Also, certain networking applications such as VoIP by their nature, perform better (more responsive) in connections where a low frame size is used.

So anyway, for now we are stuck to 1500 max which cause acceptable enough overhead for end-user connections and guarantee safe passage everywhere.

Chris will know better for sure and can correct me where I'm wrong.

ThankYou nske for your explanation. Feel free to correct me where ever I am wrong.

MTU is limited to 1500 mainly because Data in the 802.3_Ethernet Frame at the Data Link Layer can only accept a Minimum of 46Bytes and a Maximum of 1500Bytes. So, it is mainly due to old technology still being in existence at Layer-2.

Now, I understand why Packet Fragmentation occurs at Layer-3 if the Data handed to IP from TCP is greater than 1500 Bytes.

Also, If I may, I used a Ping command with a Buffer Size = 66000.
I get a reply saying Bad Value for Buffer Size, Valid Range is from 0 to 65500. I was puzzled, when I saw the reply. Why? Because IP fragments into multiple packets if Data > 1500 bytes. Why, then I get the above error message?

Thankyou In Advance.

FallenZer0,

yes, you've got this right.

About your last question, it is as you said, packet will be fragmented to travell through the ethernet since it's larger than the MTU, but IPv4 has also a maximum limit for packet size and that's 65535 bits. Subtract the IP and ICMP echo headers and you'll get 65507, wich is the maximum valid packet size for ping. So your ping program simply prohibits you from crafting an illegal IP packet.


ps. btw I thing that microsoft's dos ping had a wrong limit that allowed to send oversized packets.

Thankyou nske,

I would like to expand this topic of Buffer Size to one more protocol, FTP. I've read that FTP protocol operates at Application/Process Layer and facilitates users to transfer files in both directions once the users credentials are authenticated.

I've read that in IPv4, the Total Length field is 16 bits, so 2 ^ 16 is 65536.

Let's say I wish to download a 100kb file. On the FTP Server side, IP receives the datagram from TCP, and Fragments into Multiple Packets, goes to Layer-2, Layer-1 and the bits get transmitted to my PC.

During the re-assembly of all the fragments on my PC, and if IP is limited to 65536Bytes, which is 64kb, I would assume, file transfer should fail. Why doesn't it happen? Why is it IP could re-assemble a 100kb file, but the same IP fails me if I use a buffer size greater than 65500. I hope I made sense.

TCP as the underlying transport protocol for FTP, will make it's own segmenting and reassembling for you