[Top] [All Lists]

RE: productivity?

2011-08-23 14:19:53

-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Hector 
Sent: Monday, August 22, 2011 2:23 PM
To: SMTP Interest Group
Subject: Re: productivity?

For those interested, if basic laws of operations research, physics,
science and Thermodynamics isn't good enough, then Believe Sendmail!

     The ConnectionCacheTimeout ( K) option specifies the maximum time
     that any cached connection will be permitted to idle. When the idle
     time exceeds this value the connection is closed. *This number should be
     small (under ten minutes) to prevent you from grabbing too many resources
     from other hosts. The default is five minutes.*

But that's the RFC5321 default anyway.  So if you're holding that up as the 
Right Way, it would seem you agree no change is actually required.

An SMTP extension that tells a server how many 
sockets/threads/processes/whatever to allocate seems like a very convenient 
denial-of-service attack to me.  It's the same discussion we had with the SIZE 
extension way back when.  The real use of it would be "no, I can't support that 
many new connections from you right now," although you've already established 
the one you have, so that's just weird.

I agree with Dave that if there's some useful thing we could document out of 
this discussion, we should.  But at the moment I'm having trouble seeing what 
that might be.  It's certainly true that a client that wants to be selfish 
could open any number of connections and hold them open, replacing any the 
server closes, regardless of what we put in any standards track or BCP 
document.  So we're only talking about "law-abiding citizens" here, and I don't 
think MTAs implementing connection caching have any reckless or malicious 
intent behind those designs, but rather are trying to improve the throughput on 
both sides, and probably did some testing of the idea before rolling it out.  
So far the industry as a whole hasn't found it to be a problem (which to me 
means it's possibly even a benefit).

If someone's really keen to do so, some comparisons between running a queue 
with connection caching and running the same queue without connection caching, 
monitoring both the client and the server for total cost, would be a good place 
to start.

And now, if I may borrow from old schoolyard antics:  NOT IT!


<Prev in Thread] Current Thread [Next in Thread>