Talk:Jumbo frame

From Wikipedia, the free encyclopedia

Contents

[edit] merge discussion

I'd suggest that it would make more sense to

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)

[edit] 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)

[edit] Clean up

I'm cleaning this up, as it is somewhat wrong in places (eg, the ethernet MTU is not 1518 bytes, that is the total ethernet frame size not the ethernet payload size, which IP names the MTU). I've also added how 9000 became the conventional jumbo frame MTU and why IEEE have no interest in a standard jumbo frame size. Please forgive the lack of citations as I do so. Gdt 14:09, 6 July 2007 (UTC)

[edit] TP hubs are little computers with multiple NICs

"When a twisted pair or fiber link segment is used and neither end is connected to a hub, full-duplex" is nonsense. A hub is like a PC with multiple NICs in crossover mode and set to forward packets. Half duplex is required on coax, not with separate receive and transmit twisted pairs. Some older NIC chips were too slow or not enough ram or bad drivers, ran half duplex. Again, the TX/RX wires don't touch, collisions are actually handled in Hub firmware.

Shjacks45 (talk) 17:04, 9 December 2007 (UTC)

[edit] Sorry

posted on wrong page.

I did get a support call for a customer that was trying to use frames larger than supported by his NIC card driver. PCI resources on one of my machines NICs, largest memory setaside is 64K.

Shjacks45 (talk) 17:18, 9 December 2007 (UTC)


[edit] Notes

The format of the jumbo frame is described here. http://rtg.ietf.org/~fenner/ietf/isis/html-archive/2001-06/msg00033.html

The maximum length of traditional frames has to do with the initial ethernet protocol before the 802 standard. From memory the length was added to what was the type field, the maximum length was determined by types that were in use before the standard, the article may be right because it mentions a figure greater than 1500 as the original datagram length. I think in effect the jumbo frame proposal is going back to what was before the 802 standard. I have to dig out old documents to give refs and check all this out.

Ok the reason for the original restriction is given; sorry is sort of given in Ethernet so that is not lost history.

  • DIX it's a type field
  • 802 first draft it's a length field
  • IETF refuse to change they have type 0x600
  • 802 change to length/type with length limited to 0x5FF (1535) for example see page 51 802.3
  • jumbo packets type changed to 0x8870
  • IEEE refuse to change.
  • Industry changes anyway.

http://www.yale.edu/pclt/COMM/ETHER.HTM

The letter rejecting the jumbo draft can be found here http://www.psc.edu/~mathis/MTU/arguments.html

The whole thing is a raging battle and we don't document any of it. http://www.psc.edu/~mathis/MTU/index.html

Charles Esson (talk) 02:24, 11 January 2008 (UTC)

[edit] Ethernet jumbo frames merge proposal

The article Jumbogram contains unrelated Ethernet jumbo frames section which should be merged into this article or deleted. --pabouk (talk) 14:05, 11 January 2008 (UTC)

I agree, it has no place here. --199.46.200.232 (talk) 21:43, 5 February 2008 (UTC)

I've gone ahead and deleted that section (there's nothing to merge -- all content there is already on this article). nneonneo (talk) 23:55, 28 March 2008 (UTC)

[edit] Bibliography

This reference ("The case for jumbo frames") requires you to pay to join the site before you're allowed to read it. Is that permissible for a WP reference? GGFSquallStrife (talk) 06:48, 30 April 2008 (UTC)