[Top] [All Lists]

Re: Proposal for Adjusted DATA Timeout

2008-05-25 09:26:03

John C Klensin wrote:

--On Saturday, May 24, 2008 5:38 PM -0700 ned+ietf-smtp(_at_)mrochek(_dot_)com 
Well, not only do we have an option to increase the client
wait time based on message size
(STATUS_DATA_RECV_PER_BLOCK_TIME), we also have an option to
increase it based on number of recipients
(STATUS_DATA_RECV_PER_ADDR_TIME) and on size*recipient

As for their utility, our experience has been that this is one
of those things that's rarely needed, but when it is needed
you REALLY need it, because without it you have to choose
between crap client performance or large messages being
duplicated. Accordingly, I think writing it down somewhere
makes quite a bit of sense.

I agree. I also think an option to increase based on perceived link performance (e.g., how long TCP ACKs take to arrive if that information were available from the local stack, which, of course, it almost never is) would be worthwhile.

I was just trying to be sure I understood the question.


IMO, I don't think its a TCP or COM I/0 bandwidth issue.

But rather the local receiver system performance issue has become more of a factor today.

Put another way, this DATA Termination Timeout (DTT), whether it is 2, 5 or even the 10 minutes was never really a factor in the past because of the dominant mode of operations - post SMTP mail processing, and the presumption by clients of post SMTP operations where a fast mail drop off, with a quick 250 acknowledgment and QUIT expectation from the client was presumed. DTT was never a big issue here.

No mas.

With more systems doing dynamic DATA processing (i.e, AVS processing, and soon more DKIM hash calculations of large files), the timeout is now directly proportional factor in the maximum email size allowed per receiver (worker thread/spawned process).

So we can equate this to:

  EMS = SPR x (DTT *60)


   DTT -> minimum expected data termination timeout (per min)
   SPR -> system data processing rate (bytes per sec)
   EMS -> email max size (bytes)

SPR will be a system performance factor. COM I/O is not a factor, but might include:

   - CPU speed,
   - Hard drive speeds,
   - LAN/WAN networking speeds,
   - # of worker threads

etc, etc.

All I am saying is that these factors or timing considerations was a lesser big deal before because of the POST SMTP mentality, or rather the client side "presumption" that quick mail drops off is the modus operandi regardless of how big the burden with regard to any file size they might be sending.

With the increasing direction of dynamic SMTP operations, the final DATA termination timeout needs to be re-thought as well as the NO-QUIT-ABORT concept, as this affects the successful mail delivery and scalability of the dynamic SMTP systems.

Of course, we all have allergies towards big changes in SMTP, so I figured the practical thing for now is to highlight the issue and "advise" these clients using just a static 5 minutes is too low for all payload sizes, including large payloads. 10 minutes may not cover all, but I think this might be a practical limit for receivers to use since that has been the long time recommendation - not 5 minutes.

Of course, an ideal approach (with an eye towards some future ESMTP I-D), would be a "Keep Alive" concept that we discussed in the past.



Hector Santos, CTO