01 Making a link worse
Loss and Reordering
Dropping packets and delivering them out of order produce different failures, and software that survives one often fails the other.
Two failures that look alike and are not
Packet loss and reordering are the two most disruptive conditions a connection can suffer, and they fail software in different ways — which matters when you are trying to find out which one is actually causing a problem.
Loss is the simpler case mechanically. A packet enters a queue, the queue is full, the packet is discarded. From the receiving end, a sequence number goes missing. TCP's congestion control treats that gap as a signal that the network is overloaded: the sender cuts its transmission rate and waits. Van Jacobson's 1988 congestion-avoidance work, developed at Lawrence Berkeley National Laboratory and published through ACM SIGCOMM, built this response directly into the protocol. The loss signal does real work — it is how TCP has prevented the internet from collapsing under its own load for decades.
Reordering is subtler. The packets all arrive, but not in the order they were sent. This happens when traffic crosses multiple paths that have different latencies, or when a shaper emits packets with slight timing variations. TCP treats a gap in sequence numbers as probable loss before it knows whether the missing packet is actually gone or merely late. After three duplicate acknowledgements, it triggers a fast retransmit, cutting its window exactly as it would for a real drop. The cost is a throughput hit the sender imposed on itself for something that did not need fixing.
The interaction between the two is where things get brittle. RFC 4737, published by the IETF, defines how reordering should be measured and reported — the definitions alone run to several pages, which gives a sense of how many distinct failure modes the term covers. A retransmit caused by reordering wastes capacity; if real loss arrives on top of that, the sender is now recovering from two events simultaneously and its congestion window may collapse to near zero.
Applications above TCP see these failures differently. A video player buffering over HTTP may tolerate moderate loss gracefully — the buffer absorbs the retransmit delay — but reordering can confuse adaptive bitrate logic that watches for consistent delivery timing. A modern transport protocol like QUIC handles loss through its own recovery path and treats reordering as a measurement problem rather than a control signal, which makes it more robust to out-of-order delivery than classic TCP.
When you condition a link to reproduce either failure, introducing them independently matters. A shaper that drops packets at a fixed rate and a shaper that reorders packets at a fixed rate are not interchangeable. Software that passes one test and fails the other has told you something specific about where its brittle edge is, which is the whole point of the exercise.
