Hacker News Reader

Comment by maerF0x0 | Hacker News Reader

btw "fair" is an entirely subjective and unproductive way to describe a system. There's simply properties and priorities. Many of us have learned fair to mean a great variance of things. From per capita equal load, to you get what you pay for, to anything goes just don't hurt anyone. In families we might see this as each child gets the same number of cookies. In capitalism fair is what you negotiate and agree to. The point isn't what is or isn't fair, but that there is no universal "fair".

Should a user be able to jump the queue? What if they're your number one driver of revenue? Or they have a time-sensitive function w/ a deadline? Or if they've produced no load on the system in the past $TIME_UNIT. All of these are not fair, just properties to be designed into a product.

View on HN

Fair queueing is a very old (40 years?) CS / networking paradigm. It's what makes your internet connection feel snappy. It is distinct from order and priority, and is not subjective; there are many forms of it and each has a specific meaning.

There are many other forms of queueing other than fair, so if you're looking for a more specific use case, there may already be an algorithm for it.

https://en.wikipedia.org/wiki/Fair_queuing https://en.wikipedia.org/wiki/Weighted_fair_queueing https://intronetworks.cs.luc.edu/1/html/queuing.html

even in your linked examples Fair queuing boils down to a fairness measure which themselves are defined for certain properties.

https://en.wikipedia.org/wiki/Fairness_measure

Yeah I didn't understand what the author even meant in the article. How is first come first serve not fair?

Fair means that we should be giving users roughly the same capacity, or at least roughly the same chances to be worked on.

In the case of this queue, where each letter represents a user:

[A, Bx10000, C, D, E]

We're being unfair to C, D, and E. Realistically, while working on B's jobs we should have some mechanism to know that latency for C, D, and E are increasing and that we can start assigning them to workers.

Without that, latency for any step function you run is highly variable and impacted by other users. With multi-tenant fairness, latency is purely driven by how well we auto-scale and your own concurrency capacity.

The post here is about multi-tenant fairness in particular, so the intent is that fairness is viewed from a multi-tenant / PaaS lense.

> or at least roughly the same chances to be worked on.

Says who? What if B pays 10000x what ACDE do combined? What if B pays for that capacity?

What if B was silent for the 10000 seconds prior? And is now bursting their load just like ACDE do at other times?

There is no objective fair.

Perhaps the only objectively unfair I could think of is if you paid for a service and it's not rendered, at all, ever. That's probably unfair. But everything else is a grey spectrum in between and depends on the agreed upon properties.

> What if B pays 10000x what ACDE do combined? What if B pays for that capacity?

If B's load is consistently that high compared to the others then presumably the system has enough total capacity that those requests don't impact the latency for everyone else. If B pays for dedicated capacity they should ideally get their own queue.

> What if B was silent for the 10000 seconds prior?

Then B should smooth out their load better.

In this extreme an example, not much is lost for B by prioritizing C, D, E first sometimes anyways.

There might not be one single definition of fairness, but preventing one noisy user from impacting other users is a pretty common way to approach it.

All those shoulds are value statements which are not universal law. They're opinions about what constitutes fair.

The author defined fair in a pretty industry standard way:

> One user should not be able to block another's work.

A multi-tenant architecture implies over committing resources to achieve better economics. Once upon a time, decades ago, when computers were so expense that companies payed for batch processing instead of owning their own, FIFO was acceptable. (And for a tiny part of the market it still is.) But ever since the rise of time-sharing operating systems, users have come to expect short delays for small tasks. If you let one customer monopolize your capacity because they submitted a mountain of work before a second customer submits a handful, you probably won't have the second customer much longer.

Reply on news.ycombinator.com