ジャンボフレーム
UDPやTCPに含まれる単純な加算式チェックサムは、バス特有のビットエラーを検出するには効果的ではないことがわかっている。単純な合計では、エラーを相殺してしまう傾向があるからである。RFC 3309の採択前に、実際のデータにエラーを注入してシミュレーションを行ったところ、これらのエラーの2%が検出されないことがわかった。イーサネットフレームで使用されている単純なCRC-32エラー検出では、フレームサイズが大きくなるほど、複数のエラーが互いに相殺される可能性が高くなるため、エラーが検出されない可能性が高くなる。
IETFがジャンボフレームで採用したアプローチの一つは、イーサネットの次の通信プロトコルの層で余分なCRCを実行することで、service data unit(英語版)(SDU)のデータ完全性の低下を回避するものである。SCTP(RFC 4960)とiSCSI(RFC 7143)では、カスタニョーリCRC多項式を使用している。
ジャンボフレームは、次のIPv4上のTCPの例に示すように、プロトコルのオーバーヘッド(英語版)を削減することで、ホストにおけるイーサネットおよびネットワーク処理の効率を向上させることができる。ホストの処理オーバーヘッドは、ペイロードサイズの比率分だけ減少する可能性がある(以下の例では約6倍改善)。これが重要であるかどうかは、ホスト内でパケットがどのように処理されるかによる。TCPオフロードエンジン(英語版)を使用しているホストは、CPUでフレームを処理しているホストよりもメリットが少なくなる。
↑ 総送信サイズは、ペイロードサイズと全てのオーバーヘッドサイズの合計。
↑ 効率は、ペイロードサイズを総送信サイズで割ったもの。
パケット転送速度の関数としてのネットワークデータスループットの相対的なスケーラビリティは、パケットあたりのペイロードサイズに複雑に関係している。一般的に、回線のビットレートが上昇すると、それに比例してパケットのペイロードサイズも上昇し、同等のタイミングパラメータを維持することができる。しかし、そのためには、ネットワーク経路上にある多数の中間リンクを、必要な最大フレームサイズに合わせて拡張する必要がある。