Re: Jumbo Frames (was Re: MAE-EAST Moving? from Tysons corner to reston VA. )
On Mon, 19 June 2000, "Bora Akyol" wrote:
As long as most end users are running Ethernet, Fast Ethernet, DSL or Cable Modems, what is the point of jumbo frames/packets other than transferring BGP tables really fast. Did any one look into how many packets are moved through an OC-48 in 1 seconds. (approx. 6 million 40 byte packets). I think even without jumbo frames, this bandwidth will saturate most CPUs.
Jumbo frames are pointless until most of the Internet end users switch to a jumbo frame based media.
Yes, they look cool on the feature list (we support it as well). Yes they are marginally more efficient than 1500 byte MTUs ( 40/1500 vs 40/9000). But in reality, 99% or more of the traffic out there is less than 1500 bytes. In terms of packet counts, last time I looked at one, 50% of the packets were around 40 byte packets (ACKs) with another 40% or so at approx 576 bytes or so.
What is the big, clear advantage of supporting jumbo frames?
When 1500 byte frames from the customer's LAN enter the customer's router and enter some form of IP tunnel, then a core fabric which supports larger than 1500 byte frames will not cause fragmentation. It's not necessary to do the full jumbo size frames. I suspect that supporting two levels of encapsulation will be enough in 99.9% of the cases. For the sake of argument, what would be the downside of using a 2000 byte MTU as the minimum MTU in your core? --- Michael Dillon Phone: +44 (20) 7769 8489 Mobile: +44 (79) 7099 2658 Director of Product Engineering, GTS IP Services 151 Shaftesbury Ave. London WC2H 8AL UK
Which is one of the reasons that we specified 1600 as the frame size for most line disciplines, such as PPP over Frame Relay, etc., since circa 1992.... PPP itself is 1500, matching ethernet, in the vain hope that folks would remember to distinguish "packet" data size from "frame" size. Also, I'd like to note that jumbograms render the TCP checksum nearly useless. It's only an effective 7 bits of strength, which one might describe as "minimally" useful. michael.dillon@gtsip.net wrote:
When 1500 byte frames from the customer's LAN enter the customer's
router and enter some form of IP tunnel, then a core fabric which supports larger than 1500 byte frames will not cause fragmentation. It's not necessary to do the full jumbo size frames. I suspect that supporting two levels of encapsulation will be enough in 99.9% of the cases. For the sake of argument, what would be the downside of using a 2000 byte MTU as the minimum MTU in your core?
WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
> Which is one of the reasons that we specified 1600 as the frame size > for most line disciplines, such as PPP over Frame Relay, etc., since > circa 1992.... > PPP itself is 1500, matching ethernet, in the vain hope that folks > would remember to distinguish "packet" data size from "frame" size. This problem is also one that plagues DSL, as many DSLAMs expect to see a full Ethernet packet, including Ethernet header, inside the frame/atm packet that comes in from the network. They strip the frame/atm header, and dump the contents onto the DSL/Ethernet wire. If you're using frame relay on the backhaul, a max-length Ethernet packet with both Ethernet and frame relay headers will obviously exceed the 1500-byte limit, and get truncated. If you pull the Ethernet header out, you need to get the DSLAM to generate a new one on the other side, which many of them verge on not being smart enough to do. -Bill
-----BEGIN PGP SIGNED MESSAGE----- Bill Woodcock wrote:
This problem is also one that plagues DSL, as many DSLAMs expect to see a full Ethernet packet, including Ethernet header, inside the frame/atm packet that comes in from the network. They strip the frame/atm header, and dump the contents onto the DSL/Ethernet wire.
If you're using frame relay on the backhaul, a max-length Ethernet packet with both Ethernet and frame relay headers will obviously exceed the 1500-byte limit, and get truncated. If you pull the Ethernet header out, you need to get the DSLAM to generate a new one on the other side, which many of them verge on not being smart enough to do.
As a small ISP, we've been using Wailan.com boxen, which has both bridging and routing (RIPv2), DHCP and NAT. We turn bridging off, which seemed to fix our problems. However, I've found no documentation on their wire discipline. I'd not thought of using FrameRelay in the backhaul. (You clever fellow!) Instead, I'm trying stringing them together (that is, one of the lines into the DSLAM router is really the upstream to the city POP), putting the DSLAM into one customer site, and then running our own wires from each DSLAM to other customers in the area.... This only works because Wailan allows both 7:7 SDSL and 7:1 ADSL in the same box, and the DSLAM seems to be a special purpose self-contained router. Can you believe that BellSouth wants $2000 for installation and $91 per month to setup an unloaded alarm circuit? -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1 iQCVAwUBOU7Hmdm/qMj6R+sxAQHNWAP/dLWY3hcXXfY7w4+9gZYVXvXsqvlosK37 ns+7Jj0NOX/otoldVL1b5y6ATlM4ch99gfJMXA9VrIUt3PNaO/LLtfXmERzdNrMt pfBny/1GQqhUbptMtOr8qb6P7c/udgiMC9XQ6wGCZHOx6eMNye8eP9HC9xtMsNo0 YWsKJ0ddFc4= =nS3J -----END PGP SIGNATURE-----
Also sprach William Allen Simpson
Can you believe that BellSouth wants $2000 for installation and $91 per month to setup an unloaded alarm circuit?
Yes, see case number 99-484 (may also be shown as 1999-484) with the Kentucky Public Services Commission. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
participants (4)
-
Bill Woodcock -
Jeff Mcadams -
michael.dillon＠gtsip.net -
William Allen Simpson