The most reliable and efficient udp packet size?

Question

Would sending lots a small packets by UDP take more resources (cpu, compression by zlib, etc...). I read here that sending one big packet of ~65kBYTEs by UDP would probably fail so I'm thought that sending lots of smaller packets would succeed more often, but then comes the computational overhead of using more processing power (or at least thats what I'm assuming). The question is basically this; what is the best scenario for sending the maximum successful packets and keeping computation down to a minimum? Is there a specific size that works most of the time? I'm using Erlang for a server and Enet for the client (written in c++). Using Zlib compression also and I send the same packets to every client (broadcasting is the term I guess).

Smaragd

Answer 1

The maximum size of UDP payload that, most of the time, will not cause ip fragmentation is

MTU size of the host handling the PDU (most of the case it will be 1500) -
size of the IP header (20 bytes) -
size of UDP header (8 bytes)

1500 MTU - 20 IP hdr - 8 UDP hdr  = 1472 bytes

@EJP talked about 534 bytes but I would fix it to 508. This is the number of bytes that FOR SURE will not cause fragmentation, because the minimum MTU size that an host can set is 576 and IP header max size can be 60 bytes (508 = 576 MTU - 60 IP - 8 UDP)

By the way i'd try to go with 1472 bytes because 1500 is a standard-enough value.

Use 1492 instead of 1500 for calculation if you're passing through a PPPoE connection.

Silurian

The minimum IP MTU is 576. It doesn't include Ethernet headers, so that would give 548 actually. – Dmitri

You're right... i fixed the calculation considering also that IP header max size can reach 60 bytes – Silurian

Where does the number 1500 come from? – Marnie

these are the numbers for IPv4 ? – Teddman

Don't we need to account for ETH header? – Ossicle

Answer 2

Would sending lots a small packets by UDP take more resources ?

Yes, it would, definitely! I just did an experiment with a streaming app. The app sends 2000 frames of data each second, precisely timed. The data payload for each frame is 24 bytes. I used UDP with sendto() to send this data to a listener app on another node.

What I found was interesting. This level of activity took my sending CPU to its knees! I went from having about 64% free CPU time, to having about 5%! That was disastrous for my application, so I had to fix that. I decided to experiment with variations.

First, I simply commented out the sendto() call, to see what the packet assembly overhead looked like. About a 1% hit on CPU time. Not bad. OK... must be the sendto() call!

Then, I did a quick fakeout test... I called the sendto() API only once in every 10 iterations, but I padded the data record to 10 times its previous length, to simulate the effect of assembling a collection of smaller records into a larger one, sent less often. The results were quite satisfactory: 7% CPU hit, as compared to 59% previously. It would seem that, at least on my *NIX-like system, the operation of sending a packet is costly just in the overhead of making the call.

Just in case anyone doubts whether the test was working properly, I verified all the results with Wireshark observation of the actual UDP transmissions to confirm all was working as it should.

Conclusion: it uses MUCH less CPU time to send larger packets less often, then the same amount of data in the form of smaller packets sent more frequently. Admittedly, I do not know what happens if UDP starts fragging your overly-large UDP datagram... I mean, I don't know how much CPU overhead this adds. I will try to find out (I'd like to know myself) and update this answer.

Bestiary

I've read that using sento instead of using a connected udp socket can produce some overhead because the kernel temporarily connects the socket during sendto. If you are in a unicast scenario this should not be a problem at all. Didn't tested it by myself though but would be interesting to test your scenario with a connected udp socket. Source: https://mcmap.net/q/152150/-what-is-the-optimal-size-of-a-udp-packet-for-maximum-throughput – Hightension

Answer 3

534 bytes. That is required to be transmitted without fragmentation. It can still be lost altogether of course. The overheads due to retransmission of lost packets and the network overheads themselves are several orders of magnitude more significant than any CPU cost.

Dmitri

I wonder what the direct effect on packet of fragmentation is. In my application, when I go from 508 to 509, it seems that a '\0' is appended at the end of the 2nd packet. I wonder whether it depenmds on my particular implementation or it is a trule? – Overthrust

@mavErick The trailing null comes from, or is incorrectly observed by, your code. UDP doesn't do that. – Dmitri

Answer 4

You're probably using the wrong protocol. UDP is almost always a poor choice for data you care about transmitting. You wind up layering sequencing, retry, and integrity logic atop it, and then you have TCP.

Reglet

"retry"? But I thought that was what tcp about...resending packets to get the job done. I'm doing this for an online game so tcp will most likely be too slow, or thats what everyone else says. – Smaragd

"Everyone" is often wrong. If you're concerned that data might not arrive, you need TCP. – Reglet

Ok then what would be the most efficient tcp packet size considering Nagel, etc.. – Smaragd

For TCP, you don't choose the packet size. You just write bytes into one end of the socket and they come out the other. – Reglet

If on the other hand you don't care whether or not the packets arrive or what order they arrive in (i.e. most streaming data protocols) then UDP is the perfect choice. – Moppet

I used UDP for a view finder in my camera app. UDP is perfect in this case. TCP is unnecessary and slow. How many times you use TCP directly in a real life project? Not many either. HTTP is probably mostly used. – Outstare

@Outstare I've used TCP repeatedly, especially before the net became all-HTTP-all-the-time. And yes, for video where you don't mind a glitch between frames and you're more concerned about frame delay than stream continuity, UDP is perfect. – Reglet

StackOverflow is not a place for editorializing and pontificating. If someone is asking about UDP you should respect they know the difference from TCP and chose UDP for a reason. Thanks. – Rouse