Re: [FE] Frame size poll

[Pankaj K Jha <pkj@xxxxxxxxxxx>]

Title:

A need to increase frame size for Ethernet is more than just for adding a few bytes for MPLS, VLAN, tag, or similar fields. If the payload (user file to be transmitted) is 2048 (2K), then the Ethernet header should be 100 bytes (approx. - for L2 header, MPLS/VLAN, L3+, etc.) more than the 2048 bytes  so the file can be transmitted without fragmentation.

A limitation with current  1518 byte frames is that because an operating system file control block size is 4K, the OS needs to fragment the block before sending on Ethernet links. It would be nice to accommodate at least a file control worth of data to improve performance.

Such has been the pressure for going towards efficiency that industry has already gone ahead and supported jumbo frames (9000 bytes) for quite some time now. Even without IEEE standardization of a larger frame size, the industry has long moved beyond the Ethernet maximum of 1518 bytes, and all operating systems (Linux, Windows, etc.) have been supporting jumbo frames for several years. Most Ethernet MAC devices already support jumbo frames.

Following paragraph is taken from a Network World article:
Larger frames mean lower frame rates. In the case of Gigabit Ethernet, wire-speed throughput at 1,518-byte frames means servers face a torrent of more than 80,000 packets - and 80,000 interrupts — per second. That's enough to bring many multiprocessor platforms to their knees. Jumbo frames, in contrast, reduce the rate by more than 80%.

At GbE rates, a 1518 or a 2K byte frame would be transmitted in just about 2 microseconds.

As most MAC device available on the market supports jumbo frames, a frame size of 4K+ wouldn't be a problem for devices to handle. With all operating systems already providing support for large frame size, we should give a minimum of 4K+ bytes frame size. Jumbo support (9000+ bytes) is even better.

I'd also like to second the proposal by Jose Morales to lower the minimum byte size, as many applications routinely send much smaller than 64 byte frames, and padding to make them 64 bytes is inefficient.

=Pankaj

Geoff Thompson wrote:

Kevin-

The belief that I have that I would put forth for testing would point to #3.

The theory behind this is that the number should be some small number of bytes less than 2048 (2^10). That implementations have been built with a 2048 buffer allocation per packet. Further, that included in that allocation is some requirement for tagging inside a switch to indicate (for example) things such as length, source port, destination port, priority, etc.

IF my theory is valid THEN my number would be:
        (2048) minus (MAX reasonable internal processing tag size)

My GUESS at that tag size would be something like 12 bytes which would yield a resultant number of:     2036

The above number is open to negotiation or invalidation. Negotiation would be on the basis of actual implementation experience. I am personally untainted. Invalidation would be that everybody says my theory of implementation is all wet.

(My hope is that, should my theory and number turn out to be correct, our rationale would understood and well accepted and not subject to the sorts of derision directed at ATM for its 53 byte decision.)

Hopefully this will be adequate meat to kick off the discussion.

Best regards,

Geoff

At 12:11 PM 9/2/2004 -0700, Kevin Daines wrote:

Now to the poll. Would you prefer:

1) 1875 (which is based on the repeater calculation)
2) 2048 (a power of 2)
3) some other number (please specify)

Kevin Daines
Chair, 802.3 Frame Expansion Study Group