Timeliness without datagrams using QUIC

Original Article ↗ Hacker News Discussion ↗

Engineers debate when it still makes sense to send raw UDP datagrams versus relying on higher-level protocols like QUIC built on top of UDP. Many argue that for latency‑sensitive use cases—online games, real‑time media, sensor and market data—dropping outdated packets is preferable to TCP‑style reliability, while others note that most real systems end up reinventing reliability, encryption, and congestion control over UDP and would be better served by QUIC or similar. The exchange highlights trade‑offs around timeliness, congestion behavior, platform support, and complexity, with a rough consensus that raw UDP is vital for certain real‑time or broadcast scenarios but a poor default for general application networking.

UDP vs QUIC vs TCP

  • Many comments argue the real choice is not “UDP vs TCP” but “raw datagrams vs something built on them,” with QUIC as a prominent option.
  • QUIC is praised for providing congestion control, reliability, multiplexed streams, and optional unreliability, avoiding the need to reinvent these over UDP.
  • Skeptics say QUIC can add unnecessary complexity for simple, latency-critical workloads where retransmission and congestion control don’t help.

Video games and real-time interactive apps

  • Fast-paced multiplayer games are a major counterexample to “never use UDP.”
  • For games that resend full world state every tick, simple UDP is considered ideal: no retransmission, tiny bandwidth, and ignoring old packets is correct behavior.
  • More complex games that send diffs or inputs need some reliability; people often build custom reliable/unreliable layers on top of UDP, which end up “QUIC-like.”
  • Some point out QUIC can do “cancel on loss” or per-stream priorities, but others argue this still doesn’t match game-specific timing and recovery logic.

Other UDP-friendly use cases

  • Listed UDP uses: local discovery, broadcast/multicast, VPNs/tunnels, high-frequency sensors, HFT/market data, media art protocols (OSC, ArtNet), real-time voice/video.
  • Rationale: timeliness, multicast, simple fire‑and‑forget semantics, and avoiding TCP-over-TCP pathologies.

Reliability, ‘best-effort’, and semantics

  • Debate over calling UDP “unreliable” vs “best-effort.”
  • Consensus: the key distinction is who handles loss/reordering—transport layer (TCP/QUIC) vs application/protocol above UDP.
  • Several note that many UDP systems are effectively reliable because higher layers add acks, sequence numbers, FEC, or retransmission.

Streams vs messages

  • Frustration that TCP is stream-based when most apps think in messages; many reimplement framing on top.
  • Some wish IP had standardized “reliable, message-based” transport; SCTP and QUIC are mentioned as partial answers, but middleboxes and deployment issues limited SCTP.

Congestion and network behavior

  • Concerns: bufferbloat, OS and router buffering, and aggressive TCP congestion backoff on lossy links.
  • Some argue games and certain IoT/LPWAN scenarios assume congestion is unacceptable and design around transient loss instead, making TCP/QUIC behavior a poor fit.