Re: Jumbo Frames in 10GbE?

[gwinn@xxxxxxxxxx (Joe Gwinn)]

Brian,

At 3:16 PM 99/6/21, Brian MacLeod wrote:
>Joe,
>
>Some thoughts on the issue:
>
>1)  If Jumbo Frames are a good thing, they should be applied to all forms of
>Ethernet.  Therefore, the HSSG (which is about higher speed links) is not
>the correct place.  The 802.3 Working Group is the correct place.  Assuming
>there was high interest, we could get a Study Group going to look only at
>Jumbo Frames at all Ethernet speeds.

This is kind of like waiting for peace in the Mideast before we can have
peace anywhere.

The reason to start with 10GbE is obvious -- it's the fastest ethernet
around, and it's under development right now.  The other ethernets can
catch up later, if necessary.   Somehow, I doubt that the 10/100 Mbit folk
have much need for larger frames.


>2)  What are Jumbo Frames?  How many bytes of payload?  One manufacturer has
>championed 9,000 bytes.  What is to say that this is the correct number?
>Remember that we have had previous "industry moves" for efficiency (remember
>document scanning systems with 4,096 byte packets?) that have long since bit
>the dust.

Obviously, a matter for discussion.  If we take Jain's work at face value,
then 11,450 bytes is the limit.

With the document scanners, the 4096-byte packets probably died because
ethernet wouldn't handle such large frames, and ethernet is pervasive.
However, I have built systems using FDDI where we very much did use big
packets.


>3)  You are correct that there is a system performance issue.  However, if
>you look at the overall system components (of say a workstation or server),
>the network connection is generally not the least efficient.  Software
>systems usually top the list, with inefficient bus systems and poor system
>integration as number two.  For example, at my last shop, we were able to
>get the same hardware to pass from 240 Mbps to 700 Mbps depending on the
>operating system and driver software used.  Similarly, consider that the
>maximum throughput of a 64-bit 66 MHz PCI bus is over 4 Gbps - have you seen
>a PCI system giving much above 1 Gbps?

No, but nor is PCI the end of bus architectures.  Also, bigger packets are
a help for efficient DMA transfers.  And, router manufacturers use their
own special busses.


>My point here is that we should be tackling the worst inefficiencies first -
>the low hanging fruit.  That is not the network connection.   The HSSG job
>is not to solve the overall systems inefficiency problem but to solve
>inefficiencies that might arise in the network system as we move to 10 Gbps.

It's certainly true that there are many possible sources of inefficiency,
but if we don't fix the packet-size issue here and now, we never will, and
the prophesy will fulfill itself.

People will have no reason to fix the other problems unless the standard
supports high performance for those needing it.  Not all implementations
need be equally fast, but the standard will set the final limit on all
implementations.

Joe Gwinn



>-----Original Message-----
>From: Joe Gwinn <gwinn@xxxxxxxxxx>
>To: Booth, Brad <bbooth@xxxxxxxxxx>
>Cc: HSSG_reflector (E-mail) <stds-802-3-hssg@xxxxxxxx>
>Date: Monday, June 21, 1999 1:35 PM
>Subject: Jumbo Frames in 10GbE?
>
>
>>
>>At 4:24 PM 99/6/17, Booth, Brad wrote:
>>>Just a small point.  One of the objectives that passed with greater than
>>>75% in Coeur d'Alene was to "preserve minimum and maximum FrameSize of
>>>current 802.3 Std."
>>
>>I don't know that the issue is going to stay decided all that long, based
>>on the recent article "Jumbo Frames gather support" (Jeff Caruso, Network
>>World, 14 June 1999, page 6), which states that IETF has published a
>>working document proposing that ethernet frames be made larger than the
>>current 1,500-byte maximum, the basic rationale being to reduce the packet
>>rate and thus load on packet-handling components of the system.  In short,
>>this is a system issue, and cannot really be decided solely at the MAC
>>level.
>>
>>If jumbo frames are to come, 10GbE would be a logical place to start.
>>
>>The issue will ultimately be decided by an IEEE Ballot Group, not a
>>Plenary.  If the market is really going to bigger packets, as this article
>>implies, it will be hard to resist.
>>
>>Joe Gwinn