Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!bellcore!ulysses!ucbvax!mcvax.UUCP!dpk
From: dpk@mcvax.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Adaptive SMTP Timeouts
Message-ID: <8605302157.AA21314@sering.uucp>
Date: Sat, 31-May-86 01:29:33 EDT
Article-I.D.: sering.8605302157.AA21314
Posted: Sat May 31 01:29:33 1986
Date-Received: Sat, 31-May-86 15:56:16 EDT
References: <[USC-ISI.ARPA]29-May-86.21:28:26.CERF>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 22
Approved: tcp-ip@sri-nic.arpa

I am aware of DOD operational requirements, as you know.

I also have been responsible for real service at a large mail
host that essentially talked to every Internet host at the time.

My opinions come from this background.  While arbitrary limits
are to be avoided, there are certain cases when a decision which
may help you in a few cases (say a 5 minute response time) can
tie up significant resources at other times when a more reasonable
timeout would be say 30 seconds.  If you can classify hosts or
users in one group or the other fine, you can have different
classes of response times.  But if preclassification is not
possible, you have to be careful you don't create more problem
that solution.  We have had times at BRL when we could not
get rid of the mail as fast as it was coming in until we ran
seven outbound mail processes simultaneously (with what are now
believed to be too short time intervals).  Think about it.  Novel
solutions welcome, but waiting forever is not practical.

-Doug-

PS.  We didn't start out with timeouts, they were added for a reason.