Does /proc/net/udp count all drops that occur between ethernet plug and my app?

Question

/proc/net/udp on Linux has a "drops" column:

cat /proc/net/udp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops
16151: 00000000:CB53 00000000:0000 07 00000000:00000000 00:00000000 00000000  1000        0 39947169 2 ffff88084c108080 0

If the drops counter is 0 for a certain socket, can I be sure that any drops that occur between the sender of a legitimate UDP packet and the application happened outside of my box, say in some switch or router etc.?

Or could it be that i.e. my NIC driver silently dropped a packet for whatever reason, without affecting the counter?

I know for a fact that on Windows packets may get dropped even though there is still lots of space in the receive buffer, not sure if something similar exists on Linux.

Solution 1

No.

Packets can be lost before they are de-multiplexed into user sockets.

This happens when the kernel is not able to read packets fast enough from the network card for some reason.

Network cards do not count packets lost on a per-port basis... at least not necessarily, and I don't believe anything like that is integrated into per-socket counts in /proc/net/udp.

There's a 2015 document that goes into detail about packet drops, I don't know if you'd find it interesting. https://access.redhat.com/sites/default/files/attachments/20150325_network_performance_tuning.pdf

Solution 2

UDP is by definition a connection-less protocol. By definition, at the system level, the sender cares only about sending, and not acknowledging reception. So into what touches the sender, as long it was able to dispatch the UDP packet, it was successful.

There are no guarantees whatsoever the receiver will receive all those packets, because of possible congestion/errors, or in the order they were sent, because of multiple factors, including multiple path routing, and varying degrees of congestion.

The buffer has also limited sizes, and if the packets overrun the buffer, they will be lost too.

To answer at your answer, dealing with a protocol that is not oriented to the connection, looking at a packet drop conter of 0, at the system level, done only in one side of the connection, either the sender or the receiver, or even at both sides, does not tell the whole picture.

So, whilst the stats reflect dropped packets from buffers, they won't account for all packets lost in transmission.

You may want to look at the number of packets send and received in addition to that, in both sizes.

Going to upper layer, namely at the application level, namely DNS or NTP, for instance, there can be additional controls to get more meaningful stats of the service.

From UDP - Wikipedia

UDP uses a simple connectionless transmission model with a minimum of protocol mechanism. It has no handshaking dialogues, and thus exposes the user's program to any unreliability of the underlying network protocol. There is no guarantee of delivery, ordering, or duplicate protection. UDP provides checksums for data integrity, and port numbers for addressing different functions at the source and destination of the datagram.

Relate thread in stack overflow How to monitor Linux UDP buffer available space?

Comments

[Evgeniy Berezovsky]

I asked specifically about whether the "drops" counter counts every UDP packet dropped inside my machine or if it does not.

[Rui F Ribeiro]

I updated the answer, for me it is evident it cannot by design from the text, account for all packets lost in transmission, my fault.