Difference between revisions of "EJFAT UDP General Information"
Jump to navigation
Jump to search
Line 11: | Line 11: | ||
* The NICs on the ejfat nodes support an MTU up to 9978 bytes, as do the connected switches | * The NICs on the ejfat nodes support an MTU up to 9978 bytes, as do the connected switches | ||
+ | |||
+ | [[File:BackEnd1.jpg]] | ||
+ | |||
+ | [[File:BackEnd2.jpg]] | ||
+ | |||
+ | [[File:BackEnd3.jpg]] | ||
+ | |||
</font> | </font> |
Revision as of 19:48, 10 January 2024
IP Fragmentation
- See UDP and IP Fragmentation and Wikipedia IP Fragmentation. The basic low-down is that IP fragmentation of UDP packets should be avoided at all costs since it will slow things down, increase the amount of data sent, but most importantly in our case, fragmented packets will most likely be dropped. Look at the following section from the second link:
In IPv4, hosts must make a best-effort attempt to reassemble fragmented IP packets with a total reassembled size of up to 576 bytes. They may also attempt to reassemble fragmented IP packets larger than 576 bytes, but they are also permitted to silently discard such larger packets. Applications are recommended to refrain from sending packets larger than 576 bytes unless they have prior knowledge that the remote host is capable of accepting or reassembling them.
In IPv6, hosts must make a best-effort attempt to reassemble fragmented packets with a total reassembled size of up to 1500 bytes, larger than IPv6's minimum MTU of 1280 bytes. Fragmented packets with a total reassembled size larger than 1500 bytes may optionally be silently discarded. Applications relying upon IPv6 fragmentation to overcome a path MTU limitation must explicitly fragment the packet at the point of origin; however, they should not attempt to send fragmented packets with a total size larger than 1500 bytes unless they know in advance that the remote host is capable of reassembly.
- Yet another reason to avoid IP fragmentation: unless you know your network can handle jumbo frames, break up your data into chunks of 1400 bytes. This is because you don't want to fragment your packets on high speed networks. On fast networks the 16-bit packet-id can overflow within the reassembly timeframe and - if the checksum matches or is not set - fragments of different packets could be reassembled.
Jumbo Frames
- As far as Jumbo frames go, the use of 9000 bytes as preferred payload size for jumbo frames arose from discussions within the Joint Engineering Team of Internet2 and the U.S. federal government networks. Their recommendation has been adopted by all other national research and education networks. Manufacturers have in turn adopted 9000 bytes as the conventional MTU size, with a total jumbo frame size of between 9014 and 9022 bytes with ethernet headers included. Most Ethernet equipment can support jumbo frames up to 9216 bytes.
- The NICs on the ejfat nodes support an MTU up to 9978 bytes, as do the connected switches