Talk:Jumbo frame

frame structure and example

• It would be very helpful if a frame structure of jumbo frame is illustrated. —Preceding unsigned comment added by 144.160.226.53 (talk) 22:06, 5 April 2010 (UTC)

 Done ~Kvng (talk) 16:30, 30 November 2021 (UTC)

merge discussion

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I'd suggest that it would make more sense to

• merge the content in Jumbo Frames into Jumbogram
• change Jumbo Frames to be a redirect to Jumbogram
• add Jumbo frames as a redirect also

Both articles are very short at present, and there's more scope for developing Jumbogram into a fully-fledged article than the more specific jumbo frames topic.

Jon Dowland 12:35, 25 October 2006 (UTC)

Why is the term "jumbogram" any better than "jumbo frame"? If anything, "jumbo frame" is in much wider use. Look at the sources in this article, and look at the settings for your NICs and switches, if the options are there. If the option isn't merely listed as "MTU size", I bet it'll be "jumbo frames." I say, if anything, merge "jumbogram" into this article. --UNHchabo 07:27, 20 February 2007 (UTC)

The term jumbogram is more generic: it applies to both Ethernet jumbo frames and to IPv6 jumbograms. If you merge Jumbogram into Jumbo frame, where does the IPv6 jumbogram information belong? I'm removing all the merging tags between Jumbogram and Jumbo frame. Let's stop this sillinness. Jec 06:01, 13 July 2007 (UTC)

The term "jumbogram" refers to IPv6 network layer packets greater than 64KBytes. The term "jumbo frame" refers to link layer frames (usually ethernet) longer than allowed by the link layer's typical specification. These are distinctly different things, which is why we coined two words in the first place. There are good consumer protection reasons to restrict the usage of "jumbo frame" to 9000 bytes (There are 8KByte NICs and switches out there and we don't want to permit claims that these are capable of jumbo frames. We have adopted "large frame" for these inferior products). "Super jumbo frames" are frames well in excess of 9000 bytes, and use of this term is likely to be restricted to 64KByte lengths as happened with the evolution of the word "jumbo frame".

With the terminology cleared up, it should be clear to all that the best exposition is to merge "jumbo frame" and "super jumbo frame" and to leave "IPv6 jumbogram" as a distinct article. Best wishes, Glen Gdt 14:41, 6 September 2007 (UTC)

Recommend not merge Jumbo Frames and Jumbograms

I don't believe the pages for Jumbo Frames and Jumbograms should be merged. They are not at all the same thing. Jumbo frames are an extension of the 802.3 hardware specification and are part of the MAC layer of the protocol stack (I am still looking for the hardware spec for jumbo frames). Jumbo frames are also applicable to both IPv4 and IPv6. The term jumbograms is quite clearly defined as part of the IPv6 layer of the Internet protocol stack.

It is unfortunate that both terms have "jumbo" in them as they are really very separate things. It is true that both Wikipedia pages are quite small, now, but that is because they are missing a lot of information, not because they should be merged. Hrob 01:19, 13 March 2007 (UTC)

How are jumbogram's possible without jumbo frames? Surely to have large payloads, you need the underlying OSI layers to also support the concept. Considering jumbo frames ("frame" being the common reference for layer 2 packets, "(data)gram" being for layer 3 and higher) is a more fundamental concent and requirement, why not have that as the article, with a section about jumbograms being a use of them (eg jumbo frames allowing the use of jumbograms) — Lee Carré 22:42, 7 July 2007 (UTC)

Jumbograms (IPv6 only) are specifically possible at L3 if the data is packaged into multiple L2 ethernet (or other) frames. That is the point, IPv4 technically does not allow this, and the term "jumbo frame" as defined here is the name for the way to package larger-than-allowed IPv4 packets (i.e. >1500 bytes). Jumbo frames and jumbograms are not to be confused with packet MTU, which is a physical-layer limitation (1518 bytes for ethernet). Large MTUs are defined per-vendor, and to use them violates 802.3, so it is very proprietary in implementation (though coincidentally usually compatible). The term "jumbo frame" is occasionally used, especially among non-technical people (i.e. managers), for L2 packets that are >1518 bytes, but that is a colloquialism in my opinion (and apparently in the opinion of whoever wrote the main article). Tdcrone 16:44, 10 July 2007 (UTC)

Hi Tdcrone. I re-wrote the top half of the article. The reason I warned of confusing ethernet jumbo frames with IPv6 jumbograms is that confusing the link and network layers is not useful. IPv6 jumbograms are IPv6 packets greater than 64Kbytes. Expressing this packet length requires the IPv6 Jumbo Payload header, see RFC2675. Those packet sizes require a link layer which can handle frames larger than 64Kbytes, such as SDH. The packets are not "packaged into multiple ... frames" by the network layer. In fact the reverse is true -- IPv4's poor experience with packet fragmentation lead to the removal of packet fragmentation from IPv6. To date there have been no implementations of IPv6 Jumbograms over ethernet.

