Wietse Venema:
> Viktor Dukhovni:
> > On Wed, Jun 24, 2020 at 04:43:55PM -0400, Wietse Venema wrote:
> >
> > > For a given transport and destination, if all three classes have
> > > work then round-robin interleaving gives each class gets 1/3 of the
> > > delivery slots, 1/2 if there are only two classes with work, all
> > > slots if there is only one class witth work, and zero if there is
> > > no work.
> > >
> > > If implemented in oqmgr, it's brain-dead round-robin with FIFO.
> > > What could possibly go wrong? :-) Well it does not interleave
> > > deliveries within the same class. But, with single-recipient messages,
> > > that wasn't happening anyway, so we are not making things worse.
> >
> > My instinct is that just "oqmgr" + coarse classes is not quite enough.
> > There can be multiple large messages in one of the larger classes that
> > can take a while to drain to a popular destination. There should
> > still be some sort of preemption after a particular message group
> > has consumed enough resources.
>
> Possible solutions:
>
> a) Within a class and destination, select round-robin by sender
> key, and then deliver that sender's requests in FIFO order. That
> would maximize fairness, while making the data more complex.
One might think that the class is no longer needed, and simply
rely on:
1 - round-robin select transport
2 - round-robin select destination
3 - round-robin select sender key
4 - deliver the first request in that sender's FIFO
But that could be problematic for large senders. Example: 1 large
sender and N small senders. The large sender would get only 1/N of
the delivery slots, whereas with classes, it might still get 1/3.
BTW Postfix can have a similar problem for an inbound mail relay,
where inbound mail for 1 internal domain has to compete against
round-robin selection among N remote domains; the inbound stream
got only 1/N of the delivery slots. The solution was to use distinct
transports for inbound mail (relay) and outbound mail (smtp).
Wietse
> b) Within a class and destination, forget about FIFO order and use
> random selection. That would not increase data struture complexity,
> but the increased tail latency would weaken fairness.
>
> c) Within a class and destination, shuffle the FIFO in a more careful
> manner, or select randomly only from the first N entries in a FIFO.
>
> Ideally, deliveries from different senders always interleave, and
> no sender can hog resources.
>
> Wietse
>
