On Fri, Apr 27, 2001 at 02:10:48PM -0500, Stephen Sprunk wrote:
Or unless you actually have >1500 MTU to the hosts, which is quite possible. A traffic study from MCI's backbone (obviously years ago) showed nearly 40% (byte-wise) of their traffic was in packets >1500 bytes. With the death of FDDI, this has probably come down, but GE-attached servers in colos should push it back up.
Probably not since GigE defaults to 1500 bytes and there is no agreed upon standard for jumbo frames. Right now it doesn't make much sense to attempt jumbo frames for packets headed outside of your administrative control, because of PMTU-D problems.
Router performance is, however, directly related to packet size, since forwarding overhead is per-packet and not per-byte. It is much easier to fill big pipes with 9000 byte packets than 1500 byte packets.
More importantly it's easier to generate the packets in the first place. The amount of overhead that goes into generating a packet on a host is really quite a bit, and operations on 1500 bytes are exactly the opposite of how most hosts are optimized. At gigabit speeds (125MB/sec) it only takes 12 microseconds to transfer 1500 bytes. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
On Fri, 27 Apr 2001, Richard A. Steenbergen wrote:
On Fri, Apr 27, 2001 at 02:10:48PM -0500, Stephen Sprunk wrote:
Or unless you actually have >1500 MTU to the hosts, which is quite possible. A traffic study from MCI's backbone (obviously years ago) showed nearly 40% (byte-wise) of their traffic was in packets >1500 bytes. With the death of FDDI, this has probably come down, but GE-attached servers in colos should push it back up.
Probably not since GigE defaults to 1500 bytes and there is no agreed upon standard for jumbo frames. Right now it doesn't make much sense to attempt jumbo frames for packets headed outside of your administrative control, because of PMTU-D problems.
Not trying to start flame-wars again but: If we didn't have weirdos using RFC1918 space on WAN links, the PMTU problem wouldn't be such a problem. If you're using anything beyond ethernet on your LAN/WAN, the likelihood is that you already have links with MTUs of 4470, etc. I don't understand why people are treating GigE any different than any other layer2 media capable of MTU larger than 1500. The fact that there is no standard "jumbo" size is moot. You should verify like MTU on the ends of any link. Am I mistaken? Are there folks out there who are setting their ATM OC-3/12/48 links to 1500 MTUs? --- John Fraizer EnterZone, Inc
On Fri, 27 Apr 2001, John Fraizer wrote:
On Fri, 27 Apr 2001, Richard A. Steenbergen wrote:
On Fri, Apr 27, 2001 at 02:10:48PM -0500, Stephen Sprunk wrote:
Or unless you actually have >1500 MTU to the hosts, which is quite possible. A traffic study from MCI's backbone (obviously years ago) showed nearly 40% (byte-wise) of their traffic was in packets >1500 bytes. With the death of FDDI, this has probably come down, but GE-attached servers in colos should push it back up.
Probably not since GigE defaults to 1500 bytes and there is no agreed upon standard for jumbo frames. Right now it doesn't make much sense to attempt jumbo frames for packets headed outside of your administrative control, because of PMTU-D problems.
Not trying to start flame-wars again but: If we didn't have weirdos using RFC1918 space on WAN links, the PMTU problem wouldn't be such a problem.
*groan* not again please... At any rate, there are any number of things which break PMTU-D, for example boneheads who filter all ICMP including needfrag. It can even be more benign, for example networks which rate limit ICMP on their borders thinking they are doing the "right thing". All it takes is one smurf and that rate limit has effectively become a deny all ICMP. Another example is that most routers don't support ICMP type and code filtering granularity, which means if you think you are doing a good thing by filtering or rate limiting ICMP Unreach (does anyone remember the days of ICMP Unreach scans which attempted to reset established connections) you've probably broken PMTU-D as well. If you are pushing jumbo frames out to the internet and relying upon PMTU-D to bring it back down to 1500 for ordinary ethernet users, you are now DOWN for the majority of users who are not optimized. Noone wants to deploy something like that on a wide scale, for packets heading outside of their administrative control...
If you're using anything beyond ethernet on your LAN/WAN, the likelihood is that you already have links with MTUs of 4470, etc. I don't understand why people are treating GigE any different than any other layer2 media capable of MTU larger than 1500. The fact that there is no standard "jumbo" size is moot. You should verify like MTU on the ends of any link. Am I mistaken? Are there folks out there who are setting their ATM OC-3/12/48 links to 1500 MTUs?
The fact that it is not standardized is key, because it is very unlikely to be deployed correctly on both ends (especially across a switched fabric like a NAP) without extra human interaction and equiment which supports the agreed upon minimium... Not even the big router vendors get it right (ex: Cisco GSR 3-port gige linecards), so most people are not going to deploy it outside of their administrative control. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
participants (2)
-
John Fraizer -
Richard A. Steenbergen