Before the fog lifts, the harbor is at its quietest.

The accountant at Pier Seven is named Tang. Two ledgers lie open in front of her. One counts the quay: ten zhang, not one inch more. One counts the cranes: ten hours, and after midday nothing can be borrowed.

Boats queue outside the mouth before dawn.

A fishing boat is thin. It needs one zhang of quay. It has hands and nets of its own, and asks the crane for a quarter of an hour — the boatman would rather carry the catch himself.

A stone barge is heavy. Two zhang of quay. One hour of crane: the stone goes up, and then it does not move.

The iron-hulled freighter is the biggest. Three zhang of quay, six hours of crane. One unloading takes it a whole day.

Tang’s difficulty is not arithmetic. It is that the word “fair” has no single spelling.

At first she took boats in arrival order. Three days later there was nothing left on the water but freighters. The fishing boats had come early, but arriving early bought them no quay; the freighters held the quay two days running, and the fishing boats stopped coming.

Then she gave every boat an equal slot. Eleven boats, each allowed one eleventh of everything. That was worse. The freighter’s eleventh was too little quay to berth, so it sat empty. The fishing boat’s eleventh was more crane than it could use, so that sat empty too. The harbor loaded half its cargo while looking as if it had loaded a third.

— —

On the coldest night of that winter, Tang laid the two ledgers on top of each other, and saw something she had not seen before.

Every boat, it turned out, carried one tightest number.

Fishing boat: one zhang of quay, one part in ten. A quarter hour of crane, one part in thirty. Its tightest number is quay — one part.

Stone barge: two zhang of quay, two parts in ten. One hour of crane, one part in ten. Its tightest number is also quay — two parts.

Freighter: three zhang of quay, three parts in ten. Six hours of crane, six parts in ten. Its tightest number is the crane — six parts.

Tang rewrote the rule in one sentence: whoever’s tightest number is smallest berths first; when they are done, write what they used back into their own ledger, and look again from the top.

She read it out the next morning. The fishing boat spent one part and went in first. The stone barge, two parts, followed. The freighter, carrying six parts, could only wait at the back and watch the small boats unload one after another. By the time it finally berthed it had taken three parts of quay and six parts of crane — and that day both ledgers closed full. Not an inch of quay left. Not an hour of crane.

That was not the best part.

The best part was the captain who thought he was clever. He believed that if he declared one zhang more quay than he needed, he would be given one zhang more. Tang did the arithmetic from his own ledger: his tightest number rose first, so he queued further back, and he still paid for the zhang he had declared. He came back the second time and declared it exactly.

Then there was envy. The old master of the stone barge objected at first — by what right does the freighter take three zhang at once? He worked the two ledgers for a long while, then pushed them back and said: if I took its place, I would land less stone than I do now. He said nothing more.

By now you’ve probably recognized it: this is Dominant Resource Fairness (DRF).

What it is

Dominant Resource Fairness is a definition of fairness in multi-resource schedulers, together with an algorithm that achieves it. It comes from the 2011 Mesos paper (Ghodsi et al.).

A machine or a cluster never offers only one kind of resource: CPU, memory, GPU, bandwidth, ephemeral storage. Different workloads consume different resources. An inference service saturates the GPU and barely touches the CPU. An in-memory database saturates memory and barely touches the CPU. A compile job wants both. If you allocate by slot — one fixed-size box per task — then every allocation wastes the half of the box the task does not need.

DRF works like this. For each user or queue, compute the fraction it holds of every resource the cluster offers. The largest of those fractions is that user’s dominant share, and the resource behind it is its dominant resource. The scheduler always gives the next allocation to the user with the smallest dominant share.

The paper proves that this single rule satisfies four properties at once:

• Sharing incentive: no user prefers to leave and take a private slice, because inside the shared pool it receives at least 1/n of its own dominant resource.
• Strategy-proofness: overstating demand only raises your own dominant share, pushes you back in the queue, and still charges you for what you declared.
• Envy-freeness: no user wants to swap places with another user.
• Pareto efficiency: no change improves one user without hurting another.

It is also work-conserving: as long as some task fits, the machine does not idle. For large indivisible tasks the paper adds progressive filling; H-DRF carries the same ledger into hierarchical queues.

Why it matters

Single-resource fairness is easy. Multi-resource fairness is a definition problem before it is an algorithm. You have to answer “what does fair mean” before you can implement anything. Half of DRF’s value is the algorithm; the other half is those four properties, which turn a vague word into a claim someone can argue with.

You already run on this. Mesos resource allocation, YARN’s Capacity Scheduler and Fair Scheduler in their multi-resource forms, Kubernetes extended resources quotas and the NodeResourcesFit scoring in kube-scheduler, and most gang scheduling and warehouse queue managers are DRF’s ledger wearing different clothes. In any cluster one specific resource always runs out first; DRF tells you which needle to watch.

It also explains why “equal shares” is often the worst allocation. Equal shares measure fairness along one resource and idle the rest. DRF measures fairness along the tightest one, which drives waste toward zero.

And it draws its own boundary. DRF handles steady-state fairness over divisible resources. It does not handle preemption by priority, placement constraints from affinity or topology, or the burstiness of real traffic. A production scheduler layers DRF’s ledger underneath all of those rules.

Metaphor mapping

• The harbor → a cluster or a single machine
• Ten zhang of quay, ten hours of crane → two divisible resources (CPU, memory, GPU…)
• What one boat asks for → a task’s request vector
• Tang’s two ledgers → the scheduler’s allocation state
• Each boat’s tightest number → its dominant share; the resource behind it is its dominant resource
• “Smallest tightest number berths first” → DRF’s choice rule
• The freighter bottlenecked on cranes, not quay → different workloads have different bottleneck resources, which is why DRF exists
• Writing usage back into the boat’s own ledger → updating that user’s allocation and looping
• Both ledgers closing full → work-conserving, Pareto-efficient
• The captain who over-declares and queues further back → strategy-proofness
• The barge master doing the arithmetic and falling silent → envy-freeness
• The fishing boat always fitting in → sharing incentive, at least 1/n of the dominant resource
• Arrival order starving the fishing boats → FIFO is unfair across heterogeneous resources
• Equal slots leaving half the harbor empty → the waste of slot-based allocation