10 ms·
Why use TCP? Video conferencing, VOIP, and other low-latency applications typically don't need guaranteed delivery. With the right error-correction, some packet
by AngryParsley 14y ago
Why use TCP? Video conferencing, VOIP, and other low-latency applications typically don't need guaranteed delivery. With the right error-correction, some packets can be dropped without issue, and an occasional cut-out is more acceptable than constant low throughput. UDP makes a lot more sense in those cases.
UDP has issues of course. Breaking through NAT is tricky, and you have a smaller selection of libraries and tools. Still, that trade-off seems a lot better than trying to get everyone to change their congestion algorithms and adopt new standards.
- obtu 14y agoUDP fills the same (overlarge) buffers before it can be sent over a link; it can be stalled by misbehaving TCP. Since TCP still dominates bandwidth usage, TCP bufferbloat needs to be fixed for UDP to have a chance at low latency. Also, if a UDP application can possibly use a significant share of the bottleneck bandwidth, it will need its own latency feedback to avoid being another cause of bufferbloat. Whatever fills the buffer has no bearing on the outcome in most cases (most buffers are just for ethernet retransmission and routers don't manage them; the exceptions I know are with AQM and QoS).
- wmf 14y agoHe's already assuming that latency-sensitive apps are using UDP (which they are); the problem is that apps that are (properly or improperly) using TCP can easily kill UDP. For example, a single TCP connection can near-instantly queue up 10 packets (15KB), creating >100 ms of latency for any UDP traffic.