Jumbo frame
# Jumbo frame

Nelle reti di computer, i jumbo frame sono frame Ethernet con più di 1500 byte di payload, il limite fissato dallo standard IEEE 802.3. Comunemente, i jumbo frame possono trasportare fino a 9000 byte di payload, ma esistono varianti più piccole e occorre prestare attenzione nell'usare il termine in questi casi. Molti switch Gigabit Ethernet e schede di rete Gigabit supportano i jumbo frame. Alcuni switch Fast Ethernet e schede di rete Fast Ethernet possono supportare i jumbo frame.

## Introduzione

Ogni frame Ethernet deve essere elaborato mentre passa attraverso gli apparati di rete. L'elaborazione del contenuto di un singolo frame di grandi dimensioni è preferibile all'elaborazione dello stesso contenuto suddiviso in frame più piccoli, poiché ciò consente di utilizzare meglio il tempo di CPU disponibile riducendo gli interrupt. Ciò minimizza anche l'overhead e riduce il numero di frame che devono essere elaborati. Questo è analogo a spedire fisicamente un pacchetto di fogli invece di diverse buste singole con un foglio ciascuna, risparmiando buste e riducendo i tempi di smistamento.

I jumbo frame hanno inizialmente acquisito importanza nel 1998, quando Alteon WebSystems li ha introdotti nelle proprie schede di rete ACEnic Gigabit Ethernet. Anche molti altri fornitori hanno fatto altrettanto; tuttavia, i jumbo frame non fanno parte dello standard Ethernet IEEE 802.3 ufficialmente.

## Uso

L'uso dei jumbo frame riducono l'overhead e il carico della CPU e hanno un effetto migliorativo sulle prestazioni TCP. La presenza di jumbo frame può avere un effetto negativo sulla latenza di rete, in particolare sui collegamenti a larghezza di banda ridotta.

La dimensione del frame utilizzata da una connessione end-to-end è generalmente limitata dalla dimensione più bassa del frame nei collegamenti intermedi. Token Ring 802.5 può supportare frame con MTU pari a 4464 byte, FDDI pari a 4352 byte, ATM di 9180 byte e 802.11 può trasportare MTU di 2304 bytes (MSDU maximun size) -MAC Header e Encryption Header esclusi- ( In caso di frame aggregation (A-MSDU) l'MTU può arrivare sino a 7935 byte)..

Lo standard Ethernet IEEE 802.3 originariamente imponeva la dimensione per frame MTU da 1500 byte, dimensioni frame totali 1518 byte (1522 byte se con tag VLAN / QoS IEEE 802.1Q). L'aggiornamento IEEE 802.3as ha integrato le dimensioni delle intestazioni, trailer e incapsulamenti comuni arrivando quindi fino a 482 byte di intestazione e trailer e il frame Ethernet supportato da IEEE 802.3 più grande è diventato 2000 byte. L'utilizzo di 9000 byte come dimensione del payload preferito per i jumbo frame è nato da discussioni all'interno del Joint Engineering Team di Internet2 e dalle rete del governo federale degli Stati Uniti. La loro raccomandazione è stata adottata da tutti gli altri enti nazionali di ricerca e istruzione. Per soddisfare questo criterio obbligatorio di acquisto, i produttori hanno adottato a loro volta 9000 byte come dimensione MTU convenzionale, con una dimensione del frame jumbo di almeno 9018/9022 byte (senza o con IEEE 802.1Q). La maggior parte delle apparecchiature Ethernet può supportare jumbo frame fino a 9216 byte.

IEEE 802.1AB -2009 e IEEE 802.3bc -2009 hanno aggiunto, nel protocollo LLDP per Ethernet, la lunghezza massima del frame (sottotipo TLV 4). Consente il rilevamento della lunghezza del frame su una porta tramite un campo a due byte. A partire da IEEE 802.3-2015, i valori consentiti sono 1518 (solo frame di base), 1522 (frame con tag 802.1Q) e 2000 (frame multi-tagged, incapsulamento).

## Rilevamento degli errori

Semplici checksum aggiuntivi contenuti nei protocolli di trasporto UDP e TCP si sono dimostrati inefficaci nel rilevare errori di bit specifici del bus perché con semplici somme, questi errori tendono a compensarsi. Prima dell'adozione [rfc:3309 dell'RFC 3309], i test di simulazione con inserimento di errori, rispetto a dati reali, mostravano che fino al 2% di questi errori non veniva rilevato.

I frame più grandi hanno maggiori probabilità di subire errori non rilevati con il semplice rilevamento degli errori CRC32, utilizzato nei frame Ethernet: all'aumentare della dimensione del pacchetto diventa più probabile che più errori si annullino a vicenda.

Un approccio IETF per l'adozione dei jumbo frame evita la riduzione dell'integrità della service data unit eseguendo un CRC aggiuntivo al livello del protocollo di rete successivo ad Ethernet. Il trasporto SCTP (Stream Control Transmission Protocol [rfc:4960) (RFC 4960]) e iSCSI (RFC 7143) utilizzano il polinomio Castagnoli CRC. Il polinomio di Castagnoli 0x1EDC6F41 raggiunge la distanza di Hamming HD = 6 oltre una MTU Ethernet (fino a una lunghezza di 16.360 bit) e HD = da 4 a 114.663 bit, che è più di 9 volte la lunghezza di una MTU Ethernet. Ciò fornisce due bit aggiuntivi di capacità di rilevamento degli errori su blocchi di dimensioni MTU rispetto al polinomio standard Ethernet CRC senza sacrificare la capacità HD = 4 per le dimensioni dati fino e oltre 72 kbit. Il supporto del polinomio Castagnoli CRC all'interno di un trasporto generico è stato progettato per gestire blocchi di dati e all'interno di un trasporto TCP per trasportare dati SCSI, entrambi forniscono migliori tassi di rilevamento degli errori nonostante l'uso di jumbo frame dove un aumento della MTU Ethernet avrebbe altrimenti ha determinato una significativa riduzione del rilevamento degli errori.

