ジャンボフレーム

イーサネットフレームは、ネットワークを通過するたびに処理する必要がある。ある内容を伝送する場合、小さなフレームに分割して処理するよりも、1つの大きなフレームに入れて処理する方が、割り込みを減らして利用可能なCPU時間を有効に活用できるため、より好ましい[3]。これは、1枚ずつ封筒に入れて郵送するのではなく、複数枚の紙をまとめて1つの封筒に入れて郵送することで、封筒を節約し、仕分けの時間を短縮することに似ている。

ジャンボフレームは、1998年にアルテオン・ウェブシステムズ社が同社のギガビットイーサネットアダプタ"ACEnic"に搭載したことで注目を集めた[4]。その後、他の多くのベンダーもアルテオン社と同じパケットサイズを採用したが、ジャンボフレームはイーサネットの公式規格であるIEEE 802.3には含まれていなかった。

ジャンボフレームは、オーバーヘッドとCPUサイクルを削減する可能性があり[5]、エンド・ツー・エンドのTCPパフォーマンスに良い効果をもたらす[6]。ただし、ジャンボフレームの存在は、特に低帯域幅のリンクにおいて、ネットワークのレイテンシに悪影響を及ぼす可能性がある。エンド・ツー・エンドの接続で使用可能なフレームサイズは、通常、通過経路のリンクの中の最低のフレームサイズによって制限される。トークンリングは4464バイト、FDDI は4352バイト、ATMは9180バイト、IEEE 802.11は7935バイトのMTUのフレームに対応している。IEEE 802.3イーサネット規格では、当初、MTUが1500バイト、総フレームサイズが1518バイト（オプションのIEEE 802.1Q VLAN/QoSタグを含めると1522バイト）に対応することが義務付けられていた。IEEE 802.3asのアップデートでは、複数の共通ヘッダ、トレーラ、カプセル化を引き継いで、最大482バイトのヘッダとトレーラを含むことができる「エンベロープ」という概念が導入され、IEEE 802.3が対応する最大のイーサネットフレームサイズが2000バイトまで拡大された。

ジャンボフレームのペイロードサイズとして9000バイトが推奨されているのは、Internet2と米国連邦政府のネットワークの合同チームでの議論から生まれたものである[7]。この勧告は、アメリカ以外の国の研究・教育ネットワークでも採用されている。ほとんどのイーサネット機器は、9216バイトまでのジャンボフレームに対応している[8]。

IEEE 802.1AB-2009およびIEEE 802.3bc-2009では、標準イーサネットにLLDPディスカバリを追加し、最大フレーム長（TLVサブタイプ4）を設定した[9]。これにより、2オクテットのフィールドによってポート上のフレーム長を検出することができる。IEEE 802.3-2015時点での許容値は、1518（ベーシックフレームのみ）、1522（802.1Qタグ付きフレーム）、2000（マルチタグ付き、エンベロープフレーム）である[10]。

UDPやTCPに含まれる単純な加算式チェックサムは、バス特有のビットエラーを検出するには効果的ではないことがわかっている。単純な合計では、エラーを相殺してしまう傾向があるからである。RFC 3309の採択前に、実際のデータにエラーを注入してシミュレーションを行ったところ、これらのエラーの2%が検出されないことがわかった。イーサネットフレームで使用されている単純なCRC-32エラー検出では、フレームサイズが大きくなるほど、複数のエラーが互いに相殺される可能性が高くなるため、エラーが検出されない可能性が高くなる[注釈 1]。

IETFがジャンボフレームで採用したアプローチの一つは、イーサネットの次の通信プロトコルの層で余分なCRCを実行することで、service data unit(SDU)のデータ完全性の低下を回避するものである。SCTP(RFC 4960)とiSCSI(RFC 7143)では、カスタニョーリCRC多項式を使用している。カスタニョーリ多項式0x1EDC6F41は、ハミング距離HD=6をイーサネットのMTU1個分（16,360ビットのデータワード長まで）を超えて達成し、HD=4をイーサネットのMTUの9倍以上の長さである114,663ビットまで達成している。これにより、イーサネットCRC多項式と比較して、MTUサイズのデータワードで2ビットのエラー検出能力が追加される一方、72kbits以上のデータワードサイズでHD=4の能力が犠牲になることはない[12]。カスタニョーリCRC多項式は、データチャンクを扱うように設計された汎用トランスポートと、SCSIデータを伝送するように設計されたTCPトランスポートの両方に対応しており、ジャンボフレームを使用しているにもかかわらず、エラー検出率が向上しているが、イーサネットのMTUが増加するとエラー検出率が大幅に低下する。

ベンダによって、ヘッダをサイズ設定に含めている場合と含めていない場合とがある。前者の場合は最大フレームサイズ（フレームヘッダを含む、レイヤ2の最大パケットサイズ）となり、後者の場合最大伝送ユニット（フレームヘッダを除くレイヤ3の最大パケットサイズ）となる。そのため、異なるベンダの機器を接続する場合には、設定値に注意する必要がある。

ジャンボフレーム用に設定された機器と、ジャンボフレーム用に設定されていない機器がネットワーク上に混在すると、ネットワークのパフォーマンスに問題が生じる可能性がある[13]。

ジャンボフレームは、次のIPv4上のTCPの例に示すように、プロトコルのオーバーヘッドを削減することで、ホストにおけるイーサネットおよびネットワーク処理の効率を向上させることができる。ホストの処理オーバーヘッドは、ペイロードサイズの比率分だけ減少する可能性がある（以下の例では約6倍改善）。これが重要であるかどうかは、ホスト内でパケットがどのように処理されるかによる。TCPオフロードエンジンを使用しているホストは、CPUでフレームを処理しているホストよりもメリットが少なくなる。

パケット転送速度の関数としてのネットワークデータスループットの相対的なスケーラビリティは、パケットあたりのペイロードサイズに複雑に関係している[16]。一般的に、回線のビットレートが上昇すると、それに比例してパケットのペイロードサイズも上昇し、同等のタイミングパラメータを維持することができる。しかし、そのためには、ネットワーク経路上にある多数の中間リンクを、必要な最大フレームサイズに合わせて拡張する必要がある。

ベビージャイアントフレーム(baby giant frame)またはベビージャンボフレーム(baby jumbo frame)とは、IEEEイーサネット規格で認められているサイズよりもわずかに大きいイーサネットフレームのことである[2]。ベビージャイアントフレームは、例えば、1500バイトの標準的なペイロードを持つイーサネットサービスをIP/MPLS over Ethernetが提供するために必要となる。ほとんどの実装では、非ジャンボユーザフレームをMPLSフレームフォーマットにカプセル化する必要がある。MPLSフレームフォーマットは、EtherType値が0x8847と0x8848の適切なイーサネットフレームフォーマットにカプセル化される[17]。MPLSとイーサネットのヘッダを追加することでオーバーヘッドが増えるため、キャリアイーサネットネットワークでは最大1600バイトのフレームに対応する必要がある[18]。

• ジャンボグラム - IPv6における大きなパケット

• Jumbo Frames – Where to use it?
• Jumbo frames? Yes!, by Selina Lo, Alteon Networks, 2/23/1998 in NetworkWorld
• Pushing up the Internet MTU
• IEEE 802.3as Frame Expansion Task Force
• 32-Bit Cyclic Redundancy Codes for Internet Applications
• Need To Know: Jumbo Frames in Small Networks
• Jumbo frames in Arch Linux wiki