Perhaps we need to add the following table to the article to help the "managers" you refer to: Standard frame: 0 to 1500 bytes Large frame: 0 to 8999 Jumbo frame: 0 to 9000 Super jumbo frame: 0 to 64Kbytes Complicating this slightly is that switches need to hold a few handfuls of bytes up their sleave to present 9000 bytes to the customer. These bytes are used for VLAN and similar headers. So a jumbo frame switch might actually have a maximum frame size of 9100 bytes. On the ISP edge router, the customer-facing interface will have a MTU of 9000, but the core-facing interface will have a higher MTU to allow for internal MPLS/PPP/IPSec tunnels and the like.

For jumbo frames it is important that exactly 9000 bytes is presented to the customer's host. The TCP MTU plateau is 9000 bytes, presenting a slightly smaller MTU will lead to TCP using the 8KB plateau and roughly 10% more packets being transmitted. Standard frames do not have this issue: the MTU plateau is 1492 bytes and this allows for a few bytes to be stolen, usually by an ADSL modem's PPP. Because of the MTU issues this caused, jumbo frames have taken the opposite approach -- the ISP should provision for any overhead bytes, not the customer.

Feel free to work this information into the article. Regards, Glen 150.101.246.227 11:36, 9 September 2007 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Hamming distance

The Adoption section is confusing because it talks about Hamming distance and assorted checksums in upper layer protocols, without ever mentioning that the Ethernet CRC Hamming distance of 4 applies not just to standard 1500 byte frames, but also to 9k jumbo frames. (The limit for HD=4 is 11453 bytes.) Paul Koning (talk) 20:01, 13 November 2009 (UTC)

Hamming distance is discussed in Jumbo frame#Error detection and a similar number (114,663 bits) is mentioned but is not explained. ~Kvng (talk) 16:30, 30 November 2021 (UTC)

"Baby giant" or "Baby jumbo"?

Is it "Baby giant" or "Baby jumbo"? There is in consistent wording in that section. --Pelago (talk) 14:54, 23 May 2012 (UTC)

Either but I've edited things so that Baby giant is the primary term for the purposes of this article. ~Kvng (talk) 19:50, 16 May 2018 (UTC)

16 KB Jumbo Frames

For what it’s worth, when I was in the process of selecting 10+ GbE PCIe adapters for our FreeBSD servers, I created a small survey of various adapters supported by FreeBSD. It also included the maximum size of jumbo frames supported. So here it is, ordered by maximum frame size:

9000	Chelsio T3
9000	Emulex OneConnect
9000	Myricom Myri10GE (LANai Z8E)
9184	QLogic NetXtreme II (BCM577xx / BCM578xx)
9216	Nvidia Mellanox ConnectX
9216	Solarflare SFC9000
9600	Chelsio T4 / T5 / T6
9600	Neterion X3100
9600	QLogic / Marvell FastLinQ
9706	Intel 10Gb Ethernet 700 series (X*7xx)
16000	LiquidIO II CN23xx (Cavium 23xx)
16114	Intel 10Gb XF / AF (82598EB)
16114	Intel PRO/10GbE (82597EX)

I think it is particularly remarkable that some of the newer adapters go beyond the 9xxx limit and pushed it up to 16xxx. These are NICs that support more than 10 GbE, i.e. 25, 40, 50 or more. Maybe the article could be improved by mentioning this, as it currently gives the impression that 9xxx was the limit, but this is not the case anymore. I’m not a native English speaker, so I’m reluctant to modify the article myself. --Winof (talk) 11:08, 27 August 2020 (UTC)

Since there is no standard, any survey can only capture the current market and is bound to become obsolete. I'm OK with adding your table to the article – maybe in a new section below Super jumbo frames? – but probably it's only usable if it's kept up to date somewhat. Do make sure that you don't mix maximum frame size and maximum payload size as some of those entries seem to indicate. --Zac67 (talk) 13:49, 27 August 2020 (UTC)

I don't think this should be added. It is already a skewed sample (only those supporting FreeBSD are considered), it is clearly WP:OR and we won't be able to keep this up to date.

The article does give the impression that 9000 or so is as high as it goes and that's probably accurate up to Gigabit. What we need is to find a secondary source that discusses jumbos on faster Ethernets. ~Kvng (talk) 13:13, 30 August 2020 (UTC)