Jonathan Morton <[email protected]> writes: >> This is why I think that any fix that tries to solve this problem in >> the queueing system should be avoided. It does not solve the real >> problem (overload) and introduces latency. > > Most people, myself included, prefer systems that degrade gracefully > instead of simply failing or rejecting new loads. Systems that exhibit > the latter behaviours tend to be open to DoS attacks, which are > obviously bad. Or users obsessively retry the failed requests until > they succeed, increasing total load for the same goodput and inferior > perceived QoS. Or ignorant application developers try to work around a > perceived-unreliable system by spamming it with connections so that > *their* traffic ends up getting through somehow. > > By designing a system which exhibits engineering elegance where > practical, and graceful degradation otherwise, I try to encourage > others to do the Right Thing by providing suitable incentives in the > system's behaviour. The conventional way (of just throwing up one's > hands when load exceeds capacity) has already been tried, extensively, > and obviously doesn't work. Cake does better.
Except this is not simply a question of "better and more elegant". It is a tradeoff between different concerns, and your solution significantly hurts performance in the common case to accommodate a corner case that quite fundamentally *can't* be solved properly at the queueing level, as Luca points out. -Toke _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