## Configurazione

Alcuni costruttori, non tutti, permettono l'impostazione della dimensione delle intestazioni, la dimensione massima del frame (comprese le intestazioni dei frame, la dimensione massima del pacchetto layer 2) o l'unità di trasmissione massima (dimensione massima del pacchetto layer 3 escluse le intestazioni dei frame). Pertanto, potrebbe essere necessario configurare valori diversi in apparecchiature di fornitori diversi per far corrispondere le impostazioni.

Combinare dispositivi configurati con jumbo frame e dispositivi non configurati con jumbo frame su una rete può causare problemi di prestazioni di rete.

## Efficienza di banda

I jumbo frame possono aumentare l'efficienza delle reti Ethernet e negli host riducendo l'overhead di protocollo, come mostrato nell'esempio seguente con TCP su IPv4. Il overhead di elaborazione degli host può potenzialmente diminuire in base al rapporto tra le dimensioni del carico utile (circa sei volte il miglioramento nell'esempio). Questo può essere significativo ma dipende da come i pacchetti vengono elaborati nell'host. Gli host che utilizzano la gestione del protocollo TCP a livello scheda di rete avranno meno vantaggi rispetto agli host che elaborano i frame con la CPU.

Efficienza della larghezza di banda a livello di frame :

| Tipo di frame | MTU | Overhead a livello 1 | Overhead a livello 1 | Overhead a livello 2 | Overhead a livello 2 | Overhead a livello 3 | Overhead a livello 4 | Dimensioni PDU | Totale trasmesso [alfa 1 superiore] | Efficienza [alfa 2 superiore] |
| - | - | - | - | - | - | - | - | - | - | - |
| Standard | 1500 | preambolo 8 byte | IPG 12 byte | intestazione frame 14 byte | FCS 4 byte | Intestazione IPv4 20 byte | Intestazione TCP 20 byte | 1460 byte | 1538 byte | 94,93% |
| Jumbo | 9000 | preambolo 8 byte | IPG 12 byte | intestazione frame 14 byte | FCS 4 byte | Intestazione IPv4 20 byte | Intestazione TCP 20 byte | 8960 byte | 9038 byte | 99,14% |
| Altre dimensioni del frame per riferimento |||||||||||
| IEEE 802.11 | 7935 | Preambolo e intestazione PLCP 24 byte | IPG variabile | frame header e ovhd di sicurezza 52 byte | FCS 4 byte | Intestazione IPv4 20 byte | Intestazione TCP 20 byte | 7895 byte | 8015 + IPG size byte | <98,5% |
| IEEE 802.11 con bridge su Ethernet | 1500 | Preambolo e intestazione PLCP 24 byte | IPG variabile | frame header e ovhd di sicurezza 52 byte | FCS 4 byte | Intestazione IPv4 20 byte | Intestazione TCP 20 byte | 1460 byte | 1580 + IPG size byte | <92,4% |

La scalabilità relativa del throughput dei dati di rete in funzione delle velocità di trasferimento dei pacchetti è correlata in modo complesso alla dimensione del payload del pacchetto. Generalmente, all'aumentare della velocità di trasmissione della linea, la dimensione del payload del pacchetto dovrebbe aumentare in proporzione diretta per mantenere parametri di temporizzazione equivalenti. Ciò tuttavia implica il ridimensionamento di numerosi circuiti logici intermedi lungo il percorso di rete per adattarsi alla dimensione massima richiesta del frame.

## Baby jumbo frame

I baby jumbo frame sono frame Ethernet che sono solo leggermente più grandi di quanto consentito dagli standard Ethernet IEEE. I baby jumbo frame sono, ad esempio, necessari per l'implementazione di IP / MPLS su Ethernet mantenendo i servizi Ethernet con payload standard di 1500 byte. La maggior parte delle implementazioni richiederà che i frame utente non jumbo siano incapsulati nel formato di frame MPLS che a sua volta può essere incapsulato in un formato di frame Ethernet appropriato, con valori EtherType di 0x8847 e 0x8848. Il maggiore overhead di header MPLS ed Ethernet aggiuntivi significa che il supporto per frame fino a 1600 byte è richiesto nelle reti Carrier Ethernet.

## Super jumbo frame

I super jumbo frame (SJF) sono frame con una dimensione del payload superiore a 9000 byte. Come è stato lungo e difficile il processo di adeguamento della dimensione MTU delle reti nazionali di ricerca e istruzione ad alte prestazioni da 1500 byte a 9000 byte circa, è ancora allo studio un ulteriore aumento possibilmente a 64.000 byte. Il fattore principale coinvolto con un aumento della dimensione massima del segmento (MSS) è un aumento della dimensione del buffer di memoria disponibile in ogni apparato di rete intermedio lungo il percorso.

## Approccio alternativo

La gestione in scheda di rete di frame di grandi dimensioni in invio e ricezione di grandi dimensioni, libera il carico della CPU rendendolo indipendente dalle dimensioni del frame. È un modo per eliminare l'overhead per pacchetto che ha portato a progettare i jumbo frame. I jumbo frame sono ancora utili dal punto di vista della larghezza di banda, poiché riducono la quantità di larghezza di banda utilizzata riducendo l'overhead di protocollo.

