Re: [FE] Frame size poll
Pankaj-
Your proposal is out of scope.
It has been said all along that changing the core payload size was a
different project.
This project is ONLY about how much length we should add to the frame to
accommodate (nested?) TAGs around a core payload of 1500 bytes.
Therefore I extract from your discussion that:
The added
header should be 100 bytes, thus (1522 + 100) yielding a 1622 max.
My
comments about reserving a chunk for internal processing are not relevant
from your point of view given that they don't receive mention.
Geoff
At 04:10 PM 9/7/2004 -0700, Pankaj K Jha wrote:
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