Hi Geoff:
I fully agree it's out of scope for frame expansion study group. I was
thinking that since the any new frame size wouldn't interoperate with
the legacy Ethernet boxes anyway, there may not be much point trying to
keep the user data portion to 1500 bytes (MAC devices don't just return
the user data portion to a system or a device driver, they return the
entire L2 frame including tag and other headers, so any increase would
have problems with legacy Ethernet).
We could use this opportunity to address the issue of performance, etc.
and increasing interest in larger frames while we're working on the
frame size expansion. Rather than continuing to have Ethernet limit it
to 1500 while current MAC devices and systems exceed the value in
reality, maybe we can standardize on a larger user data size. This will
avoid a need to be asked for a larger frame size in the future.
I'd appreciate an insight into the reasoning behind keeping the 1500
bytes user data limit.
I do realize that the project is only for the extra header bytes, but
maybe the study group can provide additional recommendations.
=Pankaj
Geoff Thompson wrote:
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
|