Packet Loss

General definition

Packet Loss is the fraction of packets that leave the sender and never reach the receiver, expressed as a percentage over some interval. The most common cause is congestion: a router or switch whose queue is full has no choice but to discard what arrives next. Wireless links add a second source, since Wi-Fi and mobile radios lose frames to interference, weak signal and hand-offs between access points. Faulty cables, overloaded network cards and mismatched MTU settings account for the rest. Bufferbloat, where oversized queues absorb congestion instead of signalling it, tends to show up as growing latency first and then as bursts of loss when the queue finally overflows.

Loss is measured as a percentage of packets sent, usually alongside round-trip time and jitter. Tools such as ping, mtr and iperf report it for a path; inside a call, RTP receivers report the fraction lost back to the sender in RTCP receiver reports (RFC 3550), and WebRTC exposes the same numbers through the getStats API. As a rule of thumb, below 1% loss is unnoticeable in most applications, 1 to 3% is audible or visible on calls, and above 3 to 5% a call degrades badly unless the application compensates.

• Chat runs over TCP (WebSocket or XMPP), so every lost packet is retransmitted; the message still arrives, but head-of-line blocking pauses the whole connection until it does, which users see as a stalled spinner or a burst of late messages
• Calls run over UDP, so a lost packet is simply gone; WebRTC hides the gap rather than waiting for it
• NACK asks the sender to retransmit a specific packet (RFC 4585) when the round trip is short enough to make it in time
• Forward error correction sends redundant data ahead of time so the receiver can rebuild a lost packet without asking; Opus has in-band FEC and video can use FlexFEC
• Packet loss concealment in the audio decoder fills a missing 20 ms frame with a plausible guess so the listener hears a click at worst; RED (RFC 2198) sends a copy of the previous audio frame with each new one

Sustained loss is also a signal. WebRTC bandwidth estimation treats loss as congestion and lowers the sending bitrate, which is why a call on a bad link turns blurry before it freezes. A media server such as an SFU handles loss on each leg separately: it can request retransmissions from the publisher and answer NACKs from each subscriber out of its own buffer, so one participant on a poor connection does not drag the others down.

In the Ethora ecosystem

Ethora carries chat over XMPP on a WebSocket connection, so a lost packet costs a short delay rather than a lost message: the connection retransmits, the server keeps the message in its archive, and unread counts and last-message state are computed server-side, which means a client that reconnects after a rough patch catches up rather than guessing. Voice and video calls run on WebRTC through an SFU media server, which gives every call the standard WebRTC loss-handling toolkit: NACK retransmission, forward error correction, concealment in the Opus decoder and bandwidth estimation that steps the bitrate down before quality collapses.

On a dedicated or self-hosted deployment you control where the media server runs, and placing it in the same region as your users shortens the round trip that retransmissions depend on. The bundled Grafana and Prometheus monitoring and the load-testing tools let an operations team watch loss and jitter on their own infrastructure instead of inferring them from user complaints. See the voice and video call API page for what the calling stack includes.