Re: Proposal for Adjusted DATA Timeout

John C Klensin wrote:

> --On Saturday, May 24, 2008 5:38 PM -0700 ned+ietf-smtp(_at_)mrochek(_dot_)com 
> wrote:
> > ...
> > 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
> > (STATUS_DATA_RECV_PER_ADDR_PER_BLK_TIME).
> >
> > 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.
>
>     john
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)

where

   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.
Thanks

--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com