[xboxnolifes]

Why is that the obvious choice? TCP can recover through retransmission, UDP can not. Sounds just as logical of a choice to prioritize UDP and allow TCP connections to have a slowdown rather than allow UDP connections to have data loss.

[astrobe_]

As I said, application programmers expect and accept that their UDP packets might be lost or duplicated. This is sort of part of the contract. Even datagram integrity is in theory not guaranteed, as the checksum field of UDP is optional.

Sometimes people don't see a point at first in UDP because you eventually have to implement sequence numbers, CRCs, time-outs, retries, etc. that are similar to what TCP does. One can finds the reasons why one wants to do this anyway in [1]. In a nutshell, reliability is often insured by the application layer anyway so you don't need the transport protocol to do extra stuff you have no control over and might even get in the way (see the numerous esoteric ioctl and sysctl settings under Linux).

It is an obvious choice because, as I said again, a router dropping a packet does not necessary triggers a resend, e.g. RTP or syslog (over UDP). In TCP, this is guaranteed. If you are overloaded, you'd rather take the action you can get away with than probably just buy time.

[1] https://web.mit.edu/Saltzer/www/publications/endtoend/endtoe...

[remram]

That some be lost is expected, that all of them be blocked is not.