So its not left for the IP protocol to fragment the packet. But it still could in many cases cause of the size of it.
I think the max packet size should be 508, which will most likely improve reliablity of messages and ensure the message never fragments through the IP but yes be heavier on the CPU...
"IPv4 defines the minimum as 576 bytes, but popular operating systems can cope with very big packets"
"Assuming a best-case size of 1500 octets and a worst-case size of 1280 octets for an IPv6 packet that can be transmitted without fragmentation, this leaves at most 1500 - 40 = 1460 and at least 1280 - 40 = 1240 octets available for expressing a UDP datagram. Given the size of the UDP header, this means a best-case maximum size of (1500 - 40) - 8 = 1452 and a worst-case maximum size of (1280 - 40) - 8 = 1232 octets available for the actual content of a UDP datagram.
As a consequence of the above limits, it can be inferred that it is more efficient to send fewer but larger packets. A single datagram sent with 1000 octets of user data may incur 48 octets of overhead by the underlying protocols. The same 1000 octets of user data sent as 10 separate datagrams may effectively incur 48 * 10 = 480 octets of overhead: Nearly half the size of the data itself! Additionally, sending a datagram will typically imply making a relatively costly call to the operating system. Making one system call is generally faster than making ten calls. Sending packets that are too large, however, will run the risk of fragmentation and/or dropped packets. Unfortunately, there is no way to know the implementation-specific limits of all the hardware that a packet may traverse between the sender and receiver, so the programmer is forced to rely on experimentation, conservative estimates, and/or adaptive application-defined protocols."
(See ref IP fragmentation section https://notes.shichao.io/tcpv1/ch10/) what happens is the IP protocol will fragment the packet. Which means it has more chance of getting lost and never recieved. If any fragment is lost, the entire datagram is lost.
https://github.com/CREDITSCOM/node/blob/8903cf449cfe07bcdcc656cf0e532884acb9990c/net/include/net/packet.hpp#L89
The max packet size = 1024
and
https://github.com/CREDITSCOM/node/blob/8903cf449cfe07bcdcc656cf0e532884acb9990c/net/src/pacmans.cpp
Does the fragmentation manually.
So its not left for the IP protocol to fragment the packet. But it still could in many cases cause of the size of it. I think the max packet size should be 508, which will most likely improve reliablity of messages and ensure the message never fragments through the IP but yes be heavier on the CPU...
https://io7m.com/documents/udp-reliable/ https://blog.cloudflare.com/ip-fragmentation-is-broken/
"IPv4 defines the minimum as 576 bytes, but popular operating systems can cope with very big packets"
"Assuming a best-case size of 1500 octets and a worst-case size of 1280 octets for an IPv6 packet that can be transmitted without fragmentation, this leaves at most 1500 - 40 = 1460 and at least 1280 - 40 = 1240 octets available for expressing a UDP datagram. Given the size of the UDP header, this means a best-case maximum size of (1500 - 40) - 8 = 1452 and a worst-case maximum size of (1280 - 40) - 8 = 1232 octets available for the actual content of a UDP datagram. As a consequence of the above limits, it can be inferred that it is more efficient to send fewer but larger packets. A single datagram sent with 1000 octets of user data may incur 48 octets of overhead by the underlying protocols. The same 1000 octets of user data sent as 10 separate datagrams may effectively incur 48 * 10 = 480 octets of overhead: Nearly half the size of the data itself! Additionally, sending a datagram will typically imply making a relatively costly call to the operating system. Making one system call is generally faster than making ten calls. Sending packets that are too large, however, will run the risk of fragmentation and/or dropped packets. Unfortunately, there is no way to know the implementation-specific limits of all the hardware that a packet may traverse between the sender and receiver, so the programmer is forced to rely on experimentation, conservative estimates, and/or adaptive application-defined protocols."
(See ref IP fragmentation section https://notes.shichao.io/tcpv1/ch10/) what happens is the IP protocol will fragment the packet. Which means it has more chance of getting lost and never recieved. If any fragment is lost, the entire datagram is lost.