UDP fragmentation & max packet size possible in UDPUDP Header size = 8 bytes
Fragmentation is to be handled by the OS level which is in turn visible to the OS which is not in the case of TCP over IP.
The UDP fragmentation is more unreliable, as only the sender can fragment the datagram. The intermediate routers with less MTU cannot fragment the UDP datagram. In case of TCP, intermediate routers or any L3 intelligent devices can fragment the previous fragments and reassemble them properly. UDP the path MTU discovery has to be there so that the sender can fragment the UDP packets with the minimum possible MTU. This has to be considered for UDP over WAN.
Smaller UDP packets are always suggested as the larger we go; greater will be the chances of the loss due to subtle fragmentation.
IPv4 data length = 65535 bytes
Total Length field = 16 bit which gives the size of 65535 including the header itself. (2^16 = 65536 => 65535)
1) Irrespective of the MTU
20 bytes min IP header
8 Bytes min UDP header
Data size will be of 65507 bytes
20 + 8 + 65507 = 65535 bytes
But this is the case if we don’t consider the MTU 1500 bytes.
2) MTU 1500 bytes (standard Ethernet frame)
Most UDP apps uses the size of = 512 bytes user data to prevent further fragmentation.
However the standard size set is 576 bytes minimum datagram actual data =
576 - 20 - 8 = 548 (minimum IP/UDP headers)
So the data has to be <= 548 bytes.
Considering that, 512 bytes of user data in UDP packets
1 UDP over IP packet will be of = 512 + 8 + 20 = 540 bytes
Now 540 x 3 = 1620 bytes this is more than 1500 bytes of MTU (not possible as fragmentation will lead us to problems)
Now according to my calculations,
472 bytes of user data with minimum options of IP header, we have
472 + 8 + 20 = 500 exactly
500 x 3 = 1500 bytes MTU
Hence the respective max out UDP size will be of 472 user data bytes.
This implies that 3 UDP packets in 1 Ethernet frame (full utilization of MTU, no padding required)
More than 472 user data will require padding in MTU and underutilization of the frame.
This is only for complete UDP traffic; scenario may change for mix traffic of TCP/UDP
Smaller packets may also be computed depending upon the need.
Maximum Ethernet frame of MTU 1500 bytes can be 1518 bytes (1500 payload MTU)
So to deliver the 1 Max out packet of 65535 bytes across the LAN, 65535/1500 = 43.xx frames => 44 frames of Ethernet is required comprising of fragmented IP packets.
OOBOOB (out of bound) data is the urgent priority data for TCP stream as per the sources
It’s only flag on the IPv4 packet giving specially handling
It is read inline itself
Generally induced by the application layer protocols, like FTP
UDP Protocols1. NFS
Out of this TFTP is interesting. The communication provided by TFTP is quite simple and with less overhead.
Hit the Wikipedia for the TFTP details
Good source for performance of TCP/UDP-