Mailing List Archive

On Sat, 8 Mar 1997, Mark Delany wrote:

>
> With concurrencyremote tuned to our average outbound needs and capabilities,
> qmail-remote simply melts the other end for two reasons: first they are
> running an MTA that uses a lot more resources per message, second their link
> capacity is an order of magnitude less than ours.

> What a "given destination" is and how it's determined is tricky. If it
> involves MX sorting and such then that's pretty messy and probably a fairly
> major structural change. It might however be determined by a simpler pattern
> match.

how about a slow-start mechanism? a SMTP transfer goes though a number of
states: connect, HELO, MAIL, RCPT, DATA, QUIT, close.
qmail could be attempting to start /remoteconcurrency/ simultaneous
transfers instantly to one machine. By not attempting to connect to a
remote MTA if you're already attempting to connect to the same remote
MTA one might achieve soft-starting. If the remote end can only cope
with n simultaneous connections then n+1 should cause a deferment.

I'll look and see if this is possible as a hack on my machines here and
see what the effect is.

RjL
+----------------------------+
| richard@illuin.demon.co.uk | Aut viam inveniam aut faciam
+----------------------------+

At 04:36 PM 3/7/97 -0600, Jon Kay wrote:
>My messages seem to have caused a great deal of confusion.
>
>I'm talking only about adverse effects of qmail's high
>concurrencyremote setting to the rest of the Internet.

>The phenomenon is called "brownouts,"

That's a cute term to apply to the effect. I think we understand what you're
identifying. Our systems unwittingly create it with a number of other sites
who
are at the receiving end of a mailing list that has many hundreds of
recipients destined for the same MX host.

With concurrencyremote tuned to our average outbound needs and capabilities,
qmail-remote simply melts the other end for two reasons: first they are
running an MTA that uses a lot more resources per message, second their link
capacity is an order of magnitude less than ours.

There is no pleasant solution I know of. The other end are not particularly
interested in maintaining remote lists. The other end say it is our fault as
it's only happened since we changed MTAs and I'm disinclined to have to
reactively create ad hoc serialmail solutions as a hack way of creating
multiple
queues.

Finer control would be one possible way. That is, leave concurrencyremote as
a method of controlling how much total outbound a site will deliver, but
have a
second lever that controls how many deliveries to a "given destination".

What a "given destination" is and how it's determined is tricky. If it
involves MX sorting and such then that's pretty messy and probably a fairly
major structural change. It might however be determined by a simpler pattern
match.

cat >/var/qmail/control/concurrencyqueues <<EOD
*:50
aol.com:30
*imeltdown.too-often.com:3
EOD

Ie, create 3 queues. Last pattern match wins.

The problem with this sort of direction is that it still requires manual
intervention.

A dynamic number of queues that are created and indexed by the pattern match
would be more difficult but less prone to require manual intervention.


cat >/var/qmail/control/queuepatterns <<EOD
*.*:10
EOD

Pattern match on the last two tokens of the destination address and use
those to create queues that have a concurrency of 10. Thus:

fred.someuni.edu creates a queue called someuni.edu with concurrency 10.
harry.someuni.edu goes into the same queue.
john.otheruni.edu creates a second queue with concurrency 10.
aol.com creates a third queue
allofaustralia.com.au creates a forth queue for all of .com.au

All turns into a bit of a monster really doesn't it?

Going down the path of MX sorting for a moment. Do you really want to
control concurrency on a MX basis? Probably most people would want a high
concurrency for AOL even though it has just one MX record.


The general problem is that there is no easy way to determine which
set of destination addresses have a common constraining resource, what that
resource is and how big it is. It also surely varies for different
observation points and over time.

In the general sense, only the receiving end knows its own capabilities and
needs to regulate access accordingly.

What these qmail "brownouts" have done is to change the load profile and
forced
many sites to address this issue for the first time.

This sort of change is nothing new to the Net of course, look what web
browsing has done to us all in terms of resource management.


Regards.

Mark Delany notes:
> Jon Kay (jkay@cs.utexas.edu) states:
> >I'm talking only about adverse effects of qmail's high
> >concurrencyremote setting to the rest of the Internet.
>
>The phenomenon is called "brownouts,"
>
> That's a cute term to apply to the effect. I think we understand what you're
> identifying. Our systems unwittingly create it with a number of other sites
> who are at the receiving end of a mailing list that has many hundreds of
> recipients destined for the same MX host.

I was thinking about Internet links, but you're right - the problem
also crops up with receivers. Sites with high-performance mail
servers will melt sites that use old machines as servers.

And you're right. This one is tougher to solve. I'm not sure enough
about qmail retry interactions, but my earlier suggestion of only
spawning off temporarily unreachable guys might well leave them in for
a blasting upon recovery.

> What these qmail "brownouts" have done is to change the load profile and
> forced many sites to address this issue for the first time.
>
> This sort of change is nothing new to the Net of course, look what web
> browsing has done to us all in terms of resource management.

:-( ...yeah....

Jon

On Mon, 17 Mar 1997, Jon Kay wrote:

> Mark Delany notes:
> > Jon Kay (jkay@cs.utexas.edu) states:
> > >I'm talking only about adverse effects of qmail's high
> > >concurrencyremote setting to the rest of the Internet.
> >
> >The phenomenon is called "brownouts,"
> >
> > That's a cute term to apply to the effect. I think we understand what you're
> > identifying. Our systems unwittingly create it with a number of other sites
> > who are at the receiving end of a mailing list that has many hundreds of
> > recipients destined for the same MX host.
>
> I was thinking about Internet links, but you're right - the problem
> also crops up with receivers. Sites with high-performance mail
> servers will melt sites that use old machines as servers.
>
> And you're right. This one is tougher to solve. I'm not sure enough
> about qmail retry interactions, but my earlier suggestion of only
> spawning off temporarily unreachable guys might well leave them in for
> a blasting upon recovery.
>
> > What these qmail "brownouts" have done is to change the load profile and
> > forced many sites to address this issue for the first time.
> >
> > This sort of change is nothing new to the Net of course, look what web
> > browsing has done to us all in terms of resource management.

I'm not sure what all the fuss is about Qmail bandwidth useage. A few
weeks after installing Qmail, I had the unpleasant experience of one of my
users being mailbombed. It was coming from a shell account on a Frac-T3
connected ISP, and it still only used about a 3rd of my T1 for the
duration of the attack. The sending server was only an SS2, as is my
server, so my guess is that's as fast as the CPUs could churn.

That doesn't strike me as unreasonable, but perhaps I misunderstand what
the problem is supposed to be.

James Smallacombe Internet Access for Bucks County
james@pil.net And Philadelphia, PA.
PlantageNet Internet Ltd. http://www.pil.net
"I'll plant Plantagenet, root him up who dares." 3Henry Vi, I,i