With UDP, you're at the mercy of the application using it. With TCP, you're
merely at the mercy of the operating system.

AQM acts on UDP packets in the same way as TCP packets - in fact it can't
tell them apart. So any application which detects and responds to UDP
packet loss in the same way as TCP does, will back off just the same.

In practice, UDP is used for several different types of application:

- simple request response, such as DNS and NTP, where eliminating TCP's
connection setup overhead is important. In any case, TCP's congestion
control doesn't get a chance to do any good on such s short-lived
connection. Packet loss in this situation is tolerated by retry, with
exponential backoff as an alternative congestion control measure.

- latency sensitive and often isochronous (inelastic) flows like VoIP.
Packet loss may lead to a loss of quality, but there is little the
application can do to reduce its loss except dropping the call completely.

- as a way to implement delay sensitive and pacific congestion control
algorithms, as in uTP.

A flow isolation system, such as that in fq_codel, will often leave UDP
flows alone completely, because they tend not to be the ones using the bulk
of the bandwidth. Conversely, if a single UDP flow was responsible for the
congestion, it would let the other traffic bypass it. This is why fq_codel
is better than just plain codel, if you can get it.

- Jonathan Morton