3 ms·
This is how congestion works: queues are not infinitely deep, so the only way to deal with congestion is to (at some point) start dropping packets. TCP (that i
by colanderman 12y ago
This is how congestion works: queues are not infinitely deep, so the only way to deal with congestion is to (at some point) start dropping packets.
TCP (that is, most TCP flow control algorithms) specifically uses packet loss as an indicator of network congestion / how much bandwidth is available, and will back off and retry dropped packets at a lower rate; hence why TCP continues to function (albeit at degraded performance). UDP has no such mechanism, hence you see firsthand the dropped packets. A well-written application should back off in such a scenario so as not to flood the network, but of course many won't.
(Of course TCP may very well be prioritized over UDP! It's just not necessary to explain your observations.)
- mey 12y agoAlso priority may be a function of the network configuration (QoS etc) not biased against UDP by default.
- tptacek 12y agoIt's often the opposite. In order to prevent the Internet from melting, TCP does an elaborate dance with all the TCP speakers to back off and avoid congesting the network. UDP does no such dance, and so can monopolize traffic at the expense of TCP. Obviously this presumes that the UDP protocol in question has some mechanism for handling lost packets. But, for instance, if you're doing lossy video or forward error correction, end users do not deal directly with lost packets.