Viktor Dukhovni:
> On Tue, May 14, 2013 at 10:37:07AM -0400, Wietse Venema wrote:
>
> > > Hmm, I am afraid that such a small window makes nearly no difference as
> > > far as the delivery agent bottleneck is concerned.
> >
> > It should be OK for fast connections.
> >
> > > > It can be a little smarter than that. It can group SMTP/TCP connection
> > > > requests by nexthop, effectively creating a connection request queue.
> > > >
> > > > If a nexthop is quick, then its connection requests clear the
> > > > connection request queue quickly, so this queue could be given
> > > > favorable scheduling preference. If a nexthop is slow, then this
> > > > really wants a back-channel to the queue manager to provide selective
> > > > scheduler or queue-reader feedback of some kind.
> > >
> > > Isn't that just duplicating the per-destination concurrency window /
> > > dead site detection mechanism which is already in place?
> >
> > Unlike qmgr, prescreen knows that a destination is slow, so it
> > can prioritize connection requests.
>
> How does it know this? Remembering which destinations took a long
> time to connect (typically timed out) in the past?
>
> What is the concurrency for trying to make such connections? It
> should be higher, but there is some risk that the heuristic data
> is stale, and connections are made too fast. Which leads to a slow
> mail building up in the active queue.
>
> What is the resulting output rate for the slow path? Does prescreen
> help this exceed the input rate from the deferred queue?
Among the text in the complete message was mention of feedback from
prescreen based on per-hexthop DNS/TCP/SMTPgreet latency, back to
the (concurrency) scheduler and queue reader.
The scheduler would prevent slow mail from overtaking all delivery
agents, and the queue reader would prevent slow mail from overtaking
the active queue.
Basically, allow slow mail to use up most, but not all, deliveries.
Wietse
