best-effort service

Think of dropping a postcard in a mailbox. The postal service will try to deliver it, and usually does — but it makes you no promises: not that it arrives, not when, not in what order relative to your other cards, and not that it is delivered intact. You get its best effort and nothing more. The Internet's basic delivery model is exactly this. Best-effort service means the network tries to forward every packet but guarantees nothing about delivery, timing, ordering, or rate. It does not reserve resources, prioritize, or promise a minimum quality.

Concretely, under best effort a packet is forwarded hop by hop, and at each router it simply joins a first-in-first-out queue for the outgoing link. When a queue overflows because too much traffic arrives, packets are dropped — no apology, no resend by the network itself. Delay varies with how full the queues are (that is jitter), packets can take different paths and arrive out of order, and there is no notion of one flow being more important than another. Any reliability, ordering, or timing the application needs must be built at the end hosts, on top of this plain service — which is exactly what TCP does for reliability and what RTP plus a playout buffer do for real-time timing.

Why it matters: best effort is the default behavior of the entire Internet, and understanding it explains both why the network is so simple, cheap, and scalable and why real-time media takes so much extra work. It is the honest backdrop to this whole field. The big practical conclusion: although QoS architectures like IntServ and DiffServ exist to do better, the public Internet has largely chosen to stay best-effort and instead over-provision — to add enough capacity that congestion is rare — because that is simpler and cheaper to run across thousands of independent networks than coordinating end-to-end guarantees. Best effort is not a flaw to be fixed so much as a deliberate, enormously successful design choice.