What is the size of udp packets if I send 0 payload data in c#?

Question

I have figured out the maximum data before fragmentation between 2 endpoints using udp is 1472(other endpoints may vary). This states that mtu is 1500bytes and header overhead per packet is 28bytes. Is it safe to assume that if I send 0 bytes data (payload), the actual data being transferred is 28bytes? I am doing some benchmark, so it is crucial for me to know, what happens in the channel.

Answer 1

Typical IP headers are 20 bytes, if no options have been selected. UDP headers are 8 bytes. Over Ethernet, frame size is 14 bytes (header) + 4 bytes (trailer). Depending on how you capture these packets, you may or may not have to account for frame size.

Without Ethernet (IP + UDP) = 20 + 8 = 28 bytes
With Ethernet = 18 + 28 = 46 bytes

The UdpClient class in C# will return the packet from layer 5 onwards, so you won't have to account for the above.

Update:
The 1500 bytes MTU is enforced at the IP layer. That means that the packet size below the IP layer is insignificant when fragmenting.

That translates to:
Ethernet frame bytes (fixed) = 18
IP header (min) = 20
UDP header (fixed) = 8
Max. allowed payload for no fragmentation = 1472
Total number of bytes that go on the wire = (Sum above) 1518 bytes
(You can count the number of bytes leaving with a tool like Wireshark)

If (IP header + UDP header + Payload > 1500) then the packet is fragmented.

Answer 2

Is it safe to assume that if i send 0 bytes data(payload), the actual data being transferred is 28bytes

No

(and yes... because it usually makes no real difference, insofar it is "safe")

While it is true that a no-payload-no-option UDP/IPv4 datagram is exactly 28 bytes (or "octets" in network jargon), this is by no means a safe assumption.
It is, however, for the most part inconsequential. Switches and routers usually forward a small packet exactly as fast as a larger one (or, with neglegible difference). The only occasion at which you may see a difference is on your bandwidth bill (you pay for all bits on the wire, not just for the ones that you use!).

IPv4 may have up to 40 octets of "options" attached to it, and IPv4 may be encapsulated in IPv6 (without you knowing, even). Both could drastically increase the datagram's size and thus data transferred in a rather obvious way.

Also, the datagram will be further encapsulated on the link layer, both adding preambles and header data, and having minimum frame lengths. The presence of additional headers is, again, pretty obvious, the fact that besides maximum sizes, payloads also have minimum sizes is a less well-known fact.

Ethernet and ATM are two widely used standards that can get in your way on your assumptions here (but other link layers are similar).

An ethernet frame has a minimum size of 64 bytes, and is zero-padded to this size. In presence of 802.1Q (VLAN) this means that the minimum payload for an ethernet frame is 42 octets, otherwise it is 46 octets.
Sending a zero-length UDP/IPv4 datagram over "ordinary" ethernet will therefore append 18 zero bytes to the payload. You never get to see them, but they are there and they will appear on your bill.

Similarly, ATM cells (same as "frame", they use a different word for some reason) are always 53 bytes, with 48 bytes of zero-padded payload. Thus, a zero-payload UDP diagram will cause 20 zero bytes being added whereas a zero-length UDP/IPv6 datagram would keep its original size (being exactly 48 bytes in size), assuming there is no other encapsulation such as PPPoE in between.

Lastly, do note that additional packets may be needed to be sent and received in order to being able to send your packet at all. For example, your ethernet card may have to do ARP (or NDP) to be able to send your datagram. Caching the results amortizes this as you are sending several datagrams, but if you send just one UPD datagram, you may be surprised that about three times as much "data" is sent and received compared to what you might naively expect.