ARQ is the simplest possible reliability mechanism: number every packet, have the receiver acknowledge receipt or report gaps, retransmit anything the receiver says it missed. The cost per recovery is one round-trip time — the receiver has to notice the gap, send a NACK, the sender has to read the NACK and resend. For streaming this means ARQ-based protocols have a latency floor tied to RTT: a 200-ms RTT path needs at least 200 ms of buffering to recover any single lost packet.
The opposite of ARQ is FEC, which sends redundant data ahead of time so the receiver can reconstruct losses without round-tripping. ARQ is bandwidth-efficient (you only resend what's lost) but latency-sensitive (each recovery costs RTT). FEC is bandwidth-expensive (you always send the redundancy whether you need it or not) but latency-stable (no extra round-trip). Most modern protocols combine the two: a base layer of FEC absorbs short bursts, ARQ recovers anything FEC missed.
SRT and RIST expose ARQ tuning explicitly via the latency window — a 200-ms window means "ARQ will recover anything that can be retransmitted within 200 ms; longer gaps are dropped". The operator picks the window based on path RTT and acceptable loss tolerance. TCP's ARQ is hidden inside the kernel and has no upper latency bound, which is why TCP-based streaming protocols like RTMP behave unpredictably on lossy paths.
