UDP unicast over 802.11n - effect of L2 positive ACK on Linux socket send buffer

Question

Can anone explain how it works when an application sends UDP unicast datagrams over an 802.11 WiFi network? Assume non-blocking UDP socket. For concreteness, assume 802.11n or 802.11ac and a reasonably new Linux kernel (Android Lollipop or Debian stable). Specifically, if the sender NIC does not receive any positive ACK of send MPDUs, will the send() call return -1 and socket send queue in kernel be shown as non-empty with netstat? And the NIC will re-send same MPDUs repeatedly?

If this is not the right place to ask, please point to a good reference or another StackExchange site maybe.

Answer 1

In my understanding. Wifi(layer 2) would NOT care about UDP/TCP protocol, for wifi hardware, it is just a frame,

the cast will act like this.....

frame sending -> no ack -> retry again -> no ack -> retry -> no ack -> retry ...

after a few retry, wifi hardware will drop this frame and send next frame in NIC buffer. wifi driver should NOT always keep this frame, because frame drop or lost is frequently case in wifi.

then we talk about UDP network protocol now, because it's anon-blocking UDP socket, UDP would not care any error, it just continue sending and sending and sending....

Android phone has a feature -- "miracast", it also use UDP as a video streaming protocol and use wifi to transfer data. maybe you can check how does this function work.

Answer 2

Layer-2 (Wi-Fi, in this case) knows nothing about the layer-3 protocol (IP, IPX, etc.) used, much less the layer-4 protocol (TCP, UDP, SPX, etc.) used: Wi-Fi doesn't know about IP, which doesn't know about UDP. The whole point of the network layers is that they are independent of each other. Wi-Fi can carry any layer-3 protocol, which, in turn, can carry any layer-4 protocol, which can carry any upper layer protocols.