Packet loss happens whenever an IP packet leaves the sender and never reaches the receiver — dropped at a congested router, killed by a noisy radio link, or refused by a misconfigured firewall. For TCP and QUIC, loss is invisible to the application: the transport retransmits and the application sees only a brief latency spike. For UDP-based real-time streams (WebRTC, SRT, RIST) loss is visible and the application must decide what to do.
Streaming protocols have three classic responses. ARQ (automatic repeat request, used by SRT and TCP) asks the sender to resend, costing one RTT per recovery. FEC (forward error correction, used in WebRTC and RIST) sends redundant parity packets so the receiver can reconstruct lost packets without waiting, costing extra bandwidth. And graceful degradation — for video specifically, the encoder generates frames in a way that lets the decoder drop the lost ones and keep going at lower quality.
Loss is rarely uniform. Real networks have bursty loss — a brief Wi-Fi collision drops 5 packets in a row. SRT and similar protocols measure the loss profile and pick a retransmit window appropriate for the longest expected burst. Below 0.5 % loss most streaming protocols work fine. Between 0.5 % and 3 % the choice of FEC vs ARQ starts to matter. Above 3 % you need real engineering — bonded transports (SRT bonding, multi-path QUIC) or to fall back to a lower bitrate that fits in the surviving capacity.
